[PR19826] fix non-LE TLS in static programs
Florian Weimer
fweimer@redhat.com
Tue Dec 6 07:45:00 GMT 2016
On 12/06/2016 08:15 AM, Alexandre Oliva wrote:
> On Dec 2, 2016, Florian Weimer <fweimer@redhat.com> wrote:
>
>> I don't know if it is really needed,
>
> No, it's wrong, it had been fixed before.
>
>> I and I have no idea how to make initialization at this point safe
>
> It's safe to leave that initialization out. The checks for whether the
> DTV needs updating are "safe enough". As in, a thread will take care of
> its own DTV, so there won't be races with other threads.
But it's also called for the thread which invoked dlopen. Does
_dl_update_slotinfo (called from _dl_try_allocate_static_tls) take care
of that?
> However, it's
> not AS-Safe: if DTV resizing is interrupted by a signal whose handler
> triggers another DTV resizing, we'll have trouble, as we always had.
Can we block signals during DTV resizing?
> That's one of the reasons why GD TLS is not AS-Safe. Another is that
> dynamic TLS blocks may have to be allocated, and we use(d?) AS-Unsafe
> means for the allocation. There may be other reasons that don't come to
> mind right now.
We still have malloc calls in there. It's not just a problem for
asynchronous signals, we do not have a way to report allocation
failures, either.
Thanks,
Florian
More information about the Libc-alpha
mailing list