glibc-2.19 (and possibly 2.18) includes --enable-lock-elision=yes by default which causes "cpuid" instructions to be generated in libpthread. Older CPUs that lack cpuid will fail with an Illegal instruction signal when this lib is loaded. There should be a USE variable to disable this option in glibc. The ebuild for glibc is a bit beyond me this point. Also, perhaps someone can recommend a better solution I run a Gentoo-based embedded system on Ampro CM420 modules (STPC Atlas CPU). These are pretty old devices that lack cpuid. glibc-2.17 did not have this issue, and I ran into trouble with glibc-2.19 this week. Reproducible: Always Check libpthread for cpuid instructions with: objdump -Sd /lib/libpthread.so.0 | grep cpuid
Created attachment 385838 [details] ebuild diff with lock-elision USE and --disable-lock-elision fixes. This is a diff from the glibc-2.20.ebuild to my ebuild named 'glibc-2.20-r99.ebuild'. It adds the lock-elision USE and a patch that allows lock elision to be disabled properly for cpus without cpuid. This is what I am using in my overlay to get around the glibc lock-elision issues.
Glibc lock elision seems to be causing problems on various platforms (ref https://sourceware.org/ml/libc-alpha/2014-09/msg00662.html) so I think adding this USE flag is important. As things stand right now, glibc-2.19 and glibc-2.20 will fail on 486 cpus. Should these be masked for x86? A secondary wrinkle here is that --disable-lock-elision is buggy and still allows cpuid instructions to execute. The link above includes a patch for glibc-2.20, and I've verified that it allows pthreads to work on my 486 when --disable-lock-elision is specified. I've included a diff that shows my ebuild changes and includes the above patch.
the trouble with elision in specific Intel cpus are resolved by updating your microcode. we aren't worrying about those edge cases. not working on i486 is worrisome though. i could just disable it for all i486 targets as it's not like it'd be a big win there in the first place. masking for all of x86 doesn't really make sense.
I was not aware you could disable it just for i486. That's much more sensible than my suggestion.
Updating the microcode on intel haswell to the most recent version on a running system or during boot can cause illegal opcodes in libpthread, when hardware lock elision(HLE) is used. This caused systemd to crash during boot on my laptop. If I could disable HLE in glibc, updating the microcode wouldn't be a problem. See also: https://lists.debian.org/debian-glibc/2014/09/msg00044.html
(In reply to register+gentoo from comment #5) that is bug 528712 and not a problem in glibc itself
i'm not actually seeing lock elision enabled by default glibc-2.19 and newer have: AC_ARG_ENABLE([lock-elision], AC_HELP_STRING([--enable-lock-elision[=yes/no]], [Enable lock elision for pthread mutexes by default]), [enable_lock_elision=$enableval], [enable_lock_elision=no]) if test "$enable_lock_elision" = yes ; then AC_DEFINE(ENABLE_LOCK_ELISION) fi that means the default is to turn it off you can see that by running configure: mkdir build && cd build ../configure --prefix=/usr grep ELISION config.h config.h:/* #undef ENABLE_LOCK_ELISION */ does glibc-2.20 fail for you as well ?
nm, i saw your patch ... i thought it was just for the ebuild and not the sources
can you try this patch out ? https://sourceware.org/ml/libc-alpha/2015-08/msg00376.html
this should be fixed in glibc-2.23, but i'm not sure i'll backport things as the changes landed to resolve this were quite extensive it boils down to the new sysdeps/x86/cpu-features.h file and commit 1814df5b02b9c359052c2048a1d2d617b406a17a that disables CPUID usage for i486
since 2.23 is in ~arch now, will just let this filter out into stable like normal
