On 02/06/2020 23.15, Phil Blundell wrote: > On Tue, Jun 02, 2020 at 09:17:44PM +0100, Richard Purdie wrote: >> I understand the concern, I am a little torn on this as adding in too >> many different controls and options complicates the test matrix and >> makes things harder for users. >> >> You're effectively suggesting a new DISTRO_FEATURE to control this? or >> maybe better, perhaps a glibc PACKAGECONFIG? > > Yes, right. I don't think it need be a DISTRO_FEATURE because nothing > outside glibc needs to care. > > Here are the scenarios that I think matter, ordered from simplest to > most complex: > > 1. Immutable filesystem, every library installed in the place where > ld.so would first look for it anyway (i.e. everything in {/usr}/lib). > In this case, we don't want ldconfig (because it can never do anything > useful), we don't want ld.so.cache and we don't want ld.so.conf > because they would cause ld.so to do extra file loads and computation > but end up with the same result that it would anyway. > > I think right now oe-core supports #1 and #3. The proposed patch > seems to be aimed at #2, which is a completely valid usecase, but > my concern is that we don't want to pessimize #1 in the process.
With or without my patch, there's an ldconfig invocation at image build time, and lacking an /etc/ld.so.conf in the -r filesystem, ldconfig just looks at the default locations (/lib and /usr/lib, perhaps a few more depending on $arch). But you still get an ld.so.cache generated listing the libs in /lib and /usr/lib. So I don't understand this performance concern at all - at the very most, the presence of the config file causes a microscopic performance hit at image build time when ldconfig goes looking for the /etc/ld.so.conf.d/* files and (usually) find none. Also, IME, the cache file usually speed things up since ld.so avoids a filesystem access to figure out that /{usr,}/lib/<arch-specific-path>/libfoo.so doesn't exist (of course there's an upfront cost of mmapping and parsing the ld.so.cache, so for programs with very few dynlib dependencies, it might be faster to not have the cache). See below. If you really don't want the ld.so.cache, ldconfig has the -N option. But adding some knob to put that in is completely orthogonal to this patch. Rasmus Here's the first few lines of "strace -o /tmp/cache.txt factor 12345": execve("/usr/bin/factor", ["factor", "12345"], 0xbff6cf3c /* 14 vars */) = 0 brk(NULL) = 0x10173000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=6527, ...}) = 0 mmap2(NULL, 6527, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ef2000 close(3) = 0 openat(AT_FDCWD, "/lib/librt.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\36\300\0\0\0004"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=38596, ...}) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7ef0000 mmap2(0xffdf000, 65768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffdf000 mprotect(0xffe7000, 28672, PROT_NONE) = 0 mmap2(0xffee000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0xffee000 close(3) = 0 openat(AT_FDCWD, "/lib/libcap.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\21P\0\0\0004"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=22060, ...}) = 0 mmap2(0xffbe000, 65820, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffbe000 mprotect(0xffc3000, 40960, PROT_NONE) = 0 mmap2(0xffcd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0xffcd000 close(3) = 0 openat(AT_FDCWD, "/usr/lib/libgmp.so.10", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\226 \0\0\0004"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=551740, ...}) = 0 mmap2(0xff1d000, 591268, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xff1d000 mprotect(0xffa3000, 36864, PROT_NONE) = 0 mmap2(0xffac000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x85000) = 0xffac000 close(3) = 0 Compare that to what happens when I move the ld.so.cache out of the way: execve("/usr/bin/factor", ["factor", "12345"], 0xbfc7c3bc /* 14 vars */) = 0 brk(NULL) = 0x10173000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/tls/ppc603/librt.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/lib/tls/ppc603", 0xbf98df78) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/tls/librt.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/lib/tls", 0xbf98df78) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/ppc603/librt.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/lib/ppc603", 0xbf98df78) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/lib/librt.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\36\300\0\0\0004"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=38596, ...}) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7cd0000 mmap2(0xffdf000, 65768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffdf000 mprotect(0xffe7000, 28672, PROT_NONE) = 0 mmap2(0xffee000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x8000) = 0xffee000 close(3) = 0 openat(AT_FDCWD, "/lib/libcap.so.2", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\21P\0\0\0004"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=22060, ...}) = 0 mmap2(0xffbe000, 65820, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xffbe000 mprotect(0xffc3000, 40960, PROT_NONE) = 0 mmap2(0xffcd000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0xffcd000 close(3) = 0 openat(AT_FDCWD, "/lib/libgmp.so.10", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/tls/ppc603/libgmp.so.10", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/lib/tls/ppc603", 0xbf98df38) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/tls/libgmp.so.10", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/lib/tls", 0xbf98df38) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/ppc603/libgmp.so.10", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) stat64("/usr/lib/ppc603", 0xbf98df38) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/lib/libgmp.so.10", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\24\0\0\0\1\0\0\226 \0\0\0004"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=551740, ...}) = 0 mmap2(0xff1d000, 591268, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xff1d000 mprotect(0xffa3000, 36864, PROT_NONE) = 0 mmap2(0xffac000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x85000) = 0xffac000 close(3) = 0 So ld.so is smart enough to say, "hm, ok, there was no /lib/tls/libfoo.so, is there even a /lib/tls or do I not need bother looking there for the next few libraries". But (1) we still end up doing 10 more system calls compared to the case of having a cache and (2) this is the good case, if some library (maybe totally unrelated to this binary) did exist in one of those arch-specific dirs, the directory would of course exist, and ld.so would keep searching that dir before looking in /lib or /usr/lib.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#139148): https://lists.openembedded.org/g/openembedded-core/message/139148 Mute This Topic: https://lists.openembedded.org/mt/74625854/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-