Bug#738575: pthread: segfault in libpthread on Intel Galileo board
Package: libc6-i386
Version: 2.19-17
Hi all,
I thought that the glibc mailing list was a better home for this
discussion than Debian-devel, if I have err'ed please redirect me.
I am following up on Bug#738575:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575
Put simply the Intel X1000 (Pentium ISA) has a bug on the LOCK prefix,
that cannot be fixed with an updated microcode and cannot be worked
around by trapping in the Kernel. The only workable solution is to
simply not use the LOCK prefix on the Intel X1000.
The most obvious way to fix this bug is strip the LOCK prefix from glibc
on X1000. I have prototyped the following on wheezy.
1. Kernel being aware it is running on a platform with the bug and
indicating this in proc cpuinfo.
2. The Kernel hinting to the runtime linker that the Microprocessor has
the "nolock" bug through a hwcap, in much the same way as the Xen
"nosegneg" hinting works.
3. The runtime linker then loads a specific version of libc with the
LOCK prefix stripped, using the omit-lock-prefix assembly option.
(appending -Wa,momit-lock-prefix=yes to extra_cflags).
The trouble with this fix is that we assume that i386 Libc is the lowest
common denominator - it should always work, but on X1000 it is broken by
virtue of containing the LOCK prefix.
This is where the X1000 differs to Xen, on Xen you can use the default
i386 Libc at a performance penalty. Xen just works faster if you have
the "nosegneg" libc version installed.
If there is always a "nolock" version of the Glibc installed there is no
issue. The alternative strategy is to forget about a version of libc
specifically
to tackle the X1000 bug and strip the default i386 libc version of the
lock
prefix - I considered this problematic.
In theory this might work as all 32bit non-pae Kernels are non-SMP,
however my concern is this would break the i386 Libc usefulness as
failover
on 32bit 686-pae.
Hoping the maintainer could comment on this -
1. Are we safe stripping i386 version of libc of the LOCK prefix, or am
I correct this would break 686-pae in failover situations (i.e.
situations where the cmov optimized version is missing for some reason).
or
2. Should we do as I describe above, creating a version of glibc
specifically with the LOCK prefix removed.
Trying to balance complexity (a new glibc target) versus not breaking
any existing platforms.
Ray Kinsella
Reply to: