dwfl_module_getsym vs. prelink

Josh Stone jistone at redhat.com
Fri Nov 15 18:31:02 UTC 2013


On 11/15/2013 06:01 AM, Mark Wielaard wrote:
> On Fri, 2013-11-15 at 14:35 +0100, Mark Wielaard wrote:
>> OK, that is definitely a bug. But I cannot immediately explain why it
>> worked fine in the -N case and not in the -r case. Except for the
>> specific load address there should be no difference.
> 
> Except that prelink -r doesn't actually do a prelink. In particular it
> doesn't add a .gnu.prelink_undo section which we look for to create the
> synchronization address between the main and debug files. See 
> find_prelink_address_sync() in libdwfl/dwfl_module_getdwarf.c.

Wow, that's a healthy chunk of code!  But I wonder about this comment:

  If the main file might have been prelinked, then we need to
  discover the correct synchronization address between the main and
  debug files.  Because of prelink's section juggling, we cannot rely
  on the address_sync computed from PT_LOAD segments (see open_elf).

For this case without prelink_undo, I think we'll have to fallback on
just the difference in PT_LOAD segments.  That makes some assumptions,
but at least it's better than doing nothing at all...

> This is a somewhat strange case. We separate the main and debug/aux
> files first and then run prelink -r to adjust the base address of the
> main file. How important is this case?

At a minimum, it falls in the realm of "things that are possible to
happen to ELF files," which should be supported.  The fact that it's
separated before any type of prelink is normal to me; it's exactly how
distro binaries are usually mangled.


More information about the elfutils-devel mailing list