Re: [9fans] MIPS LSB compiler

[Paul Lalonde <plalonde@telus.net>]

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.
>
>