This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Expect SI_KERNEL si_code for a MIPS software breakpoint trap


Hi Maciej,

I'm finally getting back to this. Sorry for the delay.

On 09/18/2015 01:56 PM, Maciej W. Rozycki wrote:
Hi Luis,

I tracked this down to the lack of a proper definition of what MIPS' kernel
returns in the si_code for a software breakpoint trap.

Though i did not find documentation about this, tests showed that we should
check for SI_KERNEL, just like i386. I've cc-ed Maciej, just to be sure this
is indeed correct.

  Hmm, the MIPS/Linux port does not set any particular code for SIGTRAP,
all such signals will have the SI_KERNEL default, so you may well return
TRUE unconditionally.


That is unfortunate. It would be nice to have a well defined standard of communicating these events from kernels to debuggers. All is not lost though, since that can be improved.

  I'm not convinced however that it is safe to assume all SIGTRAPs come
from breakpoints -- this signal is sent by the kernel for both BREAK and
trap (multiple mnemonics, e.g. TEQ, TGEI, etc.) instructions which may
have been placed throughout code for some reason, for example to serve as
cheap assertion checks.

  Is there a separate check made afterwards like `bpstat_explains_signal'
to validate the source of the signal here?


In my specific example we are dealing with two breakpoint hits by different threads. The first one is reported just fine and the one we have problems with is the queued one that is reported afterwards when we attempt to move the other thread.

We do rely on bpstat_explains_signal when gdbserver/the remote target notifies gdb about a stop. In the case of a queued breakpoint hit, it doesn't even get reported back to gdb and is just ignored by gdbserver if it is recognized as a breakpoint hit.

With the proposed change, even the hardcoded traps will initially be recognized as breakpoints, albeit maybe recognized as permanent breakpoints for some opcodes. It may cause gdbserver to ignore a second hardcoded trap hit, which is not desirable.

  Perhaps we should make it a part of the ABI and teach MIPS/Linux about
the breakpoint encoding used by GDB, which is `BREAK 5' (aka BRK_SSTEPBP
in kernel-speak, a misnomer I'm afraid), and make it set `si_code' to
TRAP_BRKPT, as expected.  This won't fix history of course, but at least
it will make debugging a little bit easier to handle in the future.
Cc-ing `linux-mips' for further input.

This is the best solution in my opinion and will definitely make the debugger's life easier if it can tell the difference between multiple seemingly equivalent SIGTRAP's.

Does this involve handling BRK_SSTEPBP inside arch/mips/kernel/traps.c:do_trap_or_bp?


  I was wondering where these SIGTRAPs come from too BTW, thanks for
investigating it.  And thanks for the heads-up!

You're welcome.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]