mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-01-30 12:44:10 +08:00
2af87c859f
target_follow_exec is currently only called in the "follow-exec-mode == new" branch of follow_exec, not the "follow-exec-mode == same" branch. I think it would make sense to call it regardless of the mode to let targets do some necessary handling. This is needed in the context of rocm-gdb [1], where a target is pushed on top of the linux-nat target. On exec, it needs to do some bookkeeping, close some file descriptors / handles that were related to the process pre-exec and open some new ones for the process post-exec. However, by looking at the only in-tree implementation of target_ops::follow_exec, remote_target::follow_exec, I found that it would be useful for the extended-remote target too, to align its behavior with native debugging (although I think that behavior is not very user-friendly, see PR 27745 [2]). Using two programs, one (let's call it "execer") that execs the other (let's call it "execee"), with native: $ ./gdb -q -nx --data-directory=data-directory ./execer Reading symbols from ./execer... (gdb) r Starting program: /home/simark/build/binutils-gdb/gdb/execer I am execer process 1495622 is executing new program: /home/simark/build/binutils-gdb/gdb/execee I am execee [Inferior 1 (process 1495622) exited normally] (gdb) r Starting program: /home/simark/build/binutils-gdb/gdb/execee I am execee [Inferior 1 (process 1495626) exited normally] And now with gdbserver (some irrelevant output lines removed for brevity): $ ./gdbserver --once --multi :1234 ... $ ./gdb -q -nx --data-directory=data-directory ./execer -ex "set remote exec-file /home/simark/build/binutils-gdb/gdb/execer" -ex "tar ext :1234" Reading symbols from ./execer... Remote debugging using :1234 (gdb) r Starting program: /home/simark/build/binutils-gdb/gdb/execer process 1495724 is executing new program: /home/simark/build/binutils-gdb/gdb/execee [Inferior 1 (process 1495724) exited normally] (gdb) r `target:/home/simark/build/binutils-gdb/gdb/execee' has disappeared; keeping its symbols. Starting program: target:/home/simark/build/binutils-gdb/gdb/execee warning: Build ID mismatch between current exec-file target:/home/simark/build/binutils-gdb/gdb/execee and automatically determined exec-file target:/home/simark/build/binutils-gdb/gdb/execer exec-file-mismatch handling is currently "ask" Reading /home/simark/build/binutils-gdb/gdb/execer from remote target... Load new symbol table from "target:/home/simark/build/binutils-gdb/gdb/execer"? (y or n) When handling the exec, GDB updates the exec-file of the inferior to be the execee. This means that a subsequent "run" will run the execee, not the original executable (execer). remote_target::follow_exec is meant to update the "remote exec-file", which is the file on the remote system that will be executed if you "run" the inferior, to the execee as well. However, this is not called when follow-exec-mode is same, because target_follow_exec is not called in this branch. As a result, GDB thinks the inferior is executing execee but the remote side is really executing execer, hence the mismatch message. By calling target_follow_exec in the "same" branch of the follow_exec function, we ensure that everybody agrees, and we get the same behavior with the extended-remote target as we get with the native target, the execee is executed on the second run: $ ./gdbserver --once --multi :1234 ... $ ./gdb -q -nx --data-directory=data-directory ./execer -ex "set remote exec-file /home/simark/build/binutils-gdb/gdb/execer" -ex "tar ext :1234" Reading symbols from ./execer... Remote debugging using :1234 (gdb) r Starting program: /home/simark/build/binutils-gdb/gdb/execer process 1501445 is executing new program: /home/simark/build/binutils-gdb/gdb/execee [Inferior 1 (process 1501445) exited normally] (gdb) r `target:/home/simark/build/binutils-gdb/gdb/execee' has disappeared; keeping its symbols. Starting program: target:/home/simark/build/binutils-gdb/gdb/execee [Inferior 1 (process 1501447) exited normally] (gdb) This scenario is tested in gdb.base/foll-exec-mode.exp, and in fact this patch fixes the test for me when using --target_board=native-extended-gdbserver. gdb/ChangeLog: * infrun.c (follow_exec): Call target_follow_fork when follow-exec-mode is same. * target.h (target_follow_fork): Improve doc. [1] https://github.com/ROCm-Developer-Tools/ROCgdb [2] https://sourceware.org/bugzilla/show_bug.cgi?id=27745 Change-Id: I4ee84a875e39bf3f8eaf3e6789a4bfe23a2a430e |
||
---|---|---|
bfd | ||
binutils | ||
config | ||
contrib | ||
cpu | ||
elfcpp | ||
etc | ||
gas | ||
gdb | ||
gdbserver | ||
gdbsupport | ||
gnulib | ||
gold | ||
gprof | ||
include | ||
intl | ||
ld | ||
libctf | ||
libdecnumber | ||
libiberty | ||
opcodes | ||
readline | ||
sim | ||
texinfo | ||
zlib | ||
.cvsignore | ||
.gitattributes | ||
.gitignore | ||
ar-lib | ||
ChangeLog | ||
compile | ||
config-ml.in | ||
config.guess | ||
config.rpath | ||
config.sub | ||
configure | ||
configure.ac | ||
COPYING | ||
COPYING3 | ||
COPYING3.LIB | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
lt~obsolete.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
MAINTAINERS | ||
Makefile.def | ||
Makefile.in | ||
Makefile.tpl | ||
makefile.vms | ||
missing | ||
mkdep | ||
mkinstalldirs | ||
move-if-change | ||
multilib.am | ||
README | ||
README-maintainer-mode | ||
setup.com | ||
src-release.sh | ||
symlink-tree | ||
test-driver | ||
ylwrap |
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.