This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: 2.25 freeze status
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, <nd at arm dot com>, Siddhesh Poyarekar <siddhesh at gotplt dot org>, "libc-alpha\@sourceware.org" <libc-alpha at sourceware dot org>
- Date: Wed, 01 Feb 2017 12:47:16 -0200
- Subject: Re: 2.25 freeze status
- Authentication-results: sourceware.org; auth=none
- References: <c4cfc6e1-ff9f-c8b3-4a56-38f8d484aa05@gotplt.org> <627e42c4-4bf4-e297-2f06-a32ea9698192@redhat.com> <588B74E3.808@arm.com> <f2ee2fed-3430-d9a9-3cee-64a8626e2905@redhat.com> <or8tpqe50g.fsf@lxoliva.fsfla.org> <5891BA4A.4010507@arm.com>
On Feb 1, 2017, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> On 01/02/17 07:37, Alexandre Oliva wrote:
>> On Jan 27, 2017, Florian Weimer <fweimer@redhat.com> wrote:
>>
>>>> writing to the dtv of other threads is neither
>>>> necessary nor correct.
>>
>>> Let's do it then. Is this patch okay?
>>
>> I see you're taken out the reversal of
>>
>> * elf/dl-reloc.c (_dl_nothread_init_static_tls)
>>
>> from the patch I proposed back on Sept 24 for BZ #19826.
>>
>> I don't think it is right to drop that part.
>>
>> That's the nptl-less TLS initializer analogous to
>>
>> * nptl/allocatestack.c (init_one_static_tls)
>>
>> in programs that link with libpthread.
> but it does not touch the dtv of other threads.
> so it does not seem harmful only inconsistent.
No, it could be harmful: if the DTV needed resizing but it didn't
perform resizing, the assert in _dl_nothread_init_static_tls would fail,
causing the program to abort when it didn't have to. Reverting the
change that brought the assert back would avoid that.
> _dl_update_slotinfo_list is called
guarded by #ifdef SHARED. Do you see it called in some other path
within the to-be-statically-linked dl_open_worker? If not, this assert
could fail not just when users called dlopen in statically-linked
programs, but even when they called functions that rely on dlopening
internally (nss comes to mind).
IMHO, reverting both hunks is the conservative approach. We (well, I)
know they were introduced unnecessarily, just for (false) symmetry, and
we are sure at least one of them is harmful, and we have no hard
evidence that the other isn't. Considering that the same code path
takes us to each of them, my conservative assessment is to revert both,
unless deeper analysis points strongly in a different direction.
--
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