[PATCH 05/13] string: Remove old TLS usage on strsignal
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