Re: [PATCH 1/2] Make linux checkpoints work with multiple inferiors

[Pedro Alves <pedro@palves.net>]

Hi Kevin,

On 2024-03-23 20:27, Kevin Buettner wrote:

> info_checkpoints_command used to simply iterate over the list of
> forks (checkpoints), printing each one out.  It now needs to iterate
> over all inferiors and, for those which have checkpoints, it needs
> to iterate over the list of checkpoints in that inferior.  This
> command prints out a '*' preceding the currently active checkpoint.
> That's still the case, but it'll now also print out a '+' preceding
> the current checkpoint in non-current inferiors.  E.g...
> 
>     (gdb) info checkpoints
>     + 4 process 8996 (main process) at 0x401199, file hello.c, line 51
>       5 process 9004 at 0x401199, file hello.c, line 51
>       1 process 9001 (main process) at 0x401258, file goodbye.c, line 62
>     + 6 process 9005 at 0x401258, file goodbye.c, line 62
>     * 7 process 9006 (main process) at 0x40115c, file hangout.c, line 31
>       9 process 9008 at 0x40115c, file hangout.c, line 31

This is very confusing output/design IMO.  Checkpoint numbers aren't sorted, nor is
there any indication of which inferior each checkpoint is for.

IMO, a much better interface, is to instead make "info checkpoints" multi-inferior-aware
like "info threads" is:

By making each inferior have its own checkpoint number space.  I.e., like threads have
a INF.THR id, checkpoints would have an INF.CHKP id.

And like you can suppress the inferior number when refering thread ids, i.e,.
"thread 1.1" and "thread 1" is the same thread if we're focused on inferior 1,
so would "checkpoint 1.1" and "checkpoint 1".

And with that, checkpoints for an inferior could always start at 0 (or 1) like today,
and also like we always restart the inferior thread ids at 1 when we restart an inferior.

So the example above would turn into:

     (gdb) info checkpoints
     + 1.0 process 8996 (main process) at 0x401199, file hello.c, line 51
       1.1 process 9004 at 0x401199, file hello.c, line 51
       2.0 process 9001 (main process) at 0x401258, file goodbye.c, line 62
     + 2.1 process 9005 at 0x401258, file goodbye.c, line 62
     * 3.0 process 9006 (main process) at 0x40115c, file hangout.c, line 31
       3.1 process 9008 at 0x40115c, file hangout.c, line 31

"restart 1" or "restart 3.1" would switch to checkpoint 3.1.
"restart 2.1" would switch to checkpoint 1 of inferior 2.

With this, if you create a new checkpoint for inferior 2, it gets numbered as
checkpoint 2.2 , irrespective of whether which inferior you last created a checkpoint for.

I'm also not sure whether "+" is the best interface to indicate which checkpoint is active.
I'd think we could do that with a separate column, like, e.g., a state column that indicates
which checkpoint is active, and maybe also which one is the main process:

     (gdb) info checkpoints
       Id  State  Target Id   Frame
       1.0  AM process 8996 at 0x401199, file hello.c, line 51
       1.1     process 9004 at 0x401199, file hello.c, line 51
       2.0  M  process 9001 at 0x401258, file goodbye.c, line 62
       2.1  A  process 9005 at 0x401258, file goodbye.c, line 62
     * 3.0  AM process 9006 at 0x40115c, file hangout.c, line 31
       3.1     process 9008 at 0x40115c, file hangout.c, line 31

Though really "main process" info is redundant, as it's always the one with checkpoint id 0:

     (gdb) info checkpoints
       Id  State  Target Id   Frame
       1.0  A  process 8996 at 0x401199, file hello.c, line 51
       1.1     process 9004 at 0x401199, file hello.c, line 51
       2.0     process 9001 at 0x401258, file goodbye.c, line 62
       2.1  A  process 9005 at 0x401258, file goodbye.c, line 62
     * 3.0  A  process 9006 at 0x40115c, file hangout.c, line 31
       3.1     process 9008 at 0x40115c, file hangout.c, line 31

Pedro Alves