On Tue, 2013-12-17 at 10:12 -0800, Josh Stone wrote:
On 12/17/2013 01:59 AM, Mark Wielaard wrote:
> 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.
Yes, but it also means it is still somewhat flaky and out of the control
of the user, who might not know why or why not it works depending on how
they might have created/manipulated the Elf.
I'm not arguing against moving all of the alt file lookup to
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.
I do think code-wise your patch is fine now (v2).
But I also think it is going in the wrong direction. We make it
magically work in libdw for 90% instead of 50% of the cases (yes,
numbers made up). But we will probably remove it again and provide "real
support" through libdwfl and an explicit libdw interface. So I rather
not see it go in because it might make users depend on the current
kludge working and it might postpone our fixing it up for real even