This is the mail archive of the
mailing list for the elfutils project.
Re: [patch 1/4] unwinder: New base address based dwfl_report_elf_baseaddr
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Mon, 18 Mar 2013 21:02:25 +0100
- Subject: Re: [patch 1/4] unwinder: New base address based dwfl_report_elf_baseaddr
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.)