From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26704 invoked by alias); 18 Dec 2008 19:47:02 -0000 Received: (qmail 26690 invoked by uid 22791); 18 Dec 2008 19:47:01 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Dec 2008 19:46:20 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id A95A7C; Thu, 18 Dec 2008 11:46:17 -0800 (PST) Received: from [10.20.92.151] (promb-2s-dhcp151.eng.vmware.com [10.20.92.151]) by mailhost5.vmware.com (Postfix) with ESMTP id A1461DC0F4; Thu, 18 Dec 2008 11:46:17 -0800 (PST) Message-ID: <494AA75A.1060607@vmware.com> Date: Thu, 18 Dec 2008 19:47:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Doug Evans CC: "gdb-patches@sourceware.org" Subject: Re: [RFA] add some comments to linux-low.c:linux_attach_lwp References: <20081213212631.C563D1C7A0F@localhost> In-Reply-To: <20081213212631.C563D1C7A0F@localhost> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00328.txt.bz2 Seems fine. Doug Evans wrote: > Hi. > > Until things are fixed, I'd like to record some knowledge so > I don't forget. This also does a better job (IMO) of enumerating > all the cases that need to be handled here. > > Ok to check in? > > 2008-12-13 Doug Evans > > * linux-low.c (linux_attach_lwp): Add some comments/fixmes. > > Index: linux-low.c > =================================================================== > RCS file: /cvs/src/src/gdb/gdbserver/linux-low.c,v > retrieving revision 1.84 > diff -u -p -r1.84 linux-low.c > --- linux-low.c 12 Dec 2008 23:14:28 -0000 1.84 > +++ linux-low.c 13 Dec 2008 21:24:00 -0000 > @@ -326,6 +326,8 @@ linux_attach_lwp (unsigned long pid) > strerror (errno), errno); > } > > + /* FIXME: This intermittently fails. > + We need to wait for SIGSTOP first. */ > ptrace (PTRACE_SETOPTIONS, pid, 0, PTRACE_O_TRACECLONE); > > new_process = (struct process_info *) add_process (pid); > @@ -333,15 +335,36 @@ linux_attach_lwp (unsigned long pid) > new_thread_notify (thread_id_to_gdb_id (new_process->lwpid)); > > /* The next time we wait for this LWP we'll see a SIGSTOP as PTRACE_ATTACH > - brings it to a halt. We should ignore that SIGSTOP and resume the process > - (unless this is the first process, in which case the flag will be cleared > - in linux_attach). > + brings it to a halt. > + > + There are several cases to consider here: > + > + 1) gdbserver has already attached to the process and is being notified > + of a new thread that is being created. > + In this case we should ignore that SIGSTOP and resume the process. > + This is handled below by setting stop_expected = 1. > + > + 2) This is the first thread (the process thread), and we're attaching > + to it via attach_inferior. > + In this case we want the process thread to stop. > + This is handled by having linux_attach clear stop_expected after > + we return. > + ??? If the process already has several threads we leave the other > + threads running. > + > + 3) GDB is connecting to gdbserver and is requesting an enumeration of all > + existing threads. > + In this case we want the thread to stop. > + FIXME: This case is currently not properly handled. > + We should wait for the SIGSTOP but don't. Things work apparently > + because enough time passes between when we ptrace (ATTACH) and when > + gdb makes the next ptrace call on the thread. > > On the other hand, if we are currently trying to stop all threads, we > should treat the new thread as if we had sent it a SIGSTOP. This works > - because we are guaranteed that add_process added us to the end of the > - list, and so the new thread has not yet reached wait_for_sigstop (but > - will). */ > + because we are guaranteed that the add_process call above added us to the > + end of the list, and so the new thread has not yet reached > + wait_for_sigstop (but will). */ > if (! stopping_threads) > new_process->stop_expected = 1; > }