[rtems commit] libdl: Add support to import base image TLS symbols

[Chris Johns]

On 14/9/2023 7:33 pm, Sebastian Huber wrote:
> On 14.09.23 10:51, Chris Johns wrote:
>> On 14/9/2023 5:58 pm, Sebastian Huber wrote:
>>> On 14.09.23 09:38, Chris Johns wrote:
>>>>>> The issue I faced was no score interface to get the TLS base for a thread to
>>>>>> determine a symbol's offset. If we had that and something to say if TLS is
>>>>>> supported libdl would be easy to fix.
>>>>> Why don't we add this interface if it simplifies things?
>>>> Yes please, that would be good. I do not know the TSL support well enough to do
>>>> a decent job of it.
>>> Which interface do you need?
>> A define that says TLS is support for an arch?
>>
>> A call that returns the base address for an arch? I have added some in libdl:
>>
>> https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-tls.c
>>
>> however having this in score would mean a new arch does not break libdl.
> 
> Yes, this should be definitely added to the CPU port. What is the purpose of
> rtems_rtl_tls_get_base()? It seems to be unused.

It is used by the symbol table loader so is referenced in the symbol table
generated code ...

https://git.rtems.org/rtems-tools/tree/linkers/rtems-syms.cpp#n66
https://git.rtems.org/rtems-tools/tree/linkers/rtems-syms.cpp#n319

A TLS symbol is an offset into the TLS area. I encountered two problems. First I
could not find a way to equate a TLS symbol offset to a label in asm or C and
second the offsets move with each link phase and with the 2 stage linking the
offsets move. As a result the offset needs to be computer at runtime. To do this
the base image TLS symbols each get a small piece of code that determines the
offset at runtime. The symbol table in the target contains the TLS area offset
in an arch ABI specific format. The relocs know how to handle the offset the
symbol holds.

Chris