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

Adhemerval Zanella adhemerval.zanella@linaro.org
Mon Jun 1 18:39:16 GMT 2020

On 01/06/2020 15:13, Florian Weimer wrote:
> * Adhemerval Zanella via Libc-alpha:
>>>> 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? 
> Right, but using call_function_static_weak does not achieve that.
> This is a general problem with using TLS that needs separate
> deallocation.  We don't have per-namespace thread exit hooks, but we
> probably need them.

My confusion in fact, this is another issue indeed.  I added it just
to follow the small optimization dony by __strerror_thread_freeres
to avoid pulling the free code on static usage.

So do you think it would be better to just call free on
__libc_thread_freeres (it should be ok since code initializes it to
NULL)? If so, maybe also do the same for __strerror_thread_freeres?

More information about the Libc-alpha mailing list