[PATCH] libdw: Try .gnu_debugaltlink paths relative to the debug file

Josh Stone jistone at redhat.com
Tue Dec 17 18:12:46 UTC 2013

On 12/17/2013 01:59 AM, Mark Wielaard wrote:
> On Mon, 2013-12-16 at 11:16 -0800, Josh Stone wrote:
>> On 12/16/2013 06:17 AM, Mark Wielaard wrote:
>>> On Sat, 2013-12-14 at 13:51 -0800, Josh Stone wrote:
>>>> In Fedora, these paths are relative to the debug file itself, so that's
>>>> a better thing to try first.  We don't actually have the debug path in
>>>> libdw, but we can usually find it from elf->fildes and /proc/self/fd/.
>>> It is a smart trick (using Elf internals though).
>> Is that a problem to use libelfP.h?  I see this going on elsewhere, in
>> elflint, readelf, libdw/cfi.h, and a few places in libdwfl.  At least
>> fildes is a pretty unassuming detail of the implementation, IMO.
> No it isn't on itself. But it is a warning flag to check why we need to
> use any internals and why a user couldn't do something similar
> themselves. In some cases there are very good reasons to use and hide
> implementation details like these. In this case however I do think it
> shows something "fishy" is going on. An Elf might or might not be backed
> by a fildes (anymore). Like when elf_cntl (elf, ELF_C_FDREAD) has
> already been called. So this "trick" might or might not work depending
> on internal state of the Elf.

That will make fildes = -1, so the procfs trick will be just skipped,
and alt file searching will be no worse than it was before.

I'm not arguing against moving all of the alt file lookup to libdwfl.
Its path-based operation will make this easier, it's true.  I might even
volunteer for this later, when I need a diversion from normal tasks -
just not today.

But this patch is not critical either.  If the feeling here is "no more
changes until the API is fixed" - so be it.


More information about the elfutils-devel mailing list