From: Namhyung Kim <namhyung@kernel.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>, Jiri Olsa <jolsa@kernel.org>
Cc: Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
linux-perf-users@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Stephane Eranian <eranian@google.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
linux-toolchains@vger.kernel.org,
linux-trace-devel@vger.kernel.org,
Ben Woodard <woodard@redhat.com>, Joe Mario <jmario@redhat.com>,
Kees Cook <keescook@chromium.org>,
David Blaikie <blaikie@google.com>, Xu Liu <xliuprof@google.com>,
Kan Liang <kan.liang@linux.intel.com>,
Ravi Bangoria <ravi.bangoria@amd.com>,
Mark Wielaard <mark@klomp.org>, Jason Merrill <jason@redhat.com>,
"Jose E . Marchesi" <jose.marchesi@oracle.com>,
William Huang <williamjhuang@google.com>
Subject: [PATCHSET 0/9] perf tools: More updates on data type profiling (v4)
Date: Tue, 16 Jan 2024 22:26:48 -0800 [thread overview]
Message-ID: <20240117062657.985479-1-namhyung@kernel.org> (raw)
Hello,
This is a continuation of the data type profiling series. Now the basic
part (v3) which uses pointer variables is merged to the perf-tools-next
tree. And this part is for memory accesses without pointers as well as
small updates to handle some corner cases. Still mores to come to
complete the original series.
There's no change from the previous version. For background and usages,
pleaes refer the posting of previous version [1] and a LWN article [2].
Basically most memory accesses happen with pointers, but there are cases
don't use pointers - direct accesses to global and local variables.
Global variables are located in a static memory at a specific address.
So the DWARF location expression for the global vairable would also have
the static address. And it's common to access them using PC-relative
addressing mode. Thus it needs a special handling for global variables.
On the other hand, local variables are located in the stack which varies
as program executes. So the local variables are accessed either by the
(stack) frame pointer or (current) stack pointer. But sometimes DWARF
location expression uses a frame base address (CFA) to specify location
of local variables. So it may need to convert or normalize the location
extracted from the instruction to match DWARF expression.
Lastly, there are some cases DWARF location expressions end up having
complex (or not straight-forward) location. In that case, it cannot
simply match just the first expression with the instruction location.
It'd be safer to reject them.
The code is available at 'perf/data-profile-update-v4' branch in the tree
below. The full version of the code is in 'perf/data-profile-v4' branch.
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
Thanks,
Namhyung
Cc: Ben Woodard <woodard@redhat.com>
Cc: Joe Mario <jmario@redhat.com>
CC: Kees Cook <keescook@chromium.org>
Cc: David Blaikie <blaikie@google.com>
Cc: Xu Liu <xliuprof@google.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Ravi Bangoria <ravi.bangoria@amd.com>
Cc: Mark Wielaard <mark@klomp.org>
Cc: Jason Merrill <jason@redhat.com>
Cc: Jose E. Marchesi <jose.marchesi@oracle.com>
Cc: William Huang <williamjhuang@google.com>
[1] https://lore.kernel.org/linux-perf-users/20231213001323.718046-1-namhyung@kernel.org/
[2] https://lwn.net/Articles/955709/
Namhyung Kim (9):
perf annotate-data: Parse 'lock' prefix from llvm-objdump
perf annotate-data: Handle macro fusion on x86
perf annotate-data: Handle array style accesses
perf annotate-data: Add stack operation pseudo type
perf annotate-data: Handle PC-relative addressing
perf annotate-data: Support global variables
perf dwarf-aux: Add die_get_cfa()
perf annotate-data: Support stack variables
perf dwarf-aux: Check allowed DWARF Ops
tools/perf/util/annotate-data.c | 119 ++++++++++++++++----
tools/perf/util/annotate-data.h | 8 +-
tools/perf/util/annotate.c | 153 ++++++++++++++++++++++++--
tools/perf/util/annotate.h | 12 +-
tools/perf/util/dwarf-aux.c | 187 ++++++++++++++++++++++++++++----
tools/perf/util/dwarf-aux.h | 18 +++
6 files changed, 439 insertions(+), 58 deletions(-)
base-commit: d988c9f511af71a3445b6a4f3a2c67208ff8e480
--
2.43.0.381.gb435a96ce8-goog
next reply other threads:[~2024-01-17 6:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 6:26 Namhyung Kim [this message]
2024-01-17 6:26 ` [PATCH 1/9] perf annotate-data: Parse 'lock' prefix from llvm-objdump Namhyung Kim
2024-01-17 6:26 ` [PATCH 2/9] perf annotate-data: Handle macro fusion on x86 Namhyung Kim
2024-01-17 6:26 ` [PATCH 3/9] perf annotate-data: Handle array style accesses Namhyung Kim
2024-01-17 6:26 ` [PATCH 4/9] perf annotate-data: Add stack operation pseudo type Namhyung Kim
2024-01-17 6:26 ` [PATCH 5/9] perf annotate-data: Handle PC-relative addressing Namhyung Kim
2024-01-17 6:26 ` [PATCH 6/9] perf annotate-data: Support global variables Namhyung Kim
2024-01-17 6:26 ` [PATCH 7/9] perf dwarf-aux: Add die_get_cfa() Namhyung Kim
2024-01-17 6:26 ` [PATCH 8/9] perf annotate-data: Support stack variables Namhyung Kim
2024-01-17 6:26 ` [PATCH 9/9] perf dwarf-aux: Check allowed DWARF Ops Namhyung Kim
2024-01-18 16:36 ` [PATCHSET 0/9] perf tools: More updates on data type profiling (v4) Ian Rogers
2024-01-22 20:37 ` Namhyung Kim
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=20240117062657.985479-1-namhyung@kernel.org \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=blaikie@google.com \
--cc=eranian@google.com \
--cc=irogers@google.com \
--cc=jason@redhat.com \
--cc=jmario@redhat.com \
--cc=jolsa@kernel.org \
--cc=jose.marchesi@oracle.com \
--cc=kan.liang@linux.intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=mark@klomp.org \
--cc=mhiramat@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@amd.com \
--cc=torvalds@linux-foundation.org \
--cc=williamjhuang@google.com \
--cc=woodard@redhat.com \
--cc=xliuprof@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).