Re: [9fans] Go Plan 9

Re: [9fans] Go Plan 9

[Pavel Zholkover]

[-- Attachment #1: Type: text/plain, Size: 564 bytes --]

The mainline go will not compile syscall after the last post-weekly tag due
to the mmap support.
Russ wrote he'll look into it next week.

I try to maintain the bitbucket patch que with CLs still being reviewed
(Anthony's time changes for example) so people can test them as a whole.

There is no need for two different GOBINs, the same 8g/8l you built for eg.
Linux are able to produce Linux ELFs and Plan 9 a.out simply by changing to
GOOS environment variable.

Pavel
On Apr 9, 2011 9:26 PM, "Skip Tavakkolian" <skip.tavakkolian@gmail.com>
wrote:

[-- Attachment #2: Type: text/html, Size: 711 bytes --]

Re: [9fans] Go Plan 9

[Skip Tavakkolian]

Great info! thanks.
-Skip

On Sat, Apr 9, 2011 at 11:53 AM, Pavel Zholkover <paulzhol@gmail.com> wrote:
> The mainline go will not compile syscall after the last post-weekly tag due
> to the mmap support.
> Russ wrote he'll look into it next week.
>
> I try to maintain the bitbucket patch que with CLs still being reviewed
> (Anthony's time changes for example) so people can test them as a whole.
>
> There is no need for two different GOBINs, the same 8g/8l you built for eg.
> Linux are able to produce Linux ELFs and Plan 9 a.out simply by changing to
> GOOS environment variable.
>
> Pavel
>
> On Apr 9, 2011 9:26 PM, "Skip Tavakkolian" <skip.tavakkolian@gmail.com>
> wrote:
>

[9fans] Go Plan 9

[Pavel Zholkover]

Sorry, Skip was right.. It looks like make install in src/pkg will
also build and overwrite some of the cmd tools already in your GOBIN
with Plan 9 a.out. This is probably not what you were looking for.
The new build incantation is:

cd $GOROOT/src/pkg
make clean
mkdir -p $GROOT/bin/plan9
GOOS=plan9 GOBIN=$GOROOT/bin/plan9 make -k install

Pavel

On Sat, Apr 9, 2011 at 10:04 PM, Skip Tavakkolian
<skip.tavakkolian@gmail.com> wrote:
> Great info! thanks.
> -Skip
>
> On Sat, Apr 9, 2011 at 11:53 AM, Pavel Zholkover <paulzhol@gmail.com> wrote:
>> The mainline go will not compile syscall after the last post-weekly tag due
>> to the mmap support.
>> Russ wrote he'll look into it next week.
>>
>> I try to maintain the bitbucket patch que with CLs still being reviewed
>> (Anthony's time changes for example) so people can test them as a whole.
>>
>> There is no need for two different GOBINs, the same 8g/8l you built for eg.
>> Linux are able to produce Linux ELFs and Plan 9 a.out simply by changing to
>> GOOS environment variable.
>>
>> Pavel
>>
>> On Apr 9, 2011 9:26 PM, "Skip Tavakkolian" <skip.tavakkolian@gmail.com>
>> wrote:
>>
>

Re: [9fans] Go Plan 9

[Lucio De Re]

> The new build incantation is:
>
> cd $GOROOT/src/pkg
> make clean
> mkdir -p $GROOT/bin/plan9
> GOOS=plan9 GOBIN=$GOROOT/bin/plan9 make -k install

I won't try this until the mmap problem you refer to is resolved, so a
question is in order: are the plan 9 tools essential to the operation
of 8l with GOOS=plan9 and will they be found by default or will one
need to make sure that the PATH is set to find them ahead of the Linux
ones?

Wait.  You are talking about a.out executables, these are specifically
for the Plan 9 environment, aren't they?  I guess I need to look for
myself :-)

Alternatively, is it sufficient to specify a different GOBIN or does
the PATH need to be changed?  I think I know the answer to this
question is that the PATH needs changing, but I am normally wrong in
these matters.

++L

Re: [9fans] Go Plan 9

[Pavel Zholkover]

The following executables are installed into $GOROOT/bin as Plan 9
a.out binaries when you run make -k install inside src/pkg:
cgo, ebnflint, gofix, gofmt, gotest, gotype, govet, goyacc, hgpatch.
They should be directed somewhere else by setting GOBIN, there is no
need to include them in your PATH, the host's native executables are
already in place after you build Go.

There is a temporary fix to the mmap issue with pkg syscall in my
patch queue, it just moves the mmap staff over to syscall_unix.go.

Pavel

On Sun, Apr 10, 2011 at 8:07 AM, Lucio De Re <lucio@proxima.alt.za> wrote:
>> The new build incantation is:
>>
>> cd $GOROOT/src/pkg
>> make clean
>> mkdir -p $GROOT/bin/plan9
>> GOOS=plan9 GOBIN=$GOROOT/bin/plan9 make -k install
>
> I won't try this until the mmap problem you refer to is resolved, so a
> question is in order: are the plan 9 tools essential to the operation
> of 8l with GOOS=plan9 and will they be found by default or will one
> need to make sure that the PATH is set to find them ahead of the Linux
> ones?
>
> Wait.  You are talking about a.out executables, these are specifically
> for the Plan 9 environment, aren't they?  I guess I need to look for
> myself :-)
>
> Alternatively, is it sufficient to specify a different GOBIN or does
> the PATH need to be changed?  I think I know the answer to this
> question is that the PATH needs changing, but I am normally wrong in
> these matters.
>
> ++L
>
>
>

Re: [9fans] Go Plan 9

[Lucio De Re]

> The following executables are installed into $GOROOT/bin as Plan 9
> a.out binaries when you run make -k install inside src/pkg:
> cgo, ebnflint, gofix, gofmt, gotest, gotype, govet, goyacc, hgpatch.
> They should be directed somewhere else by setting GOBIN, there is no
> need to include them in your PATH, the host's native executables are
> already in place after you build Go.

OK, I think I got it.  These belong on the Plan 9 platform where it is
easy to

	bind -a .../bin/plan9 /bin

to access them.  Thanks for clarifying this for me: as I have
nentioned more than once, getting my mind around all the permutations
of toolchains, tools, platforms, architectures and targets isn't easy.

++L

PS: So far I have had no joy building any of them, but that will get
fixed :-)

Re: [9fans] Go Plan 9

[Joel C. Salomon]

On Tuesday, April 5, 2011 1:33:30 PM UTC-4, David  Leimbach wrote:
> What we need is an OS port of Plan 9 to Go that can run hosted on another OS or natively.
>
> InfernGo?

Fuego.

--Joel

Re: [9fans] Go Plan 9

[David Leimbach]

Sent from my iPhone

On Apr 6, 2011, at 1:27 PM, "Joel C. Salomon" <joelcsalomon@gmail.com> wrote:

> On Tuesday, April 5, 2011 1:33:30 PM UTC-4, David  Leimbach wrote:
>> What we need is an OS port of Plan 9 to Go that can run hosted on another OS or natively.
>> 
>> InfernGo?
> 
> Fuego.
> 

+9!

> --Joel
> 

Re: [9fans] Go Plan 9

[Jason Catena]

leimy2k@gmail.com:
> rsc@swtch.com:
>> What we need is an OS port of Plan 9 to Go that can run hosted on another OS or natively.
> InfernGo?

Seconded, or at least Acme SAC-n-Go.  I'd rather use Go than Limbo,
and I'd much rather only compile Go executables once.

Jason Catena

Re: [9fans] Go Plan 9

[Russ Cox]

[Sorry for being quiet, I got unsubscribed from 9fans!]

> no, the shared libraries are not going to affect the heap size.
> Certainly not to this scale.
>
> My understanding was that Go used this large sparse address space to
> effect for its garbage collection; the fact that it is backed by mmap
> of anonymous memory is what makes it work, since pages are not
> allocated until touched. Russ?

The large sparse address space is nice on 64-bit
because you can do some address calculation tricks.
On 32-bit it just doesn't matter.  I think the current
code in package runtime is correct already for Plan 9.

Russ

[9fans] Go Plan 9

[Pavel Zholkover]

What about the old gcc3 port? Is it enough for bootstrapping the compilers?
On Apr 3, 2011 7:28 PM, "Skip Tavakkolian" <skip.tavakkolian at gmail.com>
wrote:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.9fans.net/private/9fans/attachments/20110403/08629d92/attachment.html>

[9fans] Go Plan 9

[Lucio De Re]

On Sun, Apr 03, 2011 at 07:49:06PM +0300, Pavel Zholkover wrote:
> What about the old gcc3 port? Is it enough for bootstrapping the compilers?
> On Apr 3, 2011 7:28 PM, "Skip Tavakkolian" <skip.tavakkolian at gmail.com>
> wrote:

You'd perpetuate an alien binary format, which sounds like a bad idea
to me.  But I'm so muddled up with all the options, I can't really find
my way out of that paperbag.  So perhaps somebody can pick up where Erik
and I independently left off and make something out of it.  I keep trying,
but it keeps getting more and more complicated, at least to me.

I'm happy to donate all the mkfiles I strung together, but even those
may need major surgery.

++L

[9fans] Go Plan 9

[Pavel Zholkover]

On Apr 3, 2011 12:18 PM, "erik quanstrom" <quanstro at quanstro.net> wrote:
> okay, i volunteer.  just to make sure, we're talking
> about a plan 9 port, not a cross compile?
>
> just let me know what i need to get set up.  i can
> easily do 386 and arm at this point.
>
> - erik
>
I think Rob meant it would be a cross compile,  at least at first.

Could you comment on your changes at http://code.google.com/p/go-plan9/ ?
Can they be pushed to mainline ?

Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.9fans.net/private/9fans/attachments/20110403/b93fd547/attachment.html>

[9fans] Go Plan 9

[erik quanstrom]

> Could you comment on your changes at http://code.google.com/p/go-plan9/ ?
> Can they be pushed to mainline ?

i don't think they can in total.  we should push the silly
print format fixes and the added USED() that 8c caught
and gcc didn't.

but there definately are some difficult bits.  this hacked
inclusion of stdio.h is a problem on plan 9.

http://code.google.com/p/go-plan9/source/diff?spec=svnd6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851&r=d6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851&format=side&path=/src/cmd/8a/a.y

my "solution" clearly ignored the problems in pushing
back to the main line.  but at least we have the problem identified.

/src/cmd/8l/l.h has another problem.  we need to figure
out how to get the definitions for uint8, etc from "#include <u.h>"
the defines i put in are just wrong, but the alternative is passing in -Isomedir
with a <u.h> that includes the real u.h and then tweaks other stuff.
that's just wronger.  :-)

a real solution would be one of
0  copy u.h; hack to taste
1  add the hacks to the real u.h
2  come to a concensus with go about what the defined-bit-width
types should be called.  change both plan 9 and go to conform.

i'd vote for 2.  it's harder that way, but i'd hate for go to
feel like it was pasted on.  but i'd like to know what everyone
else thinks.

- erik

[9fans] Go Plan 9

[Lucio De Re]

On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
> 
> a real solution would be one of
> 0  copy u.h; hack to taste
> 1  add the hacks to the real u.h
> 2  come to a concensus with go about what the defined-bit-width
> types should be called.  change both plan 9 and go to conform.
> 
> i'd vote for 2.  it's harder that way, but i'd hate for go to
> feel like it was pasted on.  but i'd like to know what everyone
> else thinks.
> 
I don't think anything comes near to 2 as a solution.  And it really
isn't all that invasive either.  Add my vote to yours.

++L

[9fans] Go Plan 9

[Lucio De Re]

On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
> 
> but there definately are some difficult bits.  this hacked
> inclusion of stdio.h is a problem on plan 9.
> 
> http://code.google.com/p/go-plan9/source/diff?spec=svnd6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851&r=d6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851&format=side&path=/src/cmd/8a/a.y
> 
As GNU says, GNU is not Unix (or Plan 9).  There is no #ifdef-free
way to satisfy both toolchains unless one wants to pervert the Plan 9
toolchain.  One trivial change to GCC, namely Plan 9's use of empty names
to represent unused arguments, would improve GCC greatly, but is unlikely
to be accepted by the developers.  The alternative is a pain in the butt.

But I agree with Erik, the changes to port the Go toolchain to Plan 9
are quite extensive and would require a great deal of care, I have done
a similar job a year ago.  Actually, I think it was two years agon and
I failed to resurrect my efforts a year later.

I'm not sure whether the compiler, assembler and linker that seemed
to work after my first attempts could be used to bootstrap a fresh
source tree.  I put no effort in place on the Go package side, so that
remains to be tried.

In passing, Erik, you made some changes to Yacc to accept //-comments,
do you still have those at hand?  Do you have some idea why they were
not applied to P9 Yacc?

++L

[9fans] Go Plan 9

[erik quanstrom]

> As GNU says, GNU is not Unix (or Plan 9).  There is no #ifdef-free
> way to satisfy both toolchains unless one wants to pervert the Plan 9
> toolchain.  One trivial change to GCC, namely Plan 9's use of empty names
> to represent unused arguments, would improve GCC greatly, but is unlikely
> to be accepted by the developers.  The alternative is a pain in the butt.

a sed script in the plan9-specific could do the trick.  ideally, though,
the go source wouldn't redefine getc(), and the include could no longer
be necessary.  i've seen go define cget in other places, that might be a
solution; but i don't know the local customs well.

> In passing, Erik, you made some changes to Yacc to accept //-comments,
> do you still have those at hand?  Do you have some idea why they were
> not applied to P9 Yacc?

they have been applied.  thanks to geoff for integrating the
change: /n/sources/patch/applied/yacccmt

- erik

[9fans] Go Plan 9

[Skip Tavakkolian]

Why can't we use linuxemu to run the build?

-Skip

On Apr 3, 2011, at 8:43 AM, erik quanstrom <quanstro at quanstro.net> wrote:

>> As GNU says, GNU is not Unix (or Plan 9).  There is no #ifdef-free
>> way to satisfy both toolchains unless one wants to pervert the Plan 9
>> toolchain.  One trivial change to GCC, namely Plan 9's use of empty names
>> to represent unused arguments, would improve GCC greatly, but is unlikely
>> to be accepted by the developers.  The alternative is a pain in the butt.
> 
> a sed script in the plan9-specific could do the trick.  ideally, though,
> the go source wouldn't redefine getc(), and the include could no longer
> be necessary.  i've seen go define cget in other places, that might be a
> solution; but i don't know the local customs well.
> 
>> In passing, Erik, you made some changes to Yacc to accept //-comments,
>> do you still have those at hand?  Do you have some idea why they were
>> not applied to P9 Yacc?
> 
> they have been applied.  thanks to geoff for integrating the
> change: /n/sources/patch/applied/yacccmt
> 
> - erik
> 

[9fans] Go Plan 9

[erik quanstrom]

On Sun Apr  3 12:27:29 EDT 2011, skip.tavakkolian at gmail.com wrote:
> Why can't we use linuxemu to run the build?
> 

sure we could,  but then you have to maintain linuxemu, and
go.  that seems silly.

> Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...

what does gcc have to do with getting go compiled on plan 9?

- erik

Re: [9fans] Go Plan 9

[Skip Tavakkolian]

the point is that if the linuxemu is provisioned properly (gmake, gcc,
bash) to build the Plan 9 $GOBIN from source, then there wont be a
need for a linux build box, or porting and maintaining gmake, gcc,
bash, etc. one could also build Plan 9 binaries under linuxemu.

options as i see them are:

1. a linux build environment for Go which is also a partial dev
environment (i.e. where 8g and 8l will run)
2. port (and maintain) all gnu tools needed to build Go from sources
under Plan 9
3. a linuxemu build environment that is complete enough to compile Go
and serve as Go compilation environment

-Skip

On Sun, Apr 3, 2011 at 10:46 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Sun Apr  3 12:27:29 EDT 2011, skip.tavakkolian@gmail.com wrote:
>> Why can't we use linuxemu to run the build?
>>
>
> sure we could,  but then you have to maintain linuxemu, and
> go.  that seems silly.
>
> - erik
>
>

[9fans] Go Plan 9

[Devon H. O'Dell]

Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...
On Apr 3, 2011 11:26 AM, "Lucio De Re" <lucio at proxima.alt.za> wrote:
> On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
>>
>> but there definately are some difficult bits. this hacked
>> inclusion of stdio.h is a problem on plan 9.
>>
>>
http://code.google.com/p/go-plan9/source/diff?spec=svnd6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851&r=d6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851&format=side&path=/src/cmd/8a/a.y
>>
> As GNU says, GNU is not Unix (or Plan 9). There is no #ifdef-free
> way to satisfy both toolchains unless one wants to pervert the Plan 9
> toolchain. One trivial change to GCC, namely Plan 9's use of empty names
> to represent unused arguments, would improve GCC greatly, but is unlikely
> to be accepted by the developers. The alternative is a pain in the butt.
>
> But I agree with Erik, the changes to port the Go toolchain to Plan 9
> are quite extensive and would require a great deal of care, I have done
> a similar job a year ago. Actually, I think it was two years agon and
> I failed to resurrect my efforts a year later.
>
> I'm not sure whether the compiler, assembler and linker that seemed
> to work after my first attempts could be used to bootstrap a fresh
> source tree. I put no effort in place on the Go package side, so that
> remains to be tried.
>
> In passing, Erik, you made some changes to Yacc to accept //-comments,
> do you still have those at hand? Do you have some idea why they were
> not applied to P9 Yacc?
>
> ++L
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.9fans.net/private/9fans/attachments/20110403/197a21f4/attachment-0001.html>

[9fans] Go Plan 9

[Lucio De Re]

On Sun, Apr 03, 2011 at 01:43:53PM -0400, Devon H. O'Dell wrote:
> 
> Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...

That would be great.  I don't even pretend to keep track of what the GCC
group does, I guess I owe you thanks for correcting me.  If that's how one
goes about finding these things out, well, it's not pretty, but it works.

And in passing that grants me the option to drop unwanted argument names
in the Go sources, but will the Go developers follow suit?  Have they
already done so?  I think I have enough evidence to track down most if
not all instances.

++L

[9fans] Go Plan 9

[Rob Pike]

I'm not sure I follow.  The 6c and 6g compilers in the Go distribution
are compiled with the local compiler, such as gcc on Linux and OS X.
I don't believe it's possible they have Plan 9-specific features in
their source.  I can believe they would have problems compiling on
Plan 9, but that's the inverse problem.

Once 6c is built, it is used to build the Go runtime, so the source
and compiler should match perfectly.  Plan 9 compiler issues should
not be relevant.

-rob

[9fans] Go Plan 9

[Lucio De Re]

On Sun, Apr 03, 2011 at 11:20:25AM -0700, Rob Pike wrote:
> 
> I'm not sure I follow.  The 6c and 6g compilers in the Go distribution
> are compiled with the local compiler, such as gcc on Linux and OS X.
> I don't believe it's possible they have Plan 9-specific features in
> their source.  I can believe they would have problems compiling on
> Plan 9, but that's the inverse problem.
> 
On the contrary (if that makes sense), they have that nasty "#include
<stdio.h>" that Erik referred to and Plan 9 is allergic to, as well as a
number of nested #includes that trigger rebellion in the Plan 9 toolchain.
And I don't have a 64-bit host to test them on.

But do not forget that I have a Plan 9 native toolchain that compiles
a runnable copy of "hello.c", including printf() invocation. It's just
too old to be useful.

> Once 6c is built, it is used to build the Go runtime, so the source
> and compiler should match perfectly.  Plan 9 compiler issues should
> not be relevant.
> 
I haven't even considered using the toolchain for Plan 9 native because
I can't track releases given the many changes required to silence the
Plan 9 toolchain.  And maybe some warnings can be overlooked, but I
don't want to be the judge of that.

Basically, I can't find an approach to submitting changes to the Go
toolchain so it can run under Plan 9 that does not involve major surgery,
nor can I separate the changes out in small parcels because testing
is impractical.  I'm hoping that things will eventually settle down and
there will be resources to review extensive, if documentable changes.
Not being able to back-port the Go toolchain to Plan 9 native seems
defeatist.  Now that a runtime is available and will hopefully receive
extensive testing, it makes the exercise even more worthwhile.

And if issues such as compatibility in function argument definitions can
be resolved amicably between the GCC compiler and the Plan 9 toolchain,
then things are really looking up.  But, as I stated earlier, it requires
the will on the Go side to retrofit changes for the sake of Plan 9, and
that may be a problem.  My failed efforts (possibly thoroughly misguided)
to get l.h accepted with changes acceptable to the Plan 9 built-in
pre-processor suggest that the Go developers have different objectives
in mind.

If this does not address Rob's concerns, then I'd like to ask for the
question(s) to be phrased more clearly.

And again, I think one ought to look at all the "Plan 9" favours out
there: 9vx deserves effort, Plan9port could support Go better than the
native environment, linuxemu would provide a useful testbench.  Only GCC
3.0 in Plan 9 is almost certainly a dead end.

++L

[9fans] Go Plan 9

[Pavel Zholkover]

Hi all!

Rob just committed my syscall and os Plan 9 patches into mainline.

The produced binaries do not run properly on 9vx since the last gc changes
so its native or kvm+qemu etc.

Please test :)

Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.9fans.net/private/9fans/attachments/20110403/4bc0c20b/attachment.html>

[9fans] Go Plan 9

[andrey mirtchovski]

Congratulations on the hard work and thanks for seeing this through!

[9fans] Go Plan 9

[David Leimbach]

So wait... We can get the toolchain built on plan 9. Or we can target plan 9 via cross compiler?  Either way is pretty awesome!  Nice work!

Sent from my iPhone

On Apr 2, 2011, at 4:00 PM, andrey mirtchovski <mirtchovski at gmail.com> wrote:

> Congratulations on the hard work and thanks for seeing this through!
> 

[9fans] Go Plan 9

[ron minnich]

On Sat, Apr 2, 2011 at 4:52 PM, David Leimbach <leimy2k at gmail.com> wrote:
> So wait... We can get the toolchain built on plan 9. Or we can target plan 9 via cross compiler? ?Either way is pretty awesome! ?Nice work!

I'm trying a cross-build now

ron

[9fans] Go Plan 9

[ron minnich]

On Sat, Apr 2, 2011 at 5:04 PM, ron minnich <rminnich at gmail.com> wrote:
> On Sat, Apr 2, 2011 at 4:52 PM, David Leimbach <leimy2k at gmail.com> wrote:
>> So wait... We can get the toolchain built on plan 9. Or we can target plan 9 via cross compiler? ?Either way is pretty awesome! ?Nice work!
>
> I'm trying a cross-build now

i.e. I set GOOS to plan9 and it has not complained.

ron

[9fans] Go Plan 9

[ron minnich]

Things went badly here:

8g -o _go_.8 exp.go normal.go rand.go rng.go zipf.go
gopack grc _obj/hash/crc32.a _go_.8
match.go:45: undefined: Separator
match.go:62: undefined: Separator
match.go:160: undefined: Separator
match.go:227: undefined: Separator
path.go:18: undefined: Separator
path.go:19: undefined: ListSeparator
path.go:45: undefined: IsAbs
path.go:52: undefined: volumeName
path.go:58: undefined: Separator
path.go:64: undefined: isSeparator
path.go:64: too many errors
make[1]: *** [_go_.8] Error 1
make[1]: Leaving directory
`/home/rminnich/src/9vx-0.12/usr/rminnich/go/src/pkg/path/filepath'
make: *** [path/filepath.install] Error 2
make: *** Waiting for unfinished jobs....

Ubuntu 10.04.2 LTS \n \l

[9fans] Go Plan 9

[andrey mirtchovski]

http://codereview.appspot.com/4316054

:)

[9fans] Go Plan 9

[andrey mirtchovski]

cross-compilation (GOOS=plan9, GOARCH=386, link with -s), but there
are a few issues -- the build fails at crypto, so fmt is not compiled.
for a hello world you need to manually make install pkg/strconv and
pkg/reflect and pkg/fmt.

[9fans] Go Plan 9

[Pavel Zholkover]

On Sun, Apr 3, 2011 at 2:52 AM, David Leimbach <leimy2k at gmail.com> wrote:
> So wait... We can get the toolchain built on plan 9. Or we can target plan 9 via cross compiler? ?Either way is pretty awesome! ?Nice work!

We are cross-compiling unless someone syncs
http://code.google.com/p/go-plan9/ with mainline.

Pavel

[9fans] Go Plan 9

[Skip Tavakkolian]

Thank you!

FYI, I'm building on Ubungo 10.10, I'm getting several packages that
aren't building (io/ioutil, tabwriter, time - so far); most seem to be
lack of or conflict in definitions in os.* and syscall.*. Is this
expected?

This just gave me more ammunition to convince some Seattle Gophers
that Plan 9 is NOT dead.

-Skip

On Sat, Apr 2, 2011 at 3:56 PM, Pavel Zholkover <paulzhol at gmail.com> wrote:
> Hi all!
>
> Rob just committed my syscall and os Plan 9 patches into mainline.
>
> The produced binaries do not run properly on 9vx since the last gc changes
> so its native or kvm+qemu etc.
>
> Please test :)
>
> Pavel

[9fans] Go Plan 9

[Rob Pike]

We'll get the Plan 9 implementation up to scratch. It's not there yet,
though.  Once things look solid we'll need a volunteer to set up a
builder so we can automatically make sure the Plan 9 port stays
current.

-rob

[9fans] Go Plan 9

[Lucio De Re]

On Sat, Apr 02, 2011 at 07:48:14PM -0700, Rob Pike wrote:
> 
> We'll get the Plan 9 implementation up to scratch. It's not there yet,
> though.  Once things look solid we'll need a volunteer to set up a
> builder so we can automatically make sure the Plan 9 port stays
> current.
> 
That's code for "we'll have a build under Linux for the Plan 9
cross-development system" or "we'll have a Plan 9 port of Go?"

I've been thinking, besides my now very dated efforts to port the Go
toolchain to Plan 9 native, that there may be merit in an intermediate
port of the C and Go toolchains to p9p.  But combining the build
environments looked pretty complicated.  I did try, but I got lost
trying to keep the three build environments (Linux, Plan 9 and p9p)
in my head at the same time.

Still, there may be somebody out there who can get this done better than
I would.

++L

[9fans] Go Plan 9

[Steve Simon]

A month or so ago I got the go compiler chain to build on plan9,
port is too grand a term, it was just fixing a few nits.

I wrote mkfiles and fixed a few minor bugs. The bigest problem was my knowledge
of yacc was not sufficent to rework the error generation magic go uses from
the bison based code to plan9 yacc code. perhaps there is a yacc expert out there
who would be interested in helping?

I am happy to push back my changes, but without either getting yacc to work, or,
abandoning yacc and porting bison, I didn't feel it was ready.

-Steve

[9fans] Go Plan 9

[Lucio De Re]

On Sun, Apr 03, 2011 at 07:50:20PM +0100, Steve Simon wrote:
> 
> A month or so ago I got the go compiler chain to build on plan9,
> port is too grand a term, it was just fixing a few nits.
> 
That makes a third version.  I seem to remember Erik's version compiled clean and I have to ask Steve now whether his version actually generates Plna 9 executables.  And, for that matter, how far the Go portion reached.

The version I have restricts itself to C, but has libraries generated using the Go toolchain and has produced one non-trivial object code that ran successfully.  Regarding the Go compiler and runtime, I seem to remember that gc.a was created, but nothing else.

> I wrote mkfiles and fixed a few minor bugs. The bigest problem was my knowledge
> of yacc was not sufficent to rework the error generation magic go uses from
> the bison based code to plan9 yacc code. perhaps there is a yacc expert out there
> who would be interested in helping?
> 
When I looked at the Go sources, no such magic stood out, but it's a
long time ago and I may have ignored the problem intentionally.

> I am happy to push back my changes, but without either getting yacc to work, or,
> abandoning yacc and porting bison, I didn't feel it was ready.
> 
Maybe Erik, Steve and I should consolidate our changes into a single batch
and submit it as a unit, knowing that it will have received at least some
competent code review.  Anybody else who may want to contribute would,
in my view, be welcome.  Reviewing code intended for Plan 9 cannot be
terribly high within the Google framework at this point in time.

++L

[9fans] Go Plan 9

[Pavel Zholkover]

I've set up a Mercurial patch queue with some instructions on building
at https://bitbucket.org/paulzhol/golang-plan9-runtime-patches/
with Andrey and Taru's patches. I'll try to keep it updated :)

Pavel

[9fans] Go Plan 9

[andrey mirtchovski]

my paatch is not correct. i've "fixed" it here, but i'd love to be
able to get a gotest binary to run on plan9 to make sure my fix is
right.

On Sun, Apr 3, 2011 at 1:45 AM, Pavel Zholkover <paulzhol at gmail.com> wrote:
> I've set up a Mercurial patch queue with some instructions on building
> at https://bitbucket.org/paulzhol/golang-plan9-runtime-patches/
> with Andrey and Taru's patches. I'll try to keep it updated :)
>
> Pavel
>
>

[9fans] Go Plan 9

[erik quanstrom]

On Sat Apr  2 22:49:25 EDT 2011, robpike at gmail.com wrote:
> We'll get the Plan 9 implementation up to scratch. It's not there yet,
> though.  Once things look solid we'll need a volunteer to set up a
> builder so we can automatically make sure the Plan 9 port stays
> current.

okay, i volunteer.  just to make sure, we're talking
about a plan 9 port, not a cross compile?

just let me know what i need to get set up.  i can
easily do 386 and arm at this point.

- erik

[9fans] Go Plan 9

[Anthony Martin]

andrey mirtchovski <mirtchovski at gmail.com> once said:
> cross-compilation (GOOS=plan9, GOARCH=386, link with -s), but there
> are a few issues -- the build fails at crypto, so fmt is not compiled.
> for a hello world you need to manually make install pkg/strconv and
> pkg/reflect and pkg/fmt.

Everything works fine for me without the '-s' flag.

Pavel Zholkover <paulzhol at gmail.com> once said:
> The produced binaries do not run properly on 9vx since the last gc
> changes so its native or kvm+qemu etc.

The reason it doesn't work on 9vx is because the 32 bit Go runtime
reserves a large chunk of address space (currently 768mb).  On all
other platforms, this is accomplised with an mmap equivalient, which
we all know won't work on Plan 9.

Right now, if you want to run Go binaries on Plan 9, you have to 
apply the patch at the bottom of this message.  In the future we
should probably have the runtime use the segment(3) device.

  Anthony


diff -r 11611373ac8a src/pkg/runtime/malloc.goc
--- a/src/pkg/runtime/malloc.goc	Sun Apr 03 09:11:41 2011 -0700
+++ b/src/pkg/runtime/malloc.goc	Sun Apr 03 14:00:13 2011 -0700
@@ -231,7 +231,7 @@
 
 int32 runtime?sizeof_C_MStats = sizeof(MStats);
 
-#define MaxArena32 (2U<<30)
+#define MaxArena32 (240U<<20)
 
 void
 runtime?mallocinit(void)
@@ -292,7 +292,7 @@
 		// kernel threw at us, but normally that's a waste of 512 MB
 		// of address space, which is probably too much in a 32-bit world.
 		bitmap_size = MaxArena32 / (sizeof(void*)*8/4);
-		arena_size = 512<<20;
+		arena_size = 64<<20;
 		
 		// SysReserve treats the address we ask for, end, as a hint,
 		// not as an absolute requirement.  If we ask for the end

[9fans] Go Plan 9

[Anthony Martin]

Anthony Martin <ality at pbrane.org> once said:
> Right now, if you want to run Go binaries on Plan 9, you have to 
> apply the patch at the bottom of this message.  In the future we
> should probably have the runtime use the segment(3) device.

That should have been '9vx' instead of 'Plan 9'. Sorry.

  Anthony

[9fans] Go Plan 9

[Pavel Zholkover]

I'm not sure I understand the reason 9vx will fail to reserve 768mb
with brk() while my Plan 9 install on kvm+qemu with 128mb or ram works
fine, as long as it is not written to.

The -s is no longer needed, 8l generates a.out symbols correctly.

Pavel

On Mon, Apr 4, 2011 at 12:16 AM, Anthony Martin <ality at pbrane.org> wrote:
> Anthony Martin <ality at pbrane.org> once said:
>> Right now, if you want to run Go binaries on Plan 9, you have to
>> apply the patch at the bottom of this message. ?In the future we
>> should probably have the runtime use the segment(3) device.
>
> That should have been '9vx' instead of 'Plan 9'. Sorry.
>
> ?Anthony
>
>

[9fans] Go Plan 9

[Anthony Martin]

Pavel Zholkover <paulzhol at gmail.com> once said:
> I'm not sure I understand the reason 9vx will fail to reserve 768mb
> with brk() while my Plan 9 install on kvm+qemu with 128mb or ram works
> fine, as long as it is not written to.

The reason is because 9vx gives user processes a virtual
address space of only 256mb.  The brk works but the
first time we fault one of those pages past USTKTOP the
program suicides.

The first fault happens at src/pkg/runtime/mcache.c:21
in the runtime?MCache_Alloc function.

To show you what I mean, here's a formatted stack trace:

term% cat y.go
package main

func main() {
	println("Hello, world.")
}

term% ./8.out
8.out 174: suicide: sys: trap: page fault pc=0x000021df

term% db 8.out 174
386 binary
page fault
/go/src/pkg/runtime/mcache.c:21 runtime.MCache_Alloc+39/	MOVL	0(AX),AX
$c
runtime.MCache_Alloc(sizeclass=0x1, c=0x30424000, size=0x8, zeroed=0x1)
	/go/src/pkg/runtime/mcache.c:13 called from runtime.mallocgc+db
	/go/src/pkg/runtime/malloc.goc:62
runtime.mallocgc(size=0x8, zeroed=0x1, flag=0x0, dogc=0x0)
	/go/src/pkg/runtime/malloc.goc:40 called from runtime.malloc+41
	/go/src/pkg/runtime/malloc.goc:115
runtime.malloc(size=0x1)
	/go/src/pkg/runtime/malloc.goc:113 called from runtime.mallocinit+e9
	/go/src/pkg/runtime/malloc.goc:319
runtime.mallocinit()
	/go/src/pkg/runtime/malloc.goc:237 called from runtime.schedinit+39
	/go/src/pkg/runtime/proc.c:122
runtime.schedinit()
	/go/src/pkg/runtime/proc.c:113 called from _rt0_386+b3
	/go/src/pkg/runtime/386/asm.s:78
_rt0_386()
	/go/src/pkg/runtime/386/asm.s:12 called from 1 


Cheers,
  Anthony

[9fans] Go Plan 9

[Pavel Zholkover]

Thanks for the detailed explanation, I've added your patch to if that
is alright with you https://bitbucket.org/paulzhol/golang-plan9-
runtime-patches/

Pavel

On Mon, Apr 4, 2011 at 1:30 AM, Anthony Martin <ality at pbrane.org> wrote:
> Pavel Zholkover <paulzhol at gmail.com> once said:
>> I'm not sure I understand the reason 9vx will fail to reserve 768mb
>> with brk() while my Plan 9 install on kvm+qemu with 128mb or ram works
>> fine, as long as it is not written to.
>
> The reason is because 9vx gives user processes a virtual
> address space of only 256mb. ?The brk works but the
> first time we fault one of those pages past USTKTOP the
> program suicides.
>
> The first fault happens at src/pkg/runtime/mcache.c:21
> in the runtime?MCache_Alloc function.
>
> To show you what I mean, here's a formatted stack trace:
>
> term% cat y.go
> package main
>
> func main() {
> ? ? ? ?println("Hello, world.")
> }
>
> term% ./8.out
> 8.out 174: suicide: sys: trap: page fault pc=0x000021df
>
> term% db 8.out 174
> 386 binary
> page fault
> /go/src/pkg/runtime/mcache.c:21 runtime.MCache_Alloc+39/ ? ? ? ?MOVL ? ?0(AX),AX
> $c
> runtime.MCache_Alloc(sizeclass=0x1, c=0x30424000, size=0x8, zeroed=0x1)
> ? ? ? ?/go/src/pkg/runtime/mcache.c:13 called from runtime.mallocgc+db
> ? ? ? ?/go/src/pkg/runtime/malloc.goc:62
> runtime.mallocgc(size=0x8, zeroed=0x1, flag=0x0, dogc=0x0)
> ? ? ? ?/go/src/pkg/runtime/malloc.goc:40 called from runtime.malloc+41
> ? ? ? ?/go/src/pkg/runtime/malloc.goc:115
> runtime.malloc(size=0x1)
> ? ? ? ?/go/src/pkg/runtime/malloc.goc:113 called from runtime.mallocinit+e9
> ? ? ? ?/go/src/pkg/runtime/malloc.goc:319
> runtime.mallocinit()
> ? ? ? ?/go/src/pkg/runtime/malloc.goc:237 called from runtime.schedinit+39
> ? ? ? ?/go/src/pkg/runtime/proc.c:122
> runtime.schedinit()
> ? ? ? ?/go/src/pkg/runtime/proc.c:113 called from _rt0_386+b3
> ? ? ? ?/go/src/pkg/runtime/386/asm.s:78
> _rt0_386()
> ? ? ? ?/go/src/pkg/runtime/386/asm.s:12 called from 1
>
>
> Cheers,
> ?Anthony
>
>

[9fans] Go Plan 9

[Lucio De Re]

On Mon, Apr 04, 2011 at 10:37:30AM +0300, Pavel Zholkover wrote:
> 
> Thanks for the detailed explanation, I've added your patch to if that
> is alright with you https://bitbucket.org/paulzhol/golang-plan9-
> runtime-patches/
> 
May I suggest that we identify Go executables, because they may not run
under 9vx, as different from Plan 9 executables and adjust the Plan 9
kernel to identify these and avoid running them under 9vx?

There will be changes to Plan 9 to match the Go toolchain, this one is
really small and could be seen as acceptance of Go as part of Plan 9's
future.  Ideally, when the Go runtime no longer needs special treatment
we can re-categorise Go executables as normal Plan 9 executables.
That option moves into the hands of the Go developers, which to me seems
like the right place.

The other one I would like to submit as a patch affects /386/include/u.h
(and other architectures), involving the addition of integer types of
various length.  Equally small and benign.

Opinions?

++L

PS: Would anybody like to summarise for us plebs whether there is any
convergence looming between Go and Plan 9 on the x64 front?  It seems
sad to miss a chance to add a peer-reviewed and thoroughly tested 64-bit
toolchain to Plan 9.

[9fans] Go Plan 9

[Pavel Zholkover]

On Mon, Apr 4, 2011 at 8:27 PM, Lucio De Re <lucio at proxima.alt.za> wrote:
> PS: Would anybody like to summarise for us plebs whether there is any
> convergence looming between Go and Plan 9 on the x64 front? ?It seems
> sad to miss a chance to add a peer-reviewed and thoroughly tested 64-bit
> toolchain to Plan 9.

the basic runtime support (not the current syscall and os changes)
involved changes to 8l and some C and 386 specific assembly in
pkg/runtime. I guess this could be re-done for 6l + x64 code in
runtime. The question is whether it is a useful application of
developers time at this stage (it would be still cross-compiled) and
the 386 runtime has not been properly tested.

Pavel

Re: [9fans] Go Plan 9

[Lucio De Re]

On Mon, Apr 04, 2011 at 10:18:12PM +0300, Pavel Zholkover wrote:
> On Mon, Apr 4, 2011 at 8:27 PM, Lucio De Re <lucio@proxima.alt.za> wrote:
> > PS: Would anybody like to summarise for us plebs whether there is any
> > convergence looming between Go and Plan 9 on the x64 front?  It seems
> > sad to miss a chance to add a peer-reviewed and thoroughly tested 64-bit
> > toolchain to Plan 9.
> 
> the basic runtime support (not the current syscall and os changes)
> involved changes to 8l and some C and 386 specific assembly in
> pkg/runtime. I guess this could be re-done for 6l + x64 code in
> runtime. The question is whether it is a useful application of
> developers time at this stage (it would be still cross-compiled) and
> the 386 runtime has not been properly tested.
> 
I agree that focussing on x64 when there isn't a working target would be
pointless, if intriguing.  I guess the question then belongs in the Plan
9 camp: are we going to see an x64 Plan 9 development soon?  and is the
availability of the 6? chain in the Go sources helpful in arriving there?

++L

Re: [9fans] Go Plan 9

[Lucio De Re]

On Mon, Apr 04, 2011 at 07:27:28PM +0200, Lucio De Re wrote:
> On Mon, Apr 04, 2011 at 10:37:30AM +0300, Pavel Zholkover wrote:
> >
> > Thanks for the detailed explanation, I've added your patch to if that
> > is alright with you https://bitbucket.org/paulzhol/golang-plan9-
> > runtime-patches/
> >
> [ ... ]
>
> The other one I would like to submit as a patch affects /386/include/u.h
> (and other architectures), involving the addition of integer types of
> various length.  Equally small and benign.
>
> Opinions?
>
Here is how I changed u.h for the 386 architecture:

term% diff /n/dump/2011/0130/386/include/u.h /n/dump/2011/0404/386/include/u.h
21a22,34
> /* for the GO toolchain */
> /* (with some effort this could go into /go/386/include,
>     but there's really no reason to keep it from the
> 	native toolchain)
> */
> typedef char int8;
> typedef short int16;
> typedef long int32;
> typedef long long int64;
> typedef unsigned char uint8;
> typedef unsigned short uint16;
> typedef unsigned long uint32;
> typedef unsigned long long uint64;

Seems harmless enough. I'm sure I've actually rebuilt the Plan 9 binaries
in their entirety with these changes and no ill effect.

++L

Re: [9fans] Go Plan 9

[erik quanstrom]

> term% diff /n/dump/2011/0130/386/include/u.h /n/dump/2011/0404/386/include/u.h
> 21a22,34
> > /* for the GO toolchain */
> > /* (with some effort this could go into /go/386/include,
> >     but there's really no reason to keep it from the
> > 	native toolchain)
> > */
> > typedef char int8;
> > typedef short int16;
> > typedef long int32;
> > typedef long long int64;
> > typedef unsigned char uint8;
> > typedef unsigned short uint16;
> > typedef unsigned long uint32;
> > typedef unsigned long long uint64;
>
> Seems harmless enough. I'm sure I've actually rebuilt the Plan 9 binaries
> in their entirety with these changes and no ill effect.

that part is easy enough.  and this part is easy enough, too

	{
		# will get quoted instances, too
		echo X ,x:[a-zA-Z_][a-zA-Z_0-9]*: v/......./ s/u(8|16|32|64)int/uint\1/g
		echo X ,x:[a-zA-Z_][a-zA-Z_0-9]*: v/......./ s/s(8|16|32|64)int/int\1/g
		echo w
		ecgi q
	} | sam -d `{find /sys/src|grep '\.[chy]$'

then you can get rid of the old definitions in /*/include/u.h
and declare a flag day.  having both seems wrong to me.
you might as well just do a local hack for the go stuff at that
point.

the hard part is convincing everyone that this large
patch is worth the pain.

i think it is, but maybe there's something i'm not
thinking of, or a different point of view.

- erik

Re: [9fans] Go Plan 9

[Lucio De Re]

On Mon, Apr 04, 2011 at 04:33:29PM -0400, erik quanstrom wrote:
>
[ ... ]
> then you can get rid of the old definitions in /*/include/u.h
> and declare a flag day.  having both seems wrong to me.
> you might as well just do a local hack for the go stuff at that
> point.
>
> the hard part is convincing everyone that this large
> patch is worth the pain.
>
> i think it is, but maybe there's something i'm not
> thinking of, or a different point of view.
>
Personally, I like the suggestion, but I think flag days in Plan
9 are best reserved for larger issues than the name of a handful of
type definitions.  The old type names might have been a bad choice (or
a good choice, but contrary to popular opinion), but they do not need
to go away, perhaps they can just be deprecated.  I'm sure the label
"wrong" is too strong.

++L

Re: [9fans] Go Plan 9

[ron minnich]

On Mon, Apr 4, 2011 at 10:27 AM, Lucio De Re <lucio@proxima.alt.za> wrote:

> May I suggest that we identify Go executables, because they may not run
> under 9vx, as different from Plan 9 executables and adjust the Plan 9
> kernel to identify these and avoid running them under 9vx?


um, yuck :-)

anyway, all you're saying is "don't run go on 9vx". That's a solved problem :-)

ron

Re: [9fans] Go Plan 9

[Lucio De Re]

On Mon, Apr 04, 2011 at 04:10:15PM -0700, ron minnich wrote:
>
> On Mon, Apr 4, 2011 at 10:27 AM, Lucio De Re <lucio@proxima.alt.za> wrote:
>
> > May I suggest that we identify Go executables, because they may not run
> > under 9vx, as different from Plan 9 executables and adjust the Plan 9
> > kernel to identify these and avoid running them under 9vx?
>
>
> um, yuck :-)
>
> anyway, all you're saying is "don't run go on 9vx". That's a solved problem :-)
>
No, and no "yuck", either: Go executables are different animals and
they are allowed to be identified as such.  Until they are not, when
they are allowed to become the same animal.

As for not running Go on 9vx, that's a pain, I have such a nice 9vx
installation on my Ubuntu 32-bit laptop that it almost fools me into
believing it's Plan 9.  I don't always have a convenient CPU server at
hand to run Go on it.

And maybe it's just me being uninformed, but I have this suspicion that
you need a Go toolchain with Plan 9 targets to produce Plan 9 executables.
Maybe I should phrase this as a question: does the default Go toolchain
produce Plan 9 executables or is a separate toolchain required for it?
I'm pretty certain there's a need for two toolchains, but I'll be very
happy to be proven wrong (and Ron right, of course).

	The proof would be in the pudding: I tried to compile hell-o.go
	(I guess that will become a benchmark :-) under an unadulterated
	Go toolchain, then under a Go toolchain built for the Plan 9
	target (GOOS=plan9) and the object code produced showed distincly
	different sizes.  I don't have the details at my fingertips now,
	this is from memory.

And for Cinap, a challenge I wish I had the time and skills to take on
myself: can linuxemu be added as a much thinner shim to 9vx to run Linux
executables?  I can think of one very interesting door that would open,
there may be others.

++L

Re: [9fans] Go Plan 9

[erik quanstrom]

> No, and no "yuck", either: Go executables are different animals and

what's different about them? as far as i can tell, they're completely
standard.

- erik

Re: [9fans] Go Plan 9

[Pavel Zholkover]

On Tue, Apr 5, 2011 at 7:33 AM, Lucio De Re <lucio@proxima.alt.za> wrote:
> No, and no "yuck", either: Go executables are different animals and
> they are allowed to be identified as such.  Until they are not, when
> they are allowed to become the same animal.
> snip...
>
> And maybe it's just me being uninformed, but I have this suspicion that
> you need a Go toolchain with Plan 9 targets to produce Plan 9 executables.
> Maybe I should phrase this as a question: does the default Go toolchain
> produce Plan 9 executables or is a separate toolchain required for it?
> I'm pretty certain there's a need for two toolchains, but I'll be very
> happy to be proven wrong (and Ron right, of course).

The vanilla Go distribution will produce ELF executables on
Linux/FreeBSD/Darwin when the GOOS is set accordingly. If GOOS is set
to plan9, 8l will produce a real Plan 9 a.out executable (it might
complain it cannot find runtime and other packages unless you follow
the procedure to build them).

Pavel

Re: [9fans] Go Plan 9

[Yaroslav]

2011/4/5 Lucio De Re <lucio@proxima.alt.za>:
> As for not running Go on 9vx, that's a pain, I have such a nice 9vx
> installation on my Ubuntu 32-bit laptop that it almost fools me into
> believing it's Plan 9.  I don't always have a convenient CPU server at
> hand to run Go on it.

Why not to run Go directly on your Ubuntu laptop – without the 9vx abstraction?

Re: [9fans] Go Plan 9

[Paul Lalonde]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

So I can write go programs that take advantage of private namespaces and
other Plan9 innovations.

Paul

On Tue, Apr 5, 2011 at 12:06 PM, Yaroslav <yarikos@gmail.com> wrote:

> 2011/4/5 Lucio De Re <lucio@proxima.alt.za>:
> > As for not running Go on 9vx, that's a pain, I have such a nice 9vx
> > installation on my Ubuntu 32-bit laptop that it almost fools me into
> > believing it's Plan 9.  I don't always have a convenient CPU server at
> > hand to run Go on it.
>
> Why not to run Go directly on your Ubuntu laptop – without the 9vx
> abstraction?
>
>


-- 
I'm migrating my email.  plalonde@telus.net will soon be disconnected.
 Please use paul.a.lalonde@gmail.com from now on.

[-- Attachment #2: Type: text/html, Size: 1232 bytes --]

Re: [9fans] Go Plan 9

[Lucio De Re]

On Tue, Apr 05, 2011 at 10:06:49PM +0300, Yaroslav wrote:
> 
> Why not to run Go directly on your Ubuntu laptop – without the 9vx abstraction?

Because I'm a Plan 9 fan?  I use Ubuntu only because of limitations in
Plan 9.  Unfortunately, most of these limitations are going to be with
us for a long time, but I still choose to use Plan 9 whenever possible.
I don't think you really want to know the details of my situation.

I believe that Go will make it a lot easier to add missing functionality
to Plan 9, hence my focus.

Running Go applications in Ubuntu where existing versions already exist
(consider Firefox as an example) doesn't enhance Plan 9 in any way.

++L

Re: [9fans] Go Plan 9

[Sergey Kish]

Hello,

I'm unable to make go plan9 crosscompiler.
Can you help me?

# I use patched repo
hg qclone https://bitbucket.org/paulzhol/golang-plan9-runtime-patches go
cd go
hg qpush -a

# build as usual
export GOROOT=`pwd`
export GOOS=linux
export GOBIN="$GOROOT/bin"
export PATH="$GOBIN:$PATH"

mkdir -p "$GOROOT/bin"
cd "$GOROOT/src"
. ./make.bash

# prepare pkgs
cd $GOROOT/src/pkg
make clean
export GOOS=plan9
make

# and get
make -C net install
make[1]: Entering directory `/home/sergeykish/abs/go/src/go-build/src/pkg/net'
make[1]: *** No rule to make target `fd_plan9.go', needed by `_go_.8'.  Stop.
make[1]: Leaving directory `/home/sergeykish/abs/go/src/go-build/src/pkg/net'

What now?

Re: [9fans] Go Plan 9

[Skip Tavakkolian]

is there a reason you didn't build it from the official Go sources?
i only needed to make a couple of tweaks (see the patch below) to
build it.  a couple of things to watch out for:

- make sure you have two different GOBIN's; one for your local Linux
box and the other for making the Plan 9 binaries
- be sure to have the right GOBIN in the first part of your PATH for
your target environment

i use drawterm from the build box and then i can execute Plan 9
binaries produced by 8[gl] from /mnt/term/<whatever>

-Skip

$ hg diff
diff -r b002b8e25d25 src/pkg/Makefile
--- a/src/pkg/Makefile	Tue Apr 05 18:07:01 2011 -0400
+++ b/src/pkg/Makefile	Sat Apr 09 11:18:04 2011 -0700
@@ -106,7 +106,6 @@
 	image/png\
 	index/suffixarray\
 	io\
-	io/ioutil\
 	json\
 	log\
 	math\
@@ -139,7 +138,6 @@
 	sync/atomic\
 	syscall\
 	syslog\
-	tabwriter\
 	template\
 	testing\
 	testing/iotest\
@@ -206,6 +204,14 @@
 NOTEST+=net syslog
 endif

+# Disable packages that plan9 doesn't support yet
+ifneq ($(GOOS),plan9)
+DIRS+=\
+	tabwriter\
+	io/ioutil\
+
+endif
+
 # Disable tests that windows cannot run yet.
 ifeq ($(GOOS),windows)
 NOTEST+=os/signal    # no signals
diff -r b002b8e25d25 src/pkg/path/filepath/Makefile
--- a/src/pkg/path/filepath/Makefile	Tue Apr 05 18:07:01 2011 -0400
+++ b/src/pkg/path/filepath/Makefile	Sat Apr 09 11:18:04 2011 -0700
@@ -15,6 +15,9 @@
 GOFILES_darwin=\
 	path_unix.go

+GOFILES_plan9=\
+	path_unix.go
+
 GOFILES_linux=\
 	path_unix.go

diff -r b002b8e25d25 src/pkg/time/Makefile
--- a/src/pkg/time/Makefile	Tue Apr 05 18:07:01 2011 -0400
+++ b/src/pkg/time/Makefile	Sat Apr 09 11:18:04 2011 -0700
@@ -21,6 +21,9 @@
 GOFILES_linux=\
 	zoneinfo_unix.go\

+GOFILES_plan9=\
+	zoneinfo_unix.go\
+
 GOFILES_windows=\
 	zoneinfo_windows.go\



On Sat, Apr 9, 2011 at 10:51 AM, Sergey Kish <sergey.kish@gmail.com> wrote:
> Hello,
>
> I'm unable to make go plan9 crosscompiler.
> Can you help me?
>
> # I use patched repo
> hg qclone https://bitbucket.org/paulzhol/golang-plan9-runtime-patches go
> cd go
> hg qpush -a
>
> # build as usual
> export GOROOT=`pwd`
> export GOOS=linux
> export GOBIN="$GOROOT/bin"
> export PATH="$GOBIN:$PATH"
>
> mkdir -p "$GOROOT/bin"
> cd "$GOROOT/src"
> . ./make.bash
>
> # prepare pkgs
> cd $GOROOT/src/pkg
> make clean
> export GOOS=plan9
> make
>
> # and get
> make -C net install
> make[1]: Entering directory `/home/sergeykish/abs/go/src/go-build/src/pkg/net'
> make[1]: *** No rule to make target `fd_plan9.go', needed by `_go_.8'.  Stop.
> make[1]: Leaving directory `/home/sergeykish/abs/go/src/go-build/src/pkg/net'
>
> What now?
>
>

Re: [9fans] Go Plan 9

[Pavel Zholkover]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

Try make -k install like in the wiki instructions. This should continue
building packages even if some fail to compile.
 On Apr 9, 2011 8:53 PM, "Sergey Kish" <sergey.kish@gmail.com> wrote:
> Hello,
>
> I'm unable to make go plan9 crosscompiler.
> Can you help me?
>
> # I use patched repo
> hg qclone https://bitbucket.org/paulzhol/golang-plan9-runtime-patches go
> cd go
> hg qpush -a
>
> # build as usual
> export GOROOT=`pwd`
> export GOOS=linux
> export GOBIN="$GOROOT/bin"
> export PATH="$GOBIN:$PATH"
>
> mkdir -p "$GOROOT/bin"
> cd "$GOROOT/src"
> . ./make.bash
>
> # prepare pkgs
> cd $GOROOT/src/pkg
> make clean
> export GOOS=plan9
> make
>
> # and get
> make -C net install
> make[1]: Entering directory
`/home/sergeykish/abs/go/src/go-build/src/pkg/net'
> make[1]: *** No rule to make target `fd_plan9.go', needed by `_go_.8'.
Stop.
> make[1]: Leaving directory
`/home/sergeykish/abs/go/src/go-build/src/pkg/net'
>
> What now?
>

[-- Attachment #2: Type: text/html, Size: 1426 bytes --]

[9fans] Go Plan 9

[erik quanstrom]

> The reason it doesn't work on 9vx is because the 32 bit Go runtime
> reserves a large chunk of address space (currently 768mb).  On all
> other platforms, this is accomplised with an mmap equivalient, which
> we all know won't work on Plan 9.
> 

if i read the thread on this topic correctly, this reservation
isn't necessary on plan 9, since there are no shared libraries
and the heap will always be contiguous.

if there is a way to override this for plan 9, we probablly should.

- erik

[9fans] Go Plan 9

[ron minnich]

On Sun, Apr 3, 2011 at 2:24 PM, erik quanstrom <quanstro at labs.coraid.com> wrote:
>> The reason it doesn't work on 9vx is because the 32 bit Go runtime
>> reserves a large chunk of address space (currently 768mb). ?On all
>> other platforms, this is accomplised with an mmap equivalient, which
>> we all know won't work on Plan 9.
>>
>
> if i read the thread on this topic correctly, this reservation
> isn't necessary on plan 9, since there are no shared libraries
> and the heap will always be contiguous.
>

no, the shared libraries are not going to affect the heap size.
Certainly not to this scale.

My understanding was that Go used this large sparse address space to
effect for its garbage collection; the fact that it is backed by mmap
of anonymous memory is what makes it work, since pages are not
allocated until touched. Russ?

ron

[9fans] Go Plan 9

[erik quanstrom]

On Mon Apr  4 11:19:37 EDT 2011, rminnich at gmail.com wrote:
> On Sun, Apr 3, 2011 at 2:24 PM, erik quanstrom <quanstro at labs.coraid.com> wrote:
> >> The reason it doesn't work on 9vx is because the 32 bit Go runtime
> >> reserves a large chunk of address space (currently 768mb). ?On all
> >> other platforms, this is accomplised with an mmap equivalient, which
> >> we all know won't work on Plan 9.
> >>
> >
> > if i read the thread on this topic correctly, this reservation
> > isn't necessary on plan 9, since there are no shared libraries
> > and the heap will always be contiguous.
> >
> 
> no, the shared libraries are not going to affect the heap size.
> Certainly not to this scale.
> 

i'm not quite sure what you're saying "no" to.

in any event, my understanding is, it's not the size of
the heap, it's the heap's continuity.  if the heap
is not contiguous, you'll need a structure tracking it.
according to lwn http://lwn.net/Articles/428100/

	In the process of trying to reach that goal of
	"low enough overhead and no significant latency," the
	Go developers have made some simplifying assumptions,
	one of which is that the memory being managed
	for a running application comes from a
	single, virtually-contiguous address range.

this is the whole point of the big allocation, so why
would we drag this into plan 9, when it's not necessary.
the plan 9 heap is contiguous.

- erik

Re: [9fans] Go Plan 9

[ron minnich]

On Mon, Apr 4, 2011 at 8:59 AM, erik quanstrom <quanstro@quanstro.net> wrote:

> this is the whole point of the big allocation, so why
> would we drag this into plan 9, when it's not necessary.
> the plan 9 heap is contiguous.

Sorry, Erik, I misunderstood your point.

I guess what you are pointing out is that on Plan 9, presumably, since
the Go runtime is the only thing that might call brk(), it will always
get a virtually contiguous heap. Therefore, instead of a huge upfront
allocation, Go runtime could call brk() as needed.

Can we safely assume that only the Go runtime will call brk()? What if
we link a library into Go that calls brk() as well -- won't that
violate Go's model? Probably not worth worrying about since Russ says
he's good with the other change.

thanks

ron

Re: [9fans] Go Plan 9

[erik quanstrom]

> Sorry, Erik, I misunderstood your point.

no need to be sorry.

> I guess what you are pointing out is that on Plan 9, presumably, since
> the Go runtime is the only thing that might call brk(), it will always
> get a virtually contiguous heap. Therefore, instead of a huge upfront
> allocation, Go runtime could call brk() as needed.
>
> Can we safely assume that only the Go runtime will call brk()? What if
> we link a library into Go that calls brk() as well -- won't that
> violate Go's model? Probably not worth worrying about since Russ says
> he's good with the other change.

i didn't think of that, but i wouldn't think one would
want to do that.  the effort, say, to glue ndb structures
into go's world would seem on par with rewriting the library.
and it would be a great oppertunity to clean up some crunch.

one big challenge in gluing in c libraries is that you
couldn't easily pass any sort of pointer back in from c.
it would break the gc.

- erik

Re: [9fans] Go Plan 9

[ron minnich]

well, Russ has blessed the runtime fix :-)

I look forward to having go in 9vx too!

ron

Re: [9fans] Go Plan 9

[ron minnich]

I tried a simple hack on 9vx.

First, I had sysbrk_ return the max possible value instead of the
requested value. I.e., if go runtime asked for 768MB, I had it return
something less than TSTKTOP, which is around 256 MB. I like this
because if we change the USTKTOP on 9vx in future we don't have to
recompile the go runtime, and a single binary can run on many 9vx
systems which might have different limits compiled in.

Unfortunately the runtime code ignores the returned value from sbrk_;
strike one.

I then had it return -1 when asked for more memory than could be
returned; Got this:
term% ./testgo.out
throw:

and that was it.

Russ, could the go runtime maybe use the value returned by sbrk
instead of  assuming it got all it asked for?

ron

Re: [9fans] Go Plan 9

[Russ Cox]

The number of people who want to run Go on Plan 9
is already small.  The number of people who want to
run Go on Plan 9 on 9vx is smaller yet.  At that point
why not just run Go directly?

9vx is a nice hack but still a hack.

Russ

Re: [9fans] Go Plan 9

[Lucio De Re]

On Tue, Apr 05, 2011 at 12:22:18AM -0400, Russ Cox wrote:
> The number of people who want to run Go on Plan 9
> is already small.  The number of people who want to
> run Go on Plan 9 on 9vx is smaller yet.  At that point
> why not just run Go directly?
>
All that Microsoft thinking (99.9%-thinking, if you find the other label
offensive) to avoid adding a minute, one-off change to the Go runtime?
Sure, as Ron suggested it, it may need some additional thought, but we
are talking about the Plan 9 team thinking about it, surely it would
not take long to solve?

> 9vx is a nice hack but still a hack.
>
So is VMware, but it may be a breath of life for Plan 9 and adding
features to it seems inexpensive enough.  The same applies to p9p,
which is another toolkit that could benefit from providing a development
environment for Go.

That said, I'd like to make it very clear that I am extremely grateful
to all those who have contributed to making Go available on the Plan 9
platform and that I hope to be part of a growing community.  The current
solution to the 9vx problem seems adequate, one is merely concerned that
it may come back to bite an unsuspecting third party if it is forgotten.

++L

Re: [9fans] Go Plan 9

[Russ Cox]

> All that Microsoft thinking (99.9%-thinking, if you find the other label
> offensive) to avoid adding a minute, one-off change to the Go runtime?

It is not a minute, one-off change.
I don't know how to fix it to cope with tiny virtual address spaces
like those in 9vx.  It's not something I anticipated when I wrote the
allocator, and it's not something I really want to spend time on
for such a tiny fraction of use cases.  We have limited time.
We don't even support OS X 10.5 anymore.

The best answer might be to make USTKTOP 1GB.

Russ

Re: [9fans] Go Plan 9

[Lucio De Re]

On Tue, Apr 05, 2011 at 01:11:35AM -0400, Russ Cox wrote:
>
> > All that Microsoft thinking (99.9%-thinking, if you find the other label
> > offensive) to avoid adding a minute, one-off change to the Go runtime?
>
> It is not a minute, one-off change.

I stand corrected.

> I don't know how to fix it to cope with tiny virtual address spaces
> like those in 9vx.  It's not something I anticipated when I wrote the
> allocator, and it's not something I really want to spend time on
> for such a tiny fraction of use cases.  We have limited time.
> We don't even support OS X 10.5 anymore.
>
That is as good an answer as I could possibly ask for.  There will be
other eyes to look at it and hopefully supplement the lack of time.

A quick, uneducated question: should 9vx be investigated instead?

> The best answer might be to make USTKTOP 1GB.
>
Where?

Thanks for replying.

++L

Re: [9fans] Go Plan 9

[Russ Cox]

>> The best answer might be to make USTKTOP 1GB.
>>
> Where?

In 9vx.

Russ

Re: [9fans] Go Plan 9

[ron minnich]

On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox <rsc@swtch.com> wrote:

> The best answer might be to make USTKTOP 1GB.



Agreed.

ron

Re: [9fans] Go Plan 9

[ron minnich]

On Tue, Apr 5, 2011 at 8:48 AM, ron minnich <rminnich@gmail.com> wrote:
> On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox <rsc@swtch.com> wrote:
>
>> The best answer might be to make USTKTOP 1GB.
>
>
>
> Agreed.

My latest vx32 has the change and:

term% ./8.out
hello world

so Go is go on 9vx

ron

Re: [9fans] Go Plan 9

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox <rsc@swtch.com> wrote:

> > All that Microsoft thinking (99.9%-thinking, if you find the other label
> > offensive) to avoid adding a minute, one-off change to the Go runtime?
>
> It is not a minute, one-off change.
> I don't know how to fix it to cope with tiny virtual address spaces
> like those in 9vx.  It's not something I anticipated when I wrote the
> allocator, and it's not something I really want to spend time on
> for such a tiny fraction of use cases.  We have limited time.
> We don't even support OS X 10.5 anymore.
>

I'm not sure apple support OS X 10.5 anymore either?  I think that's why the
OS updates are so inexpensive :-)  (what was it like 40 bucks to go from
10.5 to 10.6?)


>
> The best answer might be to make USTKTOP 1GB.
>
> Russ
>
>

[-- Attachment #2: Type: text/html, Size: 1311 bytes --]

Re: [9fans] Go Plan 9

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 438 bytes --]

On Mon, Apr 4, 2011 at 9:22 PM, Russ Cox <rsc@swtch.com> wrote:

> The number of people who want to run Go on Plan 9
> is already small.  The number of people who want to
> run Go on Plan 9 on 9vx is smaller yet.  At that point
> why not just run Go directly?
>
> 9vx is a nice hack but still a hack.
>
> Russ
>
> What we need is an OS port of Plan 9 to Go that can run hosted on another
OS or natively.

InfernGo?

Dave

[-- Attachment #2: Type: text/html, Size: 750 bytes --]

Re: [9fans] Go Plan 9

[erik quanstrom]

> > What we need is an OS port of Plan 9 to Go that can run hosted on another
> OS or natively.
>
> InfernGo?

huh?

- erik

Re: [9fans] Go Plan 9

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

On Tue, Apr 5, 2011 at 10:36 AM, erik quanstrom <quanstro@labs.coraid.com>wrote:

> > > What we need is an OS port of Plan 9 to Go that can run hosted on
> another
> > OS or natively.
> >
> > InfernGo?
>
> huh?
>
> - erik
>
>
Inferno-like Go based OS (instead of Limbo??)

Not necessarily with any kind of virtual machine but it could be a neat
project...

[-- Attachment #2: Type: text/html, Size: 701 bytes --]

Re: [9fans] Go Plan 9

[andrey mirtchovski]

> InfernGo?

Goribund ;)

Re: [9fans] Go Plan 9

[David Leimbach]

[-- Attachment #1: Type: text/plain, Size: 134 bytes --]

2011/4/5 andrey mirtchovski <mirtchovski@gmail.com>

> > InfernGo?
>
> Goribund ;)
>
>
What a positive sounding project name!

[-- Attachment #2: Type: text/html, Size: 399 bytes --]

Re: [9fans] Go Plan 9

[Anthony Martin]

Anthony Martin <ality@pbrane.org> once said:
> -#define MaxArena32 (2U<<30)
> +#define MaxArena32 (240U<<20)

I forgot to mention this earlier but for the curious, I
used 240mb here because that is USTKTOP-USTKSIZE in 9vx.

  Anthony

P.S.
Has anyone ran into the SEGMAPSIZE limit on native Plan 9?

The current value of 1984mb was set on Sep 16 1998 and if
I've inferred the heuristic correctly, it was meant to be
USTKTOP-4*USTKSIZE.

(At the time, the top of user VM was 0x80000000).

Using the current USTKTOP would give a size of 3520mb.