[PATCH v3] RISC-V: Fix IFUNC resolver cannot access gp pointer

[Jessica Clarke]

On 7 Jan 2025, at 16:38, Florian Weimer <fweimer@redhat.com> wrote:
> 
> * Palmer Dabbelt:
> 
>> On Mon, 06 Jan 2025 18:32:54 PST (-0800), cyy@cyyself.name wrote:
>>> Ping again. It has already been 1 month after v3 patch was submitted.
>>> 
>>> I think this patch is critical for RISC-V GCC Function multi-versioning
>>> to work correctly, as GCC 15, which has this feature, is going to be
>>> released.
>> 
>> IIUC the conclusion here was to avoid global symbol resolution in
>> IFUNCs and instead use the pre-resolved function hwprobe VDSO function
>> pointer passed in via a register.  There was a long discussion on this
>> during the hwprobe/IFUNC support patches, and IIRC one during the FMV
>> patches -- though I remember accepting those and now I'm not sure why,
>> so maybe I'm just forgetting something here?
> 
> As far as I understand it, at least in some cases, the gp register needs
> to be set up for the main program even for local static/hidden symbol
> access.  Unfortunately, the ABI does not provide a completely reliable
> way for the dynamic linker to discover the gp value the main program
> requires, which leads to the code we have now.  I think we should have
> something that is more declarative than running a piece of assembler
> code at the right time (the existing code runs too late, after IFUNC
> resolver), and which does not depend on dynamic symbol resolution.

And, notably, source code that makes no use of global variables can
still end up implicitly using them, e.g. for switch statements, which
you could imagine being used for hwprobe-using code in the case of keys
that have enum values, like misaligned scalar perf. Both GCC and Clang
optimise to using a lookup table for switch statements over an enum
with that many cases, which means a global access that could become
GP-relative with the right (wrong?) linker and memory layout. See
https://godbolt.org/z/KEbof5z7h for a minimal example of that, which is
completely valid and sensible (modulo bugs from lack of testing) code
that you can write today with hwprobe and that is broken if the lookup
table is laid out by GNU ld to be close enough to __global_pointer$.

Jess