On 20/7/2022 5:03 pm, Sebastian Huber wrote: > On 20/07/2022 02:24, Chris Johns wrote: >> On 19/7/2022 5:18 pm, Sebastian Huber wrote: >>> On 13/07/2022 11:24, Sebastian Huber wrote: >>>> This makes the --enable-newlib-reent-thread-local >>>> (_REENT_THREAD_LOCAL_STORAGE) >>>> Newlib configuration option available. >>> >>> Any comments with respect to using the Newlib thread-local storage >>> configuration >>> option for arm, i386, microblaze, nios2, powerpc, riscv, and sparc? >> >> Do these archs have working TLS support? It seems Microblaze has issues which >> our tests are not picking up. It would be good to know why our tests are not >> picking up the reported problem. > > There seems to be an issue with i386: > > 08:09:56 runner ['/opt/rtems/6/bin/rtems-ld', '-C', > '/opt/rtems/6/bin/i386-rtems6-gcc', '-c', '-MMD -Wall -Wmissing-prototypes > -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs > -mtune=pentiumpro -march=pentium', '-O', 'rap', '-b', > '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06.pre', '-e', > 'rtems_main', '-s', '-o', > '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06.rap', > '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06-o1.o', > '/tmp/sh/b-rtems/i386/pc686/testsuites/libtests/dl06/dl06-o2.o', '-lm'] > error: libc.a:libc_a-lcong48.o@922544: symbol not found: > _GLOBAL_OFFSET_TABLE_> > I will remove i386 from the patch.
Good idea. We should only move those we know work. > I can't say much about the microblaze. I suggest we leave that one out unless Joel says otherwise. >> Which archs in the list have you run the testsuite on? > > I did test runs with simulators on aarch64, arm, powerpc, riscv, and sparc. Thanks. It helps knowing this list if someone needs to track down an issue. >> Has any of newlib's tests been run? Can we run newlib tests? > > Are there Newlib tests? We added a newlib01 test which tests some Newlib > details. https://github.com/RTEMS/sourceware-mirror-newlib-cygwin/tree/master/newlib/testsuite I have never looked at them but I thought it was worth asking. >> Did the switch to TLS exceptions end up on 6? I cannot see anything in the >> RSB >> commit history mentioning it. > > No, I wait for your feedback. Here is a back port from GCC 13 to GCC 12: > > https://lists.rtems.org/pipermail/devel/2022-July/072555.html Thanks. I had mistakenly though you had and I apologise for not following up. I have put it on my list. >> Are these TLS allocations in newlib based on a single use of a newlib call >> that >> brings in the reent stuff? How does that work? > > No, each TLS object is defined in the translation unit which uses the object. > The goal is to get only those objects linked in which are needed. Currently, > the > Newlib thread delete hook pulls in some objects, however, this dependency will > go away once the TLS destructors are implemented. If I have task A and it opens a file and writes something to a file system will it pull in the TLS support for files? Given the TLS support is static does this mean all threads in the A app allocate the newlib file TLS variables even if they never use newlib? My understanding of the existing reent support is tasks that do not use newlib it never allocate a reent struct? >> Does this change effect libdl users? TLS has not been implemented in libdl >> and >> the current reent model still works for those users dependent on libdl > > It could affect libdl users. Can you load parts of libc.a with libdl? The > libdl > users could add TLS support or disable the Newlib configuration option. To > disable the options, we probably need an RSB --without-newlib-tls support or > use > something like --with-newlib-tls=yes or --with-newlib-tls=no. > > On powerpc/psim for example I get an error like this in dl06: > > ] load: /dl06.rap > ] dlopen failed: global symbol not found: _tls_rand48_add Oh that is interesting and nice. It means yes this change does require libdl TLS support and that is a more complex topic than this one. In dl06 rtems-td is linking into the RAP image the dependent pieces of newlib's libm which ends up pulling in rand48 and the TLS variable it must contain. This is a hard one to decide on because dl08 is a test for archive linking and a user could make libc.a, libm.a and libgcc.a available to link from at runtime and expose the problem. Forcing all relevant pieces into the base is a design constraint I have deliberately wanted to avoid because it is a workround used else where. I think we should discuss the part of this thread on TLS resources before we come back to this part. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel