Making NPTL the default for FC3, vanilla i386 support

Jakub Jelinek jakub at redhat.com
Wed May 19 12:24:35 UTC 2004


Hi!

I'd like to make NPTL the default threading library for FC3,
as a step in phasing out LinuxThreads.

In FC2, when compiling a program which #include <pthread.h>,
or other POSIX THR option headers (or e.g. limits.h) or
when linking against -lpthread, it is compiled against
LinuxThreads headers and linked against LinuxThreads libpthread.so.
To use NPTL headers and/or link against NPTL libpthread.so,
one has to use -I/usr/include/nptl -L/usr/lib{,64}/nptl

Dynamically linked programs are then run by default against
NPTL libraries (unless LD_ASSUME_KERNEL < 2.4.19 is used),
as NPTL libraries are backwards ABI compatible with LinuxThreads
libraries, but not vice versa.

In FC3, I'd like programs to link against NPTL libpthread.so/libpthread.a
and compile against NPTL headers by default and provide some
-I/usr/include/linuxthreads -L/usr/lib{,64}/linuxthreads
way to build LinuxThreads statically linked programs and/or
dynamically linked programs which can run against LinuxThreads
too.  The advantage is that newly built programs can use
the NPTL ABI additions which are not present in LinuxThreads
(e.g. pthread_[sg]etaffinity_np, pthread_barrierattr_setpshared,
pthread_condattr_[sg]etclock, pthread_attr_[sg]etaffinity_np,
pthread_timedjoin_np, pthread_tryjoin_np and the new
__attribute__((cleanup)) based pthread_cleanup_{push,pop})
and that LinuxThreads really stays as a compatibility only
library.

The switch causes three important changes:

1) statically linked programs, no matter whether threaded or not,
   will now require a NPTL capable kernel (one from RHL 9, RHEL3,
   FC1, FC2 or any 2.6.x kernel should be enough), dynamically linked
   programs using -lpthread in some cases as well (e.g. if they are using
   the functions present in NPTL but not in LinuxThreads)

2) while previously blindly setting LD_ASSUME_KERNEL environment
   variable at the beginning of large shell scripts around some
   programs and sometimes even in /etc/profile.d/* often worked,
   now the chances are lower (any time such shell script
   runs a program which requires NPTL the program would fail
   to run).  LD_ASSUME_KERNEL should now be really only used
   on the command line of the broken program which needs
   LinuxThreads.  E.g.
   LD_ASSUME_KERNEL=2.4.19 /opt/FOOW/bin/barx --args xyz

3) NPTL has not been ported to i386, only i486+, x86_64,
   ia64, ppc32, ppc64, s390, s390x, alpha, sh and sparcv9.
   i386 (and sparc < v9) lacks atomic instructions powerful
   enough for NPTL needs.  Well, I have tried to port NPTL
   to i386, http://sources.redhat.com/ml/libc-hacker/2004-05/msg00019.html,
   but that port is severely limited and maintaining two
   different IA32 ports would be too much work.
   So for NPTL by default we need a i486-*-linux build of
   glibc at least (well, it can still use
   -march=i386 -mtune=pentium4, -march=i486 -mtune=pentium4
   wouldn't make much difference).
   This means though that almost no FC3 programs can run
   on vanilla i386{SX,DX} CPUs.  Is this a problem to anyone?
   Fedora Core installer will certainly not install on i486
   either, but if rpms from FC3 are used by RULE project...
   There have been some i486+ only instructions accidentally
   used in the past in many C++ programs (from libstdc++-v3
   headers) and apparently nobody noticed this in RHL or
   Fedora, so I assume not really many people are attempting
   to revive their i386 boxes.

Now, the question is, as at least all statically linked programs
built on Fedora Core 3 and many dynamically linked ones will require
i486+ atomic instructions (xaddl, cmpxchgl), if we should change
rpm architecture of FC3 rpms or not.

One alternative is just change the definition of .i386.rpm
to be "can run on i386{SX,DX} only with XADD/CMPXCHG emulation
in the kernel [1] or any i486+" (and I must say I'm most inclined
to this).  The corresponding rpmrc flags would be:
optflags: i386 -O2 -g -march=i386 -mtune=pentium4 -m32
optflags: i486 -O2 -g -march=i486 -m32
optflags: i586 -O2 -g -march=i586 -m32
optflags: i686 -O2 -g -march=i686 -mtune=pentium4 -m32
optflags: athlon -O2 -g -march=athlon -m32
but i386.rpm's would be allowed to contain xaddl/cmpxchgl instructions.

Another alternative is to change all rpms in FC3 which are .i386.rpm
in FC2 to .i486.rpm, with rpmrc:
optflags: i386 -O2 -g -march=i386 -m32
optflags: i486 -O2 -g -march=i486 -mtune=pentium4 -m32
optflags: i586 -O2 -g -march=i586 -m32
optflags: i686 -O2 -g -march=i686 -mtune=pentium4 -m32
optflags: athlon -O2 -g -march=athlon -m32

Using .i586.rpm's wouldn't buy us anything (-march=i586 -mtune=pentium4
is almost equivalent to -march=i486 -mtune=pentium4 and not
many programs really use cmpxchg8b instructions (which is not
even generated by GCC)) and moving the low bar to
.i686.rpm (note, i686 for GCC/rpm means i686 with X86_FEATURE_CMOV)
is probably too early for Fedora Core (there are still too many
VIA CPUs without cmov and even some Pentium's in use).

	Jakub





More information about the fedora-devel-list mailing list