This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Expect SI_KERNEL si_code for a MIPS software breakpoint trap
- From: Pedro Alves <palves at redhat dot com>
- To: Luis Machado <lgustavo at codesourcery dot com>, "Maciej W. Rozycki" <macro at imgtec dot com>
- Cc: "Maciej W. Rozycki" <macro at linux-mips dot org>, gdb-patches at sourceware dot org, linux-mips at linux-mips dot org
- Date: Tue, 16 Feb 2016 00:57:35 +0000
- Subject: Re: [PATCH] Expect SI_KERNEL si_code for a MIPS software breakpoint trap
- Authentication-results: sourceware.org; auth=none
- References: <1442592647-3051-1-git-send-email-lgustavo at codesourcery dot com> <alpine dot LFD dot 2 dot 20 dot 1509181729100 dot 10647 at eddie dot linux-mips dot org> <56B9F7E6 dot 5010006 at codesourcery dot com> <alpine dot DEB dot 2 dot 00 dot 1602092020150 dot 15885 at tp dot orcam dot me dot uk> <56BB329F dot 3080606 at codesourcery dot com>
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