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, [email protected] 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.
