what i said to people at usenix was approximately the following. i think that porting go to plan 9 - the time to get something working that runs all the go programs - is not more than a week of concerted effort. i also think that it just hasn't been high enough priority for anyone (myself included) to put that amount of effort in.
the go runtime sets up the segment registers, with the operating system's help, so that gs points at per-kernel-thread storage. the linker generates references through gs for the pseudo-addressing mode 0(gs), 4(gs), etc. on plan 9 there is already per-kernel-thread storage: it is called the stack. the workaround would be for the linker to know the top of stack address and rewrite 0(gs) and 4(gs) to fixed memory addresses just below the top of the stack. it would be just as efficient as the 0(gs), 4(gs) stuff and not require any kernel changes. the build uses make, yes, and in some places there are even include files that include other include files (gasp!), but writing equivalent mkfiles should take not very much time. we're not doing anything magical, and the particular style in the makefiles should be familiar. there's obviously a lot of divergence between the plan 9 tool chain and the go tool chain. the object files have different format, and so on. to get off the ground i would suggest treating the go copies of the tools as separate programs and libraries from the originals. for example, you might install the go libmach as /386/lib/go/libmach.a and the compiler tool chain as /386/bin/go/8a, /386/bin/go/8c, /386/bin/go/8g, /386/bin/go/8l. the .8 files created by those tools would not be compatible with the standard ones, and the standard nm wouldn't understand the final 8.out, but the final 8.out would run. you'd have to disable the runtime copy of the symbol table (the "nacl" target in 8l already does). anyway, keep everything separate and get it working. once you have a working system then you could worry about reconciling the two worlds to whatever extent is appropriate. i think people get too hung up on trying to make the port back perfect. just make it work. then make it better. russ
