[Lldb-commits] [PATCH] D65561: SymbolVendorELF: Perform build-id lookup even without a debug link
Pavel Labath via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Mon Aug 5 00:33:56 PDT 2019
labath added a comment.
The "real" goal is being able to search for external debug files using the build-id without them having the gnu_debuglink thingy. :)
That would seem to at odds with your " .gnu_debuglink is considered as a flag" assertion, but I am not sure how you came to believe that. The gdb documentation for separate debug files https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html stops short of saying that the build-id can be used without the debug link, but it does speak of them as two "methods" for finding external debug info, which at least to me, is a pretty clear indication that they can be used independently. And indeed, if you try to create such a situation, gdb will happily load the debug info from the separate file based on the build id alone:
/tmp/B $ readelf -S a.out | grep gnu # no .gnu_debuglink
[ 2] .note.gnu.build-i NOTE 00000000000002c4 000002c4
[ 4] .gnu.hash GNU_HASH 0000000000000308 00000308
[ 7] .gnu.version VERSYM 0000000000000498 00000498
[ 8] .gnu.version_r VERNEED 00000000000004a8 000004a8
/tmp/B $ gdb
GNU gdb (Gentoo 8.3 vanilla) 8.3
(gdb) set debug-file-directory /tmp/B/D
(gdb) file a.out
Reading symbols from a.out...
Reading symbols from /tmp/B/D/.build-id/7e/d1cb4d4300b8ff67f2f2ef5b273666e339a8ba.debug... # <== symbols found here
That said, I agree the extra filesystem accesses are bad, and they are a completely unintended side-effect of this patch. If that is the only issue, then I think this can be easily fixed by first checking whether the main object file contains any debug info, and skipping the rest of the lookup in that case.
CHANGES SINCE LAST ACTION
More information about the lldb-commits