binutils-gdb modified for the FreeChainXenon project
![]() When Debian (and Ubuntu) builds its binaries, it (still) doesn't use dwz's "--relative" option. This causes their debuginfo files to carry a .gnu_debugaltlink section containing a full pathname to the DWZ alt debug file, like this: $ readelf -wk /usr/bin/cat Contents of the .gnu_debugaltlink section: Separate debug info file: /usr/lib/debug/.dwz/x86_64-linux-gnu/coreutils.debug Build-ID (0x14 bytes): ee 76 5d 71 97 37 ce 46 99 44 32 bb e8 a9 1a ef 99 96 88 db Contents of the .gnu_debuglink section: Separate debug info file: 06d3bee37b8c7e67b31cb2689cb351102ae73b.debug CRC value: 0x53267655 This usually works OK, because most of the debuginfo files installed via apt will be present in /usr/lib/debug anyway. However, imagine the following scenario: - You are using /usr/bin/cat, it crashes on you and generates a corefile. - You don't want/need to "apt install" the debuginfo file for coreutils from the repositories. Instead, you already have the debuginfo files in a separate directory (e.g., $HOME/dbgsym). - You start GDB and "set debug-file-directory $HOME/dbgsym/usr/lib/debug". You then get the following message: $ gdb -ex 'set debug-file-directory ./dbgsym/usr/lib/debug' -ex 'file /bin/cat' -ex 'core-file ./cat.core' GNU gdb (Ubuntu 10.1-0ubuntu1) 10.1 ... Reading symbols from /bin/cat... Reading symbols from /home/sergio/gdb/dbgsym/usr/lib/debug/.build-id/bc/06d3bee37b8c7e67b31cb2689cb351102ae73b.debug... could not find '.gnu_debugaltlink' file for /home/sergio/gdb/dbgsym/usr/lib/debug/.build-id/bc/06d3bee37b8c7e67b31cb2689cb351102ae73b.debug This error happens because GDB is trying to locate the build-id link (inside /home/sergio/gdb/dbgsym/usr/lib/debug/.build-id) for the DWZ alt debug file, which doesn't exist. Arguably, this is a problem with how dh_dwz works in Debian, and it's something I'm also planning to tackle. But, back at the problem at hand. Besides not being able to find the build-id link in the directory mentioned above, GDB also tried to open the DWZ alt file using its filename. The problem here is that, since we don't have the distro's debuginfo installed, it can't find anything under /usr/lib/debug that satisfies it. It occurred to me that a good way to workaround this problem is to actually try to locate the DWZ alt debug file inside the debug-file-directories (that were likely provided by the user). So this is what the proposed patch does. The idea here is simple: get the filename extracted from the .gnu_debugaltlink section, and manipulate it in order to replace the initial part of the path (everything before "/.dwz/") by whatever debug-file-directories the user might have provided. I talked with Mark Wielaard and he agrees this is a sensible approach. In fact, apparently this is something that eu-readelf also does. I regtested this code, and no regressions were found. 2020-12-01 Sergio Durigan Junior <sergiodj@sergiodj.net> * dwarf2/read.c (dwz_search_other_debugdirs): New function. (dwarf2_get_dwz_file): Convert 'filename' to a std::string. Use dwz_search_other_debugdirs to search for DWZ files in the debug-file-directories provided by the user as well. |
||
---|---|---|
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 | ||
COPYING.LIB | ||
COPYING.LIBGLOSS | ||
COPYING.NEWLIB | ||
COPYING3 | ||
COPYING3.LIB | ||
depcomp | ||
djunpack.bat | ||
install-sh | ||
libtool.m4 | ||
ltgcc.m4 | ||
ltmain.sh | ||
ltoptions.m4 | ||
ltsugar.m4 | ||
ltversion.m4 | ||
lt~obsolete.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.