gdb: use mapped file information to improve debuginfod text

When opening a core-file GDB is able to use debuginfod to download the
executable that matches the core-file if GDB can find a build-id for
the executable in the core-file.

In this case GDB calls debuginfod_exec_query to download the
executable and GDB prints a message like:

  Downloading executable for /path/to/core-file...

which makes sense in that case.

For a long time GDB has also had the ability to download memory-mapped
files and shared libraries when opening a core-file.  However, recent
commits have made these cases more likely to trigger, which is a good
thing, but the messaging from GDB in these cases is not ideal.  When
downloading a memory-mapped file GDB prints:

  Downloading executable for /path/to/memory-mapped-file

And for a shared library:

  Downloading executable for /path/to/libfoo.so

These last two messages could, I think, be improved.

I propose making two changes.  First, I suggest instead of using
/path/to/core-file in the first case, we use the name of the
executable that GDB is fetching.  This makes the messaging consistent
in that we print the name of the file we're fetching rather than the
name of the file we're fetching something for.

I further propose that we replace 'executable for' with the more
generic word 'file'.  The messages will then become:

  Downloading file /path/to/exec-file...
  Downloading file /path/to/memory-mapped-file...
  Downloading file /path/to/libfoo.so...

I think these messages are clearer than what we used to have, and they
are consistent in that we name the thing being downloaded in all
cases.

There is one tiny problem.  The first case relies on GDB knowing the
name of the executable it wants to download.  The only place we can
currently get that from is, I think, the memory-mapped file list.

[ ASIDE: There is `bfd_core_file_failing_command` which reports the
  executable and argument list from the core file, but this
  information is not ideal for this task.  First, the executable and
  arguments are merged into a single string, and second, the string is
  a relatively short, fixed length string, so the executable name is
  often truncated.  For these reasons I don't consider fetching the
  executable name using this bfd function as a solution. ]

We do have to consider the case that the core file does not have any
mapped file information.  This shouldn't ever be the case for a Linux
target, but it's worth considering.

[ ASIDE: I mention Linux specifically because this only becomes a
  problem if we try to do a lookup via debuginfod, which requires that
  we have build-ids available.  Linux has special support for
  embedding build-ids into the core file, but I'm not sure if other
  kernels do this. ]

For the unlikely edge case of a core-file that has build-ids, but
doesn't have any mapped file information then I propose that we
synthesis a filename like: 'with build-id xxxxxx'.  We would then see
a message like:

  Downloading file with build-id xxxxxx...

Where 'xxxxxx' would be replaced by the actual build-id.

This isn't ideal, but I think is good enough, and, as I said, I think
this case is not going to be hit very often, or maybe at all.

We already had some tests that emitted two of the above messages,
which I've updated, these cover the mapped-file and shared library
case.

The message about downloading the exec for the core-file is actually
really hard to trigger now as usually the exec will also appear in the
memory-mapped file list and GDB will download the file at this stage.
Then when GDB needs the executable for loading the symbols it'll ask
debuginfod, and debuginfod will find the file in its cache, and so no
message will be printed.

If anyone has any ideas about how to trigger this case then I'm happy
to add additional tests.

Approved-By: Tom Tromey <tom@tromey.com>

2 files changed, 2 insertions, 2 deletions

diff --git a/gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp b/gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp
index cf96b41..cad70aa 100644
--- a/gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp
+++ b/gdb/testsuite/gdb.debuginfod/corefile-mapped-file.exp
@@ -370,7 +370,7 @@ with_debuginfod_env $cache {
     gdb_load $binfile
 
     load_core_file "load corefile, download library from debuginfod" \
-	"Downloading\[^\r\n\]* executable for [string_to_regexp $library_filename]\\.\\.\\."
+	"Downloading\[^\r\n\]* file [string_to_regexp $library_filename]\\.\\.\\."
 
     set ptr_value [read_ptr_value]
     gdb_assert { $ptr_value == $ptr_expected_value } \
diff --git a/gdb/testsuite/gdb.debuginfod/solib-with-soname.exp b/gdb/testsuite/gdb.debuginfod/solib-with-soname.exp
index 9ef1204..31ca718 100644
--- a/gdb/testsuite/gdb.debuginfod/solib-with-soname.exp
+++ b/gdb/testsuite/gdb.debuginfod/solib-with-soname.exp
@@ -161,7 +161,7 @@ proc load_exec_and_core_file { expect_warning expect_download testname \
 		set saw_warning true
 		exp_continue
 	    }
-	    -re "^Downloading executable for \[^\r\n\]+/libfoo_1\\.so\\.\\.\\.\r\n" {
+	    -re "^Downloading file \[^\r\n\]+/libfoo_1\\.so\\.\\.\\.\r\n" {
 		set saw_download true
 		exp_continue
 	    }