Re: [PATCHSET ptrace] ptrace: implement PTRACE_SEIZE/INTERRUPT andgroup stop notification, take#4

[Denys Vlasenko]

On Fri, Jun 3, 2011 at 2:11 PM, Pedro Alves <pedro@xxxxxxxxxxxxxxxx> wrote:
>> > > > * What to do about events which are reported by genuine SIGTRAP
>> > > >  generation?
>> > >
>> > > I don't understand what you meant here. Example(s)?
>> >
>> > The syscall, breakpoint, single step SIGTRAPs which can't be
>> > distinguished from userland generated SIGTRAPs and may be mixed and/or
>> > lost.  Maybe it's best to leave them alone or maybe we can add some
>> > way to distinguish them which is mostly backward compatible (which is
>> > enabled w/ SEIZE and hopefully doesn't require noticeable userland
>> > changes).
>>
>> Currently, all PTRACE_EVENTs are enabled with ptrace options.
>>
>> I propose using the same way instead of using something different.
>> It works. It's not problematic. Just add more PTRACE_O_foo bits.
>> Then user who really want it will use it, and users which
>> would rather use their existing code with less changes aren't
>> forced to change.
>
> I'm in principle against this.  What realistic good does it
> bring over making exception/syscall SIGTRAPs distinguisheable
> on the siginfo?

Requiring GETSIGINFO on every syscall trap is (1) a bit expensive
and (2) was never needed before.

>  Userspace should see these SIGTRAPs if a tracer
> isn't there anyway, and, even if a tracer _is_ there, you
> may want to forward breakpoint/step SIGTRAPs to the
> tracee, just as if a ptracer wasn't there --- I do that often to
> debug an in-process self debugger.

Ah, you are talking about int3 SIGTRAP? That one, IMHO,
should be treated as "real" signal and passed down to the program
by strace. For debuggers which use int3 as breakpoint insn,
well, I don't know. Perhaps they don't cope well with user-sent
SIGTRAPs anyway?

>  Being able to distinguish the
> cause of the SIGTRAP is useful for self debuggers as well,
> which leads to putting the info in siginfo anyway.

I don't understand what use case you have in mind.

-- 
vda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/