Re: odd objtool 'unreachable instruction' warning

[David Laight <david.laight.linux@gmail.com>]

On Wed, 29 Oct 2025 11:05:33 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Wed, Oct 29, 2025 at 09:56:38AM +0000, David Laight wrote:
> > On Tue, 28 Oct 2025 12:29:11 -0700
> > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >   
> > > Josh, Peter,
> > >  due to another entirely unrelated discussion, I ended up resurrecting
> > > my "make asm readable" patch that I have had in my local tree when I
> > > want to look at the actual generated code for user accesses.
> > > 
> > > That is a local hack that just removes the alternative noise for the
> > > common ops, so that I actually see the fences and clac/stac
> > > instructions as such, instead of seeing them as nops in the object
> > > file or as horrible noise in the assembler output.  
> > 
> > I've toyed with using explicit nop sequences that would be identifiable
> > as stac, clac and lfence.
> > 
> > At least that would tell you which is which.
> > 
> > Since the flags can be trashed there are plenty to choose from.
> > (eg all the cmpb $n,%reg if you don't mind a false dependency.)  
> 
> As long as you ensure that insn_is_nop() recognises it as such, they
> won't actually ever get ran after alternative patching, since they'll be
> rewritten in canonical nops by optimize_nops().

Ah - I've wondered about the 'nop; nop; nop' being slightly sub-optimal.
But it is hard enough to see what happens to the alternative that is
selected never mind the ones that aren't.

Instructions that change the flags can't be changed to nops.
So possibly the best options are the 0f-1f-cx (for x 0..7).
So 'long_nop %reg' rather than 0f-1f-00 'long_nop [%rax]'.

(But I've not checked the full rules for the addressing modes of
'long_nop'.)

	David