[Lldb-commits] [PATCH] D65561: SymbolVendorELF: Perform build-id lookup even without a debug link

[Pavel Labath via Phabricator via lldb-commits]

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