glibc 2.19 status?

[Joseph S. Myers]

On Tue, 4 Feb 2014, Carlos O'Donell wrote:

> It seems as though Joseph and Roland object for different
> reasons. Joseph objecting because the solution still has the
> potential to fail at runtime in odd ways, and Roland because
> we are not sufficiently conservative. I don't know that we will
> be able to resolve their requests any time soon if ever.

No, I object because we shouldn't have put a large, risky 
non-architecture-specific change like this in after the freeze started, 
and the slightest sign of a problem with or objection to such a late 
change should be enough reason to revert it.  And the fact that the merits 
are still being discussed is a sign of lack of consensus, meaning the 
change wasn't ready to go in even without the freeze.

> (4) TLS access should never fail at runtime.
> 
> Joseph and Rich have both argued that TLS access should never fail
> at runtime. While that is a good goal it seems contrary to the 
> scalability goals that some users have regarding DSO loading, TLS, 
> and threads. As Joseph suggests it might be that the lazy behaviour

I am doubtful that lazy TLS provides any significant benefit here (or ever 
did).

> is invoked via a new dlopen flag. This still means we need a fix
> for the dlopen with the alternate flag and that still breaks ASAN.

My suggestion is simply to declare that TLS accesses for modules opened 
with the new flag are not AS-safe.

-- 
Joseph S. Myers
joseph@codesourcery.com