[PATCH, v2] Expect SI_KERNEL or TRAP_BRKPT si_code values for MIPS breakpoint traps

[PATCH, v2] Expect SI_KERNEL or TRAP_BRKPT si_code values for MIPS breakpoint traps

[Luis Machado]

This is v2 of this patch. It was pre-approved by Maciej and i will commit
it soon if there are no objections.

---

While doing some MIPS/Linux tests, i've found a number of threading tests
failing due to spurious SIGTRAP's. Turns out those spurious SIGTRAP's were
actually software breakpoint hits that were supposed to be handled silently by
GDB/GDBserver, returning a swbreak event.

gdb.threads/continue-pending-status.exp is one of the testcases that show this
behavior.

--

Breakpoint 1, main () at gdb.threads/continue-pending-status.c:44^M
44        pthread_barrier_init (&barrier, NULL, NUM_THREADS);^M
(gdb) b continue-pending-status.c:36^M
Breakpoint 2 at 0x400a04: file gdb.threads/continue-pending-status.c, line 36.^M
(gdb) PASS: gdb.threads/continue-pending-status.exp: attempt 0: set break in tight loop
continue^M
Continuing.^M
[New Thread 5850]^M
[New Thread 5851]^M
[Switching to Thread 5850]^M
^M
Breakpoint 2, thread_function (arg=0x0) at gdb.threads/continue-pending-status.c:36^M
36        while (1); /* break here */^M
(gdb) PASS: gdb.threads/continue-pending-status.exp: attempt 0: continue to tight loop
print /x $_thread^M
$1 = 0x2^M
(gdb) PASS: gdb.threads/continue-pending-status.exp: attempt 0: get thread number
thread 3^M
[Switching to thread 3 (Thread 5851)]^M
36        while (1); /* break here */^M
(gdb) PASS: gdb.threads/continue-pending-status.exp: attempt 0: switch to non-event thread
delete breakpoints^M
Delete all breakpoints? (y or n) y^M
(gdb) info breakpoints^M
No breakpoints or watchpoints.^M
(gdb) continue^M
Continuing.^M
^M
Program received signal SIGTRAP, Trace/breakpoint trap.^M

<<<< This SIGTRAP was a pending breakpoint event that wasn't supposed to cause
<<<< a stop, but gdbserver did not figure out this was a breakpoint hit.

PASS: gdb.threads/continue-pending-status.exp: attempt 0: continue for ctrl-c
thread_function (arg=0x0) at gdb.threads/continue-pending-status.c:36^M
36        while (1); /* break here */^M
(gdb) FAIL: gdb.threads/continue-pending-status.exp: attempt 0: caught interrupt

--

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.

Further discussion with MIPS maintainers showed that, historically, MIPS
kernels have never set a proper si_code and thus they use the default value of
SI_KERNEL.

There are plans to update the MIPS kernel to provide more meaningful si_code
values though, so we should expect both SI_KERNEL and TRAP_BRKPT from now
on, as GDB will handle both correctly, like powerpc.

With the following patch i have cleaner results for thread tests on
MIPS/Linux.

Regression-tested on a few MIPS boards.

OK?

gdb/ChangeLog:

2016-02-22  Luis Machado  <lgustavo@codesourcery.com>

  * nat/linux-ptrace.h: Check for both SI_KERNEL and TRAP_BRKPT si_code for
    MIPS.
---
 gdb/nat/linux-ptrace.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/nat/linux-ptrace.h b/gdb/nat/linux-ptrace.h
index ba58717..71b29dd 100644
--- a/gdb/nat/linux-ptrace.h
+++ b/gdb/nat/linux-ptrace.h
@@ -144,7 +144,7 @@ struct buffer;
    instead of TRAP_BRKPT to abstract out these peculiarities.  */
 #if defined __i386__ || defined __x86_64__
 # define GDB_ARCH_IS_TRAP_BRKPT(X) ((X) == SI_KERNEL)
-#elif defined __powerpc__
+#elif defined __powerpc__ || defined __mips__
 # define GDB_ARCH_IS_TRAP_BRKPT(X) ((X) == SI_KERNEL || (X) == TRAP_BRKPT)
 #else
 # define GDB_ARCH_IS_TRAP_BRKPT(X) ((X) == TRAP_BRKPT)
-- 
1.9.1

Re: [PATCH, v2] Expect SI_KERNEL or TRAP_BRKPT si_code values for MIPS breakpoint traps

[Pedro Alves]

On 02/22/2016 12:57 PM, Luis Machado wrote:
> This is v2 of this patch. It was pre-approved by Maciej and i will commit
> it soon if there are no objections.

I'd like to have a short paragraph in linux-nat.h about MIPS's behavior,
below the ppc comment.  If you look at the x86 table above, which cases get
SI_KERNEL, and which don't?  Single-step is not applicable, since the
MIPS doesn't handle single-stepping itself (IIRC), but do we also get
SI_KERNEL hardware bps and watchpoints, for example?

> Further discussion with MIPS maintainers showed that, historically, MIPS
> kernels have never set a proper si_code and thus they use the default value of
> SI_KERNEL.
> 
> There are plans to update the MIPS kernel to provide more meaningful si_code
> values though, so we should expect both SI_KERNEL and TRAP_BRKPT from now
> on, as GDB will handle both correctly, like powerpc.

Thanks,
Pedro Alves

Re: [PATCH, v2] Expect SI_KERNEL or TRAP_BRKPT si_code values for MIPS breakpoint traps

[Maciej W. Rozycki]

On Mon, 22 Feb 2016, Pedro Alves wrote:

> I'd like to have a short paragraph in linux-nat.h about MIPS's behavior,
> below the ppc comment.  If you look at the x86 table above, which cases get
> SI_KERNEL, and which don't?  Single-step is not applicable, since the
> MIPS doesn't handle single-stepping itself (IIRC), but do we also get
> SI_KERNEL hardware bps and watchpoints, for example?

 As I previously noted the MIPS Linux port currently does not support 
hardware breakpoints even though hardware may have them implemented 
(they're optional).  Only hardware watchpoints are supported right now.

 You are right in that there's no OS single-stepping support defined in 
the MIPS architecture and consequently Linux cannot support it on the MIPS 
target.  Only JTAG single-stepping is possible with MIPS hardware.

  Maciej

Re: [PATCH, v2] Expect SI_KERNEL or TRAP_BRKPT si_code values for MIPS breakpoint traps

[Pedro Alves]

On 02/22/2016 04:19 PM, Maciej W. Rozycki wrote:
> On Mon, 22 Feb 2016, Pedro Alves wrote:
> 
>> I'd like to have a short paragraph in linux-nat.h about MIPS's behavior,
>> below the ppc comment.  If you look at the x86 table above, which cases get
>> SI_KERNEL, and which don't?  Single-step is not applicable, since the
>> MIPS doesn't handle single-stepping itself (IIRC), but do we also get
>> SI_KERNEL hardware bps and watchpoints, for example?
> 
>  As I previously noted the MIPS Linux port currently does not support 
> hardware breakpoints even though hardware may have them implemented 
> (they're optional).  Only hardware watchpoints are supported right now.

Ah.

>  You are right in that there's no OS single-stepping support defined in 
> the MIPS architecture and consequently Linux cannot support it on the MIPS 
> target.  Only JTAG single-stepping is possible with MIPS hardware.

Yeah.  I see I missed a word, sorry.  I meant
"since the MIPS _kernel_ doesn't handle single-stepping itself".

I was thinking about e.g., uprobes, and imagining that since the kernel
needs to advance past uprobes-set breakpoints somehow, that the kernel
could have learned to software single-step, and that that might have been
hooked to PTRACE_SINGLESTEP.

Thanks,
Pedro Alves