[PATCH 05/13] string: Remove old TLS usage on strsignal

[Adhemerval Zanella]

On 28/05/2020 08:38, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
> 
>> The per-thread state is refactored two use two strategies:
>>
>>   1. The default one uses a TLS structure, which will be place in the
>>      static TLS space (using __thread keyword).
>>
>>   2. Linux allocates on struct pthread and access it through THREAD_*
>>      macros.
> 
> Hurd can use the same infrastructure nowadays, since commit
> b65a82e4e757c1e6cb7073916a29 ("hurd: Add THREAD_GET/SETMEM/_NC").

Different than Linux, Hurd's THREAD_SELF returns a tcbhead_t. I don't
have a strong preference, I use the generic Hurd mainly to avoid
touching Hurd specific files.

> 
> I'm not sure if struct tls_internal_t is necessary at this point.

I added the tls_internal_t as a focal point for extra field when
required. I don't have a strong preference, but I think it is
slight better than update multiple files (for instance the generic
and Linux one).

> 
>> diff --git a/malloc/thread-freeres.c b/malloc/thread-freeres.c
>> index c71ca4fc33..d42eea770b 100644
>> --- a/malloc/thread-freeres.c
>> +++ b/malloc/thread-freeres.c
>> @@ -32,6 +32,7 @@ __libc_thread_freeres (void)
>>    call_function_static_weak (__rpc_thread_destroy);
>>    call_function_static_weak (__res_thread_freeres);
>>    call_function_static_weak (__strerror_thread_freeres);
>> +  call_function_static_weak (__strsignal_thread_freeres);
> 
> I think you can call free directly.  I doubt it increases binary
> size—the data is in the thread descriptor, so nothing needs to be pulled
> into the link for this.

Don't we need it to deallocate the memory in the case of a libc
loaded in a different namespace?