[PATCH] RISC-V: Stop referencing __global_pointer$ under PIC

[Palmer Dabbelt]

On Mon, 26 Jun 2023 06:55:54 PDT (-0700), Jeff Law wrote:
>
>
> On 6/26/23 07:44, Palmer Dabbelt wrote:
>> On Thu, 08 Jun 2023 09:44:37 PDT (-0700), Palmer Dabbelt wrote:
>>> This has some cascading fallout related to PC-relative references to
>>> SHN_ABS that Jim reported in [1].  I have a workaround for that issue in
>>> binutils [2], but GP isn't useful in PIC so we might as well just stop
>>> referencing it at all.
>>>
>>> Link: https://sourceware.org/bugzilla/show_bug.cgi?id=24678
>>> Link:
>>> https://inbox.sourceware.org/binutils/20230608155214.32435-1-palmer@rivosinc.com/T/#u
>>> Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
>>>
>>> ---
>>>
>>> I haven't tested thiis or the binutils patch.  There's a handful of
>>> coupled issues here that might take a bit to untangle, but this came up
>>> in the RISC-V LLVM sync this morning so I figured it would be best to
>>> send something along.
>>
>> Nelson found the binutils patch to allow this behavior 890744e8585
>> ("RISC-V: PR28789, Reject R_RISCV_PCREL relocations with ABS symbol in
>> PIC/PIE."), it was committed with the bit that allows these symbols to
>> be resolved when linking.  Dropping that causes pretty much everything
>> to fail to link, so at least that part of the mystery is solved.
>>
>> That leaves us with what to do here.  Nelson pointed out that just
>> leaving GP uninitialized is probably the wrong way to go, so at least
>> setting it to 0 seems reasonable.  It also might be better to fix the
>> emulparams bug and just keep putting GP in the CRTs, though, as in
>> theory this is usable for PIEs and thus removing it is an ABI break
>> (though as far as I know we're not using it and it's currently subtly
>> broken).
>>
>> The rough plan would be to get a patch in binutils that makes the
>> SHN_ABS/PIC resolution optional (probably both a command-line argument
>> and a configure-time default) and then try a ditro rebuild with it to
>> see if anything else breaks.  With the binutils release coming up we're
>> probably not going to have time to get confidence in any changes over
>> there, so it's probably best to wait a bit on this one as well just to
>> avoid risking breaking anything.
> So just from a staging standpoint.  The fall Fedora releases often do
> not do full distro rebuilds, but the spring releases always perform full
> Fedora rebuilds.  Additionally there should be another release of
> binutils & glibc in time for the spring 2024 Fedora build.
>
> Meaning that there's no huge rush to push this through, at least from a
> Fedora standpoint -- the real goal should be to have all the pieces in
> place for the spring 2024 release.  Meaning binutils-2.42 and glibc-2.39.

Just to be clear: this isn't for the GP-free ABI, it's just a bug fix 
for the GP-enabled ABI.  It happens the bug fix ends up triggering a 
rabbit hole of other bugs, hence the complexity.

> I'm less familiar with the Debian, SuSE and Ubuntu schedules, but I do
> think they do full builds in the spring as well (mostly to pick up the
> new compilers).  So further support for trying to line things up fo the
> spring 2024 releases.
>
> jeff