This is the mail archive of the elfutils-devel@sourceware.org mailing list for the elfutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libdw errors for DW_FORM_GNU_strp_alt attributes


On 04/07/2014 04:37 PM, Mark Wielaard wrote:

>> How can I obtain these attributes?
>
> If elfutils was configure with --enable-dwz then it should automagically
> find the alternative debug (dwz) file. And it does for me on f20 with
> elfutils-libs-0.158-1.fc20.x86_64:
>
> ./report-cu /usr/lib/debug/usr/bin/bsdiff.debug
> Compilation unit at offset 0, tag 17:
>    name (format 0xe): "bsdiff.c"
>    comp_dir (format 0x1f21): "/usr/src/debug/bsdiff-4.3"
>    producer (format 0x1f21): "GNU C 4.8.1 20130717 (Red Hat 4.8.1-5) -m64 -mtune=generic -march=x86-64 -g -O2 -fexceptions -fstack-protector-strong --param ssp-buffer-size=4"
>
> The alt file is found by inspecting the .gnu_debugaltlink section in the
> bsdiff.debug file and resolving either the file name
> (../../.dwz/bsdiff-4.3-12.fc20.x86_64 which
> is /lib/debug/.dwz/bsdiff-4.3-12.fc20.x86_64) or the build-id given in
> that section (42643ed4e062195a11211c3696fc5e6cec73d0fb) which resolves
> to /lib/debug/.build-id/42/643ed4e062195a11211c3696fc5e6cec73d0fb.debug
> -> ../../.dwz/bsdiff-4.3-12.fc20.x86_64 (the same file through a soft
> link).

Thanks for the explanation.  I find it kind of surprising that libdw 
goes behind my back and opens random files based on paths extracted from 
the data I supply.  I would have expected that from libdwfl, not libdw.

Does libelf do something similar?

> We currently don't have an interface to explicitly set the alt-debug
> file for a Dwarf but should (and then the magic lookup should be moved
> from libdw to libdwfl, but that has as drawback that a simple
> dwarf_begin () won't set it automagically anymore and you'll have to
> either use dwfl_begin () to set it automagically or use an explicit
> setter for it).

Should I propose a patch with a dwarf_begin_elf function that takes an 
additional flag argument which makes this behavior user-controllable? 
Or would it be better to overload the Elf_Scn * argument?

I can't use the current file location code anyway, even if it were 
exported, because my data does not actually reside in the file system 
and certainly not at the paths expected by the library.

-- 
Florian Weimer / Red Hat Product Security Team

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]