From: Andrew Burgess <aburgess@redhat.com>
Date: Thu, 22 May 2025 13:29:49 +0000 (+0100)
Subject: gdb: better warning when attaching, and executable is unknown
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=bed15c776d137c0ad70afb770c8320f34d9cd173;p=thirdparty%2Fbinutils-gdb.git

gdb: better warning when attaching, and executable is unknown

Currently, when attaching to a process, if the user hasn't told GDB
which executable they are going to be debugging, GDB will try to
figure out the executable from the running process.

There are two (for this patch) interesting places where this can fail,
both in exec_file_locate_attach.

First GDB calls target_pid_to_exec_file, this does target specific
"stuff" to find the name of the executable file.  If this returns NULL
then GDB will give a warning and return.

After this we need to "find" the executable.  This is where we apply
things like the sysroot in order to transform the executable path.
This is done by calling exec_file_find, and this too can return NULL
to indicate that the executable couldn't be found.

Currently, if exec_file_find returns NULL then GDB doesn't give a
warning, instead we push on and call try_open_exec_file passing in the
NULL pointer as the filename string.  This has the effect of removing
the current executable from the current program space.

However, exec_file_locate_attach already checks there is no executable
attached to the current program space.  If there was, then there would
be no need to try and lookup the executable from the running process.
So calling try_open_exec_file with a NULL string is, I claim,
pointless.

But worse, calling try_open_exec_file with a NULL string means that
GDB prints the message: "No executable file now.", which, while
correct, isn't (I think) very helpful.  To me this message indicates
that we've moved from a state of having an executable to a state of
not having one, which isn't correct.

I think we should introduce a new warning in exec_file_locate_attach,
which is printed if the executable cannot be found.

So, before this patch GDB's output looked like this:

  (gdb) attach 12345
  Attaching to process 12345
  No executable file now.
  warning: Could not load vsyscall page because no executable was specified
  0x00007f0978b94557 in ?? ()
  (gdb)

After this patch the output now looks like this:

  (gdb) attach 12345
  Attaching to process 12345
  No executable has been specified, and target executable /tmp/my-exec (deleted) could not be found.  Try using the "file" command.
  warning: Could not load vsyscall page because no executable was specified
  0x00007f0978b94557 in ?? ()
  (gdb)

This warning includes the name of the file that GDB was looking for,
and gives a hint that the 'file' command should be used to tell GDB
which executable is being debugged.  Much better.

There's no test for this change in this commit.  The next commit fixes
another (semi-related) bug, and includes a test that checks for this
warning string.
---

diff --git a/gdb/exec.c b/gdb/exec.c
index d08ac7a38f4..b998809fdeb 100644
--- a/gdb/exec.c
+++ b/gdb/exec.c
@@ -338,6 +338,14 @@ exec_file_locate_attach (int pid, int defer_bp_reset, int from_tty)
 
   gdb::unique_xmalloc_ptr<char> exec_file_host
     = exec_file_find (exec_file_target, NULL);
+  if (exec_file_host == nullptr)
+    {
+      warning (_("No executable has been specified, and target executable "
+		 "%ps could not be found.  Try using the \"%ps\" command."),
+	       styled_string (file_name_style.style (), exec_file_target),
+	       styled_string (command_style.style (), "file"));
+      return;
+    }
 
   if (defer_bp_reset)
     add_flags |= SYMFILE_DEFER_BP_RESET;