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

[Yangyu Chen]

On 1/13/25 20:50, Florian Weimer wrote:
> * Yangyu Chen:
> 
>> 2. There is no ABI grey area now.
>>
>>  From [3] we have: `__global_pointer$` must be exported in the dynamic
>> symbol table of dynamically-linked executables if there are any
>> GP-relative accesses present in the executable.
> 
> If you can link editors to follow this even with version scripts that
> use ”local: *”, it will work.  But that's a big If.
> 

Thanks for that pointing out. For this issue, I think we should modify 
the psABI to force the linker to export `__global_pointer$` even with 
the existing version script. At least, the linker should output a 
warning message. Whatever, it is still simpler than adding something 
like DT_RISCV_GP_VALUE.

> We've relied on unconditionally exported symbols before, and I don't
> think it works very well.  See _IO_stdin_used and bug reports related to
> that.
> 
>> 3. The original bug happens because the NULL value of l->l_scope has
>> been solved by this patch.
>>
>> The root cause of the original bug is l->l_scope is NULL when calling
>> elf_machine_runtime_setup in statie-pie. Because we have no scope at
>> this time in statie-pie.
>>
>> However, static-pie doesn't need to do this. It will call `load_gp` at
>> entry_point, thus there is no need to lookup symbol and set up gp
>> here. We just solve it by adding `#ifdef SHARED`.
> 
> Agreed.
> 
> This lookup should not use the link map's scope anyway because that
> could included preloaded objects with a conflicting definition of
> __global_pointer$.  You can use _dl_lookup_direct, similar to what
> _dl_call_libc_early_init does.  It wants the symbol in exactly this
> particular object, too.

If we have checked l->l_type == lt_executable before looking for the 
`__global_pointer$` symbol, I think some preloaded objects will not 
cause any conflicting definitions. Is it right? Or am I missing something?

Thanks,
Yangyu Chen

> 
> Thanks,
> Florian