This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support for Intel X1000
- From: "Kinsella, Ray" <ray dot kinsella at intel dot com>
- To: "joseph at codesourcery dot com" <joseph at codesourcery dot com>
- Cc: "carlos at redhat dot com" <carlos at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Wed, 13 May 2015 10:30:11 +0000
- Subject: Re: Support for Intel X1000
- Authentication-results: sourceware.org; auth=none
- References: <1431426490 dot 3246 dot 29 dot camel at intel dot com> <alpine dot DEB dot 2 dot 10 dot 1505121547500 dot 30680 at digraph dot polyomino dot org dot uk>
On Tue, 2015-05-12 at 15:52 +0000, Joseph Myers wrote:
> On Tue, 12 May 2015, Kinsella, Ray wrote:
>
> > Clearly no changes are needed to glibc for this - as it already provides
> > a UP build, however I wanted to socialize the approach to fixing the
>
> glibc does not provide a UP build. The UP conditionals in glibc should be
> presumed bitrotten, and should be removed; there is no supported configure
> option to enable them.
ok - good to know.
UP is pretty ubiquitous across the glibc locking code - but sounds like
can't be trusted. Tweaking the assembler is the only way to strip LOCK
at the moment.
> The right way to use different atomics in builds for different
processors
> is to move to using __atomic_* as far as possible when building with
> sufficiently recent GCC versions and then have GCC deal with the
different
> atomics.
Agreed but there is a significant amount of code that does not work this
way today.
from nptl/sysdeps/unix/sysv/linux/i386/lowlevellock.h
#if defined NOT_IN_libc || defined UP
# define __lll_trylock_asm LOCK_INSTR "cmpxchgl %2, %1"
#else
# define __lll_trylock_asm "cmpl $0, %%gs:%P5\n\t" \
"je 0f\n\t"
\
"lock\n"
\
"0:\tcmpxchgl %2, %1"
#endif
> glibc always
> requires atomic compare-and-exchange to be available in some form, whether
> through hardware instructions or kernel helpers, and does not support
> processor/kernel combinations without such an operation.)
>
As the X1000 with the bug is only available in a UP (single core, single
socket) configuration - the cmpxchg instr without the LOCK prefix can be
considered to
be atomic on this platform.
Ray K