[9fans] Plan 9 port of the Go toolchain

[9fans] Plan 9 port of the Go toolchain

[Lucio De Re]

.../src/cmd/8a/asm.c, around line #900:

		/* This null SHdr must appear before all others */
		sh = newElfShdr(elfstr[ElfStrEmpty]);

My guess is that this needs to be followed by an instruction to write
out the header, which in fact does not take place.

I will not be able to test this until a number of other
inconsistencies have been addressed, so if anyone knows whether this
code could in fact be dropped, I'd appreciate not having to figure it
out myself.

The full diffs to asm.c look like this:

	308c308
	< archreloc(Reloc *r, Sym *s, vlong *val)
	---
	> archreloc(Reloc *r, Sym *, vlong *val)
	647c647
	< 	uint32 va, fo, w, symo, startva, machlink;
	---
	> 	uint32 symo, startva, machlink;
	779d778
	< 		lputl(0);			/* x */
	895d893
	< 		fo = HEADR;
	897,901d894
	< 		va = startva + fo;
	< 		w = segtext.filelen;
	<
	< 		/* This null SHdr must appear before all others */
	< 		sh = newElfShdr(elfstr[ElfStrEmpty]);
	1217c1210
	< 		Bprint(&bso, "symsize = %ud\n", symsize);
	---
	> 		Bprint(&bso, "symsize = %uld\n", symsize);

Comments are welcome.  And, no, I don't plan to publish each set of
changes, I just would like anyone who cares to know that I'm embarking
on this and to make as many suggestions as they deem necessary.

++L

Re: [9fans] Plan 9 port of the Go toolchain

[Russ Cox]

> .../src/cmd/8a/asm.c, around line #900:
>
>                /* This null SHdr must appear before all others */
>                sh = newElfShdr(elfstr[ElfStrEmpty]);
>
> My guess is that this needs to be followed by an instruction to write
> out the header, which in fact does not take place.

The code is corect.  newElfShdr updates a global table.
You can delete the "sh = " but not the whole line.

>        308c308
>        < archreloc(Reloc *r, Sym *s, vlong *val)
>        ---
>        > archreloc(Reloc *r, Sym *, vlong *val)

If you insert USED(s) as a statement in the body of the
function, we can take back the change.

Russ

Re: [9fans] Plan 9 port of the Go toolchain

[Lucio De Re]

>> PS: I still can't link an executable with the version of 8l from the
>> Go toolchain that I built under Plan 9, but I'm hoping to get there
>> soon.
> 
> It's of some consolation to me that I see exactly the same results
> under Ubuntu, so that particular problem isn't in the 8l executable
> created for Plan 9.  I may have something exciting to report on this
> issue within the day.
> 
Having rebuilt a copy of runtime.a as well as of "hell-o.8", I now
have an executable created from "hell-o.go" that runs sucessfully
under Plan 9 after having been linked with an "8l" from the Go
toolchain built entirely under Plan 9.  If I were any good with
picture I'd try to make the above easier to visualise.

It seems to me that, contrary to Pavel's careful statement, '8g"
itself is not agnostic regarding the "GOOS=plan9" environment
variable: I'll stick out my neck and claim without sufficient
investigation that (a) the object code is flagged with the
architecture name and (b) that the module functions init() and main()
are labelled with a period (main.main) versus with the Go-special
mid-line dot (middle-dot or UTF-00b7 as in "main·main") in Linux and
Plan 9 respectively.

I would like to upload the modified Go toolchain source code I used to
produce "8l" under Plan 9 to "sources", but I'll wait to find that
there is some interest as well as suggestions on the best approach to
submit these sources to review and testing by others.  I have
everything at hand to reproduce these sources, but some help will be
needed to tie up any lose ends from outside the Go toolchain sources.

And, once again, many thanks to Pavel (and the Go Authors, of course)
for making this possible and assisting with it.  My next task will be
to make similar changes to "8a", "8c" and "8g" to complete the series
of 386 tools.  But I also want to submit the changes in "src/cmd/8l"
and "src/cmd/ld" to the Go Authors for inclusion in future releases,
but that isn't going to be a trouble-free request, the changes have
been rather pervasive.

++L

Re: [9fans] Plan 9 port of the Go toolchain

[Lucio De Re]

> PS: I still can't link an executable with the version of 8l from the
> Go toolchain that I built under Plan 9, but I'm hoping to get there
> soon.

It's of some consolation to me that I see exactly the same results
under Ubuntu, so that particular problem isn't in the 8l executable
created for Plan 9.  I may have something exciting to report on this
issue within the day.

++L

[9fans] Plan 9 port of the Go toolchain

[Lucio De Re]

I have tweaked the Plan 9 native <ar.h> to allow for manual adjustment
around the different needs of Go and native Plan 9 toolchains, so now:

	#ifndef	SARNAME
	#define SARNAME	16
	#endif

SARNAME can be predefined to the "64" that Go prefers.  Unfortunately,
it's a short term solution, I'm hoping for suggestions on the way
forward from here.

++L

PS: I still can't link an executable with the version of 8l from the
Go toolchain that I built under Plan 9, but I'm hoping to get there
soon.