Re: objtool query: section start/end symbols?

[Linus Torvalds]

On Thu, 6 Jun 2024 at 12:45, Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote:
>
> That should be trivial.  But ideally the interface would be less magical
> and wouldn't need objtool to sprinkle any pixie dust.  Could it be
> implemented similar to static keys by making the static const variable
> an opaque structure instead of just a "normal" variable?

So I will absolutely add some wrappers - we'll need them just to make
the "no static constants" case work.

I doubt I'll need any more than a simple wrapper, because there is no
equivalent of a trampoline when it comes to static constants - the
whole point is avoiding any indirection at all, and generating better
code.

So the only "wrapper" needed is the "different architectures will have
to have different ways to generate the runtime constant operations"
and the "with no support, it will just use the variable as before".

But the data itself is fundamentally embedded in the inline asm that
generates the constant op (note that I say "op" - it's not just
loading a constant, it's using a constant as *part* of the
instruction).

IOW, think of this more as an "alternative asm", where the alternative
is about the constants used in order to avoid memory loads and extra
registers.

I did name it after the "static call" model, but it's actually pretty different.

For example, if we ever extend this to modules, then any constants
will be fixed up by the module loader. There will not ever be any
dynamic rewriting like static calls support.

This would be for some very core constants only. Not random code that
wants to avoid an indirect call.

My code did the dentry hash table and size, but I would envision it
would be for pseudo-constants like __VIRTUAL_MASK_SHIFT etc (which
_used_ to be a big pain for put_user() and friends, but we solved it
with a different model).

Things that depend purely on boot time stuff.

>   DEFINE_STATIC_CONST(dentry_hashtable);
>
> That could create something similar to 'struct static_key' which
> correlates the const variable with all its use sites.

Oh, honestly, I don't need the disgusting things that static_calls()
do. The patch I already have is better than that.

IOW, already have the list of where the static call data is (the thing
that the .static_call_sites section contains).

Sure, it's not a "single" array of sites, because my sections are
partitioned by size (the static calls use a flag value instead), and
my "key" for the array traversal is just the address of the runtime
constant that they deal with.

It all works fine, although it will need some abstraction to deal with
different architectures.

I'm not at all interested in creating some fancy linked list of those
things like static calls do in __static_call_init() at runtime.,

This is literally for a one-time constant for built-in code, I think
the static call code is completely over-designed and inappropriate for
this.

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".

                    Linus