Messages in this thread | | | Date | Mon, 16 May 2011 17:52:53 +0200 | From | Tejun Heo <> | Subject | Re: Ptrace documentation, draft #1 |
| |
Hello,
I haven't read the whole thing yet but wanna comment on some.
On Mon, May 16, 2011 at 05:31:22PM +0200, Oleg Nesterov wrote: > > Kernel delivers an extra SIGTRAP to tracee after execve syscall > > returns. This is an ordinary signal (similar to one generated by kill > > -TRAP), not a special kind of ptrace-stop. If PTRACE_O_TRACEEXEC option > > is in effect, a PTRACE_EVENT_EXEC-stop is generated instead. > > > > ??? can this SIGTRAP be distinguished from "real" user-generated SIGTRAP > > by looking at its siginfo? > > Afaics no. Well, except .si_pid shows that the signal was sent by the > tracing process to itself.
If you do GETSIGINFO and look at si->si_code, user generated signals can't have non-zero value there (assuming SETSIGINFO doesn't allow uploading __SI_TRAP siginfo), so, if si->si_code contains SIGTRAP | PTRACE_EVENT_* << 8, I think it reliably identifies a specific trap. We probably want to add more PTRACE_EVENT_* so that each trap site can be identified uniquely. Note that the si_code is also returned as exit_code on wait(2) and combined with CLD_TRAPPED ptrace traps should be reliably identifiable.
> > Note that restarting ptrace commands issued in ptrace-stops other than > > signal-delivery-stop do NOT inject a signal, even if sig is nonzero. No > > error is reported either. This is a cause of confusion among ptrace > > users. > > Yes. Except syscall entry/exit. But in this case SET_SIGINFO doesn't work > to add more confusion ;)
Yeah, I hate these signal injections. Maybe we can remove these if SEIZED? Tracer might as well just do tkill(). I don't really see the point of the signal injection feature.
> > Syscall-enter-stop and syscall-exit-stop are indistinguishable by > > tracer. > > Almost... at least on x86 rax = -ENOSYS in syscall-enter-stop.
We can add PTRACE_EVENT_* values if SEIZED.
> > ptrace(PTRACE_cmd, pid, 0, sig); > > where cmd is CONT, DETACH, SYSCALL, SINGLESTEP, SYSEMU, > > SYSEMU_SINGLESTEP. If tracee is in signal-delivery-stop, sig is the > > signal to be injected. Otherwise, sig is ignored. > > There is another special case. If the tracee single-stepps into the > signal handler, it reports SIGTRAP as if it recieved this SIGNAL. > But ptrace(PTRACE, ..., sig) doesn't inject after that.
Ditto as PTRACE_SYSCALL. I think resuming from signal delivery trap should be the only place where @data means signo.
> > Is signal injected if they were in signal-delivery-stop? > > Yes, The tracee resumes and handles the previously reported signal.
Please note that this one really isn't an injection. It's just given a chance to either suppress or alter a signal which is being delivered. It's not creating a new one.
Thank you.
-- tejun
| |