Handling pgoff in perf elf mmap/mmap2 elf info
Milian Wolff
mail@milianw.de
Thu Oct 11 18:14:00 GMT 2018
On Donnerstag, 11. Oktober 2018 19:37:07 CEST Mark Wielaard wrote:
> 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.
I'll try to come up with some minimal code examples we can use to test all of
this. But from what I remember, neither of the above suggestions will be
sufficient as we can still run into overlapping module errors from elfutils
when we always load everything. I.e. I believe we've seen mappings that
eventually become partially obsoleted by a future mmap event. At that point,
we somehow need to be able to only map parts of a file, not all of it. So just
subtracting or honoring pgoff is not enough, I believe we also need to be able
to explicitly say how much of a file to map.
But to make this discussion easier to follow for others, I'll create some
standalone cpp code that takes a `perf script --show-mmap-events | grep
PERF_RECORD_MMAP` input file and then runs this through elfutils API to
reproduce the issues we are facing.
I'll get back to you all once this is done.
Cheers
--
Milian Wolff
mail@milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/elfutils-devel/attachments/20181011/db874509/attachment.sig>
More information about the Elfutils-devel
mailing list