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

[Luis Machado <lgustavo at codesourcery dot com>]

On 02/24/2016 03:51 PM, Pedro Alves wrote:
> 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.

I think we should converge to a standard solution across all 
architectures in the future rather than potentially perpetuate old 
non-standard ways. So the movement towards returning well defined 
si_code values in the MIPS Linux Kernel is a plus, even though we might 
not benefit from it right now. I'm in favor of having the change to the 
kernel made.

The later we change this, the longer we need to support the old ways and 
their one-off mechanisms for each architecture, no?