This is the mail archive of the
mailing list for the elfutils project.
Re: libdw errors for DW_FORM_GNU_strp_alt attributes
- From: Florian Weimer <fweimer at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Mon, 07 Apr 2014 17:55:39 +0200
- Subject: 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
> ./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
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