This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
[asuffield@debian.org: Bug#161788: libc6 always loads i686 libraries from cache when available, ignoring the host arch]
- From: Daniel Jacobowitz <dan at debian dot org>
- To: libc-alpha at sources dot redhat dot com, Andrew Suffield <asuffield at debian dot org>,debian-glibc at sources dot redhat dot com
- Date: Sat, 21 Sep 2002 12:14:47 -0400
- Subject: [asuffield@debian.org: Bug#161788: libc6 always loads i686 libraries from cache when available, ignoring the host arch]
This bug still appears to be present in current CVS, as of a day or so
ago, so it's probably in 2.2.94. Andrew's interpretation looks right
to me...
----- Forwarded message from Andrew Suffield <asuffield@debian.org> -----
Date: Sat, 21 Sep 2002 16:59:58 +0100
From: Andrew Suffield <asuffield@debian.org>
Subject: Bug#161788: libc6 always loads i686 libraries from cache when available, ignoring the host arch
To: submit@bugs.debian.org
Reply-To: Andrew Suffield <asuffield@debian.org>,
161788@bugs.debian.org
Package: libc6
Severity: grave
Here's a cute one. On any i386 platform, when there is an
i686-specific library in ld.so.cache, libc6 will prefer it over all
other libraries in the cache, even if the local system is really
i[345]86.
The problem is specific to cached libraries, and should not occur on
other architectures.
This causes the latest version of libssl to crash with SIGILL on
i[345]86 systems. It can be directly diagnosed by setting
LD_DEBUG=libs and looking at the first few lines generated when the
offending binary is run, and observing that /usr/lib/i686/libcrypto*
is being loaded from the cache.
When _dl_load_cache_lookup searches the cache, it checks the platform
using this expression (sysdeps/generic/dl-cache.c around line 233):
if (_DL_PLATFORMS_COUNT && platform != -1 \
&& (lib->hwcap & _DL_HWCAP_PLATFORM) != 0 \
&& (lib->hwcap & _DL_HWCAP_PLATFORM) != platform) \
continue; \
_DL_HWCAP_PLATFORM is a mask that is supposed to match all the bits in
an hwcap field that can represent the current platform. Unfortunately,
it's got the wrong value. Here's the fix (haven't tested this yet,
glibc takes too long to build, but some bit-twiddling in gdb indicates
it should work):
--- sysdeps/unix/sysv/linux/i386/dl-procinfo.h~ 2001-07-22 21:24:56.000000000 +0100
+++ sysdeps/unix/sysv/linux/i386/dl-procinfo.h 2002-09-21 16:38:34.000000000 +0100
@@ -34,7 +34,7 @@
/* Start at 48 to reserve some space. */
#define _DL_FIRST_PLATFORM 48
/* Mask to filter out platforms. */
-#define _DL_HWCAP_PLATFORM (7ULL << _DL_FIRST_PLATFORM)
+#define _DL_HWCAP_PLATFORM (((1ULL << _DL_PLATFORMS_COUNT) - 1) << _DL_FIRST_PLATFORM)
static inline int
The value '7' clearly dates from when there were only three platforms,
and never got updated when i686 was added. The practical upshot is
that the bit for 'i686' is never considered by anything to be a
platform, so the entry in ld.so.cache is assumed to be for any
platform.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ | Dept. of Computing,
`. `' | Imperial College,
`- -><- | London, UK
----- End forwarded message -----
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer