Bug 31846 - GDB fails to read build ID from debug file
Summary: GDB fails to read build ID from debug file
Status: UNCONFIRMED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-06-05 09:54 UTC by Antoine Allard
Modified: 2024-06-14 19:49 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Antoine Allard 2024-06-05 09:54:22 UTC
I have reproduced this issue with both GDB 14.2 and HEAD.
I have a separate debug file _debug/.build-id/d8/93a4204e84a2777fd175096616364bcdfb6714.debug_ that GDB is resolving but skips with the following warning:
```
(gdb) symbol-file XXX
Reading symbols from XXX...
warning: File "debug/.build-id/d8/93a4204e84a2777fd175096616364bcdfb6714.debug" has no build-id, file skipped
```

However, other tools can read the build ID embedded in this debug file:
``` 
$ file --version
file-5.33
$ file debug/.build-id/d8/93a4204e84a2777fd175096616364bcdfb6714.debug
debug/.build-id/d8/93a4204e84a2777fd175096616364bcdfb6714.debug: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter *empty*, for GNU/Linux 3.2.0, BuildID[sha1]=d893a4204e84a2777fd175096616364bcdfb6714, with debug_info, not stripped
$ readelf --version
GNU readelf version 2.30-119.el8
$ readelf -n debug/.build-id/d8/93a4204e84a2777fd175096616364bcdfb6714.debug | grep "Build ID:"
    Build ID: d893a4204e84a2777fd175096616364bcdfb6714
```

I have another binary from the same build that GDB has no issue with:
```
(gdb) symbol-file YYY
Reading symbols from YYY...
Reading symbols from debug/.build-id/dc/48b56fec6a71a384f0b78dfa0431f25d6fb62f.debug...
```

The only difference as far as I can tell is in the size of the debug files:
```
# XXX skipped debug file
$ du -skh debug/.build-id/d8/93a4204e84a2777fd175096616364bcdfb6714.debug
5.6G    debug/.build-id/d8/93a4204e84a2777fd175096616364bcdfb6714.debug

# YYY loaded debug file
$ du -skh debug/.build-id/dc/48b56fec6a71a384f0b78dfa0431f25d6fb62f.debug
19M     debug/.build-id/dc/48b56fec6a71a384f0b78dfa0431f25d6fb62f.debug
```

I tried to debug GDB itself and I was able to pinpoint to difference between XXX and YYY to the calls to `bfd_check_format()` in `build_id_bfd_get()` [gdb/build-id.c:33](https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/build-id.c;h=41667d5e5cf3dd9fb3a9f778fb56d21a2e3485c0;hb=HEAD#l41).
Both call `bfd_check_format()` return false in the case of the XXX debug file, but I am not able to understand why.
Comment 1 Antoine Allard 2024-06-14 14:17:01 UTC
Any insight on the possible root cause of this issue or how to debug GDB itself to understand what's wrong with my binaries would be really appreciated :)
(not sure if I filled the bug report correctly as well, let me know if that's not the case)
Comment 2 Antoine Allard 2024-06-14 14:17:31 UTC
Any insight on the possible root cause of this issue or how to debug GDB itself to understand what's wrong with my binaries would be really appreciated :)
(not sure if I filled the bug report correctly as well, let me know if that's not the case)
Comment 3 Simon Marchi 2024-06-14 19:49:04 UTC
I have no idea off hand for your actual problem.  But to debug GDB, configure (the top-level configure in binutils-gdb) with something like:

  $ ./configure CFLAGS="-g3 -O0" CXXFLAGS="-g3 -O0"
  $ make all-gdb -j$(nproc)  # the all-gdb target, in order to avoid building the other tools

Then I usually cd in the gdb directory and use:

  $ ./gdb -nx -q --data-directory=data-directory <other args>

And you can debug gdb itself by doing:

  $ gdb --args ./gdb -nx -q --data-directory=data-directory <other args>

Debugging something like this should be relatively easy, since it's not something timing dependent.  Break at the point the message is issued and work your way up to see when code paths diverge.