Re: sparc64 and sparc architecture -- any consensus?
On Tue, May 11, 1999 at 01:15:06PM +0200, Jakub Jelinek wrote:
> > 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).
Last I checked the sparc64 linker is called ld-linux64.so and egcs and
glibc know about this and are able to distinguish the two at runtime.
> > 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.
I think 95% of what is going to be compiled is going to be sparc32, even
on sparc64 platforms. Compiling sparc64 should be a conscious thing, not
something the compiler decides to do on it's own. Default should be
sparc32 unless passed 64bit flags.
> > > * 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.
As I said, It's not ready, and it is missing floating point support. I've
not tested it thoroughly enough, other than checking to see that linking
the alt paths (/lib64:/usr/lib64) works and it seems to do just that.
> > > * 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
I was under the impression that ld defaulted to what ever the object was
compiled with and as far as the /lib64:/usr/lib64, these are passed to ld
from egcs (which forces ld to use these paths). This is what I have
gathered from the current egcs CVS config for sparc64 (linux64).
Reply to: