> because the .gnu_debuglink for libc (libc.so.6) was "libc-2.19.so".
That seems rather odd, the debuglink is typically to `<filename>.debug`. What distro uses the same name without an extension? > If the user has a newer version of debug symbols in the library directory > than those in /usr/lib/debug (perhaps because he is working on the library), > then those should get picked up anyway, because the newer library should have > a different UUID. Note that on FreeBSD we use .gnu_debuglink but do not (yet) have build-ID in binaries/libraries. Moving up the `files.push_back (dirname + "/.build-id/" + uuid_str);` at line 81 may be what you want instead. Also this change doesn't match GDB's ordering, which is: - /usr/lib/debug/.build-id/ab/cdef1234.debug - /usr/bin/ls.debug - /usr/bin/.debug/ls.debug - /usr/lib/debug/usr/bin/ls.debug. (from https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html) ================ Comment at: test/functionalities/unwind/noreturn/TestNoreturnUnwind.py:47-49 @@ -46,3 +46,5 @@ for f in thread.frames: - if f.GetFunctionName() == "abort": + # We use endswith() to look for abort() since some C libraries mangle the symbol into + # __GI_abort or similar. + if f.GetFunctionName().endswith("abort"): break ---------------- This is needed because you now have debug data for libc? http://reviews.llvm.org/D7595 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ lldb-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
