On Wed, Mar 19, 2008 at 06:57:56PM +0000, Tomasz Mateja wrote: > [EMAIL PROTECTED] wrote: > > 19/3/2008, "Tomasz Mateja" <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] ~]$ gcc -o c c.c -mcpu=v8 [EMAIL PROTECTED] ~]$ 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 [EMAIL PROTECTED] ~]$ gcc -o c c.c -mcpu=v9 [EMAIL PROTECTED] ~]$ 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/ _______________________________________________ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl