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.