On 15/9/2023 5:07 pm, Sebastian Huber wrote: > On 14.09.23 23:56, Chris Johns wrote: >> 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. > > It would be really nice to have a Doxygen comment for rtems_rtl_tls_get_base() > which contains this information.
Good idea. The change is still in development and now you are back and commenting I am happy to do this. > There are also no test cases for this function. > Without test cases it is easy to break something without knowing it. The libdl test cases have been updated to reference TLS newlib variables to test this. Is that enough? If not what would you like to see? Note, TLS variables in loaded modules is not supported. That needs an allocator and the size of TLS memory used by base image variables. Most of the code is in libdl (see PowerPC SDATA) so these change may make that be within reach. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
