From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1607 invoked by alias); 9 Sep 2009 06:40:35 -0000 Received: (qmail 1521 invoked by uid 22791); 9 Sep 2009 06:40:33 -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; Wed, 09 Sep 2009 06:40:27 +0000 Received: (qmail 21175 invoked from network); 9 Sep 2009 06:40:25 -0000 Received: from unknown (HELO wind.localnet) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 9 Sep 2009 06:40:25 -0000 From: Vladimir Prus To: Pedro Alves Subject: Re: [v4 2/2] multi-executable support (new v5 patch included) Date: Wed, 09 Sep 2009 06:40:00 -0000 User-Agent: KMail/1.11.90 (Linux/2.6.24-24-generic; KDE/4.2.90; i686; svn-979530; 2009-06-10) Cc: gdb-patches@sourceware.org, Eli Zaretskii , Marc Khouzam References: <200909030349.38319.pedro@codesourcery.com> <837hwc4ven.fsf@gnu.org> <200909081616.18200.pedro@codesourcery.com> In-Reply-To: <200909081616.18200.pedro@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200909091040.23991.vladimir@codesourcery.com> 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-09/txt/msg00237.txt.bz2 On Tuesday 08 September 2009 Pedro Alves wrote: > OTOH, if this sounds confusing to you, it's almost certain > it will sound confusing to most users too. I'm one of those that > needs to try and get a feel for things, so, i've spent a bit > reworking things around to implement that add-inferior model, and > here's what we have now: > > >./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 > > > 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". > > This is similar, yet different from what was in the > multiprocess-20081120-branch. In that branch, you'd have > proto-inferiors (inferiors with pid == 0, like that > above), but, when you issued a "run", that would still created > yet another inferior. That turned out to be a bad idea. > > So, in this new version, an inferior ID is stable across > a "run" or "attach". This probably makes things simpler > for python scripting. > > > I've tweaked things around so that MI's thread-groups are > created at the same time as before, but obviously, MI needs to > be extended to be able to support multi-exec + multi-inferiors > properly. What do you mean precisely. I have no comment about the above behaviour in CLI, but I think that for MI it is important that the 'thread-group-created' notification is emitted only when you have "real" inferiour that frontend can interact with, and not some "fake" one that is associated with a file but is otherwise dead. Also, what is exactly requires to support multi-exec/multi-inferiours? Is there any reason why thread groups are not sufficient to represent this? - Volodya