From mboxrd@z Thu Jan 1 00:00:00 1970 References: <2b8152e044cd233c0ee7603d37f4d369@proxima.alt.za> Message-Id: From: Paul Lalonde To: "lucio@proxima.alt.za" , Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: <2b8152e044cd233c0ee7603d37f4d369@proxima.alt.za> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7A341) Date: Sun, 15 Nov 2009 09:26:17 -0800 Cc: "9fans@9fans.net" <9fans@9fans.net> Subject: Re: [9fans] MIPS LSB compiler Topicbox-Message-UUID: 9bf8cc8e-ead5-11e9-9d60-3106f5b1d025 I'd be very interested in an ELF based cross-compilation to plan9. I have this many-core IA part that I would desperately love to boot a nicer OS on than we currently have (memory footprint, scheduling, vm architecture, syscall performance, remote exposure), but the principal application that has to run on it is in C++. If there was a clear path, I might even be able to shake loose some resources for it. Paul On 2009-11-15, at 8:52 AM, lucio@proxima.alt.za wrote: >>> Given the addition of this toolchain, one wonders how far we are >>> from >>> being able to port all the P9 compilers to Linux and consequently to >>> all Posix platforms. My beef is that I have a wide choice of cross- >>> and native toolchains with which to port Plan 9 to a MIPS platform >>> (LSB), but I really wish I could settle on something I am much more >>> comfortable and familiar with. >> >> I guess I'm not following your line of thought here. > > There are two almost orthogonal issues here: "go" itself and the > toolchain that it relies on. Whereas I do care about "go" and would > dearly like to assimilate it into my toolkit, my more immediate > interest lies with porting native Plan 9 "C" facilities beyond the > Plan 9 boundaries, specifically into the various environments served > by the "ELF" object format. Worse, my wish is for the Plan 9 kernel > to be able to cope with ELF executables so that Plan 9 can readily (*) > join the platforms that can be used to cross-develop software. > > Now, the "go" toolchain is very close to the Plan 9 native toolchain, > its most obvious difference lies in its default object format. Given > the desirability of being able to generate ELF executables from within > Plan 9 (the MIPS toolchain already does, but I had issues with that > before now and the "go" toolchain diverges from that model somewhat, I > believe from inspecting the source somewhat superficially) my hope is > that the differences in the toolchains provided by the "go" > development and Plan 9 can mostly be eliminated. Besides providing > Plan 9 with a more modern toolchain, it also makes it more practical > to port "go" to Plan 9 and it makes it possible to cross-develop "go" > code on a Plan 9 platform; a small amount of effort in the direction > of the MIPS architecture will also facilitate porting "go" to it. All > developments I would be keen to contribute to, but lack the confidence > more than the expertise to undertake on my own. > > ++L > > (*) There are mutual benefits: cross-compiling on a GNU platform to a > Plan 9 target is too hard if one needs to produce Plan 9 native > executables. Dave Hogan managed to twist GCC 3.0 (actually, binutils > 2.11, if I remember right) to produce Plan 9 native executables, but I > have failed dismally to reproduce his results on later versions of the > GNU toolchain, it's just too dense for me. I have configured a > cross-development toolchain under NetBSD that uses the Plan 9 > libraries and syscall interface; it isn't yet possible for me to test > whether the generated ELF executable actually would work, too many > other chestnuts in the fire right now. Were this cross-development > tool to be viable, one would use it to bootstrap the most recent > stable version of GCC/G++, with results some 9fans might welcome. > >