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

[Yangyu Chen]

On 1/15/25 00:36, Yangyu Chen wrote:
> 
> 
> On 1/8/25 03:12, Palmer Dabbelt wrote:
>>
>> At least in GCC the docs for `-fjump-table` say to turn it off if 
>> you're in
>> code that can't handle getting symbols references added, so if the 
>> rules are to
>> avoid resolving symbols in IFUNC resolvers then that's just user error 
>> (though
>> kind of a clunky one).  So I think GP is really just a red herring, 
>> here --
>> sure it's one way this can break, but we went through months of other 
>> reasons
>> this can break when we decided not to allow them.
>>
>> That said, I think there's an even bigger issue here: if we're 
>> expecting users
>> to return function pointers from the IFUNC resolver, then how are they 
>> supposed
>> to get those function pointers pre-relocation?  Even if it was easy to 
>> get the
>> compiler to only use PC-relative references, those would still just be 
>> wrong.
> 
> I think this is a feature of IFUNC that should not reference any symbol 
> that requires relocation. Luckily, the current C-API design and GCC 
> implementation of FMV have already prevented this.

Specifically, this was achieved by using the `static` [1] and `hidden` 
[2][3] attributes. We can also check it using `readelf -a` and see that 
all these symbols are locally bound.

Additionally, some compiler-generated symbols, such as jump tables, are 
not global symbols either, so there are no concerns about relocation issues.

If you have any other concerns about this patch, please don't hesitate 
to let me know.

[1] 
https://github.com/gcc-mirror/gcc/blob/3dbcf794f0fe89443288143405718d72e7963805/libgcc/config/riscv/feature_bits.c#L391
[2] 
https://github.com/gcc-mirror/gcc/blob/3dbcf794f0fe89443288143405718d72e7963805/libgcc/config/riscv/feature_bits.c#L31
[3] 
https://github.com/gcc-mirror/gcc/blame/3dbcf794f0fe89443288143405718d72e7963805/gcc/config/riscv/riscv.cc#L13365

Thanks,
Yangyu Chen

> Also, any user- > provided IFUNC resolver should be aware of this. This is not an
> architecture-specific issue related to RISC-V.
> 
> Thanks,
> Yangyu Chen
> 
>>
>> So unless I'm just lost here, I think we've got something else wrong?
>>
>>> Jess