[RSB 1/3] 6/7: Update Newlib

[Chris Johns]

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 at 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