From: Peter Zijlstra <peterz@infradead.org>
To: Alexandre Chartre <alexandre.chartre@oracle.com>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, jpoimboe@kernel.org
Subject: Re: [RFC PATCH v2 00/17] objtool: Function validation tracing
Date: Wed, 24 Sep 2025 09:42:06 +0200 [thread overview]
Message-ID: <20250924074206.GW4068168@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20250924073649.GT4067720@noisy.programming.kicks-ass.net>
On Wed, Sep 24, 2025 at 09:36:49AM +0200, Peter Zijlstra wrote:
> > Example 2 (--disas option): Disassemble perf_get_x86_pmu_capability()
> > ---------------------------------------------------------------------
> >
> > $ ./tools/objtool/objtool --disas=perf_get_x86_pmu_capability --link vmlinux.o
> > perf_get_x86_pmu_capability:
> > d000: perf_get_x86_pmu_capability endbr64
> > d004: perf_get_x86_pmu_capability+0x4 callq __fentry__
> > d009: perf_get_x86_pmu_capability+0x9 mov %rdi,%rdx
> > <alternative.d00c> default - begin
> > d00c: perf_get_x86_pmu_capability+0xc | jmpq .altinstr_aux+0x90
>
> (you probably need to relocate the target -- we never jump into alinstr)
>
> > <alternative.d00c> default - end
> > <alternative.d00c> 1/2 - begin
> > | <fake nop> (5 bytes)
> > <alternative.d00c> 1/2 end
> > <alternative.d00c> 2/2 - begin
> > 5e5: .altinstr_replacement+0x5e5 | jmpq perf_get_x86_pmu_capability+0x3f
> > <alternative.d00c> 2/2 end
>
> Idem; the above is *really* hard to decipher.
>
> d00c: perf_get_x86_pmu_capability+0xc | jmpq .altinstr_aux+0x90 | nop5 | jmpq perf_get_x86_pmu_capability+0x3f
>
> > d011: perf_get_x86_pmu_capability+0x11 ud2
> > d013: perf_get_x86_pmu_capability+0x13 movq $0x0,(%rdx)
> > d01a: perf_get_x86_pmu_capability+0x1a movq $0x0,0x8(%rdx)
> > d022: perf_get_x86_pmu_capability+0x22 movq $0x0,0x10(%rdx)
> > d02a: perf_get_x86_pmu_capability+0x2a movq $0x0,0x18(%rdx)
> > d032: perf_get_x86_pmu_capability+0x32 xor %eax,%eax
> > d034: perf_get_x86_pmu_capability+0x34 xor %edx,%edx
> > d036: perf_get_x86_pmu_capability+0x36 xor %ecx,%ecx
> > d038: perf_get_x86_pmu_capability+0x38 xor %edi,%edi
> > d03a: perf_get_x86_pmu_capability+0x3a jmpq __x86_return_thunk
> > d03f: perf_get_x86_pmu_capability+0x3f cmpq $0x0,0x0(%rip) # x86_pmu+0x10
> > d047: perf_get_x86_pmu_capability+0x47 je d013 <perf_get_x86_pmu_capability+0x13>
> > d049: perf_get_x86_pmu_capability+0x49 mov 0x0(%rip),%eax # x86_pmu+0x8
> > d04f: perf_get_x86_pmu_capability+0x4f mov %eax,(%rdi)
> > <jump alternative.d051> default
> > d051: perf_get_x86_pmu_capability+0x51 | xchg %ax,%ax
> > <jump alternative.d051> else
> > d051: perf_get_x86_pmu_capability+0x51 | jmp d053 <perf_get_x86_pmu_capability+0x53>
> > <jump alternative.d051> end
>
> this is a jump_label; if we would retain the whole 'key' reloc, and
> not only the key_addend, you could make it something like:
>
> d051: perf_get_x86_pmu_capability+0x51 [ jmp.d8 d053 <perf_get_x86_pmu_capability+0x53> ] * perf_is_hybrid
>
> (also, this here reads like it is either nop2 or jmp.d8 +0, which is
> 'weird')
Also, particularly in alternatives I think it makes sense to make
explicit distinction between jmp.d8 and jmp.d32 (and similar for Jcc.d8
/ Jcc.d32).
next prev parent reply other threads:[~2025-09-24 7:42 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-19 14:56 Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 01/17] objtool: Move disassembly functions to a separated file Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 02/17] objtool: Create disassembly context Alexandre Chartre
2025-09-23 22:23 ` Josh Poimboeuf
2025-06-19 14:56 ` [RFC PATCH v2 03/17] objtool: Disassemble code with libopcodes instead of running objdump Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 04/17] tool build: Remove annoying newline in build output Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 05/17] objtool: Print symbol during disassembly Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 06/17] objtool: Improve offstr() output Alexandre Chartre
2025-09-23 22:23 ` Josh Poimboeuf
2025-06-19 14:56 ` [RFC PATCH v2 07/17] objtool: Store instruction disassembly result Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 08/17] objtool: Disassemble instruction on warning or backtrace Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 09/17] objtool: Extract code to validate instruction from the validate branch loop Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 10/17] objtool: Record symbol name max length Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 11/17] objtool: Add option to trace function validation Alexandre Chartre
2025-09-23 22:25 ` Josh Poimboeuf
2025-06-19 14:56 ` [RFC PATCH v2 12/17] objtool: Trace instruction state changes during " Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 13/17] objtool: Improve register reporting " Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 14/17] objtool: Improve tracing of alternative instructions Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 15/17] objtool: Do not validate IBT for .return_sites and .call_sites Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 16/17] objtool: Add the --disas=<function-pattern> action Alexandre Chartre
2025-06-19 14:56 ` [RFC PATCH v2 17/17] objtool: Disassemble all alternatives when using --disas Alexandre Chartre
2025-09-23 22:33 ` [RFC PATCH v2 00/17] objtool: Function validation tracing Josh Poimboeuf
2025-09-24 9:25 ` Alexandre Chartre
2025-09-24 7:36 ` Peter Zijlstra
2025-09-24 7:42 ` Peter Zijlstra [this message]
2025-09-24 10:08 ` Peter Zijlstra
2025-09-24 10:10 ` Peter Zijlstra
2025-09-24 10:52 ` Alexandre Chartre
2025-09-24 10:58 ` Peter Zijlstra
2025-09-24 11:45 ` Peter Zijlstra
2025-09-24 11:57 ` Alexandre Chartre
2025-09-24 9:17 ` Peter Zijlstra
2025-09-24 9:50 ` Alexandre Chartre
2025-09-24 9:57 ` Peter Zijlstra
2025-09-24 9:37 ` Alexandre Chartre
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=20250924074206.GW4068168@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alexandre.chartre@oracle.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@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®