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

[Ulf Hermann <ulf.hermann@qt.io>]

> OK, so pgoff is like the offset argument of the mmap call?

As far as I understand it, yes.

> Is it just recording all user space mmap events that have PROT_EXEC in
> their prot argument? 

It just records all mmap events, also the ones without PROT_EXEC.

We check in perfparser if the file in question is supposed to be an elf 
file and consider everything that looks like one for later reporting to 
dwfl. We then report modules on demand, though. So, if no sample ever 
touches a module, the module doesn't get reported. Mmaps without 
PROT_EXEC shouldn't show up in any samples, except if the trace data is 
bad in some other way. But then, if we reported to dwfl a module that 
isn't actually linked in the target application but still mapped to a 
place in memory, that wouldn't disturb the unwinding for other modules. 
Would it?

We can probably determine the initial PROT_EXEC state for some mmaps, 
though. There are two possible variants of mmap events in the perf 
trace, one of which has a "prot" field. However, I don't know if we can 
rely on that being present in traces from the systems in question.

> What about if the mapping was later changed with mprotect? 

We don't get separate events for mprotect, so the "prot" field is 
probably worthless.

> Or does PERF_RECORD_MMAP only map to some internal kernel mmap action?

I don't know exactly where the mmap events are generated, but it has to 
be somewhere in the kernel. That is how perf_event_open operates, and, 
by extension, how perf gets its data. We might get some synthesized mmap 
events generated from the current memory map of an application when we 
attach while it's already running. I don't quite know how that works.

> dwfl_report_elf indeed does assume the whole ELF file is mapped in
> according to the PHDRs in the file and the given base address. But what
> you are actually seeing (I think, depending on the answers on the
> questions above) is the dynamic loader mapping in the file in pieces.

Yes, that is my interpretation of the (limited) data I have. Maybe 
Christoph can add something here.

> And so you would like an interface where you can report the module
> piece wise while it is being mapped in. So what would be most
> convenient would be some kind of dwfl_report_elf_mmap function that you
> can use to either get a new Dwfl_Module or to extend an existing one.

That sounds about right.

> I have to think how that interacts with mprotect and mmunmap.

We don't get any extra events for mprotect and munmap. If we detect an 
address space conflict between different modules, we just throw out the 
dwfl state and restart the reporting. (I know, there is a potential for 
optimization here: We could use the callback to dwfl_report_end and only 
throw out the conflicting modules.)

cheers,
Ulf