From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25024 invoked by alias); 12 Dec 2008 23:08:10 -0000 Received: (qmail 25011 invoked by uid 22791); 12 Dec 2008 23:08:09 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 12 Dec 2008 23:07:34 +0000 Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id mBCN6kuQ017954 for ; Fri, 12 Dec 2008 15:06:47 -0800 Received: from rn-out-0910.google.com (rnej66.prod.google.com [10.38.161.66]) by spaceape12.eur.corp.google.com with ESMTP id mBCN6i3E014168 for ; Fri, 12 Dec 2008 15:06:45 -0800 Received: by rn-out-0910.google.com with SMTP id j66so1602641rne.20 for ; Fri, 12 Dec 2008 15:06:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.94.2 with SMTP id r2mr2599643agb.62.1229123204522; Fri, 12 Dec 2008 15:06:44 -0800 (PST) In-Reply-To: <20081212212838.GA8833@caradoc.them.org> References: <20081212211315.57CE01C7A79@localhost> <20081212212838.GA8833@caradoc.them.org> Date: Fri, 12 Dec 2008 23:08:00 -0000 Message-ID: Subject: Re: gdbserver ptrace not doing waitpid after attaching to threads? From: Doug Evans To: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00046.txt.bz2 On Fri, Dec 12, 2008 at 1:28 PM, Daniel Jacobowitz 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).