]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
gdb: fix reopen_exec_file for files with target: prefix
authorAndrew Burgess <aburgess@redhat.com>
Thu, 5 Oct 2023 12:12:42 +0000 (13:12 +0100)
committerAndrew Burgess <aburgess@redhat.com>
Mon, 20 Nov 2023 10:54:17 +0000 (10:54 +0000)
commit70fd94b244573225cb04ae41101d495def78b9e6
treeab1cdac72867068697707e91404226f27bc9aae9
parent96619f154a3b9bbd8e3dbd5b4408fa4f27d67f17
gdb: fix reopen_exec_file for files with target: prefix

Following on from this commit:

  commit f2c4f78c813a9cef38b7e9c9ad18822fb9e19345
  Date:   Thu Sep 21 16:35:30 2023 +0100

      gdb: fix reread_symbols when an objfile has target: prefix

In this commit I update reopen_exec_file to correctly handle
executables with a target: prefix.  Before this commit we used the
system 'stat' call, which obviously isn't going to work for files with
a target: prefix (files located on a possibly remote target machine).

By switching to bfd_stat we will use remote fileio to stat the remote
files, which means we should now correctly detect changes in a remote
executable.

The program_space::ebfd_mtime variable, with which we compare the
result of bfd_stat is set with a call to bfd_get_mtime, which in turn
calls bfd_stat, so comparing to the result of calling bfd_stat makes
sense (I think).

As I discussed in the commit f2c4f78c813a, if a BFD is an in-memory
BFD, then calling bfd_stat will always return 0, while bfd_get_mtime
will always return the time at which the BFD was created.  As a result
comparing the results will always show the file having changed.

I don't believe that GDB can set the main executable to an in-memory
BFD object, so, in this commit, I simply assert that the executable is
not in-memory.  If this ever changes then we would need to decide how
to handle this case -- always reload, or never reload.  The assert
doesn't appear to trigger for our current test suite.

Approved-By: Tom Tromey <tom@tromey.com>
gdb/corefile.c
gdb/testsuite/gdb.server/target-exec-file.exp