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

[Ingo Molnar]

* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> On Fri, Jan 08, 2016 at 03:19:42PM -0300, Arnaldo Carvalho de Melo wrote:
>
> > We already discussed how to solve it, and it involves extending once more 
> > PERF_RECORD_MMAP, so that, when we load a DSO we stash its build-id in a 
> > per-DSO data structure in the kernel, then, when generating PERF_RECORD_MMAP3 
> > we put the buildid there, this way if any of those binaries gets replaced 
> > while we're recording samples, we would notice, i.e. we wouldn't care that 
> > much about the pathname, looking everything by the content based buildid 
> > instead.
> 
> Does the kernel even know about the buildid crap? AFAIK the binfmt stuff doesn't 
> know or care about things like that. Heck, we support binfmts that do not even 
> have a buildid.

The kernel's exec() code does not care about the past, it will execute whatever is 
fit to execute right now.

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.)

Thanks,

	Ingo