* Pending fixes for all-ABIs builds
@ 2016-11-07 23:25 Joseph Myers
2016-11-08 8:28 ` Florian Weimer
0 siblings, 1 reply; 17+ messages in thread
From: Joseph Myers @ 2016-11-07 23:25 UTC (permalink / raw)
To: libc-alpha
I have the following patches pending review that fix various issues with
glibc build or compile-only test shown up with all-ABI builds with my
script (applying all 11 of these patches doesn't give completely clean
results with any GCC version, but it does improve things a lot).
https://sourceware.org/ml/libc-alpha/2016-11/msg00127.html (Make
check-installed-headers.sh ignore sys/sysctl.h for x32)
https://sourceware.org/ml/libc-alpha/2016-11/msg00182.html (Make Alpha
<sys/user.h> self-contained)
https://sourceware.org/ml/libc-alpha/2016-11/msg00183.html (Make SH
<sys/user.h> self-contained)
https://sourceware.org/ml/libc-alpha/2016-11/msg00189.html (Ignore
-Wmaybe-uninitialized in stdlib/bug-getcontext.c)
https://sourceware.org/ml/libc-alpha/2016-11/msg00213.html (Update nios2
localplt.data)
https://sourceware.org/ml/libc-alpha/2016-11/msg00214.html (Update alpha
localplt.data)
https://sourceware.org/ml/libc-alpha/2016-11/msg00216.html (Add
localplt.data for hppa)
https://sourceware.org/ml/libc-alpha/2016-11/msg00217.html (Add
localplt.data for sh)
https://sourceware.org/ml/libc-alpha/2016-11/msg00250.html (Fix rpcgen
buffer overrun (bug 20790))
https://sourceware.org/ml/libc-alpha/2016-11/msg00256.html (Make SH
ucontext always match current kernels)
https://sourceware.org/ml/libc-alpha/2016-11/msg00257.html (Fix SH4
register-dump.h for soft-float)
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-07 23:25 Pending fixes for all-ABIs builds Joseph Myers
@ 2016-11-08 8:28 ` Florian Weimer
2016-11-08 23:22 ` Joseph Myers
0 siblings, 1 reply; 17+ messages in thread
From: Florian Weimer @ 2016-11-08 8:28 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
On 11/08/2016 12:25 AM, Joseph Myers wrote:
> https://sourceware.org/ml/libc-alpha/2016-11/msg00213.html (Update nios2
> localplt.data)
>
> https://sourceware.org/ml/libc-alpha/2016-11/msg00214.html (Update alpha
> localplt.data)
>
> https://sourceware.org/ml/libc-alpha/2016-11/msg00216.html (Add
> localplt.data for hppa)
>
> https://sourceware.org/ml/libc-alpha/2016-11/msg00217.html (Add
> localplt.data for sh)
I looked at those and they seemed reasonable to me.
But there's one pre-existing issue I've been wondering about for a while
(along with the s390 maintainers): I don't understand why we have PLT
references to malloc & friends in ld.so. The malloc implementation
there is not compliant with the C requirements. Why is it exported, and
why do we use GOT indirection to call it?
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-08 8:28 ` Florian Weimer
@ 2016-11-08 23:22 ` Joseph Myers
2016-11-09 8:14 ` Florian Weimer
0 siblings, 1 reply; 17+ messages in thread
From: Joseph Myers @ 2016-11-08 23:22 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-alpha
On Tue, 8 Nov 2016, Florian Weimer wrote:
> But there's one pre-existing issue I've been wondering about for a while
> (along with the s390 maintainers): I don't understand why we have PLT
> references to malloc & friends in ld.so. The malloc implementation there is
> not compliant with the C requirements. Why is it exported, and why do we use
> GOT indirection to call it?
My understanding is that it's meant to be interposable by a user-provided
malloc implementation. See
<https://sourceware.org/ml/libc-alpha/2014-01/msg00719.html>, item 3.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-08 23:22 ` Joseph Myers
@ 2016-11-09 8:14 ` Florian Weimer
2016-11-09 8:18 ` Joseph Myers
2016-11-09 9:01 ` Andreas Schwab
0 siblings, 2 replies; 17+ messages in thread
From: Florian Weimer @ 2016-11-09 8:14 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha
On 11/09/2016 12:21 AM, Joseph Myers wrote:
> On Tue, 8 Nov 2016, Florian Weimer wrote:
>
>> But there's one pre-existing issue I've been wondering about for a while
>> (along with the s390 maintainers): I don't understand why we have PLT
>> references to malloc & friends in ld.so. The malloc implementation there is
>> not compliant with the C requirements. Why is it exported, and why do we use
>> GOT indirection to call it?
>
> My understanding is that it's meant to be interposable by a user-provided
> malloc implementation. See
> <https://sourceware.org/ml/libc-alpha/2014-01/msg00719.html>, item 3.
Does this mean the dynamic linker starts with it's GOT pointer as NULL,
initializes that to point it to the malloc in elf/dl-minimal.c, and
then, once libc.so.6 is relocated updates its GOT pointer to point to
the malloc in libc.so.6?
If that's true, maybe a comment explaining all this in elf/dl-minimal.c
would be helpful.
Thanks,
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-09 8:14 ` Florian Weimer
@ 2016-11-09 8:18 ` Joseph Myers
2016-11-09 9:01 ` Andreas Schwab
1 sibling, 0 replies; 17+ messages in thread
From: Joseph Myers @ 2016-11-09 8:18 UTC (permalink / raw)
To: Florian Weimer; +Cc: libc-alpha
On Wed, 9 Nov 2016, Florian Weimer wrote:
> On 11/09/2016 12:21 AM, Joseph Myers wrote:
> > On Tue, 8 Nov 2016, Florian Weimer wrote:
> >
> > > But there's one pre-existing issue I've been wondering about for a while
> > > (along with the s390 maintainers): I don't understand why we have PLT
> > > references to malloc & friends in ld.so. The malloc implementation there
> > > is
> > > not compliant with the C requirements. Why is it exported, and why do we
> > > use
> > > GOT indirection to call it?
> >
> > My understanding is that it's meant to be interposable by a user-provided
> > malloc implementation. See
> > <https://sourceware.org/ml/libc-alpha/2014-01/msg00719.html>, item 3.
>
> Does this mean the dynamic linker starts with it's GOT pointer as NULL,
> initializes that to point it to the malloc in elf/dl-minimal.c, and then, once
> libc.so.6 is relocated updates its GOT pointer to point to the malloc in
> libc.so.6?
I don't know the details (beyond what Roland explained, that early
allocations use ld.so's own malloc, but after interposition none of the
early allocations should ever be realloced or freed).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-09 8:14 ` Florian Weimer
2016-11-09 8:18 ` Joseph Myers
@ 2016-11-09 9:01 ` Andreas Schwab
2016-11-09 11:56 ` Florian Weimer
1 sibling, 1 reply; 17+ messages in thread
From: Andreas Schwab @ 2016-11-09 9:01 UTC (permalink / raw)
To: Florian Weimer; +Cc: Joseph Myers, libc-alpha
On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
> Does this mean the dynamic linker starts with it's GOT pointer as NULL,
> initializes that to point it to the malloc in elf/dl-minimal.c, and then,
> once libc.so.6 is relocated updates its GOT pointer to point to the malloc
> in libc.so.6?
ld.so re-relocates itself after all static dependencies have been loaded
and relocated.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-09 9:01 ` Andreas Schwab
@ 2016-11-09 11:56 ` Florian Weimer
2016-11-09 13:26 ` Andreas Schwab
0 siblings, 1 reply; 17+ messages in thread
From: Florian Weimer @ 2016-11-09 11:56 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Joseph Myers, libc-alpha
On 11/09/2016 10:01 AM, Andreas Schwab wrote:
> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>
>> Does this mean the dynamic linker starts with it's GOT pointer as NULL,
>> initializes that to point it to the malloc in elf/dl-minimal.c, and then,
>> once libc.so.6 is relocated updates its GOT pointer to point to the malloc
>> in libc.so.6?
>
> ld.so re-relocates itself after all static dependencies have been loaded
> and relocated.
And even at this point, the code is used for future dynamic linking
operations?
Thanks,
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-09 11:56 ` Florian Weimer
@ 2016-11-09 13:26 ` Andreas Schwab
2016-11-09 13:39 ` Florian Weimer
0 siblings, 1 reply; 17+ messages in thread
From: Andreas Schwab @ 2016-11-09 13:26 UTC (permalink / raw)
To: Florian Weimer; +Cc: Joseph Myers, libc-alpha
On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
> On 11/09/2016 10:01 AM, Andreas Schwab wrote:
>> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>>
>>> Does this mean the dynamic linker starts with it's GOT pointer as NULL,
>>> initializes that to point it to the malloc in elf/dl-minimal.c, and then,
>>> once libc.so.6 is relocated updates its GOT pointer to point to the malloc
>>> in libc.so.6?
>>
>> ld.so re-relocates itself after all static dependencies have been loaded
>> and relocated.
>
> And even at this point, the code is used for future dynamic linking
> operations?
"The code" refers to what?
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-09 13:26 ` Andreas Schwab
@ 2016-11-09 13:39 ` Florian Weimer
2016-11-09 13:47 ` Andreas Schwab
0 siblings, 1 reply; 17+ messages in thread
From: Florian Weimer @ 2016-11-09 13:39 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Joseph Myers, libc-alpha
On 11/09/2016 02:26 PM, Andreas Schwab wrote:
> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>
>> On 11/09/2016 10:01 AM, Andreas Schwab wrote:
>>> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>>> Does this mean the dynamic linker starts with it's GOT pointer as NULL,
>>>> initializes that to point it to the malloc in elf/dl-minimal.c, and then,
>>>> once libc.so.6 is relocated updates its GOT pointer to point to the malloc
>>>> in libc.so.6?
>>>
>>> ld.so re-relocates itself after all static dependencies have been loaded
>>> and relocated.
>>
>> And even at this point, the code is used for future dynamic linking
>> operations?
>
> "The code" refers to what?
The code in ld.so.
Thanks,
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-09 13:39 ` Florian Weimer
@ 2016-11-09 13:47 ` Andreas Schwab
2016-11-09 13:52 ` Florian Weimer
0 siblings, 1 reply; 17+ messages in thread
From: Andreas Schwab @ 2016-11-09 13:47 UTC (permalink / raw)
To: Florian Weimer; +Cc: Joseph Myers, libc-alpha
On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
> On 11/09/2016 02:26 PM, Andreas Schwab wrote:
>> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>>
>>> On 11/09/2016 10:01 AM, Andreas Schwab wrote:
>>>> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>>>>
>>>>> Does this mean the dynamic linker starts with it's GOT pointer as NULL,
>>>>> initializes that to point it to the malloc in elf/dl-minimal.c, and then,
>>>>> once libc.so.6 is relocated updates its GOT pointer to point to the malloc
>>>>> in libc.so.6?
>>>>
>>>> ld.so re-relocates itself after all static dependencies have been loaded
>>>> and relocated.
>>>
>>> And even at this point, the code is used for future dynamic linking
>>> operations?
>>
>> "The code" refers to what?
>
> The code in ld.so.
If that's the only one.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-09 13:47 ` Andreas Schwab
@ 2016-11-09 13:52 ` Florian Weimer
2016-11-09 14:50 ` Andreas Schwab
0 siblings, 1 reply; 17+ messages in thread
From: Florian Weimer @ 2016-11-09 13:52 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Joseph Myers, libc-alpha
On 11/09/2016 02:47 PM, Andreas Schwab wrote:
> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>
>> On 11/09/2016 02:26 PM, Andreas Schwab wrote:
>>> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>>> On 11/09/2016 10:01 AM, Andreas Schwab wrote:
>>>>> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>>>>>
>>>>>> Does this mean the dynamic linker starts with it's GOT pointer as NULL,
>>>>>> initializes that to point it to the malloc in elf/dl-minimal.c, and then,
>>>>>> once libc.so.6 is relocated updates its GOT pointer to point to the malloc
>>>>>> in libc.so.6?
>>>>>
>>>>> ld.so re-relocates itself after all static dependencies have been loaded
>>>>> and relocated.
>>>>
>>>> And even at this point, the code is used for future dynamic linking
>>>> operations?
>>>
>>> "The code" refers to what?
>>
>> The code in ld.so.
>
> If that's the only one.
Does this mean that if the application links against -ldl and invokes
dlopen, a different dynamic linker implementation is used? And the
ld.so implementation is only used for internal dynamic loading, e.g. for
NSS modules or gconv modules?
Thanks,
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-09 13:52 ` Florian Weimer
@ 2016-11-09 14:50 ` Andreas Schwab
2016-11-09 14:54 ` Florian Weimer
0 siblings, 1 reply; 17+ messages in thread
From: Andreas Schwab @ 2016-11-09 14:50 UTC (permalink / raw)
To: Florian Weimer; +Cc: Joseph Myers, libc-alpha
On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
> Does this mean that if the application links against -ldl and invokes
> dlopen, a different dynamic linker implementation is used?
??? There is only one dynamic linker, which is ld.so.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-09 14:50 ` Andreas Schwab
@ 2016-11-09 14:54 ` Florian Weimer
2016-11-09 22:00 ` Roland McGrath
0 siblings, 1 reply; 17+ messages in thread
From: Florian Weimer @ 2016-11-09 14:54 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Joseph Myers, libc-alpha
On 11/09/2016 03:50 PM, Andreas Schwab wrote:
> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>
>> Does this mean that if the application links against -ldl and invokes
>> dlopen, a different dynamic linker implementation is used?
>
> ??? There is only one dynamic linker, which is ld.so.
If this is really true, then I don't understand why we need the
indirection in _dl_open_hook.
Is there a way to get rid of those function pointers, or move
_dl_open_hook into a RELRO section?
Thanks,
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-09 14:54 ` Florian Weimer
@ 2016-11-09 22:00 ` Roland McGrath
2016-11-10 7:58 ` Florian Weimer
0 siblings, 1 reply; 17+ messages in thread
From: Roland McGrath @ 2016-11-09 22:00 UTC (permalink / raw)
To: Florian Weimer; +Cc: Andreas Schwab, Joseph Myers, libc-alpha
_dl_open_hook is to support the static libdl.a case.
If a static program dlopen's libc.so, and then libc.so
wants to dlopen e.g. a gconv module, it has to use the
static program's dlopen rather than ld.so's dlopen.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-09 22:00 ` Roland McGrath
@ 2016-11-10 7:58 ` Florian Weimer
2016-11-10 9:28 ` Andreas Schwab
0 siblings, 1 reply; 17+ messages in thread
From: Florian Weimer @ 2016-11-10 7:58 UTC (permalink / raw)
To: Roland McGrath; +Cc: Andreas Schwab, Joseph Myers, libc-alpha
On 11/09/2016 10:59 PM, Roland McGrath wrote:
> _dl_open_hook is to support the static libdl.a case.
> If a static program dlopen's libc.so, and then libc.so
> wants to dlopen e.g. a gconv module, it has to use the
> static program's dlopen rather than ld.so's dlopen.
Could we put this information into rtld_global_ro, instead of having a
separate variable? (Assuming that rtld_global_ro is indeed in read-only
memory after relocation.)
Thanks,
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Pending fixes for all-ABIs builds
2016-11-10 7:58 ` Florian Weimer
@ 2016-11-10 9:28 ` Andreas Schwab
2016-11-10 16:30 ` _rtld_global_ro and static dlopen (was: Re: Pending fixes for all-ABIs builds) Florian Weimer
0 siblings, 1 reply; 17+ messages in thread
From: Andreas Schwab @ 2016-11-10 9:28 UTC (permalink / raw)
To: Florian Weimer; +Cc: Roland McGrath, Joseph Myers, libc-alpha
On Nov 10 2016, Florian Weimer <fweimer@redhat.com> wrote:
> Could we put this information into rtld_global_ro, instead of having a
> separate variable? (Assuming that rtld_global_ro is indeed in read-only
> memory after relocation.)
It cannot be read-only, it is set only after ld.so is initialized.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply [flat|nested] 17+ messages in thread
* _rtld_global_ro and static dlopen (was: Re: Pending fixes for all-ABIs builds)
2016-11-10 9:28 ` Andreas Schwab
@ 2016-11-10 16:30 ` Florian Weimer
0 siblings, 0 replies; 17+ messages in thread
From: Florian Weimer @ 2016-11-10 16:30 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Roland McGrath, Joseph Myers, libc-alpha
On 11/10/2016 10:27 AM, Andreas Schwab wrote:
> On Nov 10 2016, Florian Weimer <fweimer@redhat.com> wrote:
>
>> Could we put this information into rtld_global_ro, instead of having a
>> separate variable? (Assuming that rtld_global_ro is indeed in read-only
>> memory after relocation.)
>
> It cannot be read-only, it is set only after ld.so is initialized.
I know that glibc has trouble with multiple definitions, but at least
one copy of _rtld_global_ro *is* read-only after relocation:
(gdb) print memset (&_rtld_global_ro, 1, 1)
Program received signal SIGSEGV, Segmentation fault.
__memset_sse2 () at ../sysdeps/x86_64/memset.S:110
110 movb %cl, (%rdi)
It also contains a function pointer to _dl_lookup_symbol_x, so I think
this data structure should work for locating ld.so functions.
Is the problem that we determine too late that we are running in a
nested configuration, and the inner ld.so has already been relocated?
Maybe gdb is lying to me, but it seems that we run the inner libc.so
with a _rtld_global_ro which has not been initialized beyond what is in
the default initializer. It seems that dl_main never runs.
But this means that most uses of GLRO inside libc.so.6 are broken. And
indeed, GLRO (dl_auxv) does not work as intended, and results in a NULL
pointer dereference in getauxval:
https://sourceware.org/bugzilla/show_bug.cgi?id=20802
How can we fix this? Could we synthesize a link map which interposes
the necessary definitions?
Thanks,
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2016-11-10 16:30 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-11-07 23:25 Pending fixes for all-ABIs builds Joseph Myers
2016-11-08 8:28 ` Florian Weimer
2016-11-08 23:22 ` Joseph Myers
2016-11-09 8:14 ` Florian Weimer
2016-11-09 8:18 ` Joseph Myers
2016-11-09 9:01 ` Andreas Schwab
2016-11-09 11:56 ` Florian Weimer
2016-11-09 13:26 ` Andreas Schwab
2016-11-09 13:39 ` Florian Weimer
2016-11-09 13:47 ` Andreas Schwab
2016-11-09 13:52 ` Florian Weimer
2016-11-09 14:50 ` Andreas Schwab
2016-11-09 14:54 ` Florian Weimer
2016-11-09 22:00 ` Roland McGrath
2016-11-10 7:58 ` Florian Weimer
2016-11-10 9:28 ` Andreas Schwab
2016-11-10 16:30 ` _rtld_global_ro and static dlopen (was: Re: Pending fixes for all-ABIs builds) Florian Weimer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).