why ld.so in arm-linux-gnueabihf- toolchains search so many paths ?

Discussion:

Barry Song

2015-12-01 07:24:07 UTC

hi guys,
sorry maybe my question is stupid as i am not a toolchain guy.

i have no idea why ld.so search so many paths. for example, put
"-rpath" with /home/cnb1szh/test in a simple test program. then during
dynamic linking at runtime, we get the below linking debug
information:

30693: find library=libmytest.so [0]; searching

30693: search path=/home/cnb1szh/test/tls/v7l/neon/vfp:/home/cnb1szh/test/tls/v7l/neon:/home/cnb1szh/test/tls/v7l/vfp:/home/cnb1szh/test/tls/v7l:/home/cnb1szh/test/tls/neon/vfp:/home/cnb1szh/test/tls/neon:/home/cnb1szh/test/tls/vfp:/home/cnb1szh/test/tls:/home/cnb1szh/test/v7l/neon/vfp:/home/cnb1szh/test/v7l/neon:/home/cnb1szh/test/v7l/vfp:/home/cnb1szh/test/v7l:/home/cnb1szh/test/neon/vfp:/home/cnb1szh/test/neon:/home/cnb1szh/test/vfp:/home/cnb1szh/test
(RPATH from file ./hello)

30693: trying file=/home/cnb1szh/test/tls/v7l/neon/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/v7l/neon/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/v7l/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/v7l/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/neon/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/neon/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/tls/libmytest.so

30693: trying file=/home/cnb1szh/test/v7l/neon/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/v7l/neon/libmytest.so

30693: trying file=/home/cnb1szh/test/v7l/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/v7l/libmytest.so

30693: trying file=/home/cnb1szh/test/neon/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/neon/libmytest.so

30693: trying file=/home/cnb1szh/test/vfp/libmytest.so

30693: trying file=/home/cnb1szh/test/libmytest.so

but we don't have /home/cnb1szh/test/tls/, /home/cnb1szh/test/v7l/,
/home/cnb1szh/test/vfp/, /home/cnb1szh/test/neon/, why does the ld.so
search so many paths?

-barry

Ryan Arnold

2015-12-01 15:26:27 UTC

Permalink

Post by Barry Song
hi guys,
sorry maybe my question is stupid as i am not a toolchain guy.
i have no idea why ld.so search so many paths. for example, put
"-rpath" with /home/cnb1szh/test in a simple test program. then during
dynamic linking at runtime, we get the below linking debug
30693: find library=libmytest.so [0]; searching
30693: search
path=/home/cnb1szh/test/tls/v7l/neon/vfp:/home/cnb1szh/test/tls/v7l/neon:/home/cnb1szh/test/tls/v7l/vfp:/home/cnb1szh/test/tls/v7l:/home/cnb1szh/test/tls/neon/vfp:/home/cnb1szh/test/tls/neon:/home/cnb1szh/test/tls/vfp:/home/cnb1szh/test/tls:/home/cnb1szh/test/v7l/neon/vfp:/home/cnb1szh/test/v7l/neon:/home/cnb1szh/test/v7l/vfp:/home/cnb1szh/test/v7l:/home/cnb1szh/test/neon/vfp:/home/cnb1szh/test/neon:/home/cnb1szh/test/vfp:/home/cnb1szh/test
(RPATH from file ./hello)
30693: trying file=/home/cnb1szh/test/tls/v7l/neon/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/v7l/neon/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/v7l/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/v7l/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/neon/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/neon/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/tls/libmytest.so
30693: trying file=/home/cnb1szh/test/v7l/neon/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/v7l/neon/libmytest.so
30693: trying file=/home/cnb1szh/test/v7l/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/v7l/libmytest.so
30693: trying file=/home/cnb1szh/test/neon/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/neon/libmytest.so
30693: trying file=/home/cnb1szh/test/vfp/libmytest.so
30693: trying file=/home/cnb1szh/test/libmytest.so
but we don't have /home/cnb1szh/test/tls/, /home/cnb1szh/test/v7l/,
/home/cnb1szh/test/vfp/, /home/cnb1szh/test/neon/, why does the ld.so
search so many paths?
-barry
_______________________________________________
linaro-toolchain mailing list
https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Hi Barry, this is a known, intentional behavior of the dynamic-linker.

It defaults to searching for libraries in a tls directory (the glibc
developers intend to remove this since linux-threads are now gone and nptl
is the standard but no-one has stepped forward to do so), then directories
based on the cpu, then directories that are based on the hardware
capabilities for the platform (AT_HWCAP for 'arm') in various
combinations. This is why you see it searching the different variations of
directories.

This is not a bug.

What this does is allows the Linux distribution to provide optimized
versions of the libraries in each of those directories. The optimized
versions of the library have the most efficient code-gen for the capability
present. For instance, in your own library, if you wanted to have a neon
optimized version and a non-neon optimized version you'd put the neon one
in test/neon/ and the non-optimized version in test/ directly.

--
Ryan S. Arnold
Linaro Toolchain Working Group - Engineering Manager
www.linaro.org

Barry Song

2015-12-02 08:07:09 UTC

Permalink

Post by Ryan Arnold

Hi Barry, this is a known, intentional behavior of the dynamic-linker.
It defaults to searching for libraries in a tls directory (the glibc
developers intend to remove this since linux-threads are now gone and nptl
is the standard but no-one has stepped forward to do so), then directories
based on the cpu, then directories that are based on the hardware
capabilities for the platform (AT_HWCAP for 'arm') in various combinations.
This is why you see it searching the different variations of directories.
This is not a bug.
What this does is allows the Linux distribution to provide optimized
versions of the libraries in each of those directories. The optimized
versions of the library have the most efficient code-gen for the capability
present. For instance, in your own library, if you wanted to have a neon
optimized version and a non-neon optimized version you'd put the neon one in
test/neon/ and the non-optimized version in test/ directly.

Hi Ryan,
thanks a lot!
i am wondering whether ld.so will check the capbility of ARM to decide
which version should be used.
for example, suppose we have a platform like this:

1. there is no neon in ARM chips,
2. in the filesystem, there is a lib using neon and the other lib without neon

will ld.so use the 2nd lib automatically and ignore the 1st search
path with neon?

if there is no this capbility, it seems the feature is not making so
many senses?

Post by Ryan Arnold
--
Ryan S. Arnold
Linaro Toolchain Working Group - Engineering Manager
www.linaro.org

-barry

Jim Wilson

2015-12-03 18:18:11 UTC

Permalink

Post by Barry Song
i am wondering whether ld.so will check the capbility of ARM to decide
which version should be used.

I believe the way this works is that the kernel uses the auxiliary
vector to pass an AT_HWCAP entry to programs. AT_HWCAP has hardware
capability info. ld.so then checks the AT_HWCAP info, and only
searches in matching dirs. See for instance
https://wiki.linaro.org/Resources/HowTo/DeterminingCPUFeatures

Jim