[PATCH] correctly handle "kill -TRAP $straced_programs_pid" and int3

[Roland McGrath]

> /* PTRACE_SETOPTIONS is not a #define. PT_SETOPTIONS is. */
> /* Add more OSes after you verified it works for them. */
> #if defined LINUX && defined PT_SETOPTIONS
> 	...

It would be safest to just do an autoconf check rather than a magic #if nest.

> > In the past we avoided relying on PTRACE_SETOPTIONS in strace, because
> > older Linux kernels (2.4 and early 2.6) either didn't have it or had spotty
> > support.  IIRC, there were some kernels that have PTRACE_SETOPTIONS but
> > only support some of the option bits, yet it always returns success with no
> > indicator of what is or isn't really supported.
> 
> Gaack.

Indeed.  Another of the many reasons not to worry about arcane corners in
strace that nobody actually really cares much about. :-)

> > "sigtrap80" is just a terrible name for a struct member.  You're recording
> > the status that's returned for syscall stops,
> 
> No, I do not, I record what WSTOPSIG() value do I expect from ptrace stops.

>From syscall stops.  The ptrace stop for exec doesn't return that.

> This member always contains SIGTRAP or SIGTRAP | 0x80, but
> int sigtrap_or_sigtrap_ored_with_0x80 is a bit long. :)
> 
> Will you feel better with ptrace_stop_sig name?

"syscall_wstopsig" is fine.  But you could just as well store W_STOPCODE(...)
there and compare it directly without extracting WSTOPSIG(), and then you'd
call it "syscall_status". ;-)

> ptrace manpage says nothing about inheritance of these flags across clone.
> In practice, they are inherited. Can we rely on this?

That they are inherited when we force CLONE_PTRACE (strace -f), yes.

> I will commit attached patch. Please take a look.

I guess it looks OK.  I'm not re-pondering it very deeply now.


Thanks,
Roland