From: duchangbin <changbin.du@huawei.com>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: duchangbin <changbin.du@huawei.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Nathan Chancellor <nathan@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>,
"Liang, Kan" <kan.liang@linux.intel.com>,
"Nick Desaulniers" <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
"linux-perf-users@vger.kernel.org"
<linux-perf-users@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"llvm@lists.linux.dev" <llvm@lists.linux.dev>
Subject: Re: [PATCH v4 1/5] perf: support specify vdso path in cmdline
Date: Wed, 26 Jun 2024 02:26:53 +0000 [thread overview]
Message-ID: <7eef4826a2f3494ea1dc92ed98d543fb@huawei.com> (raw)
In-Reply-To: <5a9e8dae-e9d9-4a97-98f5-d76be9068342@intel.com>
On Tue, Jun 25, 2024 at 04:20:49PM +0300, Adrian Hunter wrote:
> On 25/06/24 06:37, Changbin Du wrote:
> > The vdso dumped from process memory (in buildid-cache) lacks debugging
> > info. To annotate vdso symbols with source lines we need specify a
> > debugging version.
> >
> > For x86, we can find them from your local build as
> > arch/x86/entry/vdso/vdso{32,64}.so.dbg. Or they may reside in
> > /lib/modules/<version>/vdso/vdso{32,64}.so on Ubuntu. But notice that
> > the buildid has to match.
> >
> > $ sudo perf record -a
> > $ sudo perf report --objdump=llvm-objdump \
> > --vdso arch/x86/entry/vdso/vdso64.so.dbg,arch/x86/entry/vdso/vdso32.so.dbg
> >
> > Samples: 17K of event 'cycles:P', 4000 Hz, Event count (approx.): 1760
> > __vdso_clock_gettime /work/linux-host/arch/x86/entry/vdso/vdso64.so.d
> > Percent│ movq -48(%rbp),%rsi
> > │ testq %rax,%rax
> > │ ; return vread_hvclock();
> > │ movq %rax,%rdx
> > │ ; if (unlikely(!vdso_cycles_ok(cycles)))
> > │ ↑ js eb
> > │ ↑ jmp 74
> > │ ; ts->tv_sec = vdso_ts->sec;
> > 0.02 │147: leaq 2(%rbx),%rax
> > │ shlq $4, %rax
> > │ addq %r10,%rax
> > │ ; while ((seq = READ_ONCE(vd->seq)) & 1) {
> > 9.38 │152: movl (%r10),%ecx
> >
> > When doing cross platform analysis, we also need specify the vdso path if
> > we are interested in its symbols.
>
> Would it be possible to add vdso and vdso debug to the build-id
> cache and ensure perf can find it there?
>
> Typically, getting dsos from another machine is handled via
> build-id cache e.g. what perf-archive does
>
Hmm. I agree this is better alternative approach for cross-machine analysis.
When collecting vdsos to buildid cache, I think we can use the local searched
objects (with debug symbols) instead if its build-id matches vdsos from process
dumping (the real code ran).
Currently I just follow what perf does for vmlinux so to reuse most of existing
code. Maybe vmlinux is too big to add to buildid-cahce?
Can we keep our current strategy for now? I'll think about above options when
I have more time.
--
Cheers,
Changbin Du
next prev parent reply other threads:[~2024-06-26 2:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-25 3:37 [PATCH v4 0/5] perf: support specify vdso path in cmdline Changbin Du
2024-06-25 3:37 ` [PATCH v4 1/5] " Changbin Du
2024-06-25 13:20 ` Adrian Hunter
2024-06-26 2:26 ` duchangbin [this message]
2024-06-26 10:32 ` Adrian Hunter
2024-06-27 23:53 ` Namhyung Kim
2024-06-28 4:21 ` duchangbin
2024-06-28 17:27 ` Adrian Hunter
2024-06-29 2:32 ` duchangbin
2024-06-29 18:47 ` Adrian Hunter
2024-07-01 2:30 ` duchangbin
2024-06-25 3:37 ` [PATCH v4 2/5] perf: disasm: refactor function dso__disassemble_filename Changbin Du
2024-06-25 3:37 ` [PATCH v4 3/5] perf: disasm: use build_id_path if fallback failed Changbin Du
2024-06-25 3:37 ` [PATCH v4 4/5] perf: symbol: generalize vmlinux path searching Changbin Du
2024-06-25 3:37 ` [PATCH v4 5/5] perf: symbol: try to seach vdso path if not given by user Changbin Du
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=7eef4826a2f3494ea1dc92ed98d543fb@huawei.com \
--to=changbin.du@huawei.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=justinstitt@google.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=namhyung@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.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.