lkml.org 
[lkml]   [2011]   [Mar]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Proposal for ptrace improvements
Hi,

On Wed, Mar 02, 2011 at 12:48:56PM +0100, Denys Vlasenko wrote:
> > Of course, all ptrace traps are SIGTRAPs.
>
> Except for those SIGSTOPs in children on auto-attach
> via PTRACE_O_TRACE[V]FORK / PTRACE_O_TRACECLONE options...

Aren't they just using SIGSTOP's to trigger signal delivery path? The
signal can be delivered, right? Checking the source code.... Yeah, it
genuinely generates SIGSTOP.

> >> Why not SIGCONT? This event is, after all, caused by SIGCONT.
> >> It would be so much nicer to be able to detect it with single if()
> >> in the debugger...
> >
> > I disagree.  It's a ptrace trap.  It should use SIGTRAP.  We just need
> > well defined siginfo output to distinguish between them.  It's not
> > like we can avoid siginfo anyway.
>
> Performance problem here. Strace is already suffering from being
> rather slow, especially for multi-threaded processes.
>
> So far strace was able to avoid querying siginfo on every stop.
>
> In order to make job control stop work properly, it will now need
> to query siginfo, but only if signo==SIGSTOP. SIGSTOPs don't
> occur too often, definitely not twice per syscall as SIGTRAPs do,
> so it's not a problem.
>
> With your proposal to show resume-from-job-control-stop-via-SIGCONT
> as SIGTRAP, *every* SIGTRAP stop needs to be followed
> by PTRACE_GETSIGINFO.

I don't think it's a good idea to make these basic design choices
based on optimization concerns like the above. We're not talking
about read/write(2) here. If PTRACE_GETSIGINFO really becomes that
much of a performance bottleneck, we can put it in vdso, but I really
doubt it would come to that.

> int main()
> {
> signal(SIGSTOP, sig);
> signal(SIGCONT, sig);
> signal(SIGWINCH, sig);
> signal(SIGABRT, sig);
> again:
> printf("PID: %d\n", getpid());
> fflush(NULL);
> errno = 0;
> sleep(30);
> int e = errno;
> printf("after sleep: errno=%d %s\n", e, strerror(e));
> if (e) goto again;
> return 0;
> }
>
> # ./a.out
> PID: 16382
> <------ kill -STOP 16382
> <------ kill -ABRT 16382
> <------ kill -WINCH 16382
> <------ kill -CONT 16382
> sig: 28 Window changed
> sig: 18 Continued
> sig: 6 Aborted
> after sleep: errno=4 Interrupted system call
> PID: 16382
>
>
> Therefore we also need to think about this aspect of SIGCONT behavior
> under debuggers.
>
> Do we provide for the mechanism for debuggers to
> prevent execution of *SIGCONT userspace handler*?

Yeah, it's not different from any other signal. Just squash the
signal when ptrace signal delivery trap is taken, which is completely
separate from termination of job control stop triggered by _emission_
of SIGCONT. The two are separate. The proposed changes don't affect
the delivery path at all. I really can't understand what your point
is.

> And, looking at the example above, I see that on resume from stop,
> *SIGCONT userspace handler* actually doesn't run as *the first handler*
> after SIGCONT. Other pending signal's handlers may be executed before it.

Signal delivery is not FIFO. There are some rules that the code
describes. If you're interested, take a look at the code but in
general it would be better to avoid assuming fixed order between
signal generations and deliveries.

> How would the above example look under ptraced process? Particularly,
> this sequence:
> <------ kill -STOP 16382
> <------ kill -ABRT 16382
> <------ kill -WINCH 16382
> <------ kill -CONT 16382
> sig: 28 Window changed
> sig: 18 Continued
> sig: 6 Aborted

There's NO difference regarding signal delivery. It stays the SAME.

Thanks.

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

\
 
 \ /
  Last update: 2011-03-02 15:45    [W:0.127 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site