[PATCH] RISC-V: Use tp as gp when no TLS is used.

[Kito Cheng]

TP as GP has discussed and appeared within the psABI group several times,
and I believe tp-as-gp is useful for some specific embedded applications which
didn't have thread at all, so my expectation is that is not expected work on
linux or any non bare-metal platform - which means we don't really worry
about DSO issue - because it not intended to support that :P

Actually EABI has put that into the list[1], but unfortunately we
don't have enough
resources to develop that, so from the psABI aspect we welcome anyone
who is interested to contribute :)

Back to the patch itself, I think we might need to add a new ELF attribute
for that, and check the compatibility at link time, also need to specify
how tp initialized in the psABI spec, it defined as assume tp = gp + 0x1000,
but I would suggest you could define some extra symbol like
__global_pointer_tp$ for initialized tp, that would be more flexible
and it might be possible to cover more symbol access if it's
not fixed into gp.

[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/305

On Fri, Aug 4, 2023 at 3:35 PM Die Li <lidie@eswincomputing.com> wrote:
>
> Hi,
> On 2023-08-04 13:28,  Jeff Law wrote:
> >
> >
> >
> >On 8/3/23 05:51, Die Li wrote:
> >> This patch extends the GP-relative addressing mode by adding a 4K address
> >> range on top of GP+2k, using the TP register instead of GP for relative
> >> addressing. This allows more data to benefit from the relative addressing
> >> access mode. As TP register is used for this optimization, it checks for
> >> the presence of TLS (Thread-Local Storage) sections to ensure that the
> >> optimization is performed only when TP is available. Additionally, a linker
> >> option, "--tp-as-gp", is introduced to control the enabling of this optimization.
> >>
> >> Take the "tp_as_gp.s" from this patch as an example to illustrate its optimization effect:
> >>
> >> Before this patch:
> >> After assembling and processing with "--relax", we have:
> >> 00000000000100e8 <_start>:
> >>     100e8:   67c5                lui a5,0x11
> >>     100ea:   0f878793          add   a5,a5,248 # 110f8 <global_array>
> >>     100ee:   67c9                lui a5,0x12
> >>     100f0:   6d878793          add   a5,a5,1752 # 126d8 <global_array2>
> >>
> >> With this patch:
> >> After assembling and processing with "--relax --tp-as-gp", we have:
> >> 00000000000100e8 <_start>:
> >>     100e8:   67c5                lui a5,0x11
> >>     100ea:   0f878793          add   a5,a5,248 # 110f8 <global_array>
> >>     100ee:   de620793          add   a5,tp,-538 # .*
> >>
> >> Check the symbol table, we have:
> >>       6: 00000000000118f4     0 NOTYPE  GLOBAL DEFAULT  ABS __global_pointer$
> >>
> >> The addressable range of TP is increased by 4K beyond the addressable range of GP,
> >> thus setting TP to GP+0x1000. So the access to global_array2, which was originally
> >> represented as "lui a5,0x12" followed by "add a5,a5,1752 # 126d8", is optimized to
> >> "add a5,tp,-538", which is feasible.
> >>
> >> Signed-off-by: Die Li <lidie@eswincomputing.com>
> >>
> >> ChangeLog:
> >>
> >>          * bfd/elfnn-riscv.c (tpoff):
> >>          (_bfd_riscv_relax_lui): Convert R_RISCV_HI20 to R_RISCV_TPREL_HI20,
> >>                                  R_RISCV_LO12_I to R_RISCV_TPREL_LO12_I,
> >>                                  R_RISCV_LO12_S to R_RISCV_TPREL_LO12_S
> >>                                  when use tp as gp.
> >>          * ld/ldlex.h (enum option_values): Add OPTION_RELAX_TP_AS_GP.
> >>          * ld/ldmain.c (main): Add option state.
> >>          * ld/ldmain.h (ENABLE_TP_AS_GP): New macro to control option.
> >>          * ld/lexsup.c (parse_args): Add --tp-as-gp option.
> >>          * ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Add test entry.
> >>          * ld/testsuite/ld-riscv-elf/tp_as_gp.d: New test.
> >>          * ld/testsuite/ld-riscv-elf/tp_as_gp.s: New test.
> >Is this actually safe?  Consider that the linked executable/DSO  may not
> >have any TLS sections, but it may dlopen a DSO which does have TLS
> >sections.   The linker doesn't have the visibility to know if this
> >happens or not.
> I noticed that there is a variable named "elf_hash_table (info)->tls_sec" in the linker,
> which indicates whether there is a TLS (Thread Local Storage) section. However, as
> you mentioned, if it is not sufficient, users need to explicitly state that there will be
> no TLS sections. This limitation can be too restrictive for users. I'm a beginner at
> linker. Thanks for your discussion.
> >Furthermore, there's nothing that says a program couldn't have its own
> >implementation that behaves like dlopen, but doesn't actually use dlopen
> >(xorg IIRC used to do something like this).
> >
> >ISTM this can only be done when the user has explicitly asked for this
> >behavior.
> >
> >jeff