[PATCH 05/13] string: Remove old TLS usage on strsignal
Mon Jun 1 18:08:50 GMT 2020
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_*
> 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?
More information about the Libc-alpha