Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 161736 - It still use -mv8 while gcc4 is the compiler in /elf.
Summary: It still use -mv8 while gcc4 is the compiler in /elf.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: sparc
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-26 19:39 UTC by Balint Cristian
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-07-26 06:23:20 UTC


Attachments (Terms of Use)

Description Balint Cristian 2005-06-26 19:39:16 UTC
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 
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre 
--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):
gcc-2.3.5-11

How reproducible:
Always

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 14:15:13 UTC
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
do:
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 14:34:48 UTC
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-1.4.2.0/jre --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 16:24:38 UTC
Weird.  Does gcc -mcpu=v8 test.c work?

Comment 4 Jakub Jelinek 2005-06-28 09:08:53 UTC
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
do
  __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.