From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9038 invoked by alias); 31 May 2009 22:07:47 -0000 Received: (qmail 9030 invoked by uid 22791); 31 May 2009 22:07:46 -0000 X-SWARE-Spam-Status: No, hits=-2.4 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; Sun, 31 May 2009 22:07:41 +0000 Received: (qmail 9006 invoked from network); 31 May 2009 22:06:39 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 31 May 2009 22:06:39 -0000 From: Pedro Alves To: gdb-patches@sourceware.org, tromey@redhat.com Subject: Re: Move the multi-forks support to the generic multi-inferiors support. Date: Sun, 31 May 2009 22:07:00 -0000 User-Agent: KMail/1.9.10 References: <200905310013.38916.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200905312308.04692.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-05/txt/msg00672.txt.bz2 On Sunday 31 May 2009 21:45:33, Tom Tromey wrote: > Pedro> So, what I want to do is, to get rid of the linux-fork.c "multi-forks" > Pedro> support, replace it with generic "multi-inferior" support, but > Pedro> leave the checkpoint support there. That is what the patch > Pedro> below does. > > Your plan sounds good to me. (I didn't read the patch yet, so no > comments on that.) Great. Thanks for commenting. > Pedro> In fact, I believe that the correct abstraction is for all > Pedro> these checkpoint forks to be associated with the same inferior > Pedro> id. > > Pedro> | info forks | delete, replaced by the | > Pedro> | | generic "info inferiors" | > > I guess "info inferiors" would show all the checkpointed forks for a > given inferior? That's one option, sure. I haven't given much attention to user interface details of checkpoints. Another idea we be to just flag that there are checkpoints available, and then the user can do the usual "info checkpoints" to see them. This avoids having a too crowded "info inferiors" output. Anyway, there's one issue that needs fixing if you want that. The current checkpoints implementation is all private and pretty much hacked into linux-nat.c. The core of GDB has really has no clue of what a checkpoint is, hence neither does the "info inferiors" part of gdb. > BTW, I think the "info inferiors" output still needs cleaning up, a la > http://sourceware.org/ml/gdb-patches/2008-11/msg00666.html If you look at head's "info inferiors" output, it's not about cleaning up, it's about cooking something. :-) When some multi-exec design settles on head (the design/implementation I'm pushing has diverged too much from what's in that branch; please consider that branch closed, as it had serious limitations and design "problems"), we'll certainly have more fields to output on "info inferiors". > > Pedro> What do you think? > > Do it. > -- Pedro Alves