[PATCH] correctly handle "kill -TRAP $straced_programs_pid" and int3
roland at redhat.com
Wed Feb 11 02:51:59 UTC 2009
> /* 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.
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.
More information about the Strace-devel