Received-SPF: pass (google.com: domain of linux-kernel+bounces-205114-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 6 Jun 2024 15:18:56 -0700
From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: objtool query: section start/end symbols?
Message-ID: <20240606221856.g3iboxfkkgzp6sd3@treble>
References: <CAHk-=wjHf6C_74VQPxmge-sMmu5yuhmNor1TaO0Uq--zrA13HA@mail.gmail.com>
 <20240606194525.cdnnidxurejsjtx4@treble>
 <CAHk-=wjdrJ1H7sbsaL8_bLvRmt26_io=5_b3k_g33kd+bwFHzA@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAHk-=wjdrJ1H7sbsaL8_bLvRmt26_io=5_b3k_g33kd+bwFHzA@mail.gmail.com>

On Thu, Jun 06, 2024 at 02:10:30PM -0700, Linus Torvalds wrote:
> So what I'm interested in would be to simplify things, and get rid of
> the "key" entirely, because with a good symbol for the start and end
> of the array of users (for _each_ pseudo-constant symbol), it all
> makes the code a lot more straightforward.
> 
> In particular, it would make the architecture side much more
> straightforward, because instead of traversing some "array of keys and
> types" and pick up the ones that match, it would just traverse an
> array that is already pre-matched, because each key goes into its own
> section.
> 
> So I want to *simplify* the code, not make it the horrendous
> complicated mess that is static calls. No "build up that list of
> sites" at run-time.
> 
> Now, I actually suspect that doing this thing would then allow *other*
> cases - like possibly static calls - to simplify their code too. I
> think the static calls could easily use this to simplify the code.
> 
> So I would throw your question back at you and say "No! I'm asking for
> this support because it would allow me to *not* do even a simplified
> version of the horrible things that static calls do".

The "key" idea was probably misguided.  I didn't mean to suggest to make
it all complex like static branches/calls, I was just hoping there's a
simple way to implement "static consts" without needing objtool.

Aside from the idea of avoiding "magic", another small downside of using
objtool is that isn't currently supported on most arches.  That said, it
should be easy enough to make it arch-independent by default for simple
features like this, it just needs a little refactoring.

I still get the feeling there's a way to keep static consts simple
without objtool, but I'm too knee-deep in another problem at the moment
to be able to back that feeling up with much technical merit.

So while I'm not yet necessarily conceding that objtool is really needed
here, I could work up a quick objtool patch.  It would just be x86-only,
is that ok for the time being?

-- 
Josh