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 https://reviews.llvm.org/D65561/new/ https://reviews.llvm.org/D65561 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
