Re: Move the multi-forks support to the generic multi-inferiors support.

Pedro Alves
2009-05-31T22:07:47Z

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