[9fans] More on the GO toolchain

[9fans] More on the GO toolchain

[lucio]

Let me bore most of you in the hope that there are interested
parties...

So far I have compiled the assemblers, linkers and compilers for 386,
amd64 and arm from the GO toolchain, seemingly successfully.  I have
used the freshly acquired sheevaplug to check, at least to some
extent, that this applies to the arm and, naturally, most of the work
is being done on 386 equipment.

I have then compiled the native Plan 9 libraries, libc and libbio,
using the freshly generated tools.  I have had a bit of a setback in
this compilation and I'm writing this while taking a breather, I'll be
going back to fix this last problem next.

One of the issue I need to fix, further, is that the 386 linker (at
least) demands to access the runtime module (runtime.a - I am not yet
ready to build this library) and I wonder if there are any suggestions
here on how best to eliminate this mandatory requirements without
jeopardising compatibility between the GO toolchain and its ability to
"replace" the native Plan 9 toolchain - which is my primary objective
at this point.

Mail me off list if you are interested in the details.  I have
submitted some GO source changes to Russ personally, but I have a
feeling he has overlooked them, maybe this will remind him.  I have
more changes I would like to see incorporated in the GO sources to
save me laborious adjustments every time a new release takes place.

++L

Re: [9fans] More on the GO toolchain

[James Tomaschke]

lucio@proxima.alt.za wrote:
> One of the issue I need to fix, further, is that the 386 linker (at
> least) demands to access the runtime module (runtime.a - I am not yet
> ready to build this library) and I wonder if there are any suggestions
> here on how best to eliminate this mandatory requirements without
> jeopardising compatibility between the GO toolchain and its ability to
> "replace" the native Plan 9 toolchain - which is my primary objective
> at this point.

Perhaps the go 8l is not honoring the "-l " option?  I just tried to
create a mbr from assembly and it reported the same runtime
requirements.  A diff between the various sources might be useful since
they are similar.

Re: [9fans] More on the GO toolchain

[erik quanstrom]

> Perhaps the go 8l is not honoring the "-l " option?  I just tried to
> create a mbr from assembly and it reported the same runtime
> requirements.  A diff between the various sources might be useful since
> they are similar.

see /sys/src/boot/pc*.

; mk -n mbr.install
8l -o mbr -H3 -T0x0600 -l mbr.8
ls -l mbr
cp mbr /386/mbr

- erik

Re: [9fans] More on the GO toolchain

[James Tomaschke]

erik quanstrom wrote:
> ; mk -n mbr.install
> 8l -o mbr -H3 -T0x0600 -l mbr.8
> ls -l mbr
> cp mbr /386/mbr

The go toolchain yields:
$ 8l -o mbr -H3 -T0x0600 -l mbr.8
confidence: runtime·morestack not defined
??none??: _rt0_386_plan9: not defined

src/cmd/8l/pass.c:
symmorestack = lookup("runtime·morestack", 0);
....
if(pmorestack == P)
  diag("runtime·morestack not defined");

src/cmd/ld/lib.c: void libinit(void)
sprint(INITENTRY, "_rt0_%s_%s", goarch, goos);

If you can address these two, I think you can use 8l without the runtime.

Re: [9fans] More on the GO toolchain

[lucio]

> If you can address these two, I think you can use 8l without the runtime.

I did: the -E option allows me to define an entry point other than
_rt0_386_plan9 (if memory serves), which is helpful, but
"runtime·morestack" (how does one compose that "dot" on the
conventional Plan 9 keyboard?) is taking back seat to fixing the
TEXT/GLOBL problem I am battling with now.  But the outlook for making
the GO toolchain compatible with Plan 9 is pretty good at this stage.

++L

Re: [9fans] More on the GO toolchain

[erik quanstrom]

> "runtime·morestack" (how does one compose that "dot" on the
> conventional Plan 9 keyboard?)

compose+..

- erik

Re: [9fans] More on the GO toolchain

[lucio]

> Perhaps the go 8l is not honoring the "-l " option?  I just tried to
> create a mbr from assembly and it reported the same runtime
> requirements.  A diff between the various sources might be useful since
> they are similar.

It was easy enough to turn that off, I'm not sure how to do it
selectively and at the same time retain portability across both
architectures and target purposes (Plan 9, GO and also Inferno - this
last I have not given any attention to yet).

++L