Re: [Libunwind-devel] [PATCH 3/7] Fix issue with resolving relative addresses for prelinked libraries

[ext ext Daniel Jacobowitz]

On Wed, Jun 25, 2008 at 10:17:46AM -0400, Anderson Lizardo wrote:
> No, we don't. As explained on the description of another patch, we fill
> the struct dl_phdr_info structure ourselves with information from
> get_elf_image(), which, in turn, is read from /proc/PID/maps. The maps
> address is always the absolute virtual address, don't matter how the
> offsets are defined internally in the ELF files.
> 
> The local unwinding uses dl_iterate_phdr() to fill that structure, but
> it does not work for "remote" processes AFAIK.

Ah.  I didn't realize it was coming ultimately from /proc/PID/maps.

In that case, don't condition on p_vaddr.  Look for the segment with
p_offset == 0 (shared libraries should always have one), and determine
segbase by taking the address from /proc/PID/maps and subtracting
p_vaddr.  That same segbase will work for all other segments too.

> > It's much trickier in GDB because we support remote debugging and
> > core dumps; the library may have been re-prelinked to a different
> > address.
> 
> Isn't that valid for remote unwinding in libunwind too (except for
> the core dump handling)?

No, remote means something different here.  Remote unwinding in
libunwind is (typically, but not always when used with GDB) ptrace;
remote unwinding in GDB can be to an entirely different system.  So
it's easy to have unprelinked libraries on the GDB side and prelinked
or randomly re-prelinked libraries on the target side.

-- 
Daniel Jacobowitz
CodeSourcery