This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.19 status?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Allan McRae <allan at archlinux dot org>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Andrew Hunter <ahh at google dot com>, Roland McGrath <roland at hack dot frob dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 5 Feb 2014 14:55:46 +0000
- Subject: Re: glibc 2.19 status?
- Authentication-results: sourceware.org; auth=none
- References: <52E649BF dot 5020400 at archlinux dot org> <20140128205657 dot 16DBA74438 at topped-with-meat dot com> <52E9DEB7 dot 4000709 at redhat dot com> <52E9E84F dot 50907 at redhat dot com> <52EA682D dot 90900 at archlinux dot org> <52F03BEC dot 1020202 at archlinux dot org> <52F062C5 dot 6050705 at redhat dot com> <52F06713 dot 1040005 at archlinux dot org> <Pine dot LNX dot 4 dot 64 dot 1402050004130 dot 25166 at digraph dot polyomino dot org dot uk> <20140205001815 dot B59AB7444A at topped-with-meat dot com> <52F1B8E4 dot 8000609 at redhat dot com>
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