Re: sparc64 and sparc architecture -- any consensus?
> The way sparc64 is going to work is pretty much already planned out by
> the egcs and glibc programmers. Sparc64 will cohabitate in a sparc32
> environment. There will be a /lib64:/usr/lib64 (not sure where the
> includes go, perhaps they remain the same for both?).
Its not yet planned out, I have just an idea how to lay things out, but need
to make linker and glibc changes to make it work (well, the changes are
mostly done, but the hard part is to get them accepted).
> The compiler for
> sparc64 will be able to generate 32bit and 64bit binaries (seems it
> always does 64bit by default, I'm checking into that), so it will only
> take mere compile CFLAG changes to make it compile/link as a 64bit
> object.
It can default to 32bit as well, depends on how do you compile it.
I'd like the default to be determined by uname -m during runtime and you can
use sparc32 program to change uname -m output.
>
> > The other issues which are unclear in my mind, and which I would need
> > to know about, is how the fundamental toolchain (glibc, egcs, ldso) is
> > doing w.r.t. sparc-64 support. Reading back in the archives, the only
> > indicators I see is:
> >
> > * glibc should be basically there (??)
>
> Glibc claims to be sparc64 ready, I've been able to compile some simple
> (simple meaning no libm functions, due to egcs) statically.
Yes, glibc is basically there, although not tested much (well, not at all
since late 1997).
>
> > * egcs not quite there (grab from ultrapenguin needed)
>
> Egcs is missing only the floating-point functions in libgcc. I've
> been keeping an eye on the CVS and there may be something there soon.
Wrong. Egcs miscompiles a lot of floating-point in 64bit, generates very
suboptimal code for int types, has probably some regressions to the SYSVABI SPARCv9
(will need to recheck the whole ABI to see if everything is ok), plus I want
to discuss char/short argument passing convention in the ABI still, so it
basically is not a good idea to compile anything but the kernel with the
64bit compiler, because the ABI can still change.
>
> > * binutils not quite there (grab from ultrapenguin needed)
>
> Binutils _is_ ready, has been ready and requires nothing more right now
> than installing bintuils-multiarch to use the support. This is what has
> been used for the sparc64 kernels.
As above mentioned, it needs some code in ld if /lib64:/usr/lib64... setup
is chosen. Plus again autodetection of the default emulation based on uname
-m.
Cheers,
Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux | http://ultra.linux.cz/ | http://ultra.penguin.cz/
Linux version 2.2.7 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________
Reply to: