From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25551 invoked by alias); 25 Jul 2009 15:13:02 -0000 Received: (qmail 25535 invoked by uid 22791); 25 Jul 2009 15:13:01 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 25 Jul 2009 15:12:54 +0000 Received: (qmail 2644 invoked from network); 25 Jul 2009 15:12:51 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Jul 2009 15:12:51 -0000 From: Pedro Alves To: Tom Tromey Subject: Re: Multi-exec patches (Was: [rfc] Infrastructure to disable breakpoints during inferior startup) Date: Sat, 25 Jul 2009 16:05:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org, "Ulrich Weigand" , Jan Kratochvil References: <200907231631.n6NGV2xR018887@d12av02.megacenter.de.ibm.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907251612.50134.pedro@codesourcery.com> 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-07/txt/msg00623.txt.bz2 On Friday 24 July 2009 23:45:02, Tom Tromey wrote: > >>>>> "Tom" == Tom Tromey writes: > > Tom> I still haven't actually tried it, but I hope to do so soon. > > I tried it a little. Thank you! > > I can't remember ... should this all work ok on x86 Linux? I thought > yes, hence this report, but if not, feel free to just let me know and > ignore all this. It should. Although I've been testing most on x86_64. > Most of what I've written here seems familiar. I assume I read it all > in earlier notes of yours :-) > > > The first thing I noticed is that the new features are off by default. Right. > I had to: > > set schedule-multiple on > set detach-on-fork off > > to get it to work. Having it disabled by default is ok as long as it is > a "technology preview", but if we think it is very solid then I think we > should enable it by default. > > Having to set 2 options is obscure. I suppose I didn't really need to > set both, except my first attempt was to run "make", which tripped over > the vfork problem. > > > I put a gcc I built into my $PATH. Then I did: > > $ cd gdbserver > $ ../gdb make > > Then I tried various things. > > "run clean" worked ok! That was cool! > > Then I exited gdb and restarted it and tried a plain "run". This gave > me: > > (gdb) set schedule-multiple on > (gdb) set detach-on-fork off > (gdb) run > Starting program: /usr/bin/make > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > [New process 3931] > process 3931 is executing new program: /bin/true > (no debugging symbols found) > (no debugging symbols found) > (no debugging symbols found) > > Program exited normally. > > ... which is a little odd, since no build was done. > And, what's with process 3931 executing /bin/true? > Am I not debugging the 'make' process? Ah, but you're debugging in all-stop mode. What this means is that a program exit is a reason to stop everything and report to the user. This was /bin/true exiting. Check "info inferiors", and you should still see other inferiors there, waiting for you to tell them to continue execution. > A minor nit: I think "is executing a new program" would read better. See? That was the *only* string I changed, and it's picky. :-) I should have left that out of the patch. :-) > > Then I did "run clean": > > (gdb) run clean > Starting program: /bin/true clean > (no debugging symbols found) > (no debugging symbols found) > gcc -c -Wall -g3 -I. -I../../../archer/gdb/gdbserver -I../../../archer/gdb/gdbserver/../common -I../../../archer/gdb/gdbserver/../regformats -I../../../archer/gdb/gdbserver/../../include ../../../archer/gdb/gdbserver/regcache.c > > Here, for some reason, the compile started. And, gdb forgot that I was > looking at "make" and ran /bin/true. This is a consequence of the above. You're in all-stop mode, focusing the /bin/true program, and you've told it to run. You also have "shedule-multiple on", so what happened is that you're told 'true' to run, and, all other inferiors that were stopped also ran. (also take a look at the set follow-exec-mode setting --- doesn't apply in this case, but you seem to be expecting something like that. Disclaimer, I don't claim these new setting and command names to be perfect.) > At this point, gdb hangs and cannot be interrupted. I kill -9'd it. Hmm, possibly the vfork parent on foreground issue, but I can't tell immediately why it happened, since the children should have ran too, if I didn't miss any command you issued. > If I do the above but remember "file /usr/bin/make", gdb starts make > again ok and the compile starts. But, gdb hangs again as above. > > This hang occurs often enough that I couldn't get to other tests, like > trying to set a breakpoint that would only trigger in cc1. > > > Those "(no debugging symbols found)" messages made me want Doug's patch > more ;) ( :-) Actually, we don't need to whole of Doug's patch for this. Just the bit that suppresses these symbol loading messages for "auto-loaded" objfiles. ) > Note that it is entirely possible that the patch applied strangely and I > introduced some bug that way. Or, maybe there is some other pilot > error. You need to try it with non-stop mode on. It should work like you seem to want it to. See the "bootstrapping" gdb example here: http://sourceware.org/ml/gdb-patches/2009-06/msg00388.html all-stop + synchronous debugging is limited by design, and what we can do with it. Note that this behaviour of stopping when a program exits isn't new at all. This is how multi-forks always behaved. ( Long term, I'd very much like to fuse all-stop into non-stop. That is, implement all-stop mode on top of non-stop+async, and so have make the UI (especially the number of setting required to activate), much reduced. We're still a bit far from that... ) -- Pedro Alves