[binutils-gdb] gdb: better warning when attaching, and executable is unknown

[Andrew Burgess]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bed15c776d137c0ad70afb770c8320f34d9cd173

commit bed15c776d137c0ad70afb770c8320f34d9cd173
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Thu May 22 14:29:49 2025 +0100

    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:
---
 gdb/exec.c | 8 ++++++++
 1 file changed, 8 insertions(+)

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;