]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit - gdb/ChangeLog
Search for DWZ files in debug-file-directories as well
authorSergio Durigan Junior <sergiodj@sergiodj.net>
Sat, 14 Nov 2020 22:42:46 +0000 (17:42 -0500)
committerSergio Durigan Junior <sergiodj@sergiodj.net>
Wed, 2 Dec 2020 03:03:18 +0000 (22:03 -0500)
commit2bf3b79d05bf85e41cbdcb020bd1cc424f59dd9a
tree0885f67f968e107a8e50816dc89ba7e476c7b45c
parent77bf7e991150d3fac70294910c027c43ae5789b6
Search for DWZ files in debug-file-directories as well

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.
gdb/ChangeLog
gdb/dwarf2/read.c