sparc optflags

[Jakub Bogusz]

On Wed, Mar 19, 2008 at 06:57:56PM +0000, Tomasz Mateja wrote:
> pluto w agmk.net wrote:
> > 19/3/2008, "Tomasz Mateja" <tommat w pimpek.one.pl> napisał/a:
> >> Paweł Sikora wrote:
> 
> >> moze jednak zostanmy przy sparc ale -m32 -mcpu=ultrasparc dla th i wyzej.
> >> Tak bedzie prosciej - bez patchowania gcc i rpm-a i kto wie jeszcze czego.
> >>     
> >
> > btw. dorzuc do ./configure opcje --with-cpu=ultrsparc.
> >   
> mowisz o gcc czy o makrze %configure ??

gcc, ale średnio mi się to podoba.
Powoduje przyjęcie -mcpu=v9 jako domyślne.
-mcpu=v9 włącza mv8plus, a to jest inne ABI i inny format ELF.

[builder2 w syriusz ~]$ gcc -o c c.c -mcpu=v8
[builder2 w syriusz ~]$ file c
c: ELF 32-bit MSB executable, SPARC, version 1 (SYSV), for GNU/Linux 2.4.6, dynamically linked (uses shared libs), not stripped
[builder2 w syriusz ~]$ gcc -o c c.c -mcpu=v9
[builder2 w syriusz ~]$ file c
c: ELF 32-bit MSB executable, SPARC32PLUS, V8+ Required, version 1 (SYSV), for GNU/Linux 2.4.6, dynamically linked (uses shared libs), not stripped

Ten drugi rodzaj binarki wymaga UltraSPARCa i 64-bitowego jądra (na
Linuksie jest to akurat tożsame). I nie wszystko takie obsługuje (np.
jeszcze nie tak dawno gdb nie rozumiało tego formatu).

Swoją drogą opcja -mv8plus (przynajmniej dla gcc 3.3.5, do nowszego
nie mam teraz dostępu) nie ma wpływu na wynikową binarkę:
- przekazane przy kompilacji dla <=v8 nie robi nic, bo v8 nie ma
  64-bitowych rejestrów
- dla >=v9 asembler i tak dostaje -Av9a (lub -Av9b) i tworzy ELF
  z ABI SPARC V8+
Czyli co najwyżej -mno-v8plus wyłączy używanie 64-bitowych rejestrów,
ale binarka i tak będzie typu SPARC32PLUS.


Co do nazewnictwa, to jest zamieszanie:
ABI SPARC - wiadomo, 32-bitowe, %g5 zarezerwowany dla systemu
ABI SPARC V8+ - jw rozszerzone o 64-bitowe rejestry global i out,
  %g5 dostępny jako scratch; wymaga procesora _V9_ (UltraSPARC)
ABI SPARC V9 - w pełni 64-bitowe

Pod Solarisem sparcv9 oznacza właśnie ABI SPARC V9 (odpowiednik
sparc64 z Linuksa).
Pod Linuksem sparcv9 to nadal 32-bitowe ABI z -mcpu=v9 (-mcpu=v9
dodaje definicję makra __sparc_v9__ - co jest błędnie rozumiane
jako sparc64 przez niektóre programy; być może jest to prawda
pod Solarisem - nie wiem, nie mam w tej chwili jak sprawdzić).


IMO skoro port th/i386 z kodem wymagającym i486 nazywamy i486, a nie i386,
to portu wymagającego UltraSPARC-a też nie powinniśmy nazywać sparc,
tylko od typu minimalnego wymaganego procesora.
config.gcc to akurat nie problem - łatwo poprawić.
Trochę większy z pomieszaniem nazw (niektórym sparcv9 sugeruje, że to
sparc64) - ale to zamieszanie i tak już jest...

Poza tym jeśli sparc znaczyłoby sparcv9, to jak odróżnić tę
podarchitekturę w specu, żeby np. przekazać jakieś inne opcje dla
configure? "%ifarch sparcv9" by nie działało.
Nawet jeżeli domyślne byłoby v9, to nie zgadzam się na blokowanie
na poziomie speców możliwości budowania pakietów na v8.


Kolejna rzecz: jeżeli decydować się na v9 jako minimum w linii dystrybucji
- wszystkie rzeczy kernelowe na sparc i sparcv9 nie mają racji bytu[1]. Tylko
sparc64.

[1] dotyczy też takich drobiazgów jak obsługa modułów jądra w 32-bitowej
wersji busyboksa (32-bitowa nie umie nic zrobić z 64-bitowymi)


-- 
Jakub Bogusz    http://qboosh.pl/