Should a newer ld.so work with older libc.so (and the other way around)?

Should a newer ld.so work with older libc.so (and the other way around)?

[Andrew Pinski]

Right now there seems like there has been a recent change which broke
both ways.  This happens on AARCH64-linux-gnu.

For the newer ld.so I get:
apinski@apinski-t99:~/src/glibc/objdir2$ ./elf/ld.so `which true`
/bin/true: error while loading shared libraries:
__kernel_gettimeofday: invalid mode for dlopen(): Invalid argument

I am suspecting this caused that:
2015-05-26  Adhemerval Zanella  <adhemerval.zanella@linaro.org>

        * sysdeps/unix/sysv/linux/aarch64/gettimeofday.c (HAVE_VSYSCALL):
        Define and include sysdep-vdso.h.
        * sysdeps/unix/sysv/linux/s390/gettimeofday.c (HAVE_VSYSCALL):
        Likewise.
        * sysdeps/unix/sysv/linux/tile/gettimeofday.c (HAVE_VSYSCALL):
        Likewise.
....


With the newer libc.so (without the newer ld.so):

apinski@apinski-t99:~/src/glibc/objdir2$ LD_LIBRARY_PATH=. ls
ls: relocation error: /lib/aarch64-linux-gnu/libpthread.so.0: symbol
__libc_dl_error_tsd, version GLIBC_PRIVATE not defined in file
libc.so.6 with link time reference

And this one was caused by:
2016-11-30  Florian Weimer  <fweimer@redhat.com>

        [BZ #16628]


Note I also get some crashes weird due to ld.so and libc.so not being
compatible too.

If this is supposed to work, it means the 2.24 and 2.25 releases are
ABI incompatible with 2.23 release.

Thanks,
Andrew

Thanks,
Andrew

Re: Should a newer ld.so work with older libc.so (and the other way around)?

[Markus Trippelsdorf]

On 2017.02.13 at 23:41 -0800, Andrew Pinski wrote:
> Right now there seems like there has been a recent change which broke
> both ways.  This happens on AARCH64-linux-gnu.
> 
> For the newer ld.so I get:
> apinski@apinski-t99:~/src/glibc/objdir2$ ./elf/ld.so `which true`
> /bin/true: error while loading shared libraries:
> __kernel_gettimeofday: invalid mode for dlopen(): Invalid argument
> 
> I am suspecting this caused that:
> 2015-05-26  Adhemerval Zanella  <adhemerval.zanella@linaro.org>
> 
>         * sysdeps/unix/sysv/linux/aarch64/gettimeofday.c (HAVE_VSYSCALL):
>         Define and include sysdep-vdso.h.
>         * sysdeps/unix/sysv/linux/s390/gettimeofday.c (HAVE_VSYSCALL):
>         Likewise.
>         * sysdeps/unix/sysv/linux/tile/gettimeofday.c (HAVE_VSYSCALL):
>         Likewise.
> ....
> 
> 
> With the newer libc.so (without the newer ld.so):
> 
> apinski@apinski-t99:~/src/glibc/objdir2$ LD_LIBRARY_PATH=. ls
> ls: relocation error: /lib/aarch64-linux-gnu/libpthread.so.0: symbol
> __libc_dl_error_tsd, version GLIBC_PRIVATE not defined in file
> libc.so.6 with link time reference
> 
> And this one was caused by:
> 2016-11-30  Florian Weimer  <fweimer@redhat.com>
> 
>         [BZ #16628]
> 
> 
> Note I also get some crashes weird due to ld.so and libc.so not being
> compatible too.
> 
> If this is supposed to work, it means the 2.24 and 2.25 releases are
> ABI incompatible with 2.23 release.

No, this supposed not to work at all. See: 
https://sourceware.org/glibc/wiki/FAQ#How_do_I_install_all_of_the_GNU_C_Library_project_libraries_that_I_just_built.3F

-- 
Markus

Re: Should a newer ld.so work with older libc.so (and the other way around)?

[Andrew Pinski]

On Tue, Feb 14, 2017 at 1:02 PM, Ryan Arnold <ryan.arnold@linaro.org> wrote:
>
>
> On Tue, Feb 14, 2017 at 1:41 AM, Andrew Pinski <pinskia@gmail.com> wrote:
>>
>> Right now there seems like there has been a recent change which broke
>> both ways.  This happens on AARCH64-linux-gnu.
>>
>> For the newer ld.so I get:
>> apinski@apinski-t99:~/src/glibc/objdir2$ ./elf/ld.so `which true`
>> /bin/true: error while loading shared libraries:
>> __kernel_gettimeofday: invalid mode for dlopen(): Invalid argument
>>
>> I am suspecting this caused that:
>> 2015-05-26  Adhemerval Zanella  <adhemerval.zanella@linaro.org>
>>
>>         * sysdeps/unix/sysv/linux/aarch64/gettimeofday.c (HAVE_VSYSCALL):
>>         Define and include sysdep-vdso.h.
>>         * sysdeps/unix/sysv/linux/s390/gettimeofday.c (HAVE_VSYSCALL):
>>         Likewise.
>>         * sysdeps/unix/sysv/linux/tile/gettimeofday.c (HAVE_VSYSCALL):
>>         Likewise.
>> ....
>>
>>
>> With the newer libc.so (without the newer ld.so):
>>
>> apinski@apinski-t99:~/src/glibc/objdir2$ LD_LIBRARY_PATH=. ls
>> ls: relocation error: /lib/aarch64-linux-gnu/libpthread.so.0: symbol
>> __libc_dl_error_tsd, version GLIBC_PRIVATE not defined in file
>> libc.so.6 with link time reference
>
>
> Hi Andrew,
>
> That error you see "__kernel_gettimeofday: invalid mode for dlopen():
> Invalid argument" is interesting pointer to what's going on.
>
> If you attach a debugger to the application where this happened and traced
> through the resolver you'd likely see that __kernel_gettimeofday is in-fact
> not the function that was intended to be invoked.
>
> This is all from memory...
>
> What happens is that ld.so and libc.so are built at the same time with the
> same view of the rtld_global_ro struct.
>
> Relative offsets to function pointers held in the structure are precomputed
> and referenced in both place as offset from the location of the structure in
> memory. If the size of that structure changes then the precomputed offsets
> into that table might change as well.  Hence if you change the size of the
> structure and try to use an old dynamic linker to invoke the new libc you'll
> get incorrect function pointers invoked due to incorrect offsets.  I believe
> the __kernel_gettimeofday is one of the first function pointers in the list,
> so it's often the first thing that shows up as failing in such cases.
>
> At least this is my memory of this scenario.


Thanks all for this reply.   Now I better understand the situation and
know it is hard to provide a newer glibc to some customers and will go
and handle what I was going to do a different way.

Thanks,
Andrew

>
> --
> Ryan S. Arnold | Director - Linaro Core Technology and Tools
> ryan.arnold@linaro.org | ryanarn on #linaro-tcwg @ freenode.irc.net
> T: +1-612-424-1861