Re: Handling pgoff in perf elf mmap/mmap2 elf info

2018-10-11 Thread Ulf Hermann
Hi Milian,

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?

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.

br,
Ulf


Re: Handling pgoff in perf elf mmap/mmap2 elf info

2018-10-11 Thread Mark Wielaard
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 +, 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


Re: Handling pgoff in perf elf mmap/mmap2 elf info

2018-10-11 Thread Milian Wolff
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 +, 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
m...@milianw.de
http://milianw.de

signature.asc
Description: This is a digitally signed message part.