[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251118095845.0878e759@pumpkin>
Date: Tue, 18 Nov 2025 09:58:45 +0000
From: David Laight <david.laight.linux@...il.com>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Alexandre Chartre <alexandre.chartre@...cle.com>,
linux-kernel@...r.kernel.org, mingo@...nel.org, peterz@...radead.org
Subject: Re: [PATCH v4 00/28] objtool: Function validation tracing
On Mon, 17 Nov 2025 14:38:49 -0800
Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> On Mon, Nov 17, 2025 at 10:09:53PM +0000, David Laight wrote:
> > On Mon, 17 Nov 2025 14:11:55 +0100
> > Alexandre Chartre <alexandre.chartre@...cle.com> wrote:
> >
> > > On 11/17/25 13:37, David Laight wrote:
> > > > On Mon, 17 Nov 2025 10:47:06 +0100
> > > > Alexandre Chartre <alexandre.chartre@...cle.com> wrote:
> > > >
> > > >> On 11/17/25 10:42, David Laight wrote:
> > > > ...
> > > >>> Although I think there ought to be some indication of the 31 NOP bytes
> > > >>> at the end of the middle alternative.
>
> I'm not sure we need that. It's already implied those gaps will be
> filled with NOPs. This could add unnecessary visual clutter.
But you need some idea of the size of the gap.
A large gap isn't really a good idea and may mean it is better to
refactor the code.
While the execution time of nops might be zero, there is still
the cost of fetching and decoding them.
...
> > Do I remember something about the trailing nop being merged?
> > Perhaps that is the kernel patching code.
> > Something made me think objtool might (also) be doing it.
>
> Yes, IIRC, the alternatives code merges the small NOPs into bigger ones.
That probably means it doesn't matter how objdump displays them.
But perhaps it ought to output NOP*5 rather than NOP5 to make it
clear it is a block of NOP (that will converted later) rather
than a single NOP5 instruction.
David
Powered by blists - more mailing lists