]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
gdb: add core file name to 'info inferiors' output
authorAndrew Burgess <aburgess@redhat.com>
Wed, 10 Sep 2025 16:05:26 +0000 (17:05 +0100)
committerAndrew Burgess <aburgess@redhat.com>
Thu, 2 Oct 2025 18:25:44 +0000 (19:25 +0100)
commit1c760c0036c5686f84b8eb918358a7614f8539cd
treedaf3cef85c414aed9713492f66e0c504aa70a20a
parentace1656dad5a9dea2163bf28917c1f74cd655c74
gdb: add core file name to 'info inferiors' output

This commit builds on the previous commit.  In the future I am
proposing to move the core file BFD from the program_space into the
core_target.  In the last commit I updated 'maint info program-spaces'
to remove the core file name from the output.

In this commit I'm adding the core file name to the 'info inferiors'
output.

My proposal is to add the core file as auxiliary information beneath
an inferior's line in the 'info inferiors' output.  We already do
this vfork parent/child information.

The alternative would be to add the core file as an additional column
in the 'info inferiors' output, indeed, I did initially propose this:

  https://inbox.sourceware.org/gdb-patches/e3e040272a0f8f5fd826298331da4c19d01f3a5e.1757615333.git.aburgess@redhat.com

But the problem with this is that the 'info inferiors' output can
easily become very long, and the line wrapping gets very messy, making
the output much harder to parse.  The feedback on this initial
approach wasn't super strong, so I'm trying the auxiliary information
approach to see if this is liked more.

The new output looks like this:

  (gdb) info inferiors
    Num  Description       Connection           Executable
  * 1    process 54313     1 (core)             /tmp/executable
          core file /tmp/core.54313

The only other option I can think of, if this approach is not liked,
would be to add an entirely new command, 'info core-files', with
output like:

    Num  Core File
  * 1    /tmp/corefile.core

The 'Num' column here would just be the inferior number again.  In
effect this new command is just splitting the 'info inferiors' into
two commands.

I extended gdb.base/corefile.exp to check the current output style,
and updated the gdb.multi/multi-target-info-inferiors.exp test to take
the new output into account.

Approved-By: Tom Tromey <tom@tromey.com>
gdb/NEWS
gdb/doc/gdb.texinfo
gdb/inferior.c
gdb/testsuite/gdb.base/corefile.exp
gdb/testsuite/gdb.multi/multi-target-info-inferiors.exp