mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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).



  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®