Re: [PATCH] Handle MIPS Linux SIGTRAP siginfo.si_code values

[Pedro Alves <palves at redhat dot com>]

On 02/24/2016 06:29 PM, Maciej W. Rozycki wrote:
> On Wed, 24 Feb 2016, Pedro Alves wrote:
> 
>> @@ -140,14 +140,32 @@ struct buffer;
>>     in SPU code on a Cell/B.E.  However, SI_KERNEL is never seen
>>     on a SIGTRAP for any other reason.
>>  
>> -   The generic Linux target code should use GDB_ARCH_IS_TRAP_BRKPT
>> -   instead of TRAP_BRKPT to abstract out these peculiarities.  */
>> +   The MIPS kernel uses SI_KERNEL for all kernel generated traps.
>> +   Since:
>> +
>> +     - MIPS doesn't do hardware single-step
>> +     - We don't need to care about exec SIGTRAPs, since we assume
>> +       PTRACE_EVENT_EXEC.
>> +     - The MIPS kernel doesn't support hardware breakpoints.
>> +
>> +   on MIPS, all we need to care about is distinguishing between
>> +   software breakpoints and hardware watchpoints, which can be done by
>> +   peeking the debug registers.
> 
>  I'm assuming spurious traps such as from trap instructions will still be 
> delivered as such, right?

Yes, they should.

> 
>> +
>> +   The generic Linux target code should use GDB_ARCH_IS_TRAP_* instead
>> +   of TRAP_* to abstract out these peculiarities.  */
>>  #if defined __i386__ || defined __x86_64__
>>  # define GDB_ARCH_IS_TRAP_BRKPT(X) ((X) == SI_KERNEL)
>> +# define GDB_ARCH_IS_TRAP_HWBKPT(X) ((X) == TRAP_HWBKPT)
>>  #elif defined __powerpc__
>>  # define GDB_ARCH_IS_TRAP_BRKPT(X) ((X) == SI_KERNEL || (X) == TRAP_BRKPT)
>> +# define GDB_ARCH_IS_TRAP_HWBKPT(X) ((X) == TRAP_HWBKPT)
>> +#elif defined __mips__
>> +# define GDB_ARCH_IS_TRAP_BRKPT(X) ((X) == SI_KERNEL)
>> +# define GDB_ARCH_IS_TRAP_HWBKPT(X) ((X) == SI_KERNEL)
> 
>  Shall I add the TRAP_BRKPT and TRAP_HWBKPT codes to the MIPS Linux kernel 
> then or not?  

The higher order issue was having a way to distinguish the possible
traps, for correctness.  Since we found a way, it's no longer a
pressing issue and we could leave it be.

> If anything, this looks like a performance win to me, at no 
> significant cost (any possible kernel overhead will be in the range of a 
> couple processor instructions, which is nothing compared to an extra 
> ptrace(2) call and all the associated processing).

Yeah.  We usually need several other ptrace calls so it may not
be noticeable.  But if you do teach the kernel about TRAP_BRKPT, and want to
avoid the watchpoints check, I think gdb/gdbserver could be made to auto detect
at run time what does the kernel report.  E.g,. have gdb fork itself, set a
sw bp at the current PC in the child and continue it.  That triggers the bp
immediately.  Then the parent can check what is in the child's si_code.  We
do similar things already in linux_check_ptrace_features (gdb/nat/linux-ptrace.c).

Thanks,
Pedro Alves