lkml.org 
[lkml]   [2021]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/4] perf report: Load PE files from debug cache only
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 <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

\
 
 \ /
  Last update: 2021-02-12 22:19    [W:0.248 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site