[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <72juhabxma7rw5eq2gglct4lmeoqfvrlv5jf36sdcfimz5rxxd@gnfuxdgv6stj>
Date: Wed, 3 Dec 2025 09:46:53 -0800
From: Josh Poimboeuf <jpoimboe@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
linux-tip-commits@...r.kernel.org, x86@...nel.org
Subject: Re: [tip: objtool/urgent] objtool: Consolidate annotation macros
On Wed, Dec 03, 2025 at 09:21:55AM -0800, Linus Torvalds wrote:
> On Wed, 3 Dec 2025 at 08:57, Ingo Molnar <mingo@...nel.org> wrote:
> >
> > Find below a diff of the arch/x86/kernel/process.s output
> > of your tree versus current tip:objtool/urgent.
>
> Yeah, just a single example would have been sufficient, ie a simple
>
> Turn
>
> 911:
> .pushsection .discard.annotate_insn,"M", @progbits, 8
> .long 911b - .
> .long 1
> .popsection
> jmp __x86_return_thunk
>
> Into
>
> 911: .pushsection ".discard.annotate_insn", "M", @progbits, 8;
> .long 911b - .; .long 1; .popsection
> jmp __x86_return_thunk
>
> and btw, the quotes around the section name are not necessary afaik.
Indeed, I can remove those quotes.
> Also, I have to say that being mergeable is a bit annoying here:
> without that, we could drop the "@progbits, 8" parts too which is just
> strange noise. Is the mergeability really a win? Because I'd assume
> that it's never *actually* merged, since the expression "911b-." ends
> up being a unique value?
>
> What am I missing? It *feels* like this should just all be
>
> 911: .pushsection .discard.annotate_insn ; .long 911b - .;
> .long 1; .popsection
> jmp __x86_return_thunk
>
> instead. But it's entirely possible I'm not seeing the reason here...
So that mergeable thing is the only way to convince the toolchains to
allow setting the section entsize, which is a generic way for objtool to
look at the myriad of special sections and determine their entry sizes,
so it can extract individual entries for the purposes of creating
livepatch modules.
In this case I do realize the irony of objtool needing to know the
section size of a section which is explicitly created for objtool's use
(so of course it already knows the size).
In actuality they are two completely separate subcommands of objtool.
"Regular" objtool reads .discard.annotate_insn for its annotations,
whereas "objtool klp diff" extracts special section entries. It does so
in a generic way (entsize), regardless of whether the special section is
objtool-specific or not (e.g., the bug table).
--
Josh
Powered by blists - more mailing lists