Pending fixes for all-ABIs builds

Pending fixes for all-ABIs builds

[Joseph Myers]

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

Re: Pending fixes for all-ABIs builds

[Florian Weimer]

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

Re: Pending fixes for all-ABIs builds

[Joseph Myers]

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

Re: Pending fixes for all-ABIs builds

[Florian Weimer]

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

Re: Pending fixes for all-ABIs builds

[Joseph Myers]

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

Re: Pending fixes for all-ABIs builds

[Andreas Schwab]

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

Re: Pending fixes for all-ABIs builds

[Florian Weimer]

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

Re: Pending fixes for all-ABIs builds

[Andreas Schwab]

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

Re: Pending fixes for all-ABIs builds

[Florian Weimer]

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

Re: Pending fixes for all-ABIs builds

[Andreas Schwab]

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

Re: Pending fixes for all-ABIs builds

[Florian Weimer]

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

Re: Pending fixes for all-ABIs builds

[Andreas Schwab]

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

Re: Pending fixes for all-ABIs builds

[Florian Weimer]

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

Re: Pending fixes for all-ABIs builds

[Roland McGrath]

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

Re: Pending fixes for all-ABIs builds

[Florian Weimer]

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

Re: Pending fixes for all-ABIs builds

[Andreas Schwab]

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

_rtld_global_ro and static dlopen (was: Re: Pending fixes for all-ABIs builds)

[Florian Weimer]

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