Bug 161736 - It still use -mv8 while gcc4 is the compiler in /elf.
It still use -mv8 while gcc4 is the compiler in /elf.
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
sparc Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-06-26 15:39 EDT by Balint Cristian
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-07-26 02:23:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Balint Cristian 2005-06-26 15:39:16 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; Linux) KHTML/3.4.1 (like Gecko)

Description of problem:
There is a -mv8 switch left in the source, it is imposible to compile it   
with gcc4    
   See in sysdeps/unix/sysv/linux/sparc/sparc32/Makefile 
I use  
gcc -v 
Using built-in specs. 
Target: sparc64-redhat-linux 
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-libgcj-multifile 
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk 
--host=sparc64-redhat-linux --build=sparc64-redhat-linux 
--target=sparc64-redhat-linux --with-cpu=v7 
Thread model: posix 
gcc version 4.0.0 20050622 (Red Hat 4.0.0-13) 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Compile it. 
sparc32 rpmbuild -bb glibc.spec 

Additional info:

The fix [one posibble fix]:  
--- sysdeps/unix/sysv/linux/sparc/sparc32/Makefile.orig 2003-08-31  
20:22:46.000000000 +0300  
+++ sysdeps/unix/sysv/linux/sparc/sparc32/Makefile      2005-06-26  
18:58:07.000000000 +0300  
@@ -4,7 +4,7 @@  
 # When I get this to work, this is the right thing  
 ifeq ($(subdir),elf)  
-CFLAGS-rtld.c += -mv8  
+CFLAGS-rtld.c += -mcpu=v7 -mtune=ultrasparc  
 #rtld-routines += dl-sysdepsparc  
 sysdep-others += lddlibc4  
 install-bin += lddlibc4
Comment 1 Jakub Jelinek 2005-06-27 10:15:13 EDT
Can you explain a little bit why -mv8 does not work? -mcpu=v7 -mtune=ultrasparc
is surely wrong.
My reading of GCC HEAD sparc.h is that -mv8 should work the same as it used to
grep mv8[^p] gcc/config/sparc/sparc.h
%{mv8:-D__sparc_v8__} \
%{!mcpu*:%{!mcypress:%{!msparclite:%{!mf930:%{!mf934:%{!mv8:%{!msupersparc:%(cpp_cpu_default)}}}}}}} \
%{mv8:-mcpu=v8} %{msupersparc:-mcpu=supersparc} \
%{!mcpu*:%{!mcypress:%{!msparclite:%{!mf930:%{!mf934:%{!mv8:%{!msupersparc:%(asm_cpu_default)}}}}}}} \
Comment 2 Balint Cristian 2005-06-27 10:34:48 EDT
Well, here is the output it not work, i guess something changed in params of gcc4:  
If need more infos let me know, i am really courios why is this mess. 
[root@sun /]# gcc -v  
Using built-in specs.  
Target: sparc64-redhat-linux  
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info  
--enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib  
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile  
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk  
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj- --host=sparc64-redhat-linux  
--build=sparc64-redhat-linux --target=sparc64-redhat-linux --with-cpu=v7  
Thread model: posix  
gcc version 4.0.0 20050622 (Red Hat 4.0.0-13)  
[root@sun /]# gcc -mv8 test.c  
cc1: error: invalid option 'v8'  
[root@sun /]# gcc -mcpu=v7 -mtune=ultrasparc   test.c  
test.c: In function 'main':  
test.c:6: warning: incompatible implicit declaration of built-in function 'printf'  
[root@sun /]# file a.out 
a.out: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), for GNU/Linux 2.2.5, 
dynamically linked (uses shared libs), not stripped 
[root@sun /]# ./a.out 
Hello ! 
[root@sun /]#                                                                                                              
Comment 3 Jakub Jelinek 2005-06-27 12:24:38 EDT
Weird.  Does gcc -mcpu=v8 test.c work?
Comment 4 Jakub Jelinek 2005-06-28 05:08:53 EDT
Changed in upstream CVS, will show up in glibc-2.3.90-2 and later.
Note that there are far bigger problems for sparc though:
1) you need sufficiently recent binutils, so that sparc64 TLS support is in
2) linuxthreads have been killed, so the question is what to do with
   *.sparc.rpm builds (sparcv9.rpm and sparc64.rpm should support NPTL fine)
   We had a plan with davem what to do here:
> I started work on this.  It gets a little bit ugly because we
> have to thus override all of the sem_*.c NPTL support files as
> well on sparc.  I was thinking of overriding the fork.c and
> unregister-atfork.c stuff as well so that none of the atomic_*()
> pre-v9 sparc implementation ends up in the NPTL pthread library
> but then I noticed that a lot of top-level nptl/*.c code references
> the atomic_*() routines, sigh.

I think the current atomic_*() routines that use a lock pool
for pre-v9 are fine in most places.  The exceptions should IMHO be
a) futexes where we know the values in them are small (well, limited
to 24 bits is enough)
b) process shared stuff
So lll_*lock as well (thus pshared mutexes), rwlocks, condvars, barriers
and semaphores is enough.

lll*lock uses just 0, 1, 2 values, so ldstub there is fine.
Of the b) stuff, rwlocks are just using lll*lock and no other atomic
operations.  Condvars are also just using lll*lock and no other atomic,
except old_pthread_cond* stuff.  But old_pthread_cond* really can't
work process shared.  So, the only trouble are semaphores and barriers.
There are more than 8 bits left in both pthread_barrier_t and sem_t
though struct sem is ATM 4 bytes, and sem_t 16 (resp. 32 on sparc64) bytes,
and struct pthread_barrier is 16 bytes, while pthread_barrier_t is
20 (resp. 32) bytes.  SPARC would need to override sem_init.c and
pthread_barrier_init.c though, to clear the lock byte and even the
sparcv9/sparc64 sem/barrier routines would need to use that lock.
For lowlevellock.h, sparcv9/sparc64 would need to stop using
atomic_exchange_rel and instead use
  __val = *__futex & 3;
while (__builtin_expect (atomic_compare_and_exchange_bool_acq (__futex,
0, __val), 0));
which could be 2 cycles slower or something.

> The futex kernel stuff doesn't know about this convention we are
> using whereby the top byte of the word is used as a spinlock in
> the pre-v9 case.  Therefore my concern is that on a futex wakeup
> comparison, we might do the wrong thing if the futex kernel code
> sees the lock byte set (meaning a pre-v9 process is in the process
> of updating the futex).

The kernel ATM doesn't care, all it ever does is simple value
comparison.  Given that NPTL will never pass a value with upper 8 bits
set to the kernel as expected value of some futex, as soon as somebody
locks a futex for doing the "atomic" operation by ldstubing the upper
8 bits, kernel will consider it as a changed value and return with
-EAGAIN resp. -EWOULDBLOCK, which is what we want there.

The patch I wrote recently and Ingo said he likes that (FUTEX_WAKE_OP)
changes things, the kernel now needs to know how to unlock a lock.
But userland tells it how.  So, for SPARC we'll have 2 options,
either not use FUTEX_WAKE_OP at all and be slower in pthread_cond_signal,
or a SPARC specific operation can be added to the opcodes that will know
about the ldstub stuff and handle it properly.

Note You need to log in before you can comment on or make changes to this bug.