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

[Andrew Pinski <pinskia at gmail dot com>]

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