[RFC] make strace handle SIGTRAP properly

[Tejun Heo]

Hello,

On Fri, May 20, 2011 at 09:24:21PM +0200, Denys Vlasenko wrote:
> > That is truly scary; however, it doesn't have to be this scary even
> > without TRACESYSGOOD.
> 
> I don't see how one can determine that this SIGTRAP is not a
> syscall-stop, and moreover, to determine whether this SIGTRAP
> is a "real" SIGTRAP (such as generated with "kill -trap")
> or one generated by execve.

You're right.  I was thinking only about the trap points not the
signal ones.  We need to do something for syscall and singlestep
SIGTRAPs.  It's weird because ptrace currently is using two different
modes of event reporting - trap points and actual signals.  There's no
reason for syscall and singlesteps can't be another PTRACE_EVENT_*
trap points.  Would that work for you?

> >  * On signal delivery, it contains the siginfo of the signal.  In this
> >    case, si_code always contains either 0 or negative number.  It
> >    can't contain a positive number no matter how the signal is
> >    generated.
> 
> Not always. Compile this with gcc -m32 -nostartfiles -nostdlib FILE.s:
> 
> _start: .globl _start
>         int3
>         movl $42,%ebx
>         movl $1,%eax
>         int $0x80
> 
> This delivers SIGTRAP with si_code = 0x80, which is not a negative
> number.

Oh, I meant user-generated signals.  In the above case, the kernel
generates SIGTRAP in response to the debug trap and si_code is set to
SI_KERNEL (0x80) indicating that the signal was generated by the
kernel.  Confusing all the same, I suppose.  Again, if we consolidate
all ptrace events through trap points and leave signal delivery alone,
it could be better.  There could be other pitfalls and it might
require more modifications to userland tho.  I'll bring it up on LKML.

Thanks.

-- 
tejun