From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20135 invoked by alias); 5 Oct 2009 15:22:31 -0000 Received: (qmail 20120 invoked by uid 22791); 5 Oct 2009 15:22:29 -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; Mon, 05 Oct 2009 15:22:17 +0000 Received: (qmail 13704 invoked from network); 5 Oct 2009 15:22:15 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Oct 2009 15:22:15 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, Eli Zaretskii Subject: Re: [v4 2/2] multi-executable support (new v5 patch included) Date: Mon, 05 Oct 2009 15:22:00 -0000 User-Agent: KMail/1.9.10 Cc: marc.khouzam@ericsson.com, vladimir@codesourcery.com References: <200909030349.38319.pedro@codesourcery.com> <200909081616.18200.pedro@codesourcery.com> <83hbvd2qrk.fsf@gnu.org> In-Reply-To: <83hbvd2qrk.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910051622.15045.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-10/txt/msg00109.txt.bz2 (getting back to this now) On Tuesday 08 September 2009 20:14:07, Eli Zaretskii wrote: > > From: Pedro Alves > > Date: Tue, 8 Sep 2009 16:16:16 +0100 > > Cc: Marc Khouzam , > > Vladimir Prus > > > > >./gdb ./gdb > > (top-gdb) info inferiors > > Num Description Executable > > * 1 /home/pedro/gdb/sspaces/build/gdb/gdb > > > > (top-gdb) info inferiors > > Num Description Executable > > * 1 process 1429 /home/pedro/gdb/sspaces/build/gdb/gdb > > > > (top-gdb) kill > > Kill the program being debugged? (y or n) y > > (top-gdb) info inferiors > > Num Description Executable > > * 1 /home/pedro/gdb/sspaces/build/gdb/gdb > > > > (top-gdb) add-inferior > > Added inferior 2 > > 1 inferiors added. > > > > (top-gdb) info inferiors > > Num Description Executable > > 2 > > * 1 /home/pedro/gdb/sspaces/build/gdb/gdb > > > > (top-gdb) inferior 2 > > [Switching to inferior 2 [process 0] ()] > > > > (top-gdb) file /home/pedro/gdb/tests/threads > > Reading symbols from /home/pedro/gdb/tests/threads...done. > > > > (top-gdb) info inferiors > > Num Description Executable > > * 2 /home/pedro/gdb/tests/threads > > 1 /home/pedro/gdb/sspaces/build/gdb/gdb > > > > (top-gdb) start > > Temporary breakpoint 4 at 0x400640: file threads.c, line 35. > > Starting program: /home/pedro/gdb/tests/threads > > [Thread debugging using libthread_db enabled] > > > > Temporary breakpoint 4, main () at threads.c:35 > > 35 long i = 0; > > (top-gdb) info inferiors > > Num Description Executable > > * 2 process 1526 /home/pedro/gdb/tests/threads > > 1 /home/pedro/gdb/sspaces/build/gdb/gdb > > This is what I had in mind, yes. If it really works in practice (and > others are happy with this model), then great. I still don't know for certain exactly what to do with the DICOS model here, but, I can certainly see the value of the simplicity of this model by default. This is also the model that allows mapping HPD ptsets (or itsets on the multi-process branch) cleanly to GDB. > > > The symbol-spaces concept is still needed and is still there, but > > the user doesn't see them anymore. I've moved "info symbol-spaces" > > to "maintenanced info symbol-spaces". > > Maybe rename that to "maintenance info program-spaces". It's quite > easy to explain that a ``program space'' is a space in which to run > programs. I like this. I've renamed symbol spaces to program spaces throughout the patch as well. > > > (gdb) attach 123 > > Attached to process 123. > > (gdb) info inferiors > > Num Description Executable > > 1 > > * 2 Process 2323 > > > > It's a shame, and that was one of my main concerns (that we'd > > end up getting too stuck in the unix model of things) but I guess > > we can live with it somehow. > > Can't we have that inferior hidden in "info inferiors", like we do > with breakpoints set by GDB for its own purposes? I'm not sure about this. I think I'll leave it as is for now, and return to it at some point after the main patch is in. It's been a bit frustrating to keep the patch up to date to mainline, as new regressions keep popping up, simply due to the fact that new code isn't considering multi-exec/process. I'd like to be able to do incremental development on top. I'll post a new patch in a bit. -- Pedro Alves