All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Nicholas Fraser <nfraser@codeweavers.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Ian Rogers <irogers@google.com>,
	"Frank Ch. Eigler" <fche@redhat.com>,
	Song Liu <songliubraving@fb.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Kim Phillips <kim.phillips@amd.com>,
	Tommi Rantala <tommi.t.rantala@nokia.com>,
	Remi Bernon <rbernon@codeweavers.com>,
	linux-kernel@vger.kernel.org,
	Ulrich Czekalla <uczekalla@codeweavers.com>,
	Huw Davies <huw@codeweavers.com>
Subject: Re: [PATCH 2/4] perf report: Load PE files from debug cache only
Date: Fri, 12 Feb 2021 09:28:00 -0300	[thread overview]
Message-ID: <20210212122800.GA1398414@kernel.org> (raw)
In-Reply-To: <e58e1237-94ab-e1c9-a7b9-473531906954@codeweavers.com>

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 <nfraser@codeweavers.com>
> ---
>  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

  reply	other threads:[~2021-02-12 12:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-10 19:17 [PATCH 2/4] perf report: Load PE files from debug cache only Nicholas Fraser
2021-02-12 12:28 ` Arnaldo Carvalho de Melo [this message]
2021-02-12 16:34   ` Nicholas Fraser
2021-02-12 21:17     ` Arnaldo Carvalho de Melo
2021-02-15 14:36 ` Jiri Olsa
2021-02-16 15:55   ` Nicholas Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210212122800.GA1398414@kernel.org \
    --to=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=fche@redhat.com \
    --cc=huw@codeweavers.com \
    --cc=irogers@google.com \
    --cc=jolsa@redhat.com \
    --cc=kim.phillips@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=nfraser@codeweavers.com \
    --cc=peterz@infradead.org \
    --cc=rbernon@codeweavers.com \
    --cc=songliubraving@fb.com \
    --cc=tommi.t.rantala@nokia.com \
    --cc=uczekalla@codeweavers.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.