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

From: Ingo Molnar
Date: Tue Jan 12 2016 - 05:40:14 EST

* 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

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