Re: [Libunwind-devel] libunwind and split debug files

[Norbert Lange]

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 <address@hidden>:
> On 02/02/17 10:29 PM, Bert Wesarg wrote:
>> On Thu, Feb 2, 2017 at 6:45 PM, Dave Watson <address@hidden> 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.