From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6679 invoked by alias); 27 Jul 2009 17:15:06 -0000 Received: (qmail 6665 invoked by uid 22791); 27 Jul 2009 17:15:05 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Jul 2009 17:14:52 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n6RHCmiC015662; Mon, 27 Jul 2009 13:12:48 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n6RHClLT031949; Mon, 27 Jul 2009 13:12:47 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n6RHCkot018244; Mon, 27 Jul 2009 13:12:46 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 11D413782CF; Mon, 27 Jul 2009 11:12:46 -0600 (MDT) To: Pedro Alves Cc: gdb-patches@sourceware.org, "Ulrich Weigand" , Jan Kratochvil Subject: Re: Multi-exec patches References: <200907231631.n6NGV2xR018887@d12av02.megacenter.de.ibm.com> <200907251612.50134.pedro@codesourcery.com> From: Tom Tromey Reply-To: Tom Tromey Date: Mon, 27 Jul 2009 17:39:00 -0000 In-Reply-To: <200907251612.50134.pedro@codesourcery.com> (Pedro Alves's message of "Sat\, 25 Jul 2009 16\:12\:49 +0100") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00654.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Tom> ... which is a little odd, since no build was done. Tom> And, what's with process 3931 executing /bin/true? Tom> Am I not debugging the 'make' process? Pedro> Ah, but you're debugging in all-stop mode. What this means Pedro> is that a program exit is a reason to stop everything and report Pedro> to the user. This was /bin/true exiting. Check "info inferiors", Pedro> and you should still see other inferiors there, waiting for you Pedro> to tell them to continue execution. I didn't see anything else in "info inferiors", but I am not sure I am doing it at the right time. I made gdb crash while trying it again today: (gdb) set non-stop 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) Can not resume the parent process over vfork in the foreground while holding the child stopped. Try "set detach-on-fork" or "set schedule-multiple". Recursive internal problem. Aborted I also got this strange result: (gdb) set detach-on-fork off (gdb) set schedule-multiple on (gdb) set non-stop on (gdb) run Starting program: /usr/bin/make (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [New process 21131] Couldn't get registers: No such process. (gdb) info inf Id Target ID SSpace Main Program * 2 process 21131 2 1 process 21128 1 /usr/bin/make Also, "ps" showed me several /usr/bin/make processes still hanging around from the other day's debugging attempts. Tom> A minor nit: I think "is executing a new program" would read better. Pedro> See? That was the *only* string I changed, and it's picky. :-) Pedro> I should have left that out of the patch. :-) Hahaha. I'm sorry about that. I do try to avoid bikeshedding of this sort, but now I've discovered that I only *think* I try ;) Pedro> You need to try it with non-stop mode on. It should work like you Pedro> seem to want it to. See the "bootstrapping" gdb example here: Pedro> http://sourceware.org/ml/gdb-patches/2009-06/msg00388.html Ok, this worked much better. I was able to interrupt a cc1 process during make! I did see this, I don't know if it is intended: (gdb) kill Kill the program being debugged? (y or n) y You can't do that without a process to debug. After interrupting cc1, I used "quit". gdb exited, but then the make resumed in the background. gdb seems somewhat sluggish when I run 'make' in it. Perhaps it is just because my system is under load. I see now that inferior output is going to be a problem in this mode, at least when using gdb in a terminal. I ran into another crash somehow: ../../archer/gdb/thread.c:708: internal-error: finish_thread_state: Assertion `tp' failed. I don't know whether I can reproduce this one. I tried setting a pending breakpoint in c_common_init_options and then running make. Pedro> ( Long term, I'd very much like to fuse all-stop into non-stop. That is, Pedro> implement all-stop mode on top of non-stop+async, and so have make the Pedro> UI (especially the number of setting required to activate), much reduced. Pedro> We're still a bit far from that... ) Sounds good. Tom