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

["Maciej W. Rozycki" <macro at imgtec dot com>]

On Wed, 24 Feb 2016, Pedro Alves wrote:

> > to actually recognise these events at all in the first place.  So we 
> > better have it right away or updated kernels will break GDB for a change.  
> 
> OK, if you're still willing to change the kernel, let's do it.
> 
> I had somehow imagined (and reading back, I have no idea why) that you
> _didn't_ want to change the si_code, if possible, and was going by that.
> 
> (There's always risk associated with such a change, as it's effectively
> an ABI break and some tool out there may be relying on SI_KERNEL and may
> thus stop working correctly.  Usually ABI stability trumps "cleanliness",
> in kernel circles.)

 I'll post a proposal, cc-ing you (and Luis), and see if anything pops up.  
Given that the only codes for SIGTRAP on MIPS/Linux have so far been 
SI_USER (i.e. 0) or SI_KERNEL, I really doubt that any software bothered 
checking it.  I've never thought of trying to fool a debugger by sending 
it SIGTRAP signals with kill(2) and now that I think of it, then honestly 
I fail to see a reason to actually special-case such fooling and prevent 
the user from doing so -- if they do it, then certainly they must have had 
a reason.

 Did GDB itself check for SI_KERNEL before your recent rewrite?

> I've just finished testing it on s390 -- no regressions.  I've
> pushed it in now, as is.  I'll follow up with a new patch that makes
> gdb accept the anticipated new si_codes too.

 I'm fine with waiting for any outcome from a discussion with kernel 
people before pushing such a change.

  Maciej