Re: global pointer gets overwritten with dlopen(3) on RISC-V

[Jeff Law <jeffreyalaw@gmail.com>]

On 5/12/23 14:11, Florian Weimer via Libc-alpha wrote:
> * Fangrui Song:
> 
>>> 1. Make -mno-relax the default for ld(1) (on Linux?). We have no
>>> benchmarks whatsoever, but global variables aren't very popular in
>>> application code these days and the gp register allows access to a
>>> single memory page (4kB) only. No big deal really.
>>
>> I do agree that --no-relax-gp is a sensible default choice for GNU ld.
>> https://maskray.me/blog/2021-03-14-the-dark-side-of-riscv-linker-relaxation#global-pointer-relaxation
>>
>> Perhaps you can start a separate topic on binutils? :)
>>
>> According to a doc from SiFive about -static -mcpu=sifive-u74 builds,
>> https://docs.google.com/spreadsheets/d/14V7cPbyc80AcGHzsMaw9hYb232dzRbGCmTApnxj-SpU/edit#gid=0
>> global pointer relaxation saves at best 0.5% size (I guess that refers
>> to .text. If we count all allocable sections, the percentage is likely
>> even smaller.)
> 
> For a mature toolchain, 0.5% in code size reduction would be *a lot*,
> so I wouldn't dismiss that.
However, that value is probably a little low.

There is a really interesting little bug in the interaction between how 
we place gp and how we determine if an address computation is relaxable. 
  The net result is for relatively small data segments we can fail to 
relax address computations that we should be able to trivially cover 
with gp based addressing.

This showed up as a clearly measurable runtime performance regression in 
spec2017.  leela or deepsjeng, I can't remember which offhand.  It would 
also likely be a size issue, though I rarely look at those size issues.

Knowing that I still question if it is worth the effort to relax. 
Others have much more strongly held positions.

Jeff




> 
> Do we have a reproducer?  Is the issue actually about gp relaxation for
> the main executable?
> 
> Thanks,
> Florian
>