This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.  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.
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.

> I filed <https://sourceware.org/bugzilla/show_bug.cgi?id=20915> so
> that we keep track of this regression and fix it before the release.

Thanks.  Carlos, please add a '[BZ #20915]' to the ChangeLog of the
revised version of the second patch when you get to it.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]