This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: Handling pgoff in perf elf mmap/mmap2 elf info
- From: Mark Wielaard <mark at klomp dot org>
- To: Ulf Hermann <ulf dot hermann at qt dot io>
- Cc: Milian Wolff <mail at milianw dot de>, "elfutils-devel at sourceware dot org" <elfutils-devel at sourceware dot org>, Christoph Sterz <christoph dot sterz at kdab dot com>
- Date: Thu, 11 Oct 2018 19:37:07 +0200
- Subject: Re: Handling pgoff in perf elf mmap/mmap2 elf info
- References: <d0141f86-a010-ebff-e271-d11b556c30aa@kdab.com> <1537535249.6167.23.camel@klomp.org> <1592524.jgvKiEW90d@milian-kdab2> <3714108.l9E63im8cn@agathebauer> <9a2f15c5-2788-58e0-1df8-38b5951e652c@qt.io>
Hi,
My apologies for not having looked deeper at this.
It is a bit tricky and I just didnt have enough time to
really sit down and think it all through yet.
On Thu, Oct 11, 2018 at 05:02:18PM +0000, Ulf Hermann wrote:
> is there any pattern in how the loader maps the ELF sections into
> memory? What sections does it actually map and which of those do we need
> for unwinding?
Yes, it would be helpful to have some examples of mmap events plus
the associated segment header (eu-readelf -l) of the ELF file.
Note that the kernel and dynamic loader will use the (PT_LOAD) segments,
not the sections, to map things into memory. Each segment might contain
multiple sections.
libdwfl then tries to associate the correct sections (and address bias)
with how the ELF file was mapped into memory.
> I hope that only one of those MMAPs per ELF is actually meaningful and
> we can simply add that one's pgoff as an extra member to Dwfl_Module and
> use it whenever we poke the underlying file.
One "trick" might be to just substract the pgoff from the load address.
And so report as if the ELF file was being mapped from the start. This
isn't really correct, but it might be interesting to see if that makes
libdwfl able to just associate the whole ELF file with the correct
address map.
Cheers,
Mark