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

[Roland McGrath]

> I put relevant code into #ifdef LINUX as I unsure that
> corresponding PTRACE_xxx constants even exist on other OSes.

They don't exist in all Linux versions either.  If there is another
ptrace-using OS that defines the Linux-invented ptrace constants, I think
we can assume they work compatibly.  You should test #if defined PTRACE_FOO
for the particular ones you rely on.

> Still, yell at me if something broke as a result,
> and I will revert or fix it.

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.

I think your patch is modest enough that it can be safe even with this,
with just a little cleanup.

"sigtrap80" is just a terrible name for a struct member.  You're recording
the status that's returned for syscall stops, so "syscall_status" or
"syscall_stopsig" makes most sense.  The former is better if you just store
the encoded int ((x << 8)|0x7f) and compare status == syscall_status directly.

I'm not sure we really need a field in struct tcb at all.  The feature is
either supported by the kernel or it's not.  If it is, we'll use it
consistently for all the tasks we ptrace.  Why not just use a global?

To be robust to the aforementioned untrustworthy old kernels, all you
really have to do is not presume it worked.  That is, set syscall_status
the first time you see a SIGTRAP|0x80 or (PTRACE_EVENT_EXEC<<8)|SIGTRAP.
Before that, assume as now that any SIGTRAP you see might or might not
actually be a syscall report.  You can cache the fact if trying
PTRACE_SETOPTIONS failed (with other than ESRCH), so you don't make the
wasted ptrace call on every new thread on those old kernels.  But don't
assume just because PTRACE_SETOPTIONS did succeed that it really worked.
Only when you've seen a new-style report once can you then expect that
PTRACE_SETOPTIONS works every time.


Thanks,
Roland