From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-16.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6C32EC433E0 for ; Fri, 12 Feb 2021 21:18:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 35A1A64E95 for ; Fri, 12 Feb 2021 21:18:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231829AbhBLVSj (ORCPT ); Fri, 12 Feb 2021 16:18:39 -0500 Received: from mail.kernel.org ([198.145.29.99]:59858 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231175AbhBLVSe (ORCPT ); Fri, 12 Feb 2021 16:18:34 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id B6D5564E05; Fri, 12 Feb 2021 21:17:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613164672; bh=igwJV3Ql7mI9BeCjbv2SB4KehkRXZXKbNfnOto/Iu5U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=q3kHHg/TI83N9dl4FXATamXGs8BoL/7ZUyBtgd/CcthqD5zgKwfkfmskwEaKEtgPL gw8Mm3zUBzPfEyeZJCXoIKxFSh8CbWSmQhTIYBXm/JWNeDpihAdFaAwizUJMRpKFzy f1HRZcBfsHn4eRalVpEvPzXIQ76imjoyES/z0VEH1F6u/tymV+LBAI4Pq4nGKJCyw7 wgGY40/LYOlz2yagxoM3MJdYyecRs7fqcL/bR6GFjMZNb7puhimgOhn+7mJ9LsNtQT g3UfFWS58gF/wYrcrd5KvrQ3cxU7WvRbWNenA9wmoOk6Ng2bqa6LFfd9oM+8/SKhpX Vd8PQGgFt3TiQ== Received: by quaco.ghostprotocols.net (Postfix, from userid 1000) id 9CDE040513; Fri, 12 Feb 2021 18:17:50 -0300 (-03) Date: Fri, 12 Feb 2021 18:17:50 -0300 From: Arnaldo Carvalho de Melo To: Nicholas Fraser Cc: Peter Zijlstra , Ingo Molnar , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , "Frank Ch. Eigler" , Song Liu , Adrian Hunter , Kim Phillips , Tommi Rantala , Remi Bernon , linux-kernel@vger.kernel.org, Ulrich Czekalla , Huw Davies Subject: Re: [PATCH 2/4] perf report: Load PE files from debug cache only Message-ID: <20210212211750.GL1398414@kernel.org> References: <20210212122800.GA1398414@kernel.org> <367456d0-78ea-f2e1-2269-3e6cf95ea3fb@codeweavers.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <367456d0-78ea-f2e1-2269-3e6cf95ea3fb@codeweavers.com> X-Url: http://acmel.wordpress.com Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Fri, Feb 12, 2021 at 11:34:24AM -0500, Nicholas Fraser escreveu: > Sorry, I should have been more clear in the commit message. The use case > you outlined still works even with this patch. Ok, I'll clarify that in the commit log then. - Arnaldo > dso__load_bfd_symbols() is called in a loop from dso__load() for a variety > of paths. These are generated by the various DSO_BINARY_TYPEs in the > binary_type_symtab list at the top of util/symbol.c. In each case the > debugfile passed to dso__load_bfd_symbols() is the path to try. > > One of those iterations (the first one I believe) passes the original path > as the debugfile. If the file still exists at the original path, this is > the one that ends up being used in case the debugcache was deleted or the > PE file doesn't have a build-id. > > A later iteration (BUILD_ID_CACHE) passes debugfile as the file in the > debugcache if it has a build-id. Even if the file was previously loaded at > its original path, (if I understand correctly) this load will override it > so the debugcache file ends up being used. > > Nick > > > On 2021-02-12 7:28 a.m., Arnaldo Carvalho de Melo wrote: > > Em Wed, Feb 10, 2021 at 02:17:38PM -0500, Nicholas Fraser escreveu: > >> dso__load_bfd_symbols() attempts to load a DSO at its original path, > >> then closes it and loads the file in the debug cache. This is incorrect. > >> It should ignore the original file and work with only the debug cache. > >> The original file may have changed or may not even exist, for example if > >> the debug cache has been transferred to another machine via "perf > >> archive". > >> > >> This fix makes it only load the file in the debug cache. > > > > Well this improves your current use case and only affects PE files, so I > > am applying, but consider a slightly different workflow: > > > > 1. perf record ./foo.exe > > 2. perf report # works, finds the file in the ~/.debug cache, as stored > > # by 'perf record' > > 3. rm -rf ~/.debug # I need more space > > 4. perf report # Fails, as it looks only in the ~/.debug cache, that > > # was nuked > > > > > > So at 4 it should look at the original pathname, and hope for the best. > > > > All this is moot if we have something like a build-id in PE files, > > where we can look in any order since we'll verify the unique ID to see > > if it is the one we need, right? > > > > - Arnaldo > > > >> Signed-off-by: Nicholas Fraser > >> --- > >> tools/perf/util/symbol.c | 8 +------- > >> 1 file changed, 1 insertion(+), 7 deletions(-) > >> > >> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c > >> index 64a039cbba1b..aa9ae875b995 100644 > >> --- a/tools/perf/util/symbol.c > >> +++ b/tools/perf/util/symbol.c > >> @@ -1569,7 +1569,7 @@ int dso__load_bfd_symbols(struct dso *dso, const char *debugfile) > >> u_int i; > >> u64 start, len; > >> > >> - abfd = bfd_openr(dso->long_name, NULL); > >> + abfd = bfd_openr(debugfile, NULL); > >> if (!abfd) > >> return -1; > >> > >> @@ -1586,12 +1586,6 @@ int dso__load_bfd_symbols(struct dso *dso, const char *debugfile) > >> if (section) > >> dso->text_offset = section->vma - section->filepos; > >> > >> - bfd_close(abfd); > >> - > >> - abfd = bfd_openr(debugfile, NULL); > >> - if (!abfd) > >> - return -1; > >> - > >> if (!bfd_check_format(abfd, bfd_object)) { > >> pr_debug2("%s: cannot read %s bfd file.\n", __func__, > >> debugfile); > >> -- > >> 2.30.0 > >> > > -- - Arnaldo