From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933334AbcAKRam (ORCPT ); Mon, 11 Jan 2016 12:30:42 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:35892 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757612AbcAKRak (ORCPT ); Mon, 11 Jan 2016 12:30:40 -0500 Date: Mon, 11 Jan 2016 18:30:36 +0100 From: Peter Zijlstra To: Arnaldo Carvalho de Melo Cc: Stephane Eranian , Namhyung Kim , LKML , Jiri Olsa , Namhyung Kim , Ingo Molnar , Adrian Hunter , "ak@linux.intel.com" Subject: Re: [RFC] perf record: missing buildid for callstack modules Message-ID: <20160111173036.GA6344@twins.programming.kicks-ass.net> References: <20160107215945.GA19314@kernel.org> <80F05A66-6943-499A-B402-96249953CD15@gmail.com> <20160107234746.GB19314@kernel.org> <20160108181942.GB20576@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160108181942.GB20576@kernel.org> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.