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 _______________________________________________ elfutils-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/elfutils-devel
