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 <[email protected]> > >> --- > >> 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
