[patch 1/4] unwinder: New base address based dwfl_report_elf_baseaddr

Jan Kratochvil jan.kratochvil at redhat.com
Mon Mar 18 20:02:25 UTC 2013


Hi Roland,

On Mon, 18 Mar 2013 20:35:53 +0100, Roland McGrath wrote:
> I haven't been tracking the details, but I am confused.
> I don't want to add another function to the API.
> What is the rationale for adding dwfl_report_elf_baseaddr?

a later patch contains function report_module in a test application:

input:  PC anywhere in a shared library of some PID
uses:   /proc/PID/maps to find out VMA where the file is mapped from
output: ELF file mapped into Dwfl address space

If report_module used dwfl_report_elf then it would need to adjust the base
VMA found in /proc/PID/maps by where the DSO file is currently prelinked to.

dwfl_report_elf's parameter base = "bias" = 'in-memory VMA' - 'on-disk VMA'

This would mean the application (containing report_module) would need to parse
the ELF file to determine the current on-disk file prelink offset.
I do not find it easy and it will even have poor performance opening and
parsing the ELF file twice.  For dwfl_report_elf it is just a new flag.

(It is irrelevant where the DSO was prelinked to when PID started.)


Thanks,
Jan


More information about the elfutils-devel mailing list