From: Adrian Hunter <adrian.hunter@intel.com>
To: Changbin Du <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>
Cc: 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-kernel@vger.kernel.org,
llvm@lists.linux.dev, Hui Wang <hw.huiwang@huawei.com>
Subject: Re: [PATCH v5 1/8] perf: support specify vdso path in cmdline
Date: Thu, 18 Jul 2024 20:02:16 +0300 [thread overview]
Message-ID: <4ddbcd4a-bbf1-4773-94da-0a2ad63469dc@intel.com> (raw)
In-Reply-To: <20240702041837.5306-2-changbin.du@huawei.com>
On 2/07/24 07:18, 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.
>
Just realized this is about objdump. Sorry for not getting that
earlier.
Like perf tools, objdump follows the paradigm of attempting to
locate and use debug info transparently. However, objdump looks
at the installed debug info in /usr/lib/debug/.build-id/
For example, if the debug file is copied (or linked) there, then
objdump or llvm-objdump will find it:
$ llvm-objdump-18 -dS ~/.debug/\[vdso\]/cf702469f4637840fd6ba1a8d8a628ff83253d04/vdso | head -20
~/.debug/[vdso]/cf702469f4637840fd6ba1a8d8a628ff83253d04/vdso: file format elf64-x86-64
Disassembly of section .text:
00000000000006d0 <.text>:
6d0: 48 8d 3d 29 d9 ff ff leaq -0x26d7(%rip), %rdi # 0xffffffffffffe000
6d7: eb 19 jmp 0x6f2 <.text+0x22>
6d9: 4c 8b 0d 28 d9 ff ff movq -0x26d8(%rip), %r9 # 0xffffffffffffe008
6e0: 4c 8b 05 29 d9 ff ff movq -0x26d7(%rip), %r8 # 0xffffffffffffe010
6e7: 0f 01 f9 rdtscp
6ea: 66 90 nop
6ec: 8b 0f movl (%rdi), %ecx
6ee: 39 ce cmpl %ecx, %esi
6f0: 74 0e je 0x700 <.text+0x30>
6f2: 8b 37 movl (%rdi), %esi
6f4: 85 f6 testl %esi, %esi
6f6: 75 e1 jne 0x6d9 <.text+0x9>
6f8: 48 c7 c0 ff ff ff ff movq $-0x1, %rax
6ff: c3 retq
$ sudo ln -s /lib/modules/6.9.2-local/build/arch/x86/entry/vdso/vdso64.so.dbg /usr/lib/debug/.build-id/cf/702469f4637840fd6ba1a8d8a628ff83253d04.debug
$ llvm-objdump-18 -dS ~/.debug/\[vdso\]/cf702469f4637840fd6ba1a8d8a628ff83253d04/vdso | head -20
~/.debug/[vdso]/cf702469f4637840fd6ba1a8d8a628ff83253d04/vdso: file format elf64-x86-64
Disassembly of section .text:
00000000000006d0 <vread_hvclock>:
; hv_read_tsc_page_tsc(const struct ms_hyperv_tsc_page *tsc_pg,
6d0: 48 8d 3d 29 d9 ff ff leaq -0x26d7(%rip), %rdi # 0xffffffffffffe000 <hvclock_page>
6d7: eb 19 jmp 0x6f2 <vread_hvclock+0x22>
; scale = READ_ONCE(tsc_pg->tsc_scale);
6d9: 4c 8b 0d 28 d9 ff ff movq -0x26d8(%rip), %r9 # 0xffffffffffffe008 <hvclock_page+0x8>
; offset = READ_ONCE(tsc_pg->tsc_offset);
6e0: 4c 8b 05 29 d9 ff ff movq -0x26d7(%rip), %r8 # 0xffffffffffffe010 <hvclock_page+0x10>
; asm volatile(ALTERNATIVE_2("rdtsc",
6e7: 0f 31 rdtsc
6e9: 90 nop
6ea: 90 nop
6eb: 90 nop
; } while (READ_ONCE(tsc_pg->tsc_sequence) != sequence);
6ec: 8b 0f movl (%rdi), %ecx
$
Would that solve your problem?
Notably, later versions of llvm-objdump have an option
--debug-file-directory which makes it possible to
have the debug info in a directory owned by the user,
for example:
$ sudo rm /usr/lib/debug/.build-id/cf/702469f4637840fd6ba1a8d8a628ff83253d04.debug
$ llvm-objdump-18 -dS ~/.debug/\[vdso\]/cf702469f4637840fd6ba1a8d8a628ff83253d04/vdso | head -20
~/.debug/[vdso]/cf702469f4637840fd6ba1a8d8a628ff83253d04/vdso: file format elf64-x86-64
Disassembly of section .text:
00000000000006d0 <.text>:
6d0: 48 8d 3d 29 d9 ff ff leaq -0x26d7(%rip), %rdi # 0xffffffffffffe000
6d7: eb 19 jmp 0x6f2 <.text+0x22>
6d9: 4c 8b 0d 28 d9 ff ff movq -0x26d8(%rip), %r9 # 0xffffffffffffe008
6e0: 4c 8b 05 29 d9 ff ff movq -0x26d7(%rip), %r8 # 0xffffffffffffe010
6e7: 0f 01 f9 rdtscp
6ea: 66 90 nop
6ec: 8b 0f movl (%rdi), %ecx
6ee: 39 ce cmpl %ecx, %esi
6f0: 74 0e je 0x700 <.text+0x30>
6f2: 8b 37 movl (%rdi), %esi
6f4: 85 f6 testl %esi, %esi
6f6: 75 e1 jne 0x6d9 <.text+0x9>
6f8: 48 c7 c0 ff ff ff ff movq $-0x1, %rax
6ff: c3 retq
$ mkdir -p /tmp/debug/.build-id/cf/
$ ln -s /lib/modules/6.9.2-local/build/arch/x86/entry/vdso/vdso64.so.dbg /tmp/debug/.build-id/cf/702469f4637840fd6ba1a8d8a628ff83253d04.debug
$ llvm-objdump-18 --debug-file-directory /tmp/debug -dS ~/.debug/\[vdso\]/cf702469f4637840fd6ba1a8d8a628ff83253d04/vdso | head -20
~/.debug/[vdso]/cf702469f4637840fd6ba1a8d8a628ff83253d04/vdso: file format elf64-x86-64
Disassembly of section .text:
00000000000006d0 <vread_hvclock>:
; hv_read_tsc_page_tsc(const struct ms_hyperv_tsc_page *tsc_pg,
6d0: 48 8d 3d 29 d9 ff ff leaq -0x26d7(%rip), %rdi # 0xffffffffffffe000 <hvclock_page>
6d7: eb 19 jmp 0x6f2 <vread_hvclock+0x22>
; scale = READ_ONCE(tsc_pg->tsc_scale);
6d9: 4c 8b 0d 28 d9 ff ff movq -0x26d8(%rip), %r9 # 0xffffffffffffe008 <hvclock_page+0x8>
; offset = READ_ONCE(tsc_pg->tsc_offset);
6e0: 4c 8b 05 29 d9 ff ff movq -0x26d7(%rip), %r8 # 0xffffffffffffe010 <hvclock_page+0x10>
; asm volatile(ALTERNATIVE_2("rdtsc",
6e7: 0f 31 rdtsc
6e9: 90 nop
6ea: 90 nop
6eb: 90 nop
; } while (READ_ONCE(tsc_pg->tsc_sequence) != sequence);
6ec: 8b 0f movl (%rdi), %ecx
$
next prev parent reply other threads:[~2024-07-18 17:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-02 4:18 [PATCH v5 0/8] perf: support specify vdso path in cmdline Changbin Du
2024-07-02 4:18 ` [PATCH v5 1/8] " Changbin Du
2024-07-18 17:02 ` Adrian Hunter [this message]
2024-07-22 12:19 ` duchangbin
2024-07-22 13:15 ` Adrian Hunter
2024-07-23 1:50 ` duchangbin
2024-07-02 4:18 ` [PATCH v5 2/8] perf: disasm: refactor function dso__disassemble_filename Changbin Du
2024-07-02 4:18 ` [PATCH v5 3/8] perf: disasm: use build_id_path if fallback failed Changbin Du
2024-07-02 4:18 ` [PATCH v5 4/8] perf: build-id: name debugging vdso as "debug" Changbin Du
2024-07-18 17:03 ` Adrian Hunter
2024-07-22 12:08 ` duchangbin
2024-07-22 13:21 ` Adrian Hunter
2024-07-23 1:51 ` duchangbin
2024-07-02 4:18 ` [PATCH v5 5/8] perf: symbol: generalize vmlinux path searching Changbin Du
2024-07-02 4:18 ` [PATCH v5 6/8] perf: build-id: try to search debugging vdso and add to cache Changbin Du
2024-07-02 4:18 ` [PATCH v5 7/8] perf: disasm: prefer debugging files in build-id cache Changbin Du
2024-07-02 4:18 ` [PATCH v5 8/8] perf buildid-cache: recognize vdso when adding files Changbin Du
2024-07-03 23:18 ` Namhyung Kim
2024-07-04 1:43 ` duchangbin
2024-07-24 14:55 ` kernel test robot
2024-07-15 11:38 ` [PATCH v5 0/8] perf: support specify vdso path in cmdline duchangbin
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=4ddbcd4a-bbf1-4773-94da-0a2ad63469dc@intel.com \
--to=adrian.hunter@intel.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=changbin.du@huawei.com \
--cc=hw.huiwang@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox