From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Leo Yan <leo.yan@arm.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
"Liang, Kan" <kan.liang@linux.intel.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf probe: Correct demangled symbols in C++ program
Date: Mon, 14 Oct 2024 09:45:08 +0900 [thread overview]
Message-ID: <20241014094508.ccd8e17c79b5a833707df339@kernel.org> (raw)
In-Reply-To: <20241012141432.877894-1-leo.yan@arm.com>
On Sat, 12 Oct 2024 15:14:32 +0100
Leo Yan <leo.yan@arm.com> wrote:
> An issue can be observed when probe C++ demangled symbol with steps:
>
> # nm test_cpp_mangle | grep print_data
> 0000000000000c94 t _GLOBAL__sub_I__Z10print_datai
> 0000000000000afc T _Z10print_datai
> 0000000000000b38 T _Z10print_dataR5Point
>
> # perf probe -x /home/niayan01/test_cpp_mangle -F --demangle
> ...
> print_data(Point&)
> print_data(int)
> ...
>
> # perf --debug verbose=3 probe -x test_cpp_mangle --add "test=print_data(int)"
> probe-definition(0): test=print_data(int)
> symbol:print_data(int) file:(null) line:0 offset:0 return:0 lazy:(null)
> 0 arguments
> Open Debuginfo file: /home/niayan01/test_cpp_mangle
> Try to find probe point from debuginfo.
> Symbol print_data(int) address found : afc
> Matched function: print_data [2ccf]
> Probe point found: print_data+0
> Found 1 probe_trace_events.
> Opening /sys/kernel/tracing//uprobe_events write=1
> Opening /sys/kernel/tracing//README write=0
> Writing event: p:probe_test_cpp_mangle/test /home/niayan01/test_cpp_mangle:0xb38
> ...
>
> When tried to probe symbol "print_data(int)", the log shows:
>
> Symbol print_data(int) address found : afc
>
> The found address is 0xafc - which is right with verifying the output
> result from nm. Afterwards when write event, the command uses offset
> 0xb38 in the last log, which is a wrong address.
>
> The dwarf_diename() gets a common function name, in above case, it
> returns string "print_data". As a result, the tool parses the offset
> based on the common name. This leads to probe at the wrong symbol
> "print_data(Point&)".
>
> To fix the issue, use the die_get_linkage_name() function to retrieve
> the distinct linkage name - this is the mangled name for the C++ case.
> Based on this unique name, the tool can get a correct offset for
> probing. Based on DWARF doc, it is possible the linkage name is missed
> in the DIE, it rolls back to use dwarf_diename().
>
> After:
>
> # perf --debug verbose=3 probe -x test_cpp_mangle --add "test=print_data(int)"
> probe-definition(0): test=print_data(int)
> symbol:print_data(int) file:(null) line:0 offset:0 return:0 lazy:(null)
> 0 arguments
> Open Debuginfo file: /home/niayan01/test_cpp_mangle
> Try to find probe point from debuginfo.
> Symbol print_data(int) address found : afc
> Matched function: print_data [2d06]
> Probe point found: print_data+0
> Found 1 probe_trace_events.
> Opening /sys/kernel/tracing//uprobe_events write=1
> Opening /sys/kernel/tracing//README write=0
> Writing event: p:probe_test_cpp_mangle/test /home/niayan01/test_cpp_mangle:0xafc
> Added new event:
> probe_test_cpp_mangle:test (on print_data(int) in /home/niayan01/test_cpp_mangle)
>
> You can now use it in all perf tools, such as:
>
> perf record -e probe_test_cpp_mangle:test -aR sleep 1
>
> # perf --debug verbose=3 probe -x test_cpp_mangle --add "test2=print_data(Point&)"
> probe-definition(0): test2=print_data(Point&)
> symbol:print_data(Point&) file:(null) line:0 offset:0 return:0 lazy:(null)
> 0 arguments
> Open Debuginfo file: /home/niayan01/test_cpp_mangle
> Try to find probe point from debuginfo.
> Symbol print_data(Point&) address found : b38
> Matched function: print_data [2ccf]
> Probe point found: print_data+0
> Found 1 probe_trace_events.
> Opening /sys/kernel/tracing//uprobe_events write=1
> Parsing probe_events: p:probe_test_cpp_mangle/test /home/niayan01/test_cpp_mangle:0x0000000000000afc
> Group:probe_test_cpp_mangle Event:test probe:p
> Opening /sys/kernel/tracing//README write=0
> Writing event: p:probe_test_cpp_mangle/test2 /home/niayan01/test_cpp_mangle:0xb38
> Added new event:
> probe_test_cpp_mangle:test2 (on print_data(Point&) in /home/niayan01/test_cpp_mangle)
>
> You can now use it in all perf tools, such as:
>
> perf record -e probe_test_cpp_mangle:test2 -aR sleep 1
>
This looks good to me.
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Thank you!
> Fixes: fb1587d869a3 ("perf probe: List probes with line number and file name")
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
> tools/perf/util/probe-finder.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
> index 630e16c54ed5..498ccfb0be6f 100644
> --- a/tools/perf/util/probe-finder.c
> +++ b/tools/perf/util/probe-finder.c
> @@ -1583,8 +1583,21 @@ int debuginfo__find_probe_point(struct debuginfo *dbg, u64 addr,
>
> /* Find a corresponding function (name, baseline and baseaddr) */
> if (die_find_realfunc(&cudie, (Dwarf_Addr)addr, &spdie)) {
> - /* Get function entry information */
> - func = basefunc = dwarf_diename(&spdie);
> + /*
> + * Get function entry information.
> + *
> + * As described in the document DWARF Debugging Information
> + * Format Version 5, section 2.22 Linkage Names, "mangled names,
> + * are used in various ways, ... to distinguish multiple
> + * entities that have the same name".
> + *
> + * Firstly try to get distinct linkage name, if fail then
> + * rollback to get associated name in DIE.
> + */
> + func = basefunc = die_get_linkage_name(&spdie);
> + if (!func)
> + func = basefunc = dwarf_diename(&spdie);
> +
> if (!func ||
> die_entrypc(&spdie, &baseaddr) != 0 ||
> dwarf_decl_line(&spdie, &baseline) != 0) {
> --
> 2.25.1
>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
next prev parent reply other threads:[~2024-10-14 0:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-12 14:14 Leo Yan
2024-10-14 0:45 ` Masami Hiramatsu [this message]
2024-10-18 15:20 ` 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=20241014094508.ccd8e17c79b5a833707df339@kernel.org \
--to=mhiramat@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=leo.yan@arm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®