Re: [9fans] P9P font server

[Pavel Zholkover]

Well it's not that simple, the X11 version uses freetype2 and fontconfig to
read/render TrueType fonts..
The OS X is probably doing something similar with Apple's APIs


On Fri, Dec 13, 2013 at 7:26 PM, Friedrich Psiorz f.psi...@gmx.de wrote:

 I would really like to have fontsrv in native Plan 9. It's nice to be
 able to simply download a font or copy it from a unix system and use it
 without going through conversion. It would also de-facto introduce a
 usable interface to rendering ttf fonts on the fly. This could be a nice
 feature in many applications, e.g. abaco or document viewers.
 Even for simple conversion, it would be a much nicer interface than
 ttf2subf.

 I don't think you would have to change anything about the surrounding
 system ... isn't that the whole point for fontsrv? If I didn't
 misunderstand, it's just a virtual file system that converts ttf fonts
 to the Plan 9 pixel font format transparently.

 ~Fritz

 Am 12.12.2013 12:45, schrieb lu...@proxima.alt.za:
  I didn't pay any attention to p9p's fontsrv (sorry, Andrey!  It was
  you that got that off the ground, wasn't it?) until this morning's
  discussion, but it struck me as a very neat solution for a problem
  that has been bugging me for a long time: avoiding the time consuming
  repeated installation of Plan 9 fonts.  Specifically, p9p itself and
  local instances of 9vx could be smaller and the installation (and
  download, in most cases) would be quicker.
 
  The question then becomes whether fontsrv could be ported to Plan 9
  together with the supporting facilities (openfont(2) is my guess)?  I
  certainly would be willing to give such port a try, if I can be
  convinced that it is not beyond my ability.
 
  ++L
 
 
 
 

[9fans] govt go library

[Pavel Zholkover]

Hi all,

Does anyone use the http://http://code.google.com/p/govt package for
client side venti ?
I had to apply the attached patch to be able to read a vac score.

Thanks,
- Pavel


govt_client_fixes.diff
Description: Binary data

Re: [9fans] govt go library

[Pavel Zholkover]

diff -r 26a682609ac2 vt/pack.go
--- a/vt/pack.goTue Apr 24 12:03:56 2012 -0600
+++ b/vt/pack.goWed Jun 19 21:24:46 2013 +0300
@@ -6,8 +6,10 @@

 //import log

+const VtCorruptType = 0xFF
+
 const (
-Overrtype= 0
+Overrtype = iota
 Ovroottype
 Ovdirtype
 Ovptype0
@@ -44,8 +46,8 @@
 Ovroottype,
 }

-var fromdisk = [...]int{
--1,
+var fromdisk = [...]uint8{
+VtCorruptType,
 RBlock,
 DirBlock,
 DirBlock + 1,
@@ -55,33 +57,33 @@
 DirBlock + 5,
 DirBlock + 6,
 DirBlock + 7,
--1,
--1,
--1,
+VtCorruptType,
+VtCorruptType,
+VtCorruptType,
 DataBlock,
 }

 var Epacket *Error = Error{invalid packet}
 var Eblktype *Error = Error{invalid block type}

-func fromDiskType(val uint8) int {
+func fromDiskType(val uint8) uint8 {
 if int(val)  len(fromdisk) {
-return -1
+return VtCorruptType
 }

 return fromdisk[val]
 }

-func toDiskType(val uint8) int {
+func toDiskType(val uint8) uint8 {
 if int(val)  len(todisk) {
-return -1
+return VtCorruptType
 }

-return int(todisk[val])
+return todisk[val]
 }

 func PackCall(buf []byte, id uint8, tag uint8, size int) (int, []byte) {
-size += 2 + 1 + 1// size[2] id[1] tag[1]
+size += 2 + 1 + 1 // size[2] id[1] tag[1]
 if len(buf)  size {
 return -1, nil
 }
@@ -108,7 +110,7 @@

 func PackThello(buf []byte, tag uint8, version, uid string, strength
uint8, crypto, codec []byte) int {
 sz, buf := PackCall(buf, Thello, tag,
-7+len(version)+len(uid)+len(crypto)+len(codec))//
vesion[s] uid[s] strength[1] crypto[n] codec[n]
+7+len(version)+len(uid)+len(crypto)+len(codec)) // vesion[s]
uid[s] strength[1] crypto[n] codec[n]
 if buf == nil {
 return -1
 }
@@ -127,13 +129,13 @@
 }

 func PackTread(buf []byte, tag uint8, score Score, btype uint8, count
uint16) int {
-sz, buf := PackCall(buf, Tread, tag, Scoresize+1+1+2)//
score[20] type[1] pad[1] count[2]
+sz, buf := PackCall(buf, Tread, tag, Scoresize+1+1+2) //
score[20] type[1] pad[1] count[2]
 if buf == nil {
 return -1
 }

 buf = Pscore(score, buf)
-buf = Pint8(uint8(toDiskType(btype)), buf)
+buf = Pint8(toDiskType(btype), buf)
 buf = Pint8(0, buf)
 Pint16(count, buf)

@@ -141,12 +143,12 @@
 }

 func PackTwrite(buf []byte, tag uint8, btype uint8, data []byte) int {
-sz, buf := PackCall(buf, Twrite, tag, 1+3+len(data))//
type[1] pad[3] data
+sz, buf := PackCall(buf, Twrite, tag, 1+3+len(data)) // type[1] pad[3] data
 if buf == nil {
 return -1
 }

-buf = Pint8(uint8(toDiskType(btype)), buf)
+buf = Pint8(toDiskType(btype), buf)
 buf = Pint8(0, buf)
 buf = Pint16(0, buf)
 copy(buf, data)
diff -r 26a682609ac2 vt/vtclnt/clnt.go
--- a/vt/vtclnt/clnt.goTue Apr 24 12:03:56 2012 -0600
+++ b/vt/vtclnt/clnt.goWed Jun 19 21:24:46 2013 +0300
@@ -279,7 +279,8 @@

 pos += n
 nreqs++
-clnt.ReqFree(req)
+// req is freed in recv() if no Done channel was
registered, or by the code calling -Done.
+//clnt.ReqFree(req)
 select {
 default:
 req = nil
@@ -355,7 +356,7 @@
 clnt = NewClnt(c)
 req := clnt.ReqAlloc()
 req.Done = make(chan *Req)
-tc := req.Tc
+tc := req.Tc
 tc.Id = vt.Thello
 tc.Version = 02
 tc.Uid = anonymous
@@ -411,7 +412,7 @@
 func (clnt *Clnt) Getnb(score vt.Score, btype uint8, count uint16,
done chan *Req) (err *vt.Error) {
 req := clnt.ReqAlloc()
 req.Done = done
-tc := req.Tc
+tc := req.Tc
 tc.Id = vt.Tread
 tc.Score = score
 tc.Btype = btype
@@ -447,7 +448,7 @@
 // Put is always async, Sync will make sure all Puts finished before returning
 func (clnt *Clnt) Put(btype uint8, data []byte) (score vt.Score, err
*vt.Error) {
 req := clnt.ReqAlloc()
-tc := req.Tc
+tc := req.Tc
 tc.Id = vt.Twrite
 tc.Btype = btype
 tc.Data = data
@@ -466,7 +467,7 @@
 done := make(chan *Req)
 req := clnt.ReqAlloc()
 req.Done = done
-tc := req.Tc
+tc := req.Tc
 tc.Id = vt.Tsync
 err = clnt.Rpcnb(req)
 if err != nil {

On Sat, Jul 6, 2013 at 1:52 PM, Pavel Zholkover paulz...@gmail.com wrote:
 Hi all,

 Does anyone use the http://http://code.google.com/p/govt package for
 client side venti ?
 I had to apply the attached patch to be able to read a vac score.

 Thanks,
 - Pavel

[9fans] Tasks (libthread threads) and Channels for Python

[Pavel Zholkover]

Hi all!

I did a small port of the p9p libthread to CPython 2.7.3 and up using the
greenlet module.
https://bitbucket.org/paulzhol/libtask9

You might find it useful if like me, you failed to convince your peers to
switch to Go :)

-paulzhol

Re: [9fans] Go: CGO and Plan 9

[Pavel Zholkover]

CGO will generate C code stubs that require gcc to compile.
The gcc generated executable (_cgo_.o in the example bellow) is then
parsed for it's dwarf debug info
(I think) to get import the names and dso's of imported symbols.
Later, when you build an executable using the cgo'd package; 6l will
generate a dynamically linked executable making
the dynamic linker load/mmap the needed libraries (regular go
executables are statically linked, and there is their great value
in my opinion).

I think that if you really want LDAP, you'd either implement it
natively in Go, or massage the plan9 ported version of OpenLDAP
to build using the Go C compilers as part of a Go ldap.a library.

Attached is a simple cgo build example with verbose output from the go tool.
/tmp/test$ cat cgo_atoi.go
package cgo_atoi

// #include stdlib.h
import C

func Atoi(s string) int {
n, _ := C.atoi(C.CString(s))
return int(n)
}

/tmp/test$ go build -v -x -work
WORK=/tmp/go-build967270508
_/tmp/test
mkdir -p $WORK/_/tmp/test/_obj/
cd /tmp/test
/usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/_/tmp/test/_obj/
-- -I $WORK/_/tmp/test/_obj/ cgo_atoi.go
/usr/local/go/pkg/tool/linux_amd64/6c -FVw -I $WORK/_/tmp/test/_obj/
-I /usr/local/go/pkg/linux_amd64 -o $WORK/_/tmp/test/_obj/_cgo_defun.6
-DGOOS_linux -DGOARCH_amd64 $WORK/_/tmp/test/_obj/_cgo_defun.c
gcc -I . -g -O2 -fPIC -m64 -pthread -I $WORK/_/tmp/test/_obj/ -o
$WORK/_/tmp/test/_obj/_cgo_main.o -c $WORK/_/tmp/test/_obj/_cgo_main.c
gcc -I . -g -O2 -fPIC -m64 -pthread -I $WORK/_/tmp/test/_obj/ -o
$WORK/_/tmp/test/_obj/_cgo_export.o -c
$WORK/_/tmp/test/_obj/_cgo_export.c
gcc -I . -g -O2 -fPIC -m64 -pthread -I $WORK/_/tmp/test/_obj/ -o
$WORK/_/tmp/test/_obj/cgo_atoi.cgo2.o -c
$WORK/_/tmp/test/_obj/cgo_atoi.cgo2.c
gcc -I . -g -O2 -fPIC -m64 -pthread -o $WORK/_/tmp/test/_obj/_cgo_.o
$WORK/_/tmp/test/_obj/_cgo_main.o $WORK/_/tmp/test/_obj/_cgo_export.o
$WORK/_/tmp/test/_obj/cgo_atoi.cgo2.o
/usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/_/tmp/test/_obj/
-dynimport $WORK/_/tmp/test/_obj/_cgo_.o -dynout
$WORK/_/tmp/test/_obj/_cgo_import.c
/usr/local/go/pkg/tool/linux_amd64/6c -FVw -I $WORK/_/tmp/test/_obj/
-I /usr/local/go/pkg/linux_amd64 -o
$WORK/_/tmp/test/_obj/_cgo_import.6 -DGOOS_linux -DGOARCH_amd64
$WORK/_/tmp/test/_obj/_cgo_import.c
/usr/local/go/pkg/tool/linux_amd64/6g -o $WORK/_/tmp/test/_obj/_go_.6
-p _/tmp/test -D _/tmp/test -I $WORK
$WORK/_/tmp/test/_obj/_cgo_gotypes.go
$WORK/_/tmp/test/_obj/cgo_atoi.cgo1.go
/usr/local/go/pkg/tool/linux_amd64/pack grcP $WORK $WORK/_/tmp/test.a
$WORK/_/tmp/test/_obj/_go_.6 $WORK/_/tmp/test/_obj/_cgo_import.6
$WORK/_/tmp/test/_obj/_cgo_defun.6 $WORK/_/tmp/test/_obj/_cgo_export.o
$WORK/_/tmp/test/_obj/cgo_atoi.cgo2.o

- Pavel

On Wed, Jan 30, 2013 at 6:41 AM,  lu...@proxima.alt.za wrote:
 I need some help getting my mind around what should be a simple issue:
 how to connect Go with Plan 9's native toolchain.

 To be more specific, I have a port of the OpenLDAP library for Plan 9
 that works quite adequately and I would like to access it from GO. I
 guess this is true of any similar library ported using APE.  It seems
 to me that because Go can connect to native C libraries and because in
 Plan 9 the calling conventions are in fact identical, there ought to
 be an easy way to do it, but I don't realy understand what's involved.

 I suspect that the Go builder would have to be enhanced to deal with
 this, while at the same time I wonder if the C compiler and assembler
 should be used in a Go APE-like environment.  Whatever, I need help
 thinking this through, can anyone assist?

 ++L

 PS: I'd like the answer to be portable outside of Plan 9 (in p9p, to
 be exact), but that isn't essential.

Re: [9fans] ARM 9pfuse broken?

[Pavel Zholkover]

I've also encountered this on my synology DS411 linux based kirkwood
NAS. If I remember correctly I saw a comment by Russ regarding
weird/unhandled flags being passed to the open syscall.

My workaround was just to compile a 9p kernel module and mount the
vacfs export with it.

On Thu, Mar 22, 2012 at 6:46 PM,  smi...@icebubble.org wrote:
 Hello,

 Are there any known bugs in 9pfuse on ARM?  I can mount a vac file
 system OK with it, but trying to list files on it causes:

  unexpected open flags 02444000
  ls: cannot open directory /mnt/foo: Permission denied

 Trying to read files:

  unexpected open flags 040
  cat: /mnt/foo/bar.txt: Permission denied

 But walk/statting seem to succeed OK.  I'm planning to debug a bit
 deeper, but figured I'd give a shout out, in case this bug is already
 known, and to see if there was already a patch for it floating around.

 This is an ARMv7 OMAP4 Cortex-A9, in case that's any clue.

 --
 +---+
 |Smiley       smi...@icebubble.org    PGP key ID:    BC549F8B |
 |Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
 +---+

Re: [9fans] ARM 9pfuse broken?

[Pavel Zholkover]

I've looked at 
http://code.swtch.com/plan9port/src/9574d432c889/src/cmd/9pfuse/main.c#cl-580
and O_NOFOLLOW == 040 handling was added in
http://code.swtch.com/plan9port/changeset/43f43652132d
So maybe you can recompile a more recent version ?

On Thu, Mar 22, 2012 at 8:30 PM, Pavel Zholkover paulz...@gmail.com wrote:
 I've also encountered this on my synology DS411 linux based kirkwood
 NAS. If I remember correctly I saw a comment by Russ regarding
 weird/unhandled flags being passed to the open syscall.

 My workaround was just to compile a 9p kernel module and mount the
 vacfs export with it.

 On Thu, Mar 22, 2012 at 6:46 PM,  smi...@icebubble.org wrote:
 Hello,

 Are there any known bugs in 9pfuse on ARM?  I can mount a vac file
 system OK with it, but trying to list files on it causes:

  unexpected open flags 02444000
  ls: cannot open directory /mnt/foo: Permission denied

 Trying to read files:

  unexpected open flags 040
  cat: /mnt/foo/bar.txt: Permission denied

 But walk/statting seem to succeed OK.  I'm planning to debug a bit
 deeper, but figured I'd give a shout out, in case this bug is already
 known, and to see if there was already a patch for it floating around.

 This is an ARMv7 OMAP4 Cortex-A9, in case that's any clue.

 --
 +---+
 |Smiley       smi...@icebubble.org    PGP key ID:    BC549F8B |
 |Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
 +---+

Re: [9fans] Building Go on Plan 9

[Pavel Zholkover]

Is the builder going to be based on the native build or will it be
cross-compiled ?

Thanks!

On Thu, Dec 1, 2011 at 8:18 PM, Anthony Martin al...@pbrane.org wrote:
# In other news, I'm working on setting up an
# an automated builder so we can include Plan 9
# in the Go Dashboard.

Re: [9fans] GNU/Linux/Plan 9 disto

[Pavel Zholkover]

 setting up cross-compilation with gcc, and even using it once set up,
 has historically been surprisingly complicated; has that changed?


I'm not sure about gcc, but the go toolchain can produce quite well working
Plan 9 binaries.

Taru also has the go toolchain running native in itself after some
modifications.

Pavel

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 lu...@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

[Pavel Zholkover]

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.k...@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]

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.tavakkol...@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.tavakkol...@gmail.com wrote:
 Great info! thanks.
 -Skip

 On Sat, Apr 9, 2011 at 11:53 AM, Pavel Zholkover paulz...@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.tavakkol...@gmail.com
 wrote:

Re: [9fans] Go Plan 9

[Pavel Zholkover]

On Tue, Apr 5, 2011 at 7:33 AM, Lucio De Re lu...@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

[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 al...@pbrane.org wrote:
 Pavel Zholkover paulz...@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=0x21df

 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

Re: [9fans] Go Plan 9

[Pavel Zholkover]

On Mon, Apr 4, 2011 at 8:27 PM, Lucio De Re lu...@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

[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

Re: [9fans] Go Plan 9

[Pavel Zholkover]

On Sun, Apr 3, 2011 at 2:52 AM, David Leimbach leim...@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

Re: [9fans] Go Plan 9

[Pavel Zholkover]

On Apr 3, 2011 12:18 PM, erik quanstrom quans...@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

Re: [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.tavakkol...@gmail.com
wrote:

Re: [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 al...@pbrane.org wrote:
 Anthony Martin al...@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]

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

Re: [9fans] plan9 go output faults on 9vx but ok on cpu

[Pavel Zholkover]

On Sat, Jan 15, 2011 at 11:01 AM,  kokam...@hera.eonet.ne.jp wrote:
 I'm a bit cinfusing...

 There is a flag (GPOS=plan9) to ebnable plan9 os in the standard Go 
 dsitribution.
 How the patches you posted here now and before are related to that flag.
 I suppose the original plan9 flag is for plan9port.
 Am I correct?

 That plan9 flag works for plan9port?
 Then how I can use it on my linux box with plan9port.

 Kenji


Setting GOOS=plan9 when using the main Go distribution (and linking
with symbols stripped 8l -s) will compile to native plan 9 binaries.
They assume a stack layout that is not correct when running on 9vx as
Anthony points out.

The patch I posted is to replace the hard coded values with relative
offsets from _tos, so the binaries will run both in 9vx and on a
native install of plan 9.

Previously I posted a patch for syscall and os Go packages against the
Go distribution to allow writing code that can actually do something
useful besides println.

I'm not sure what you mean by using these with plan9port...

Pavel

Re: [9fans] plan9 go output faults on 9vx but ok on cpu

[Pavel Zholkover]

On Sat, Jan 15, 2011 at 4:00 AM, Anthony Martin al...@pbrane.org wrote:
 Pavel Zholkover paulz...@gmail.com once said:
 I have no idea what is causing it to die, I've tried adding a bunch of
 INT $3 to see how far in the flow I can get, but all I get this:

 9vx panic: unknown trap/intr: 0x203
 aborting, to dump core.

 for an INT $3 just before
 CALL  SI      // fn()

 This happens because the linker outputs the two bytes
 { 0xCD, 0x03 } for an INT $3 instruction but libvx32
 only sends a VXTRAP_BREAKPOINT to 9vx if it sees an
 INT3 instruction (a single 0xCC byte). Try using a
 'BYTE $0xCC' instead.

  Anthony

Thanks, that did the trick.

This is what I get when running goroutines on 9vx with a 0xCC
breakpoint compiled in:
% goroutines
goroutines 69: suicide: sys: breakpoint pc=0x9e44
id: 1 0
id: 1 1
id: 1 2
id: 1 3
id: 1 4
id: 1 5
id: 1 6
id: 1 7
id: 1 8
id: 1 9
% acid 69
/proc/69/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
no symbol information
acid: regs()
PC  0x9e44 0x9e44  ?file?:0
SP  0x000560e0 ECODE 0x EFLAG 0x
CS  0x DS0x SS  0x
GS  0x FS0x ES  0x
TRAP0x0003 breakpoint
AX  0x0004c0c0 BX   0x0004c0c0 CX   0x0fc8 DX   0x00054100
DI  0x00056100 SI   0x72f8 BP   0x

acid: asm(*PC-32)
0x9e24 0x9e24   ADDL$0x1ed2c,AX
0x9e29 0x9e29   MOVLDX,0xfff8(AX)
0x9e2c 0x9e2c   MOVLBX,0xfffc(AX)
0x9e2f 0x9e2f   MOVL0x1ed2c,AX
0x9e35 0x9e35   MOVL0x30(AX),AX
0x9e38 0x9e38   MOVLAX,0x24(BX)
0x9e3b 0x9e3b   CALL0x1c10
0x9e40 0x9e40   MOVL0x0(DX),DX
0x9e42 0x9e42   MOVL0x0(BX),BX
0x9e44 0x9e44   INT 3  === we stopped here,
runtime.rfork() in src/pkg/runtime/plan9/sys.s
0x9e45 0x9e45   CALL*   SI
0x9e47 0x9e47   CALL0x9eac
0x9e4c 0x9e4c   RET

0x72f8 is runtime.mstart as it should...

acid: asm(*SI)
0x72f8 0x72f8   MOVL0x1ed2c,CX
0x72fe 0x72fe   MOVL0xfff8(CX),CX
0x7301 0x7301   CMPL0x0(CX),SP
0x7303 0x7303   JHI 0x730e
0x7305 0x7305   XORLDX,DX
0x7307 0x7307   XORLAX,AX
0x7309 0x7309   CALL0x1a75
0x730e 0x730e   SUBL$0x8,SP
0x7311 0x7311   MOVL0x1ed2c,AX
0x7317 0x7317   MOVL0xfff8(AX),AX
0x731a 0x731a   MOVL0x1ed2c,CX
0x7320 0x7320   MOVL0xfffc(CX),CX
0x7323 0x7323   MOVL0x0(CX),CX
0x7325 0x7325   CMPLCX,AX
0x7327 0x7327   JEQ 0x7336
0x7329 0x7329   MOVL$0x1eb80,AX
0x732e 0x732e   MOVLAX,0x0(SP)
0x7331 0x7331   CALL0x81ee
0x7336 0x7336   MOVL0x1ed2c,AX
0x733c 0x733c   MOVL0xfffc(AX),AX
0x733f 0x733f   MOVL0x94(AX),AX
0x7345 0x7345   CMPLAX,$0x0
0x7348 0x7348   JNE 0x735e
0x734a 0x734a   CALL0x2d75
0x734f 0x734f   MOVL0x1ed2c,CX
0x7355 0x7355   MOVL0xfffc(CX),CX
0x7358 0x7358   MOVLAX,0x94(CX)
0x735e 0x735e   CALL0x9e4d
0x7363 0x7363   CALL0x74c3
0x7368 0x7368   ADDL$0x8,SP

I can't tell from this why 9vx is dying on me and I don't know how to
use acid to debug a child process after rfork,
is there something like gdb's set follow-fork-mode child ?

Pavel

Re: [9fans] plan9 go output faults on 9vx but ok on cpu

[Pavel Zholkover]

On Sat, Jan 15, 2011 at 11:30 AM,  lu...@proxima.alt.za wrote:
 In a nutshell, I actually took a very recent release of Go and tried
 to build a Plan 9 version:

        cd $GOROOT/src
        GOOS=plan9 ./make.bash

 I was not surprised that it did not build correctly on my Ubuntu
 workstation.  Fixing it did not seem a trivial task and a cursory web
 search did not reveal any encouraging help.

If you try applying http://codereview.appspot.com/3816043/ you can get
pretty far..
you need to
cd src/pkg
make clean
GOOS=plan9 make -k install

You'll get os, syscall, fmt and a bunch of other portable go libraries.

 Right now, I have a few days in which to resurrect work I did
 initially that concluded with a working version of the Hello World
 C program compiled and executed on Plan 9/386 using modifed Go
 sources to compile and build the C development toolchain under Plan
 9.  It is daunting how much effort I estimate I will need to do to get
 that far, specially with a view to propagate the rather extensive
 changes to the Go source release.  On the positive side, I had
 invested no effort in the Go aspects of the project and I'm grateful
 to those who have added the Go features for Plan 9 to the Go release.


I think that you can produce a C hello world pretty easily if you
provide stubs for 8l (like morestack and etc.) and use GOOS=plan9 8l
-s to link you stuff together.

Pavel

Re: [9fans] plan9 go output faults on 9vx but ok on cpu

[Pavel Zholkover]

 main9.s sets _tos on entry.  why not just use _tos as
 the c glue code does?

 - erik



I'm already setting _tos on entry:
http://code.google.com/p/go/source/browse/src/pkg/runtime/plan9/386/rt0.s
TEXT _rt0_386_plan9(SB),7, $0
MOVLAX, _tos(SB)

// move arguments down to make room for
// m and g at top of stack, right before Tos.
...

the hard coded addresses are here:
http://code.google.com/p/go/source/browse/src/pkg/runtime/mkasmh.sh
case $GOOS in
...
plan9)
echo '#define   get_tls(r)'
echo '#define   g(r)0xdfffefc0'
echo '#define   m(r)0xdfffefc4'

which are easy enough to modify and here:
http://code.google.com/p/go/source/browse/src/cmd/8l/pass.c
^patch(void)
...
if(HEADTYPE == 2) { // Plan 9
if(p-from.type == D_INDIR+D_GS
 p-to.type = D_AX  p-to.type = D_DI) {
p-as = AMOVL;
p-from.type = D_ADDR+D_STATIC;
p-from.offset += 0xdfffefc0;
}
}

^dostkoff(void)
...
case 2: // Plan 9
p-as = AMOVL;
p-from.type = D_ADDR+D_STATIC;
p-from.offset = 0xdfffefc0;
p-to.type = D_CX;
break;


I am not that familiar with the linker, but maybe calling Sym*
lookup(_tos) and adding some code to to add instructions for
calculating the offset would work.

It was just easier for me to start working on a kvm vm...

Re: [9fans] plan9 go output faults on 9vx but ok on cpu

[Pavel Zholkover]

I'm typing from my phone so I don't have go sources in front of me,
but 0xdfffefc0 looks like the address I used for per thread G and M
structs - just bellow struct Tos.

Andrey and I also tried running on a 32-bit 9vx with the same effect.

Is 9vx using a different memory layout than Plan 9?

On Tuesday, January 11, 2011, Skip Tavakkolian
skip.tavakkol...@gmail.com wrote:
 hell-o.go is like hello.go but uses println. 8.hell-o works properly
 on a plan9 cpu. but it faults when running on 9vx. i built vx32 --
 including 9vx -- on a linux/x86-64 from sources in the last couple of
 days.

 % 8.hell-o
 8.hell-o 270: suicide: sys: trap: page fault pc=0x10bc

 /dev/kprint reports:
 270 8.hell-o: unhandled fault va=dfffefc0 [218f7fc0] eip=10bc
 cpu0: registers for 8.hell-o 270
 FLAGS=0 TRAP=0 ECODE=0 PC=10BC USP=F00
   AX 00018D60  BX 0F8C  CX 00018DF8  DX 0001C608
   SI 0FA8  DI FFF8  BP 

 -Skip

Re: [9fans] plan9 go output faults on 9vx but ok on cpu

[Pavel Zholkover]

I did the runtime port a few month ago, now waiting for
http://codereview.appspot.com/3816043/ to get reviewed and
committed... there are still a bunch of things missing like linking
with symbols, os.ForkExec and environment variables at early runtime.

time package is also not ready, so I can't run the tests yet (I expect
there are a lot of bugs hidden inside :))

Pavel

On Tue, Jan 11, 2011 at 7:51 PM, ron minnich rminn...@gmail.com wrote:
 I did not realize this was currently supported by Plan 9 ... maybe I
 didn't get the memo?

 ron

Re: [9fans] Golang support for Plan 9

[Pavel Zholkover]

On Tue, Dec 28, 2010 at 9:24 AM, Skip Tavakkolian
skip.tavakkol...@gmail.com wrote:
 sorry for the noise; the -s was mentioned in your original post and i
 missed it.  now hell-o example works. i'll try out a few more things.

 i checked out a complete release (fresh copy) earlier today before
 applying the patch; it had the same results (one patch failed to
 apply).
 $ hg identify
 51c777dbccb9+ tip


You were right, I did a clean pull and then tried applying to patch -
it fails on exec.go (not sure what is the cause though).
I'm attaching a diff for the missing file exec_unix.go (it is not
needed for plan9 but all the other os's break without it).

Also if you are brave enough to run cd src/pkg; make clean;
GOOS=plan9 make -k install after building the 8g
toolchain you could import fmt and friends... fmt.Println should even work :)

diff -r 51c777dbccb9 src/pkg/os/exec_unix.go
--- /dev/null   Thu Jan 01 00:00:00 1970 +
+++ b/src/pkg/os/exec_unix.go   Tue Dec 28 22:53:30 2010 +0200
@@ -0,0 +1,148 @@
+// Copyright 2009 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+package os
+
+import (
+   syscall
+)
+
+// ForkExec forks the current process and invokes Exec with the
program, arguments,
+// and environment specified by name, argv, and envv.  It returns the process
+// id of the forked process and an Error, if any.  The fd array specifies the
+// file descriptors to be set up in the new process: fd[0] will be Unix file
+// descriptor 0 (standard input), fd[1] descriptor 1, and so on.  A nil entry
+// will cause the child to have no open file descriptor with that index.
+// If dir is not empty, the child chdirs into the directory before
execing the program.
+func ForkExec(name string, argv []string, envv []string, dir string,
fd []*File) (pid int, err Error) {
+   if envv == nil {
+   envv = Environ()
+   }
+   // Create array of integer (system) fds.
+   intfd := make([]int, len(fd))
+   for i, f := range fd {
+   if f == nil {
+   intfd[i] = -1
+   } else {
+   intfd[i] = f.Fd()
+   }
+   }
+
+   p, e := syscall.ForkExec(name, argv, envv, dir, intfd)
+   if e != 0 {
+   return 0, PathError{fork/exec, name, Errno(e)}
+   }
+   return p, nil
+}
+
+// Exec replaces the current process with an execution of the
+// named binary, with arguments argv and environment envv.
+// If successful, Exec never returns.  If it fails, it returns an Error.
+// ForkExec is almost always a better way to execute a program.
+func Exec(name string, argv []string, envv []string) Error {
+   if envv == nil {
+   envv = Environ()
+   }
+   e := syscall.Exec(name, argv, envv)
+   if e != 0 {
+   return PathError{exec, name, Errno(e)}
+   }
+   return nil
+}
+
+// TODO(rsc): Should os implement its own syscall.WaitStatus
+// wrapper with the methods, or is exposing the underlying one enough?
+//
+// TODO(rsc): Certainly need to have Rusage struct,
+// since syscall one might have different field types across
+// different OS.
+
+// Waitmsg stores the information about an exited process as reported by Wait.
+type Waitmsg struct {
+   Pidint // The process's id.
+   syscall.WaitStatus // System-dependent status info.
+   Rusage *syscall.Rusage // System-dependent resource usage 
info.
+}
+
+// Options for Wait.
+const (
+   WNOHANG   = syscall.WNOHANG  // Don't wait if no process has exited.
+   WSTOPPED  = syscall.WSTOPPED // If set, status of stopped
subprocesses is also reported.
+   WUNTRACED = WSTOPPED
+   WRUSAGE   = 1  20 // Record resource usage.
+)
+
+// WRUSAGE must not be too high a bit, to avoid clashing with Linux's
+// WCLONE, WALL, and WNOTHREAD flags, which sit in the top few bits of
+// the options
+
+// Wait waits for process pid to exit or stop, and then returns a
+// Waitmsg describing its status and an Error, if any. The options
+// (WNOHANG etc.) affect the behavior of the Wait call.
+func Wait(pid int, options int) (w *Waitmsg, err Error) {
+   var status syscall.WaitStatus
+   var rusage *syscall.Rusage
+   if optionsWRUSAGE != 0 {
+   rusage = new(syscall.Rusage)
+   options ^= WRUSAGE
+   }
+   pid1, e := syscall.Wait4(pid, status, options, rusage)
+   if e != 0 {
+   return nil, NewSyscallError(wait, e)
+   }
+   w = new(Waitmsg)
+   w.Pid = pid1
+   w.WaitStatus = status
+   w.Rusage = rusage
+   return w, nil
+}
+
+// Convert i to decimal string.
+func itod(i int) string {
+   if i == 0 {
+   return 0
+   }
+
+   u := uint64(i)
+   if i  0 {
+   u = -u
+   }
+
+   // Assemble decimal in reverse order.
+   

Re: [9fans] Golang support for Plan 9

[Pavel Zholkover]

The patch is against mainline tip, it also applies cleanly against
release.2010-12-22 (and probably a few earlier ones).
What version/release are you patching ?

Did you link with -s (stripped symbols) when compiling on linux ?

On Mon, Dec 27, 2010 at 10:08 PM, Skip Tavakkolian
skip.tavakkol...@gmail.com wrote:
 my hg-fu isn't very good; i'm not sure if this is the right way of
 applying the patch. using patch, one operation fails (it looks like
 the copy isn't done)

 f...@hpamd:~/go$ patch -p1  ../issue3816043_9001.diff
 patching file src/pkg/os/Makefile
 patching file src/pkg/os/dir_plan9.go
 patching file src/pkg/os/env_plan9.go
 patching file src/pkg/os/error.go
 patching file src/pkg/os/error_plan9.go
 patching file src/pkg/os/error_posix.go
 patching file src/pkg/os/exec.go
 patching file src/pkg/os/exec.go
 Hunk #1 FAILED at 146.
 1 out of 1 hunk FAILED -- saving rejects to file src/pkg/os/exec.go.rej
 patching file src/pkg/os/file.go
 patching file src/pkg/os/file_plan9.go
 patching file src/pkg/os/file_posix.go
 patching file src/pkg/os/proc.go
 patching file src/pkg/os/stat_plan9.go
 patching file src/pkg/os/sys_plan9.go
 patching file src/pkg/os/time.go
 patching file src/pkg/runtime/plan9/386/rt0.s
 patching file src/pkg/syscall/Makefile
 patching file src/pkg/syscall/asm_plan9_386.s
 patching file src/pkg/syscall/mkall.sh
 patching file src/pkg/syscall/mksyscall_plan9.awk
 patching file src/pkg/syscall/mksyscall_plan9.sh
 patching file src/pkg/syscall/mksysnum_plan9.sh
 patching file src/pkg/syscall/syscall.go
 patching file src/pkg/syscall/syscall_plan9.go
 patching file src/pkg/syscall/syscall_plan9_386.go
 patching file src/pkg/syscall/syscall_unix.go
 patching file src/pkg/syscall/types_plan9.c
 patching file src/pkg/syscall/zerrors_plan9_386.go
 patching file src/pkg/syscall/zsyscall_plan9_386.go
 patching file src/pkg/syscall/zsysnum_plan9_386.go
 patching file src/pkg/syscall/ztypes_plan9_386.go

 at any rate building on linux targeting plan9 and 386 arch (some tests
 fail), i can generate an output. running it on plan9 causes a
 protection violation:

 cpue% pwd
 /mnt/term/home/fst/test
 cpue% cat hell-o.go
 package main

 func main() {
        println(Hello, 世界)
 }
 cpue% ./8.hell-o
 8.hell-o 19698: suicide: sys: trap: general protection violation pc=0x7047

 -Skip

 On Sun, Dec 26, 2010 at 7:54 AM, Pavel Zholkover paulz...@gmail.com wrote:
 Hi all!

 I've pushed syscall and os package support for Plan 9 on x86 at
 http://codereview.appspot.com/3816043/ (pending a review).
 I had to make changes to the core go files, so keep your fingers
 crossed I didn't break anything along the way and get committed.

 If you have access to a real Plan 9 machine or inside qemu) please
 test (9vx does not seem to work, confirmed by Andrey Mirtchovski for
 early versions of code).

 (Reminder: -s needs to be passed to 8l, otherwise the binaries fail to run).

 Thanks,
 Pavel

[9fans] Golang support for Plan 9

[Pavel Zholkover]

Hi all!

I've pushed syscall and os package support for Plan 9 on x86 at
http://codereview.appspot.com/3816043/ (pending a review).
I had to make changes to the core go files, so keep your fingers
crossed I didn't break anything along the way and get committed.

If you have access to a real Plan 9 machine or inside qemu) please
test (9vx does not seem to work, confirmed by Andrey Mirtchovski for
early versions of code).

(Reminder: -s needs to be passed to 8l, otherwise the binaries fail to run).

Thanks,
Pavel

[9fans] Plan9 development

[Pavel Zholkover]

Hi,
I did a Go runtime port for x86, it is in already in the main hg repository.
Right now it is cross-compile from Linux for example (GOOS=plan9 8l -s
when linking. notice the -s, it is required).

There were a few changes made to the upstream so the following patch
is needed until the fix is committed:
http://codereview.appspot.com/2674041/

Right now I'm working on syscall package.

Pavel