From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758980AbbA3OdQ (ORCPT ); Fri, 30 Jan 2015 09:33:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56765 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757925AbbA3OdP (ORCPT ); Fri, 30 Jan 2015 09:33:15 -0500 Date: Fri, 30 Jan 2015 15:32:46 +0100 From: Jiri Olsa To: Namhyung Kim Cc: Arnaldo Carvalho de Melo , Ingo Molnar , Peter Zijlstra , LKML , David Ahern , Adrian Hunter , Andi Kleen , Stephane Eranian , Frederic Weisbecker Subject: Re: [PATCH 01/42] perf tools: Support to read compressed module from build-id cache Message-ID: <20150130143246.GE6188@krava.brq.redhat.com> References: <1422518843-25818-1-git-send-email-namhyung@kernel.org> <1422518843-25818-2-git-send-email-namhyung@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1422518843-25818-2-git-send-email-namhyung@kernel.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 29, 2015 at 05:06:42PM +0900, Namhyung Kim wrote: > The commit c00c48fc6e6e ("perf symbols: Preparation for compressed > kernel module support") added support for compressed kernel modules > but it only supports system path DSOs. When a dso is read from > build-id cache, its filename doesn't end with ".gz" but has build-id. > In this case, we should fallback to the original dso->name. > > Signed-off-by: Namhyung Kim > --- > tools/perf/util/symbol-elf.c | 13 ++++++++----- > 1 file changed, 8 insertions(+), 5 deletions(-) > > diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c > index 06fcd1bf98b6..b24f9d8727a8 100644 > --- a/tools/perf/util/symbol-elf.c > +++ b/tools/perf/util/symbol-elf.c > @@ -574,13 +574,16 @@ static int decompress_kmodule(struct dso *dso, const char *name, > const char *ext = strrchr(name, '.'); > char tmpbuf[] = "/tmp/perf-kmod-XXXXXX"; > > - if ((type != DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE_COMP && > - type != DSO_BINARY_TYPE__GUEST_KMODULE_COMP) || > - type != dso->symtab_type) > + if (type != DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE_COMP && > + type != DSO_BINARY_TYPE__GUEST_KMODULE_COMP && > + type != DSO_BINARY_TYPE__BUILD_ID_CACHE) > return -1; hum, is it possible the type == DSO_BINARY_TYPE__BUILD_ID_CACHE could get in here? --- for (i = 0; i < DSO_BINARY_TYPE__SYMTAB_CNT; i++) { struct symsrc *ss = &ss_[ss_pos]; bool next_slot = false; enum dso_binary_type symtab_type = binary_type_symtab[i]; if (!dso__is_compatible_symtab_type(dso, kmod, symtab_type)) continue; --- ^^^ this check should rule out buildid symtab_type for kmod dso? symsrc__init( I wonder wether we should set special type from compressed binaries (as of now), or instead try to decompress anything that looks like it's compressed ;-) it seems more to be more generic and could simplify the code.. jirka