From: Jiri Olsa <olsajiri@gmail.com>
To: James Clark <james.clark@arm.com>
Cc: acme@kernel.org, linux-perf-users@vger.kernel.org,
coresight@lists.linaro.org, Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 0/1] perf: Set build-id using build-id header on new mmap records
Date: Sat, 5 Mar 2022 21:33:59 +0100 [thread overview]
Message-ID: <YiPJN1yaFKILinpE@krava> (raw)
In-Reply-To: <20220304090956.2048712-1-james.clark@arm.com>
On Fri, Mar 04, 2022 at 09:09:55AM +0000, James Clark wrote:
> Changes since v1:
> * Add read lock around dso find
> * Bracket style fix
>
> Hi,
>
> We are seeing an issue with doing Coresight decode off target where
> initially the correct dso from ~/.debug is used, but after a new thread
> in the perf.data file is passed with its mmap record, the local version
> of the dso is picked up instead. This happens if the binary exists in the
> same path on both devices, for example /bin/ls.
>
> Initially when parsing the build-ids in the header, the dso for /bin/ls
> will be created, and the file will correctly point to
> ~/.debug/bin/ls/2f15ad836be3339dec0e2e6a3c637e08e48aacbd/elf, but for any
> new threads or mmaps that are also for /bin/ls, they will not have a
> build-id set so they point to /bin/ls on the local machine rather than the
> debug folder.
>
> To fix this I made it possible to look up which existing dsos have
> build id's set that originate from the header and then copy that build-id
> onto the new dso if the name matches. Another way to do it would
> be to stop comparing the mmap id so it matches on filename only, but I
> think we do want to differentiate between different mmaps, even if they
> have the same name, which is how it works in this version.
>
> Applies to perf/core 56dce8681
>
> James Clark (1):
> perf: Set build-id using build-id header on new mmap records
Acked-by: Jiri Olsa <jolsa@kernel.org>
thanks,
jirka
>
> tools/perf/util/dso.h | 1 +
> tools/perf/util/header.c | 1 +
> tools/perf/util/map.c | 20 +++++++++++++++++---
> 3 files changed, 19 insertions(+), 3 deletions(-)
>
> --
> 2.28.0
>
next prev parent reply other threads:[~2022-03-05 20:34 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-04 9:09 [PATCH v2 0/1] perf: Set build-id using build-id header on new mmap records James Clark
2022-03-04 9:09 ` [PATCH v2 1/1] " James Clark
2022-03-05 20:33 ` Jiri Olsa [this message]
2022-03-12 14:01 ` [PATCH v2 0/1] " Arnaldo Carvalho de Melo
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=YiPJN1yaFKILinpE@krava \
--to=olsajiri@gmail.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=coresight@lists.linaro.org \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=namhyung@kernel.org \
/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.