libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] [PATCH 3/7] Fix issue with resolving relative addr


From: Anderson Lizardo
Subject: Re: [Libunwind-devel] [PATCH 3/7] Fix issue with resolving relative addresses for prelinked libraries
Date: Wed, 25 Jun 2008 10:17:46 -0400
User-agent: Thunderbird 2.0.0.14 (X11/20080505)

ext ext Daniel Jacobowitz wrote:
> On Wed, Jun 25, 2008 at 08:51:31AM -0400, Anderson Lizardo wrote:
>> Do you have any suggestions on how to reliably calculate absolute
>> addresses? An alternative approach I have in mind is to peek directly at
>> the linker structures, like it's done by GDB. Is that the only feasible
>> general solution to the issue?
> 
> I'm not sure I understand what you're doing.  Don't you already have
> the run-time linker's offsets?

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.

> If you assume that any file you've
> opened is the same as the one running in the target process, then all
> it takes is combining the two; p_vaddr plus the offset from the link
> map.

In this case we should read the link map from the process address space,
instead of filling our own structure, right?

> 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)?

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia (INdT)
Manaus - Brazil




reply via email to

[Prev in Thread] Current Thread [Next in Thread]