From owner-freebsd-sparc Mon Dec 14 08:42:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA09943 for freebsd-sparc-outgoing; Mon, 14 Dec 1998 08:42:40 -0800 (PST) (envelope-from owner-freebsd-sparc@FreeBSD.ORG) Received: from bright.fx.genx.net (bright.fx.genx.net [206.64.4.154]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA09938 for ; Mon, 14 Dec 1998 08:42:38 -0800 (PST) (envelope-from bright@hotjobs.com) Received: from localhost (bright@localhost) by bright.fx.genx.net (8.9.1/8.9.1) with ESMTP id LAA97230; Mon, 14 Dec 1998 11:46:47 -0500 (EST) (envelope-from bright@hotjobs.com) X-Authentication-Warning: bright.fx.genx.net: bright owned process doing -bs Date: Mon, 14 Dec 1998 11:46:47 -0500 (EST) From: Alfred Perlstein X-Sender: bright@bright.fx.genx.net To: Paolo Di Francesco cc: freebsd-sparc@FreeBSD.ORG Subject: Re: Experiments... In-Reply-To: <19981214141012.BSNL18170.fep02-svc@winworkstation> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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