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

[Bert Wesarg]

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.

I tried it, and it looks like it is loaded:

$ UNW_DEBUG_LEVEL=15 ./unwind_split
 >_ULx86_64_init_mem_validate: using mincore to validate memory
 >_ULx86_64_init_local: (cursor=0x7ffd24119b80)
 >_ULx86_64_step: (cursor=0x7ffd24119b80, ip=0x00000000004008bf,
cfa=0x00007ffd241197b0)
              >_ULx86_64_dwarf_find_proc_info: looking for IP=0x4008be
               >_ULx86_64_dwarf_callback: checking , base=0x0)
               >_ULx86_64_dwarf_callback: found table `':
segbase=0x400a98, len=8, gp=0x601000, table_data=0x400aa4
               >_ULx86_64_dwarf_find_debug_frame: Trying to find
.debug_frame for
    >load_debug_frame: opened file
'/home/wesarg/dev/libunwind/debug-frame/unwind_split'. Section header
at offset 4576
    >load_debug_frame: loading string table of size 263
    >load_debug_frame: read 24 bytes of .gnu_debuglink from offset 4282
    >load_debug_frame: opened file
'/home/wesarg/dev/libunwind/debug-frame/unwind_split.dbg'. Section
header at offset 6448
    >load_debug_frame: loading string table of size 328
               >_ULx86_64_dwarf_find_debug_frame: loaded .debug_frame
               >_ULx86_64_dwarf_find_debug_frame: zero-length .debug_frame
               >lookup: e->start_ip_offset = ffffffffffffff28
               >lookup: e->start_ip_offset = fffffffffffffdfe
               >lookup: e->start_ip_offset = ffffffffffffff1d
               >_ULx86_64_dwarf_search_unwind_table: ip=0x4008be,
start_ip=0xfffffffffffffdfe

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.

Bert