Re: gdbserver ptrace not doing waitpid after attaching to threads?

[Doug Evans <dje at google dot com>]

On Fri, Dec 12, 2008 at 1:28 PM, Daniel Jacobowitz <drow@false.org> wrote:
>
> On Fri, Dec 12, 2008 at 01:13:15PM -0800, Doug Evans wrote:
> > Why isn't gdbserver waiting for a SIGSTOP after attaching to threads?
>
> It's supposed to be.  At one point it definitely was, though it might
> have broken recently and been saved by luck.  We attached the thread
> but did not mark it stopped
>
> > I've run gdbserver under strace and see that gdbserver is essentially doing
> > ptrace (ATTACH), ptrace (SETOPTIONS), ptrace (GETREGS) on threads
> > with no intervening waitpid.
>
> Is this current source?  A vaguely current kernel?  It shouldn't be
> doing any ATTACH; instead it should be trusting SETOPTIONS to deliver
> new threads to it via wait.

source = cvs head
kernel = 2.6.18-ish and 2.6.27-ish

I mightn't have been clear enough btw.  I'm observing these things
from doing an attach in gdb.  Example below.

Heh.  For reference sake, with cvs head in fc10 (2.6.27-ish) I just saw this:

ptrace(PTRACE_ATTACH, 12293, 0, 0)      = 0
ptrace(0x4200 /* PTRACE_??? */, 12293, 0, 0x8) = -1 ESRCH (No such process)

This is the first attach that gdbserver does, the one for the process.
Might it be possible that one has to wait for SIGSTOP even before
ptrace (SETOPTIONS)? :-)

Observed with:

bash1$ ./foo.x & # simple program that creates 4 threads that just burn cpu
12293
bash1$ strace gdbserver --multi :1234

bash2$ gdb foo.x
(gdb) tar extended-remote :1234
(gdb) attach 12293

The relevent output of strace is (from running the example on 2.6.27):

ptrace(PTRACE_ATTACH, 12293, 0, 0)      = 0
ptrace(0x4200 /* PTRACE_??? */, 12293, 0, 0x8) = -1 ESRCH (No such process)
[...]
waitpid(-1, [{WIFSTOPPED(s) && WSTOPSIG(s) == SIGSTOP}], WNOHANG) = 12293
ptrace(PTRACE_GETREGS, 12293, 0, 0x9c36248) = 0
ptrace(PTRACE_GETFPXREGS, 12293, 0, 0x9c36290) = 0
ptrace(PTRACE_GETFPREGS, 12293, 0, 0x9c36498) = 0
[...]
ptrace(PTRACE_ATTACH, 12297, 0, 0)      = 0
ptrace(0x4200 /* PTRACE_??? */, 12297, 0, 0x8) = -1 ESRCH (No such process)
[...]
ptrace(PTRACE_ATTACH, 12296, 0, 0)      = 0
ptrace(0x4200 /* PTRACE_??? */, 12296, 0, 0x8) = -1 ESRCH (No such process)
[...]
ptrace(PTRACE_ATTACH, 12295, 0, 0)      = 0
ptrace(0x4200 /* PTRACE_??? */, 12295, 0, 0x8) = 0
[...]
ptrace(PTRACE_ATTACH, 12294, 0, 0)      = 0
ptrace(0x4200 /* PTRACE_??? */, 12294, 0, 0x8) = -1 ESRCH (No such process)
[...]
ptrace(PTRACE_GETREGS, 12294, 0, 0x9c37c50) = 0
ptrace(PTRACE_GETFPXREGS, 12294, 0, 0x9c37c98) = 0
ptrace(PTRACE_GETFPREGS, 12294, 0, 0x9c37ea0) = 0

There are no waitpid calls after the one you see above.
I may be missing something, but it seems the registers for 12294 are
being read before waiting for SIGSTOP.
A lot happens between them so presumably that's why gdb is getting away with it.
Note that one ptrace (SETOPTIONS) did work, the one for thread 12295,
the other's didn't.

For clarification, your comment:

> It shouldn't be
> doing any ATTACH; instead it should be trusting SETOPTIONS to deliver
> new threads to it via wait.

was for the case where gdbserver starts the program, and not for the
case where gdbserver attaches to the program, right?  In the latter
case it seems like gdbserver does indeed need to attach to all the
threads when gdb connects.  That's what it's doing, it's just not
waiting for SIGSTOP (IIUC).