gdb: fix reread_symbols when an objfile has target: prefix
authorAndrew Burgess <aburgess@redhat.com>
Thu, 21 Sep 2023 15:35:30 +0000 (16:35 +0100)
committerAndrew Burgess <aburgess@redhat.com>
Thu, 5 Oct 2023 11:21:46 +0000 (12:21 +0100)
When using a remote target, it is possible to tell GDB that the
executable to be debugged is located on the remote machine, like this:

  (gdb) target extended-remote :54321
  ... snip ...
  (gdb) file target:/tmp/hello.x
  Reading /tmp/hello.x from remote target...
  warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
  Reading /tmp/hello.x from remote target...
  Reading symbols from target:/tmp/hello.x...
  (gdb)

So far so good.  However, when we try to start the inferior we run
into a small problem:

  (gdb) set remote exec-file /tmp/hello.x
  (gdb) start
  `target:/tmp/hello.x' has disappeared; keeping its symbols.
  Temporary breakpoint 1 at 0x401198: file /tmp/hello.c, line 18.
  Starting program: target:/tmp/hello.x
  ... snip ...

  Temporary breakpoint 1, main () at /tmp/hello.c:18
  18   printf ("Hello World\n");
  (gdb)

Notice this line:

  `target:/tmp/hello.x' has disappeared; keeping its symbols.

That's wrong, the executable hasn't been removed, GDB just doesn't
know how to check if the remote file has changed, and so falls back to
assuming that the file has been removed.

In this commit I update reread_symbols to use bfd_stat instead of
a direct stat call, this adds support for target: files, and fixes the
problem.

This change was proposed before in this commit:

  https://inbox.sourceware.org/gdb-patches/20200114210956.25115-3-tromey@adacore.com/

However, that patch never got merged, and seemed to get stuck
discussing issues around gnulib stat vs system stat as used by BFD.

I didn't 100% understand the issues discussed in that thread, however,
I think the problem with the previous thread related to the changes in
gdb_bfd.c, rather than to the change in symfile.c.  As such, I think
this change might be acceptable, my reasoning is:

  - the objfile::mtime field is set by a call to bfd_get_mtime (see
    objfiles.c), which calls bfd_stat under the hood.  This will end
    up using the system stat,

  - In symfile.c we currently call stat directly, which will call the
    gnulib stat, which, if I understand the above thread correctly,
    might give a different result to the system stat in some cases,

  - By switching to using bfd_stat in symfile.c we should now be
    consistently calling the system stat.

There is another issue that came up during testing that this commit
fixes.  Consider this GDB session:

  $ gdb -q
  (gdb) target extended-remote | ./gdbserver/gdbserver --multi --once -
  Remote debugging using | ./gdbserver/gdbserver --multi --once -
  Remote debugging using stdio
  (gdb) file /tmp/hello.x
  Reading symbols from /tmp/hello.x...
  (gdb) set remote exec-file /tmp/hello.x
  (gdb) start
  ... snip ...
  (gdb) load
  `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
  Loading section .interp, size 0x1c lma 0x4002a8
  ... snip ...
  Start address 0x0000000000401050, load size 2004
  Transfer rate: 326 KB/sec, 87 bytes/write.

Notice this line:

  `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.

We actually see the same output, for the same reasons, when using a
native target, like this:

  $ gdb -q
  (gdb) file /tmp/hello.x
  Reading symbols from /tmp/hello.x...
  (gdb) start
  ... snip ...
  (gdb) load
  `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.
  You can't do that when your target is `native'
  (gdb)

In both cases this line appears because load_command (symfile.c) calls
reread_symbols, and reread_symbols loops over every currently loaded
objfile and tries to check if the file has changed on disk by calling
stat.

However, the `system-supplied DSO at 0x7ffff7fcf000' is an in-memory
BFD, the filename for this BFD is literally the string
'system-supplied DSO at 0x7ffff7fcf000'.

Before this commit GDB would try to use the system 'stat' call to stat
the file `system-supplied DSO at 0x7ffff7fcf000', which obviously
fails; there's no file with that name (usually).  As a consequence of
the stat failing GDB prints the ' .... has disappeared ...' line.

Initially, all this commit did was switch from using 'stat' to using
'bfd_stat'.  Calling bfd_stat on an in-memory BFD works just fine,
however, BFD just fills the 'struct stat' buffer with zeros (except
for the file size), see memory_bstat in bfd/bfdio.c.

However, there is a bit of a weirdness about in-memory BFDs.  When
they are initially created the libbfd caches an mtime within the bfd
object, this is done in bfd_from_remote_memory (elfcode.h), the cached
mtime is the time at which the in-memory BFD is created.

What this means is that when GDB creates the in-memory BFD, and we
call bfd_get_mtime(), the value returned, which GDB caches within
objfile::mtime is the creation time of the in-memory BFD.  But, when
this patch changes to use bfd_stat() we now get back 0, and so we
believe that the in-memory BFD has changed.  This is a change in
behaviour.

To avoid this change in behaviour, in this commit, I propose that we
always skip in-memory BFDs in reread_symbols.  This preserves the
behaviour from before this commit -- mostly.

As I'm not specifically checking for, and then skipping, in-memory
BFDs, we no longer see this line:

  `system-supplied DSO at 0x7ffff7fcf000' has disappeared; keeping its symbols.

Which I think is an improvement.

Co-Authored-By: Tom Tromey <tromey@adacore.com>
Approved-By: Tom Tromey <tom@tromey.com>
gdb/symfile.c
gdb/testsuite/gdb.server/target-exec-file.c [new file with mode: 0644]
gdb/testsuite/gdb.server/target-exec-file.exp [new file with mode: 0644]

index 30147b7c3df2e6765579505b12fac4aef3c62064..584a62cd1d68f61d9112857925d191a52288aa6f 100644 (file)
@@ -2475,20 +2475,32 @@ reread_symbols (int from_tty)
       if (objfile->separate_debug_objfile_backlink)
        continue;
 
-      /* If this object is from an archive (what you usually create with
-        `ar', often called a `static library' on most systems, though
-        a `shared library' on AIX is also an archive), then you should
-        stat on the archive name, not member name.  */
-      const char *filename;
-      if (objfile->obfd->my_archive)
-       filename = bfd_get_filename (objfile->obfd->my_archive);
-      else
-       filename = objfile_name (objfile);
+      /* When a in-memory BFD is initially created, it's mtime (as
+        returned by bfd_get_mtime) is the creation time of the BFD.
+        However, we call bfd_stat here as we want to see if the
+        underlying file has changed, and in this case an in-memory BFD
+        will return an st_mtime of zero, so it appears that the in-memory
+        file has changed, which isn't what we want here -- this code is
+        about reloading BFDs that changed on disk.
+
+        Just skip any in-memory BFD.  */
+      if (objfile->obfd.get ()->flags & BFD_IN_MEMORY)
+       continue;
 
       struct stat new_statbuf;
-      int res = stat (filename, &new_statbuf);
+      int res = bfd_stat (objfile->obfd.get (), &new_statbuf);
       if (res != 0)
        {
+         /* If this object is from an archive (what you usually create
+            with `ar', often called a `static library' on most systems,
+            though a `shared library' on AIX is also an archive), then you
+            should stat on the archive name, not member name.  */
+         const char *filename;
+         if (objfile->obfd->my_archive)
+           filename = bfd_get_filename (objfile->obfd->my_archive);
+         else
+           filename = objfile_name (objfile);
+
          warning (_("`%ps' has disappeared; keeping its symbols."),
                   styled_string (file_name_style.style (), filename));
          continue;
diff --git a/gdb/testsuite/gdb.server/target-exec-file.c b/gdb/testsuite/gdb.server/target-exec-file.c
new file mode 100644 (file)
index 0000000..3a264f2
--- /dev/null
@@ -0,0 +1,22 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2023 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+int
+main ()
+{
+  return 0;
+}
diff --git a/gdb/testsuite/gdb.server/target-exec-file.exp b/gdb/testsuite/gdb.server/target-exec-file.exp
new file mode 100644 (file)
index 0000000..9260df8
--- /dev/null
@@ -0,0 +1,174 @@
+# This testcase is part of GDB, the GNU debugger.
+
+# Copyright 2023 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Test GDB's handling of using a file with a 'target:' prefix as the
+# executable file.  This test includes checking what happens when the
+# file on the target system changes and GDB needs to reload it.
+
+load_lib gdbserver-support.exp
+
+require allow_gdbserver_tests !use_gdb_stub
+
+standard_testfile
+
+if { [build_executable "failed to prepare" $testfile $srcfile debug] } {
+    return -1
+}
+
+clean_restart
+
+# Some boards specifically set the sysroot to the empty string to
+# avoid copying files from the target.  But for this test we do want
+# to copy files from the target, so set the sysroot back to 'target:'.
+#
+# This is fine so long as we're not using a board file that sets the
+# sysroot to something else -- but none of the standard boards do
+# this, and plenty of other tests mess with the sysroot, so I guess we
+# don't worry about that too much.
+gdb_test "set sysroot target:" ".*"
+
+# Make sure we're disconnected, in case we're testing with an
+# extended-remote board, therefore already connected.
+gdb_test "disconnect" ".*"
+
+# Ensure the executable is on the target.
+set target_exec [gdb_remote_download target $binfile]
+
+# We're going to be restarting the inferior.  Lets ask GDB not to
+# prompt us if this is the right thing to do.
+gdb_test_no_output "set confirm off"
+
+# Start gdbserver, but always in extended-remote mode, and then
+# connect to it from GDB.
+set res [gdbserver_start "--multi" $target_exec]
+set gdbserver_protocol "extended-remote"
+set gdbserver_gdbport [lindex $res 1]
+gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
+
+# Issue a 'file' command and parse the output.  We look for a couple
+# of specific things to ensure that we are correctly reading the exec
+# from the remote target.
+set saw_read_of_remote_exec false
+set saw_read_of_syms_from_exec false
+gdb_test_multiple "file target:$target_exec" "run file command" {
+    -re "^file target:\[^\r\n\]+\r\n" {
+       exp_continue
+    }
+
+    -re "^Reading (\[^\r\n\]+) from remote target\\.\\.\\.\r\n" {
+       set filename $expect_out(1,string)
+       if { $filename eq $target_exec } {
+           set saw_read_of_remote_exec true
+       }
+       exp_continue
+    }
+
+    -re "^warning: File transfers from remote targets can be slow\[^\r\n\]+\r\n" {
+       exp_continue
+    }
+
+    -re "^Reading symbols from target:(\[^\r\n\]+)\\.\\.\\.\r\n" {
+       set filename $expect_out(1,string)
+       if { $filename eq $target_exec } {
+           set saw_read_of_syms_from_exec true
+       }
+       exp_continue
+    }
+
+    -re "^Expanding full symbols from \[^\r\n\]+\r\n" {
+       exp_continue
+    }
+
+    -re "^$gdb_prompt $" {
+       pass $gdb_test_name
+    }
+}
+
+gdb_assert { $saw_read_of_remote_exec } \
+    "exec was read from the remote target"
+
+gdb_assert { $saw_read_of_syms_from_exec } \
+    "symbols were read from remote exec file"
+
+# Start the inferior (with the 'start' command), use TESTNAME for any
+# pass/fail calls.  EXPECT_REREAD should be true or false and
+# indicates if we expect to too a line like:
+#
+#  `FILE' has changed; re-reading symbols.
+proc start_inferior { testname expect_reread } {
+    with_test_prefix $testname {
+       if { [gdb_start_cmd] < 0 } {
+           fail "start command"
+           return -1
+       }
+
+       set saw_reread false
+       gdb_test_multiple "" "stopped at main" {
+           -re "^start\\s*\r\n" {
+               exp_continue
+           }
+           -re "^`\[^\r\n\]+' has changed; re-reading symbols\\.\r\n" {
+               set saw_reread true
+               exp_continue
+           }
+           -re "^Reading \[^\r\n\]+ from remote target\\.\\.\\.\r\n" {
+               exp_continue
+           }
+           -re "^Expanding full symbols from \[^\r\n\]+\\.\\.\\.\r\n" {
+               exp_continue
+           }
+           -re "^Temporary breakpoint $::decimal at $::hex: \[^\r\n\]+\r\n" {
+               exp_continue
+           }
+           -re "^Starting program: \[^\r\n\]+\r\n" {
+               exp_continue
+           }
+           -re "^\\s*\r\n" {
+               exp_continue
+           }
+           -re "^Temporary breakpoint $::decimal, main \\(\\) at .*$::gdb_prompt $" {
+               pass $testname
+           }
+       }
+
+       gdb_assert { $expect_reread == $saw_reread } \
+           "check symbol re-read behaviour"
+    }
+}
+
+# Start the inferior for the first time.  The symbols were already
+# read from the file when the 'file' command was used, we should not
+# see the symbols re-read now.
+start_inferior "start inferior the first time" false
+
+# Re-start the inferior.  The executable is unchanged so we should not
+# see the symbol file being re-read.
+start_inferior "start inferior a second time" false
+
+# Delay for a short while so, when we touch the exec, we know the
+# timestamp will change.
+sleep 1
+set res [remote_exec target "touch $target_exec"]
+set status [lindex $res 0]
+if { $status != 0 } {
+    fail "touching executable on target"
+    return -1
+}
+
+# Start the inferior again, we expect to see the symbols being re-read
+# from the remote file.
+start_inferior "start inferior a third time" true