On 02/10/2016 12:52 PM, Luis Machado wrote:
> The problem of forcing gdbserver to recognize all traps with
> si_code==SI_KERNEL is that even hardcoded traps will be reported back to
> GDB as a swbreak event, which is not ideal.
That's how swbreak is defined:
@item swbreak
@anchor{swbreak stop reason}
The packet indicates a memory breakpoint instruction was executed,
irrespective of whether it was @value{GDBN} that planted the
breakpoint or the breakpoint is hardcoded in the program.
>
> But currently there is no easy way to tell a software breakpoint hit and
> a hardcoded trap (and maybe even a hardware breakpoint hit?) apart.
Software breakpoint hits or hardcoded traps are handled the same. Even if GDB
plants the breakpoint instruction itself with direct memory pokes (instead of
z0 packets), the target should report "swbreak" stops, so that gdb can do
the right thing.
GDB knows whether to discard the hit as a delayed breakpoint hit event by
checking whether the thread's PC points at an hardcoded trap. If it does,
the event is not discarded, but instead reported to the user as a SIGTRAP.
Hardware breakpoint hits are distinguished from software breakpoint hits,
because they're reported with "hwbreak", not "swbreak":
@item hwbreak
The packet indicates the target stopped for a hardware breakpoint.
The @var{r} part must be left empty.
Thanks,
Pedro Alves
