Binutils with MCST patches
98c59b527b
The patch makes GDB do exec-file-mismatch validation by comparing build IDs instead of the current method of comparing filenames. Currently, the exec-file-mismatch feature simply compares filenames to decide whether the exec file loaded in gdb and the exec file the target reports is running match. This causes false positives when remote debugging, because it'll often be the case that the paths in the host and the target won't match. And of course misses the case of the files having the same name but being actually different files (e.g., different builds). This also broke many testcases when running against gdbserver, causing tests to be skipped like (here native-extended-gdbserver): (gdb) run Starting program: /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink-filelink warning: Mismatch between current exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink-filelink and automatically determined exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink exec-file-mismatch handling is currently "ask" Load new symbol table from "/home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink"? (y or n) UNTESTED: gdb.base/argv0-symlink.exp: could not run to main or to fail like (here native-gdbserver): (gdb) spawn /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/../../gdbserver/gdbserver --once localhost:2346 /home/pedro/gdb/binutils-gdb/build/gdb/te stsuite/outputs/gdb.btrace/buffer-size/skip_btrace_tests-19968.x Process /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.btrace/buffer-size/skip_btrace_tests-19968.x created; pid = 20040 Listening on port 2346 target remote localhost:2346 Remote debugging using localhost:2346 warning: Mismatch between current exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/temp/19968/skip_btrace_tests-19968.x and automatically determined exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.btrace/buffer-size/skip_btrace_tests-19968.x exec-file-mismatch handling is currently "ask" Load new symbol table from "/home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.btrace/buffer-size/skip_btrace_tests-19968.x"? (y or n) Quit (gdb) UNSUPPORTED: gdb.btrace/buffer-size.exp: target does not support record-btrace The former case is about GDB not realizing the two files are the same, because one of the them is a symlink to the other. The latter case is about GDB realizing that one file is a copy of the other. Over the years, the toolchain has settled on build ID matching being the canonical method to match core dumps to executables, and executables with no debug info to their debug info. This patch makes us use build IDs to match the running image of a binary with its version loaded in gdb, which may or may not have debug info. This is very much like the core dump/executable matching. The change to gdb_bfd_open is necessary to get rid of the "transfers from remote targets can be slow" warning when we open the remote file to read its build ID: (gdb) r Starting program: /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/break/break Reading /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: Mismatch between current exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/break/break and automatically determined exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink exec-file-mismatch handling is currently "ask" Load new symbol table from "/home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/argv0-symlink/argv0-symlink"? (y or n) While trying this out, I was worried that bfd would read a lot of stuff from the binary in order to extract the build ID, making it potentially slow, but turns out we don't read all that much. Maybe a couple hundred bytes, and most of it seemingly is the read-ahead cache. So I'm not worried about that. Otherwise I'd consider whether a new qXfer:buildid:read would be better. But I'm happy that we seemingly don't need to worry about it. gdb/ChangeLog: 2020-05-19 Pedro Alves <palves@redhat.com> * NEWS (set exec-file-mismatch): Adjust entry. * exec.c: Include "build-id.h". (validate_exec_file): Try to match build IDs instead of filenames. * gdb_bfd.c (struct gdb_bfd_open_closure): New. (gdb_bfd_iovec_fileio_open): Adjust to use gdb_bfd_open_closure and pass down 'warn_if_slow'. (gdb_bfd_open): Add 'warn_if_slow' parameter. Use gdb_bfd_open_closure to pass it down. * gdb_bfd.h (gdb_bfd_open): Add 'warn_if_slow' parameter. gdb/doc/ChangeLog: 2020-05-19 Pedro Alves <palves@redhat.com> * gdb.texinfo (Attach): Update exec-file-mismatch description to mention build IDs. (Separate Debug Files): Add "build id" anchor. |
||
---|---|---|
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.