Bootstrapping for Haiku

[jessica.l...@gmail.com]

Hi,

For bootstrapping Go to Haiku, is it required that I do the initial port with 1.4? Can I not just use a current version of Go on another host platform (e.g. Linux), and use an invocation along the lines of:

GOROOT_BOOTSTRAP=/usr/lib/go-1.6 GOOS=haiku GOARCH=amd64 ./bootstrap.bash

This appears to build Go first for the host platform, and then attempts to build for the target platform, which I've been making good progress with.

Considering I'd like to upstream the Haiku port, would it a) actually work not using go1.4 first, and b) be accepted without doing the initial go1.4 port?

Many Thanks,

Jessica

[Ian Lance Taylor]

On Fri, Jun 2, 2017 at 5:20 PM, <jessica.l...@gmail.com> wrote:
>
> For bootstrapping Go to Haiku, is it required that I do the initial port
> with 1.4?

No.

> Can I not just use a current version of Go on another host
> platform (e.g. Linux), and use an invocation along the lines of:
>
> GOROOT_BOOTSTRAP=/usr/lib/go-1.6 GOOS=haiku GOARCH=amd64 ./bootstrap.bash
>
> This appears to build Go first for the host platform, and then attempts to
> build for the target platform, which I've been making good progress with.
>
> Considering I'd like to upstream the Haiku port, would it a) actually work
> not using go1.4 first, and b) be accepted without doing the initial go1.4
> port?

Sure, that is fine. In fact we definitely do not want to see a Go 1.4
port. Go 1.4 is there for people who want to build all the way from
source to avoid the "trusting trust" problem. People who want to
build your port all the way from source would be expected to build Go
1.4 for their preferred target, use that to build a newer version of
Go, and use that to build your port.

A Haiku port sounds cool, hope it works out.

Ian

[Jessica Hamilton]

On 5 June 2017 at 04:44, Bruno Albuquerque <b...@bug-br.org.br> wrote:
> The syscall package is used to expose features that are platform specific
> and would not generally fall into the standard library. The syscall package
> included in the standard library is mostly there to support higher level
> components (like the network package). Note that the syscall package is
> currently frozen and new stuff is being added to golang.org/x/sys (I don't
> think this applies to new platforms but you might need to ask).

Should I still be implementing the syscall package for the new Haiku
platform support?

Documentation says the package is frozen, but it's obviously still
used a lot, so will adding Haiku support be acceptable?

[Brad Fitzpatrick]

You may (and will have to) modify the syscall package.

It's only frozen in the sense that we don't let people add things that aren't strictly needed by the rest of Go.

Optional syscall things should live in x/sys/*

[Jessica Hamilton]

Ah, that makes sense, thanks :)

I now have a new problem with how the zerrors_$GOOS_$GOARCH.go files
implement the errno to string mapping.

Haiku uses negative errno values. However, it also provides a posix
error mapper library to return positive values instead in combination
with -DB_USE_POSITIVE_POSIX_ERRORS.

But even with positive posix errno values, the values are far too large.

E.g. a quick test at golang.org with the following:
package main

import "fmt"

var errors = [...]string{
0: "no error",
2147454916: "no such attribute",
2147454917: "text file busy",
}

func main() {
fmt.Println(errors[2147454916])
}

Gives the error: type [2147454918]string too large

Any suggestions on how to work around this limitation?

[Brad Fitzpatrick]

Don't use an array.

[Russ Cox]

On Fri, Jun 16, 2017 at 2:56 PM, Jessica Hamilton <jessica.l...@gmail.com> wrote:

Haiku uses negative errno values. However, it also provides a posix
error mapper library to return positive values instead in combination
with -DB_USE_POSITIVE_POSIX_ERRORS.

But even with positive posix errno values, the values are far too large.

E.g. a quick test at golang.org with the following:
package main

import "fmt"

var errors = [...]string{
0:          "no error",
2147454916: "no such attribute",
2147454917: "text file busy",
}

Are the negative values reasonably small? Instead of using that flag, try negating the values before returning them from the system call. It's not uncommon for the register result from a system call signaling an error to be a negative errno. On those systems, the Go assembly negates it before returning it. For example, here's syscall.Syscall from asm_linux_amd64.s:

TEXT ·Syscall(SB),NOSPLIT,$0-56

CALL runtime·entersyscall(SB)

MOVQ a1+8(FP), DI

MOVQ a2+16(FP), SI

MOVQ a3+24(FP), DX

MOVQ $0, R10

MOVQ $0, R8

MOVQ $0, R9

MOVQ trap+0(FP), AX // syscall entry

SYSCALL

CMPQ AX, $0xfffffffffffff001

JLS ok

// error path begins here        

MOVQ $-1, r1+32(FP)

MOVQ $0, r2+40(FP)

NEGQ AX

MOVQ AX, err+48(FP)

CALL runtime·exitsyscall(SB)

RET

ok:

MOVQ AX, r1+32(FP)

MOVQ DX, r2+40(FP)

MOVQ $0, err+48(FP)

CALL runtime·exitsyscall(SB)

RET

Assuming the errno values are small, then indexing into an array (after negating the system call return to get a positive errno value) will be fine.

Russ

[r.w.jo...@gmail.com]

Incomplete, but https://play.golang.org/p/fM3OmplCkY.

[Jessica Hamilton]

On 17 June 2017 at 07:15, Russ Cox <r...@golang.org> wrote:
> On Fri, Jun 16, 2017 at 2:56 PM, Jessica Hamilton
> <jessica.l...@gmail.com> wrote:
>>
>> Haiku uses negative errno values. However, it also provides a posix
>> error mapper library to return positive values instead in combination
>> with -DB_USE_POSITIVE_POSIX_ERRORS.
>>
>> But even with positive posix errno values, the values are far too large.
>>
>> E.g. a quick test at golang.org with the following:
>> package main
>>
>> import "fmt"
>>
>> var errors = [...]string{
>> 0: "no error",
>> 2147454916: "no such attribute",
>> 2147454917: "text file busy",
>> }
>
>
> Are the negative values reasonably small? Instead of using that flag, try
> negating the values before returning them from the system call. It's not
> uncommon for the register result from a system call signaling an error to be
> a negative errno. On those systems, the Go assembly negates it before
> returning it.

No, they're not small,
https://github.com/haiku/haiku/blob/master/headers/os/support/Errors.h

Negative values are INT_MIN + value, positive values being -error.

I'm currently trying generating the errors array with e - 0x7fff8000,
with the largest number being 32767. I assume the array won't be
sparse? So this probably still isn't ideal.

But I can't seem to use "runtime/internal/sys" package as an import
with syscalls/syscall_unix.go: use of internal package not allowed

Was trying do something along the lines of

s = errors[e - sys.GoosHaiku * 0x7fff8000]

In: func (e Errno) Error() string

I guess the way forward is to duplicate syscall_unix.go, just for this
one function? And if I go this route, would it be recommended to use a
map instead for the errno => string table?

[Russ Cox]

On Fri, Jun 16, 2017 at 3:54 PM, Jessica Hamilton <jessica.l...@gmail.com> wrote:

I'm currently trying generating the errors array with e - 0x7fff8000,
with the largest number being 32767. I assume the array won't be
sparse? So this probably still isn't ideal.

It's not too bad, at least to get off the ground.

 

But I can't seem to use "runtime/internal/sys" package as an import
with syscalls/syscall_unix.go: use of internal package not allowed

Was trying do something along the lines of

  s = errors[e - sys.GoosHaiku * 0x7fff8000]

Right, syscall can't import runtime/internal/sys. But syscall could itself define a general 'const errnoOffset = 0' for most operating systems and define errnoOffset= 0x7fff8000 for haiku.

I wouldn't jump straight to a map - in general syscall is low-level enough that the simpler the better. If an array can be made to work, that's probably preferred.

Russ

[Matt Harden]

If you really want to keep the array short, a perfect hash function can map the large errno values to small array offsets efficiently.

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Ketelsen]

How far did you get with the Haiku port?