This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [arm] bits/atomic.h


On Thu, 24 Nov 2011, Richard Henderson wrote:

> > /* Atomic compare and exchange.  These sequences are not actually atomic;
> >    there is a race if *MEM != OLDVAL and we are preempted between the two
> >    swaps.  However, they are very close to atomic, and are the best that a
> >    pre-ARMv6 implementation can do without operating system support.
> >    LinuxThreads has been using these sequences for many years.  */
> 
> Surely we can at least use the gcc builtins, which fall back to the 
> kernel support.  Leaving this as-is just seems like a recipe for 
> disaster.
> 
> Although perhaps this should be part of a general cleanup of these 
> headers using the gcc atomic builtins (gcc 4.7) or sync builtins 
> (prior).  I assume we don't actually support too many older versions of 
> gcc...

This is another case of an obsolete header, the current one being 
sysdeps/unix/sysv/linux/arm/nptl/bits/atomic.h; apart from what you 
mention, the SWP instruction is deprecated in ARMv6 and later and I don't 
think it's atomic on SMP systems.  Since Linux is the only supported 
kernel for ARM glibc [*], and NPTL the only supported threading library 
for Linux with current glibc, nothing will every use 
sysdeps/arm/bits/atomic.h.  Yes, it should be possible to do a generic 
version of atomic.h using __atomic_* (I'm particularly interested in that 
for MIPS, to avoid an accumulation of processor-specific variants on 
atomic inline asms in glibc).

[*] sysdeps/standalone is one of the hopelessly dead bits in ports, and 
support for non-x86 versions of Hurd was recently removed from GCC as 
long-dead.  We have a version control system to find old code.  In my view 
there is no use in having such long-dead code on the current version of 
ports given the use of version control.  That is, I think

bare/
sysdeps/am29k
sysdeps/i860
sysdeps/i960
sysdeps/m88k
sysdeps/mach
sysdeps/rs6000
sysdeps/standalone
sysdeps/tahoe
sysdeps/unix/bsd
sysdeps/unix/sysv/aix
sysdeps/unix/sysv/hpux
sysdeps/unix/sysv/i386
sysdeps/unix/sysv/irix4
sysdeps/unix/sysv/isc2.2
sysdeps/unix/sysv/minix
sysdeps/unix/sysv/sco3.2
sysdeps/unix/sysv/sco3.2.4
sysdeps/unix/sysv/sysv4
sysdeps/vax
sysdeps/z8000

should all be removed - along with files for other architectures that 
aren't actually used with the Linux kernel (like the example that started 
this discussion), though those may be a bit harder to identify.  
Comments?  (Even this is quite generous to am33 and cris which don't have 
NPTL ports so won't have worked since the 2.3 era.  But some of the 
architectures listed above had their GCC ports obsoleted in version 3.1.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]