Hi,
This is not a valid approach, the code in os-linux.c searches the
debugdir + path of the executable, which is a very shaky assumption
and only works for some package-managed systems. The .gnu_debuglink
section is not even considered (its only for loading the .debug_frame
section as far as I can tell).
you can run the programm through strace to see which files are attempted.
The current scheme seems wrong, as it
- ignores .gnu_debuglink for reading debug information (asside from
.debug_frame - only if its enabled)
- assumes some distro-specific layouts within the /usr/lib/debug directory
- looking specifically at debian, it seems that .note.gnu.build-id
should be preferred. (supporting every distro specific stuff is
arguably not realistic, but )
Example for libc6.so on debian:
readelf -n -p .gnu_debuglink /usr/lib/x86_64-linux-gnu/libc.so.6
String dump of section '.gnu_debuglink':
[ 0] 725acf575edd8ab3451049e651dbdff55ebf33.debug
Displaying notes found in: .note.gnu.build-id
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 29725acf575edd8ab3451049e651dbdff55ebf33
Displaying notes found in: .note.ABI-tag
Owner Data size Description
GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag)
OS: Linux, ABI: 2.6.32
-----------------------------------------------
The actual file is in
/usr/lib/debug/.build-id/29/725acf575edd8ab3451049e651dbdff55ebf33.debug
PS. I actually don`t know how libunwind finds symbol/line information.
it doesnt seems like its using ".debug_line" and consorts?
2017-02-02 22:56 GMT+01:00 Dave Watson <davejwat...@fb.com>:
> On 02/02/17 10:29 PM, Bert Wesarg wrote:
>> On Thu, Feb 2, 2017 at 6:45 PM, Dave Watson <davejwat...@fb.com> wrote:
>> > On 02/02/17 09:58 AM, Norbert Lange wrote:
>> >> Hello,
>> >>
>> >> I want to display stacktraces in cases of crashes, and libunwind is
>> >> incapable of following the gnu_debuglink for debug information, and
>> >> cant resolve function names. The configure option --enable-debug-frame
>> >> *does resolve the right debug file*, but only seems to use it for
>> >> something else.
>> >>
>> >> Is this supposed to not work? Debug-infos can easily take dozens of
>> >> MB, so not stripping them is a annoying handicap.
>> >>
>> >
>> > Known issue. At least on master, src/os-linux.c hardcodes
>> > /usr/lib/debug... as the path to look for split debug files, instead
>> > of following the gnu_debuglink section. Hopefully we'll get it fixed
>> > shortly, diffs welcome.
>>
>> And this is probably what Norbert mean with "*does resolve the right
>> debug file*". But it is still not able to get a proc name.
>
> I changed the hardcoded path /usr/lib/debug%s to instead point to the
> unwind_split.dbg file, and it does indeed show the correct function
> names. So the get_proc_name lookup isn't using gnu_debuglink, but the
> actual unw_step() function looks like it is loading it.
_______________________________________________
Libunwind-devel mailing list
Libunwind-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
