Re: [PR19826] fix non-LE TLS in static programs

[Florian Weimer <fweimer at redhat dot com>]

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