Messages in this thread | | | Date | Tue, 12 Jan 2016 11:39:43 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC] perf record: missing buildid for callstack modules |
| |
* Peter Zijlstra <peterz@infradead.org> 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
| |