On 02/23/2016 02:00 AM, Luis Machado wrote:
On 02/22/2016 07:41 PM, Pedro Alves wrote:
On 02/22/2016 10:20 PM, Luis Machado wrote:
diff --git a/gdb/nat/linux-ptrace.h b/gdb/nat/linux-ptrace.h
index ba58717..72b32b1 100644
--- a/gdb/nat/linux-ptrace.h
+++ b/gdb/nat/linux-ptrace.h
@@ -140,11 +140,16 @@ struct buffer;
in SPU code on a Cell/B.E. However, SI_KERNEL is never seen
on a SIGTRAP for any other reason.
+ The MIPS kernel uses the default si_code of SI_KERNEL for software
+ breakpoints, hardware watchpoints and SIGTRAP's in general.
If we get this for both software breakpoints and hardware watchpoints,
then it seems to me that this change still leaves watchpoints broken,
as I can't see how check_stopped_by_watchpoint is reached, in either
gdb/linux-nat.c or gdbserver/linux-low.c.
With or without this specific breakpoint fix, hardware watchpoints are
already broken for MIPS AFAICS.
Yep, hence my "still". ;-)
MIPS' kernel has never set si_code to anything other than SI_KERNEL.
When the change to expect TRAP_HWBKPT was committed, then hardware
watchpoints stopped working properly for MIPS.
Now all hardware watchpoints produce are breakpoint-like traps that get
silently ignored by GDB as "delayed software breakpoint trap". Neither
GDB nor GDBserver can tell when a hardware watchpoint really happened by
using si_code information.
But this seems to be a different issue and i think it should be handle
separately.
I think it's all the same, and that we'll need to change
linux-nat.c:save_sigtrap and the equivalent bits in gdbserver/linux-low.c.
So if we pick the table I added for x86, and fill it in
for MIPS, this is what we get:
| what | si_code |
|------------------------------------------+----------------|
| software breakpoints | SI_KERNEL |
| single-steps | N/A |
| single-stepping a syscall | N/A |
| user sent SIGTRAP | 0 |
| exec SIGTRAP (when no PTRACE_EVENT_EXEC) | doesn't matter |
| hardware breakpoints | N/A |
| hardware watchpoints | SI_KERNEL |