Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
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	[thread overview]
Message-ID: <200905312308.04692.pedro@codesourcery.com> (raw)
In-Reply-To: <m3hbz1vw5u.fsf@fleche.redhat.com>

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


  reply	other threads:[~2009-05-31 22:07 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-30 23:13 Pedro Alves
2009-05-31 20:46 ` Tom Tromey
2009-05-31 22:07   ` Pedro Alves [this message]
2009-05-31 22:23     ` Doug Evans
2009-06-01 15:58     ` Tom Tromey
2009-06-06  0:09       ` Tom Tromey
2009-06-06 16:06         ` Pedro Alves
2009-06-08  1:34           ` Marc Khouzam
2009-06-08 22:43             ` Tom Tromey
2009-06-08 23:22               ` Pedro Alves
2009-06-08 22:39           ` Tom Tromey
2009-06-08 23:16             ` Pedro Alves
2009-06-10 22:09               ` Tom Tromey
2009-06-10 22:13                 ` Pedro Alves
2009-06-08 12:58 ` Pedro Alves
2009-06-11 19:32 ` Michael Snyder
2009-07-01 18:27   ` Pedro Alves
2009-07-01 19:16     ` Eli Zaretskii
2009-07-02 14:32       ` Pedro Alves
2009-07-02 19:00         ` Eli Zaretskii
2009-07-02 21:59           ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200905312308.04692.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox