Re: [rtems commit] libdl: Add support to import base image TLS symbols
On 18/9/2023 10:09 pm, Sebastian Huber wrote: > On 17.09.23 00:58, Chris Johns wrote: >>> 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? > > These higher level tests are all right, however, it would be nice to have also > lower level tests which just check a particular function like > rtems_rtl_tls_get_base(). This would improve the maintainability of this > stuff. > You would not have to debug a tool generated code to figure out what is wrong. This makes sense. I will think about a suitable test. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
On 17.09.23 00:58, Chris Johns wrote: 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? These higher level tests are all right, however, it would be nice to have also lower level tests which just check a particular function like rtems_rtl_tls_get_base(). This would improve the maintainability of this stuff. You would not have to debug a tool generated code to figure out what is wrong. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
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
Re: [rtems commit] libdl: Add support to import base image TLS symbols
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. There are also no test cases for this function. Without test cases it is easy to break something without knowing it. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
On Thu, Sep 14, 2023 at 4:33 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> 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. > MIPS does not have TLS support. GCC generates a specific illegal instruction and the exception handler does the right thing. Is there a way to tell GCC to use a function call? That would be much easier across all the secondary architectures. --joel > > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
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. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
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. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
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? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
On 14/9/2023 5:20 pm, Sebastian Huber wrote: > On 14.09.23 09:12, Chris Johns wrote: >> On 14/9/2023 4:55 pm, Sebastian Huber wrote: >>> On 14.09.23 08:34, Sebastian Huber wrote: This seems to break the mips build: cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture 104 | #error unsupported architecture | ^ >>> Also the moxie and 64-bit powerpc (qoriq_e6500_64) no longer build with the >>> error above. >> Yes. It was decided this be a hard error so it gets fixed. The newlib TLS >> change >> broke libdl and it is being fixed for the release. I have done what I can and >> know about but some archs need help from those who know about it. > > An intentionally broken build is not really helpful. Yes it is not ideal but leaving libdl broken with no one knowing is also not helpful. We needed a circuit breaker. > There are also other bugs left to fix, for example: > > https://devel.rtems.org/ticket/4953 > > How can I check if my patches break the build if it is already broken? Like I said it is not a prefect solution and we need to resolve this as a team. I have done some of the hard work in libdl to get things under way but I need help in the TLS score area. >> I am not sure about moxie, if it does not have TLS support it can disabled. > > moxie and mips don't have TLS support. > >> >> 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. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
On 14.09.23 09:12, Chris Johns wrote: On 14/9/2023 4:55 pm, Sebastian Huber wrote: On 14.09.23 08:34, Sebastian Huber wrote: This seems to break the mips build: cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture 104 | #error unsupported architecture | ^ Also the moxie and 64-bit powerpc (qoriq_e6500_64) no longer build with the error above. Yes. It was decided this be a hard error so it gets fixed. The newlib TLS change broke libdl and it is being fixed for the release. I have done what I can and know about but some archs need help from those who know about it. An intentionally broken build is not really helpful. There are also other bugs left to fix, for example: https://devel.rtems.org/ticket/4953 How can I check if my patches break the build if it is already broken? I am not sure about moxie, if it does not have TLS support it can disabled. moxie and mips don't have TLS support. 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? -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
On 14/9/2023 4:55 pm, Sebastian Huber wrote: > On 14.09.23 08:34, Sebastian Huber wrote: >> This seems to break the mips build: >> >> cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture >> 104 | #error unsupported architecture >> | ^ >> > > Also the moxie and 64-bit powerpc (qoriq_e6500_64) no longer build with the > error above. Yes. It was decided this be a hard error so it gets fixed. The newlib TLS change broke libdl and it is being fixed for the release. I have done what I can and know about but some archs need help from those who know about it. I am not sure about moxie, if it does not have TLS support it can disabled. 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. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
On 14.09.23 08:34, Sebastian Huber wrote: This seems to break the mips build: cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture 104 | #error unsupported architecture | ^ Also the moxie and 64-bit powerpc (qoriq_e6500_64) no longer build with the error above. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] libdl: Add support to import base image TLS symbols
This seems to break the mips build: cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture 104 | #error unsupported architecture | ^ -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
