Re: [RFC] perf record: missing buildid for callstack modules

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Tue, Jan 12, 2016 at 11:39:43AM +0100, Ingo Molnar escreveu:
> But perf tooling cares very much: it can lead to subtle bugs and bad data if we 
> display a profile with the wrong DSO or binary. 'Bad' profiles resulting out of 
> binary mismatch can be very convincing and can send developers down the wrong path 
> for hours. I'd expect my tooling to not do that.
 
> Path names alone (the thing that exec() cares about) are not unique enough to 
> identify the binary that was profiled. So we need a content hash - hence the 
> build-ID.
 
> Can you suggest a better solution than a build-time calculated content hash?
 
> As for binary formats that suck and don't allow for a content hash: we do our 
> best, but of course the risk of data mismatch is there. We could perhaps cache the 
> binary inode's mtime field to at least produce a 'profile data is older than 
> binary/DSO modification date!' warning. (Which check won't catch all cases, like 
> cross-system profiling data matches.)

So, we could think of this as: binary formats that want to aid
observability tools to:

1) Detect mismatches in contents for DSOs present at recording time to
   those to be used at analysis time.

2) Find symtabs, DSO binary contents, CFI tables, present in the DSO
   where samples were taken.

Using mtime, as suggested in other messages will help with #1, but not
with #2.

Checking for inefficiencies in the current approach of
right-after-recording post-processing looking for PERF_RECORD_MMAPs,
Adrian suggested something here, also disabling the saving into
~/.debug/ will help, collecting numbers would be great.

But the mtime thing also requires traversing the whole perf.data
contents looking for those paths in PERF_RECORD_MMAP records.

- Arnaldo