From: Paul H. Hargrove (PHHargrove_at_lbl_dot_gov)
Date: Mon Aug 24 2009 - 12:09:20 PDT
Alan Woodland wrote: > Hello, > > I just noticed building on SPARC is failing. Log of a failed build is: > > https://buildd.debian.org/fetch.cgi?pkg=blcr&arch=sparc&ver=0.8.2-3&stamp=1251122315&file=log&as=raw > > Debian builds for 'sparclite' apparently in a lowest common > denominator strategy. > > This comes from the membar instruction in several functions in > libcr/arch/sparc/cr_atomic.h right? It looks like there's half-written > support for avoiding membar. > > Would it be feasible (and sensible?) for me to put together a patch > that implements some/all of cr_atomic.h using these gcc builtins? > http://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins.html > Where hardware support exists they are translated into the appropriate > instruction, where it doesn't they become a function call. > > Is there any reason not to use these builtins for all arches and avoid > having to maintain a cr_atomic.h for every supported platform? > > Alan > Alan, There are at least 4 parts to the answer. 0) I'd be surprised if the SPARC architecture it usable, even if it compiles. It is documented to be incomplete and to support (IIRC) only UltraSPARC and higher (see #2, below). 1) The gcc atomic builtins were not (widely?) available when we started this project, and until recently we supported kernels as old as 2.4.0, which required an ancient gcc-2.96. If you were to implement an arch/generic in the same spirit as the kernel's asm-generic I think we could use it when support exists in the compiler, and as a porting aid, but we'd probably not throw away the existing implementations. 2) Sparclite does not have the required atomic instructions. With only a test-and-set or load-and-clear type of atomic support one cannot implement a signal-safe compare-and-swap in user space (kernel does it by blocking interrupts momentarily). This is true of "older" ARM as well, but on that platform there is a neat kernel trick implemented by/for the NPTL port using the equivalent of a VDSO to use the atomic instructions on "newer" ARM or use the kernel for help otherwise. I don't know of such a trick on sparclite, but NPTL must work somehow. 3) Ever since we dropped 2.4.x kernel support, I have been wondering if we could drop our user-space atomics entirely in favor of using futexes. However, I've not had the opportunity to examine that possibility. -Paul -- Paul H. Hargrove PHHargrove_at_lbl_dot_gov Future Technologies Group Tel: +1-510-495-2352 HPC Research Department Fax: +1-510-486-6900 Lawrence Berkeley National Laboratory