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 _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
