From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4122 invoked by alias); 17 Feb 2009 16:20:15 -0000 Received: (qmail 4102 invoked by uid 22791); 17 Feb 2009 16:20:13 -0000 X-SWARE-Spam-Status: No, hits=-0.4 required=5.0 tests=AWL,BAYES_40,SPF_PASS,ZMIde_GENERICSPAM1 X-Spam-Check-By: sourceware.org Received: from imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Feb 2009 16:20:02 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n1HGQVqQ015608; Tue, 17 Feb 2009 10:26:31 -0600 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 10:19:56 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Process exit in multi-process, and gdb's selected thread. Date: Tue, 17 Feb 2009 16:33:00 -0000 Message-ID: <6D19CA8D71C89C43A057926FE0D4ADAA06F3077B@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <200902170058.33653.pedro@codesourcery.com> References: <200902170058.33653.pedro@codesourcery.com> From: "Marc Khouzam" To: "Pedro Alves" , 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: 2009-02/txt/msg00349.txt.bz2 =20 > -----Original Message----- > From: gdb-patches-owner@sourceware.org=20 > [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Pedro Alves > Sent: Monday, February 16, 2009 7:59 PM > To: gdb-patches@sourceware.org > Cc: Marc Khouzam > Subject: Process exit in multi-process, and gdb's selected thread. >=20 > Hi! >=20 > I've been thinking about issues related to what to do with GDB's > notion of selected thread, if we're debugging more than one process > simultaneously, and the current processes exits. >=20 > What would you think if GDB could get into this state, > after a process exit? : >=20 > (gdb) info threads > 2 Thread 31176.31176 0x00007f0706154796 in ?? () >=20 > No selected thread. See `help thread'. > (gdb) info inferiors > 3 31176 > (gdb) c > Continuing. > Cannot execute this command without a live selected thread. > (gdb) detach > The program is not being run. > (gdb) kill > The program is not being run. > (gdb)=20=20=20 >=20 > This would happen, e.g., if the current process (it was some other > pid, not 31176) had exited or was detached from. Keep in mind that in > non-stop mode, we prefer that GDB doesn't switch threads behind the > user's back while he is typing some command. This way, when the > current thread and inferior no longer exist, GDB switches to=20 > a state that > should be safe, and the onus is on the frontend to switch to > whatever thread it wants. >=20 > In the past, I had solved this by spreading around some hacks > that tried to detect the current inferior exiting, and switching > to any other random live thread, but, that turned out to be: first, > surprising in non-stop mode, in the case mentioned above; and > second, surprisingly difficult to get right. I think this usually > means that GDB shouldn't try to be smart (well, or I shouldn't). >=20 > I've tried avoiding before getting to a state where GDB has > no thread selected, when there are threads in the thread list. But, > I don't think we'll be able to avoid it in the long run. E.g., when > GDB gains ability to load more than on program (exec) at the=20 > same time, > (say, "cat", and "grep"), even if "cat" is running already,=20 > it will fell > natural to be able to select the "grep" executable as focus, thus, > the selected thread in that case should be "null". (Also=20 > thinking about > the possibility of GDB being able in the future to switch to some form > of post-or-quasi-mortem debugging mode when a process exits,=20 > I'd want GDB > to not switch threads to some other process on a process exit.) >=20 > A bit related to this, is the hack we have currently that tags a > few commands as being "safe to apply without a valid > selected thread". This served its purpose when non-stop was first > introduced, but, I think it's time we remove them, and start making > the checks at a lower level. They are currently done at a too high > level currently, which ends up getting in the way many times. We need > more finer grained control over which operations can and can't be > applied without a valid thread selected, so we need to push those > checks down, more close to core code, or even to target code. For what it's worth, I always thought it was risky to have such a list of 'safe' commands. It just seemed to be asking for trouble. =20 > I'm thinking that we may need to extend the =3Dthread-selected > notification to tell the frontend that there's no thread selected, > and perhaps the -thread-info,current-thread-id, output too. Your patches does not do this yet, right? =20 > What do you think of all this, am I making sense? Or, does it > sound like "let's hope he comes back to senses soon, for he's > not making any"? :-) >=20 > Here's my current patch that implements this, in case you > have a stub around that implements multi-process (Hi Marc!). I don't think you explicitely said it (or maybe I've read too many emails today), but I believe you are suggesting that GDB be allowed to be in a state where no thread is selected and this state should be handled properly when receiving commands. I didn't quite understand what responsibility falls on the=20 frontend with this suggestion.=20=20 I wanted to try to patch to see what you meant more clearly. However, I think this patch applies to HEAD but HEAD does not work with my stub yet (the -list-thread-groups --available problem). But I'm quite interested... Marc