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' -
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.)