Date: Tue, 15 Dec 1998 01:06:50 +0000 From: "Paolo Di Francesco" <paipai@tin.it> To: Alfred Perlstein <bright@hotjobs.com>, freebsd-sparc@FreeBSD.ORG Subject: Re: Experiments... Message-ID: <19981215000328.FASH18170.fep02-svc@winworkstation> In-Reply-To: <Pine.BSF.4.05.9812141135270.27793-100000@bright.fx.genx.net> References: <19981214141012.BSNL18170.fep02-svc@winworkstation>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Ok, this is not a tecnical prob, the tecnical ones are:
> >
> > 1) I have compiled binutils with sparc64-elf, is this right? Have I to use
> > sparc-aout?
> >
>
> no, you are correct, our target is sparc64-elf, not aout. aout is dead,
> long live elf.
>
Ok. Only elf stuff 8)
> > 2) I'll try to compile egcs with same flags in 1)
>
> this is a pain, you'll need to set your path to the bin-util's bin
> directory, you'll also have to compile like so:
>
> (this assumes you configured with --prefix=/usr/local/sparc64)
>
> export C_INCLUDE_DIR=/usr/include
> export LD_LIBRARY_PATH=/usr/local/sparc64/sparc64-elf/bin
> export PATH=/usr/local/sparc64/sparc64-elf/bin:/usr/local/sparc64/bin
>
> gmake LANGUAGES="c c++"
>
I'll try...
> hopefully that'll work, however you'll be generating invalid elf binaries
> without Kapil Chowksey's and my patches. i still haven't exactly decided
> on what to use for our compiler, i'm temped to use egcs-current as
> supposedly the sparc back end is way better, however egcs1.1.1 is now
> supposedly branded "stable" moving between revisions shouldn't be too bad.
I'll upload everything to that site (see below). Examples, and what I have from
my toolchain. So everyone can compare...
Please download them and let me know if you have same code (.o and .S) ;)
> > My idea is to have 2 toolchains. The first one to test "compiler" and
> > the second one to use it on code. We don't know much about
> > egcs/gcc/etc. so I thought to test compiler/toolchain on a usable
> > platform (Solaris). This mean the first toolchain (I called it
> > SolarSystem) must be used _only_ to test the compiler, and the second
> > one (EatIt) must be used to do our test when SolarSystem works.
>
> this is less of an issue than just getting code done. :) there are
> workarounds for invalid asm code. moving between revisions of egcs to get
> correct code will stink but they already test their own work, we shouldn't
> need/try to duplicate their efforts.
>
I hope egcs 1.1.1 is good enough to do experiments, and to compile it. In the
meantime, I hope egcs 2.0 or 1.2 will be out soon.
> >
> > Now, I don't know if we can build Sparc64 bins under solaris, and what
> > to do to build the right toolchain.
> >
> > About test programs. I'm preparing some test programs. The first is something
> > like "do-nothing". No output, no input. After that I'll do more complicated
> > programs (math progs, and input/output, etc...).
>
> i have generated .o files (gcc -c) and .S files (gcc -S) with egcs, they
> look "ok" the only problem is that they aren't branded correctly to be
> linked into solaris binaries. Basically i haven't been able to use
> solaris 'ld' to link my generated binaries with native compiled binaries.
>
what does it tell you? Core? Cannot link? Wrong object? What?
If you have a solaris7 compiler (64bit), you can do this:
1) try to assembly the .S file (does it work? Dunno)
2) try to compare .S from toolchain and from Sun's compiler.
3) try to compile binutils under solaris and then try to assembly the .S code
from the toolchain.
4) build the whole compiler/binutils under solaris. Can this be of some help?
if you haven't a compiler under Solaris, you can do some crosscompiling. But I
don't know how to do it... This seems to be the less stable process. (build a
native solaris compiler under FreeBSD/Intel)
Maybe this can help. 8)
(or, maybe these are stupids suggestions)
> This doesn't mean that the code is bad, just that i have to play with the
> objformat stuff more.
Hum....BFD? (see the old thread about BFD)
> Also, i'm unsure of what ABI we will follow. I have a sol-7 box and
> strangly enough all the shared objects test out to be 32bit, this isn't
> our goal, 64 bit is.
>
> >
> > Suggestions?
> >
>
> *head scratch*
>
> i'm trying to merge in Kapil's kernel work into the tree i have at home...
> have you downloaded it?
>
No. Tonight I will download it... 8)
Ciao Ciao
Paolo Di Francesco
_
->B<- All Recycled Bytes Message ...
~
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-sparc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981215000328.FASH18170.fep02-svc>