Date: Mon, 14 Dec 1998 11:46:47 -0500 (EST) From: Alfred Perlstein <bright@hotjobs.com> To: Paolo Di Francesco <paipai@tin.it> Cc: freebsd-sparc@FreeBSD.ORG Subject: Re: Experiments... Message-ID: <Pine.BSF.4.05.9812141135270.27793-100000@bright.fx.genx.net> In-Reply-To: <19981214141012.BSNL18170.fep02-svc@winworkstation>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 14 Dec 1998, Paolo Di Francesco wrote: > I have done my exam at University, and now I'm again here "active" and > kicking.. ;) > > Now, the problem is: what to do? I'm trying to build my personal toolchain. So > I have compiled binutils (latest version) and I'll try to compile egcs > tomorrow. Maybe it's a better compiler, but it's more an experiment to see what > it says when I try to compile it. > The problem is: I haven't an Ultra. So someone must test bins for me (we can > compare what my toolchain gives and what _you_ obtain from your toolchain). > > 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. > 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++" 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. > 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. > > 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. This doesn't mean that the code is bad, just that i have to play with the objformat stuff more. 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? > > > 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 > 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?Pine.BSF.4.05.9812141135270.27793-100000>