[PATCH] Try to use PTRACE_SETOPTIONS to handle non-ptrace SIGTRAP

[Roland McGrath]

> > If you trace an execve, you're going to get its syscall exit stop
> > before you get its old-style traced-exec SIGTRAP.
> 
> No, you don't.

How did you come to that conclusion?  My assertion was based on knowing the
kernel code.  But below is a test program that illustrates the truth of it.
Here's the beginning of its output:

	935 0xa7f
	935 0x857f
		5 0x85
		59
	935 0x857f
		5 0x85
		59
	935 0x57f
		5 0
		59
	935 0x857f
		5 0x85
		12

935 is the PID.  0xa7f is stopped with SIGUSR1.
Next, two syscall stops for execve (59 on x86_64), one entry and one exit.
Next, a signal stop for the post-exec SIGTRAP.
Next, a syscall entry stop for brk (12 on x86_64), the first syscall in the
new program after exec.

> > But, for exec doesn't it make sense to call it a possible ptrace stop only
> > if TCB_STARTUP?
> 
> What if PTRACE_O_TRACEEXEC doesn't work?  That contradicts your own
> words.

So either TCB_STARTUP will be set or TCB_WAITEXECVE will be set.


Thanks,
Roland

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ptrace-exec.c
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20100305/87c4f1da/attachment.c>