Bugzilla – Bug 1215480
[gdb/symtab] build-id debuginfo link doesn't work when debugging from outside container
Last modified: 2023-10-09 13:15:09 UTC
[ This might be a dup of PR1197415. ] Consider this upstream PR ( https://sourceware.org/bugzilla/show_bug.cgi?id=30866 ): "[gdb/symtab] symbolic links to debuginfo not followed when debugging from outside container". It exercises 4 scenarios for finding debug info: 2 from inside the container, two from outside. For the former both work, for the latter the build-id case works but the .gnu_debuglink case doesn't (which is the subject of the upstream PR). The latter cases are with gdb build from current source, and the results reproduce with the gdb-12-branch. However, when using system gdb (12.1 based), also the build-id case doesn't work: ... Looking for separate debug info (build-id) for target:/lib64-symlink/libc.so.6 Trying /usr/lib/debug/.build-id/76/7aa1e4d4fc7c106971b202b6b00e92f47411dc.debug... Trying target:/usr/lib/debug/.build-id/76/7aa1e4d4fc7c106971b202b6b00e92f47411dc.debug... Looking for separate debug info (debug link) for target:/lib64-symlink/libc.so.6 Trying target:/lib64-symlink/libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable to open. Trying target:/lib64-symlink/.debug/libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable to open. Trying target:/usr/lib/debug//lib64-symlink/libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable to open. Trying target:/usr/lib/debug/lib64-symlink//libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable to open. Trying target:target:/usr/lib/debug/lib64-symlink//libc-2.31.so-2.31-150300.52.2.x86_64.debug... no, unable to open. Missing separate debuginfo for target:/lib64-symlink/libc.so.6 ... This looks like a problem with one of the fedora patches.
Tentative patch: ... diff --git a/gdb/build-id.c b/gdb/build-id.c index c90daab5592..a110958d34b 100644 --- a/gdb/build-id.c +++ b/gdb/build-id.c @@ -523,6 +523,8 @@ build_id_to_debug_bfd_1 (const std::string &orig_link, size_t build_id_len, if (seqno > 0) { + break; + /* There can be multiple build-id symlinks pointing to real files with the same build-id (such as hard links). Some of the real files may not be installed. */ @@ -532,6 +534,7 @@ build_id_to_debug_bfd_1 (const std::string &orig_link, size_t build_id_len, ret_link = link; +#if 0 struct stat statbuf_trash; /* `access' automatically dereferences LINK. */ @@ -540,6 +543,7 @@ build_id_to_debug_bfd_1 (const std::string &orig_link, size_t build_id_len, /* Stop increasing SEQNO. */ break; } +#endif /* lrealpath() is expensive even for the usually non-existent files. */ gdb::unique_xmalloc_ptr<char> filename_holder; ...
(In reply to Tom de Vries from comment #0) > This looks like a problem with one of the fedora patches. Reported by email to gdb maintainers affiliated with Red Hat.