Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 523830 - <sys-libs/glibc-2.23: lock-elision always uses cpuid which breaks on i486
Summary: <sys-libs/glibc-2.23: lock-elision always uses cpuid which breaks on i486
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-26 21:14 UTC by Daniel Goertzen
Modified: 2016-04-14 13:56 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
ebuild diff with lock-elision USE and --disable-lock-elision fixes. (glibc-2.20.ebuild.diff,6.12 KB, text/plain)
2014-09-30 18:38 UTC, Daniel Goertzen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Goertzen 2014-09-26 21:14:00 UTC
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
Comment 1 Daniel Goertzen 2014-09-30 18:38:24 UTC
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.
Comment 2 Daniel Goertzen 2014-09-30 18:43:51 UTC
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.
Comment 3 SpanKY gentoo-dev 2014-10-17 18:05:43 UTC
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.
Comment 4 Daniel Goertzen 2014-10-17 18:24:28 UTC
I was not aware you could disable it just for i486.  That's much more sensible than my suggestion.
Comment 5 register+gentoo 2014-11-11 12:27:01 UTC
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
Comment 6 SpanKY gentoo-dev 2014-11-11 22:24:26 UTC
(In reply to register+gentoo from comment #5)

that is bug 528712 and not a problem in glibc itself
Comment 7 SpanKY gentoo-dev 2015-03-21 16:48:40 UTC
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 ?
Comment 8 SpanKY gentoo-dev 2015-03-21 16:50:35 UTC
nm, i saw your patch ... i thought it was just for the ebuild and not the sources
Comment 9 SpanKY gentoo-dev 2015-08-11 09:28:39 UTC
can you try this patch out ?

https://sourceware.org/ml/libc-alpha/2015-08/msg00376.html
Comment 10 SpanKY gentoo-dev 2015-10-19 15:49:18 UTC
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
Comment 11 SpanKY gentoo-dev 2016-04-14 13:56:31 UTC
since 2.23 is in ~arch now, will just let this filter out into stable like normal