FAQ
Hello,

Here is a quick status report about the progress of native client support
for Go 1.3.

Russ' branch was merged in last week and I/we/us are working on re
debugging it.

Today I'm landing fixes to gc and cc that get the nacl.amd64 build to this
point

% env GOARCH=amd64p32 GOOS=nacl ./make.bash

...

# Building packages and commands for nacl/amd64p32.
runtime
# runtime
doasm: notfound from=75 to=10 00018
(/home/dfc/go/src/pkg/runtime/asm_amd64p32.s:330) MOVL $68719480832,AX
doasm: notfound from=75 to=10 00018
(/home/dfc/go/src/pkg/runtime/asm_amd64p32.s:330) MOVL $68719480832,AX
doasm: notfound from=75 to=10 00033

I *think* this is caused by something like

MOVL $runtime.morestack, AX

but it is a bit hard to tell because of the heavy macro use in that file.
My guess is the address of $runtime.morestack is a 64bit value (it's
certainly bigger than a normal 32bit offset) so 6a cannot move a 64bit
immediate value with MOVL.

The nacl/386 build also fails at about the same point in the build, but I
haven't focused on that this week.

Cheers

Dave

--

---
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Russ Cox at Mar 6, 2014 at 11:53 pm
    The problem with that instruction is that MOVL is a 32-bit move and 68719480832
    is not a 32-bit value.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Mar 6, 2014 at 11:55 pm
    I'm thinking the bug is in 6a, because it can't be referencing any symbol
    outside the .s file it is compiling.

    I'll have another read through your branch and see if there was anything
    that I missed when merging cmd/6a.

    On Fri, Mar 7, 2014 at 10:53 AM, Russ Cox wrote:

    The problem with that instruction is that MOVL is a 32-bit move and 68719480832
    is not a 32-bit value.
    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 7, 2014 at 6:42 am

    2014-03-07 0:55 GMT+01:00 Dave Cheney <dave@cheney.net>:
    I'm thinking the bug is in 6a, because it can't be referencing any symbol
    outside the .s file it is compiling.

    I'll have another read through your branch and see if there was anything
    that I missed when merging cmd/6a.

    On Fri, Mar 7, 2014 at 10:53 AM, Russ Cox wrote:

    The problem with that instruction is that MOVL is a 32-bit move and
    68719480832 is not a 32-bit value.
    I think this is the fix:
    https://codereview.appspot.com/72360044

    Rémy.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Mar 7, 2014 at 6:59 am
    Thanks Remy. I'm not 100% sure that is correct, the amd64p32 model is a bit
    weird, I'm not 100% sure if the PC can be above the 4gb boundary.

    With your fix applied I get a bit further

    # time
    pkg/time/format.go:724: internal compiler error: twobitwalktype1: invalid
    initial alignment, Time
    image/color/palette
    math/cmplx
    runtime/race
    reflect
    crypto
    encoding/base64
    crypto/md5
    # crypto/md5
    pkg/crypto/md5/md5block_generic.go:9: block redeclared in this block
             previous declaration at pkg/crypto/md5/md5block_decl.go:11
    regexp/syntax
    net/url
    crypto/aes
    crypto/rc4
    crypto/sha1
    crypto/sha256
    # crypto/sha1
    pkg/crypto/sha1/sha1block_generic.go:9: block redeclared in this block
             previous declaration at pkg/crypto/sha1/sha1block_decl.go:11


    I'll tackle the bottom two. Do you have any idea about the first error ?

    On Fri, Mar 7, 2014 at 5:42 PM, Rémy Oudompheng wrote:

    2014-03-07 0:55 GMT+01:00 Dave Cheney <dave@cheney.net>:
    I'm thinking the bug is in 6a, because it can't be referencing any symbol
    outside the .s file it is compiling.

    I'll have another read through your branch and see if there was anything
    that I missed when merging cmd/6a.

    On Fri, Mar 7, 2014 at 10:53 AM, Russ Cox wrote:

    The problem with that instruction is that MOVL is a 32-bit move and
    68719480832 is not a 32-bit value.
    I think this is the fix:
    https://codereview.appspot.com/72360044

    Rémy.
    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 7, 2014 at 7:22 am

    2014-03-07 7:59 GMT+01:00 Dave Cheney <dave@cheney.net>:
    Thanks Remy. I'm not 100% sure that is correct, the amd64p32 model is a bit
    weird, I'm not 100% sure if the PC can be above the 4gb boundary.
    It is not a PC above a 4gb boundary : actually it's not a PC at all
    nor a pointer. It's the argument to morestack11, which holds the frame
    size and arg size (32-bit numbers combined in a 64-bit register for
    convenience), not the address of the function.

    Rémy.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 7, 2014 at 7:21 pm

    2014-03-07 7:59 GMT+01:00 Dave Cheney <dave@cheney.net>:
    Thanks Remy. I'm not 100% sure that is correct, the amd64p32 model is a bit
    weird, I'm not 100% sure if the PC can be above the 4gb boundary.

    With your fix applied I get a bit further

    # time
    pkg/time/format.go:724: internal compiler error: twobitwalktype1: invalid
    initial alignment, Time
    image/color/palette
    math/cmplx
    runtime/race
    reflect
    crypto
    encoding/base64
    crypto/md5
    # crypto/md5
    pkg/crypto/md5/md5block_generic.go:9: block redeclared in this block
    previous declaration at pkg/crypto/md5/md5block_decl.go:11
    regexp/syntax
    net/url
    crypto/aes
    crypto/rc4
    crypto/sha1
    crypto/sha256
    # crypto/sha1
    pkg/crypto/sha1/sha1block_generic.go:9: block redeclared in this block
    previous declaration at pkg/crypto/sha1/sha1block_decl.go:11


    I'll tackle the bottom two. Do you have any idea about the first error ?
    The first error is avoided by:
    https://codereview.appspot.com/72270046

    Rémy.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 7, 2014 at 10:47 pm

    2014-03-07 0:42 GMT+01:00 Dave Cheney <dave@cheney.net>:
    Hello,

    Here is a quick status report about the progress of native client support
    for Go 1.3.

    Russ' branch was merged in last week and I/we/us are working on re debugging
    it.
    The runtime merge seems still a bit incomplete. What are the next steps ?

    Rémy.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Mar 8, 2014 at 12:54 am
    Hi Remy,

    Thank you for your assistance getting nacl building to this stage.
    The runtime merge seems still a bit incomplete. What are the next steps ?
    Yes, there look like there are some bits missing, see my comments inline

    # runtime
    unaligned stack size 12

    Hmm, this is new, or new from the last 24-48 hours, Remy do you think
    you could look into this ?

    # net
    pkg/net/fd_unix.go:109: undefined: syscall.SO_ERROR

    This should be pretty easy to fix, I'll take a look this evening

    # cmd/nm
    runtime.MSpan_Sweep: undefined: runtime.SysFault // maybe this is a
    new symbol in 1.3, otherwise it got lost in the merge from the branch.
    I'll take a look
    readgogc: undefined: runtime.getenv // I think this showed up when 1.3
    opened in december, I'll take a look this evening.
    runtime.schedinit: undefined: runtime.getenv
    runtime.schedinit: undefined: runtime.getenv
    runtime.gotraceback: undefined: runtime.getenv
    runtime.parsedebugvars: undefined: runtime.getenv
    runtime.free: undefined: runtime.SysFault
    runtime.getgoroot: undefined: runtime.getenv
    runtime.write: undefined: runtime.timens // this is new in 1.3, part
    of the CLOCK_MONOTONIC change
    time.now: undefined: runtime.timens
    runtime.nanotime: undefined: runtime.timens
    runtime.sigtramp: undefined: runtime.sighandler

    I think Brad was looking into getting nacl/amd64p32 and nacl/386
    builders running on the current linux/* builders. I can host a
    temporary set of builders in a vm if needed.

    Cheers

    Dave

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Mar 8, 2014 at 4:06 am
    https://codereview.appspot.com/72780043/ and
    https://codereview.appspot.com/72790043 fix most of the runtime errors.
    Still chasing runtime.timens.

    On Sat, Mar 8, 2014 at 11:54 AM, Dave Cheney wrote:

    Hi Remy,

    Thank you for your assistance getting nacl building to this stage.
    The runtime merge seems still a bit incomplete. What are the next steps ?
    Yes, there look like there are some bits missing, see my comments inline

    # runtime
    unaligned stack size 12

    Hmm, this is new, or new from the last 24-48 hours, Remy do you think
    you could look into this ?

    # net
    pkg/net/fd_unix.go:109: undefined: syscall.SO_ERROR

    This should be pretty easy to fix, I'll take a look this evening

    # cmd/nm
    runtime.MSpan_Sweep: undefined: runtime.SysFault // maybe this is a
    new symbol in 1.3, otherwise it got lost in the merge from the branch.
    I'll take a look
    readgogc: undefined: runtime.getenv // I think this showed up when 1.3
    opened in december, I'll take a look this evening.
    runtime.schedinit: undefined: runtime.getenv
    runtime.schedinit: undefined: runtime.getenv
    runtime.gotraceback: undefined: runtime.getenv
    runtime.parsedebugvars: undefined: runtime.getenv
    runtime.free: undefined: runtime.SysFault
    runtime.getgoroot: undefined: runtime.getenv
    runtime.write: undefined: runtime.timens // this is new in 1.3, part
    of the CLOCK_MONOTONIC change
    time.now: undefined: runtime.timens
    runtime.nanotime: undefined: runtime.timens
    runtime.sigtramp: undefined: runtime.sighandler

    I think Brad was looking into getting nacl/amd64p32 and nacl/386
    builders running on the current linux/* builders. I can host a
    temporary set of builders in a vm if needed.

    Cheers

    Dave
    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 9, 2014 at 10:39 am

    On 2014-03-08 5:06 GMT+01:00 Dave Cheney wrote:
    https://codereview.appspot.com/72780043/ and
    https://codereview.appspot.com/72790043 fix most of the runtime errors.
    Still chasing runtime.timens.

    On Sat, Mar 8, 2014 at 11:54 AM, Dave Cheney wrote:

    Hi Remy,

    Thank you for your assistance getting nacl building to this stage.
    The runtime merge seems still a bit incomplete. What are the next steps
    ?
    Yes, there look like there are some bits missing, see my comments inline

    # runtime
    unaligned stack size 12

    Hmm, this is new, or new from the last 24-48 hours, Remy do you think
    you could look into this ?

    # net
    pkg/net/fd_unix.go:109: undefined: syscall.SO_ERROR

    This should be pretty easy to fix, I'll take a look this evening

    # cmd/nm
    runtime.MSpan_Sweep: undefined: runtime.SysFault // maybe this is a
    new symbol in 1.3, otherwise it got lost in the merge from the branch.
    I'll take a look
    readgogc: undefined: runtime.getenv // I think this showed up when 1.3
    opened in december, I'll take a look this evening.
    runtime.schedinit: undefined: runtime.getenv
    runtime.schedinit: undefined: runtime.getenv
    runtime.gotraceback: undefined: runtime.getenv
    runtime.parsedebugvars: undefined: runtime.getenv
    runtime.free: undefined: runtime.SysFault
    runtime.getgoroot: undefined: runtime.getenv
    runtime.write: undefined: runtime.timens // this is new in 1.3, part
    of the CLOCK_MONOTONIC change
    time.now: undefined: runtime.timens
    runtime.nanotime: undefined: runtime.timens
    runtime.sigtramp: undefined: runtime.sighandler

    I think Brad was looking into getting nacl/amd64p32 and nacl/386
    builders running on the current linux/* builders. I can host a
    temporary set of builders in a vm if needed.

    Cheers

    Dave

    How do you run the generated binaries ? I tried tools/sel_ldr.py from
    the SDK but it doesn't work.

    Rémy.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Minux at Mar 9, 2014 at 8:15 pm

    On Sun, Mar 9, 2014 at 6:39 AM, Rémy Oudompheng wrote:

    How do you run the generated binaries ? I tried tools/sel_ldr.py from
    the SDK but it doesn't work.
    https://codereview.appspot.com/68730043/#msg4

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Mar 12, 2014 at 9:12 pm
    Hello,

    As of a few minutes ago both nacl/amd64p32 and nacl/386 builders were
    passing ./make.bash. Thanks to Remy, Brad, Russ and Minux for their
    help getting this far. This is a good milestone, but not the whole
    story,

    nacl/amd64p32 - each binary segfaults very early on in the process,
    looks like something is wrong with syscall.naclWrite
    nacl/386 - the binaries do not pass validation.

    I have started https://codereview.appspot.com/75080043 which adds some
    instructions and support scripts to help others experiment with nacl.
    Both the instructions and the scripts need improvement before they
    land, but hey, it's a start.

    Cheers

    Dave
    On Mon, Mar 10, 2014 at 7:15 AM, minux wrote:
    On Sun, Mar 9, 2014 at 6:39 AM, Rémy Oudompheng wrote:

    How do you run the generated binaries ? I tried tools/sel_ldr.py from
    the SDK but it doesn't work.
    https://codereview.appspot.com/68730043/#msg4
    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 12, 2014 at 10:38 pm

    2014-03-12 22:12 GMT+01:00 Dave Cheney <dave@cheney.net>:
    Hello,

    As of a few minutes ago both nacl/amd64p32 and nacl/386 builders were
    passing ./make.bash. Thanks to Remy, Brad, Russ and Minux for their
    help getting this far. This is a good milestone, but not the whole
    story,

    nacl/amd64p32 - each binary segfaults very early on in the process,
    I'm stuck in the debugging. It looks like it crashes in
    runtime.gc_m_ptr during early setup.
    In rsc's original branch the binaries don't crash. I can't find
    anything strange in the assembly:

    func gc_m_ptr(ret *interface{}) {
         *ret = (*m)(nil)
    }

    0000000000021bc0 <runtime.gc_m_ptr>:
        21bc0: 83 ec 08 sub $0x8,%esp
        21bc3: 4c 01 fc add %r15,%rsp
        21bc6: 48 31 c0 xor %rax,%rax
        21bc9: 48 c7 c1 02 00 00 00 mov $0x2,%rcx
        21bd0: 48 8d 3c 24 lea (%rsp),%rdi
        21bd4: 89 ff mov %edi,%edi
        21bd6: 49 8d 3c 3f lea (%r15,%rdi,1),%rdi
        21bda: f3 48 ab rep stos %rax,%es:(%rdi)
        21bdd: 31 c9 xor %ecx,%ecx
        21bdf: 90 nop
        21be0: 8b 5c 24 10 mov 0x10(%rsp),%ebx
        21be4: 8d 05 d6 c6 13 00 lea 0x13c6d6(%rip),%eax
        # 15e2c0 <rodata+0xe2c0>
        21bea: 89 db mov %ebx,%ebx
        21bec: 41 89 04 1f mov %eax,(%r15,%rbx,1)
        21bf0: 89 db mov %ebx,%ebx
        21bf2: 41 89 4c 1f 04 mov %ecx,0x4(%r15,%rbx,1)
        21bf7: 83 c4 08 add $0x8,%esp
        21bfa: 4c 01 fc add %r15,%rsp
        21bfd: 0f 1f 00 nopl (%rax)
        21c00: 5e pop %rsi
        21c01: 83 e6 e0 and $0xffffffe0,%esi
        21c04: 4c 01 fe add %r15,%rsi
        21c07: ff e6 jmpq *%rsi
        21c09: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
        21c10: 00 00
        21c12: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
        21c19: 00 00
        21c1b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Mar 12, 2014 at 11:19 pm
    Nothing jumps out at me. Do you know where it is crashing?
    If you run the binary using sel_ldr -g, then you can run gdb and
    say 'target remote :4014' to connect to the sel_ldr stub with gdb
    and run the program that way. I've never done this but I'm told
    it works. (I didn't find out about this until I was done.)

    Russ

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 13, 2014 at 6:06 am

    2014-03-13 0:19 GMT+01:00 Russ Cox <rsc@golang.org>:
    Nothing jumps out at me. Do you know where it is crashing?
    If you run the binary using sel_ldr -g, then you can run gdb and
    say 'target remote :4014' to connect to the sel_ldr stub with gdb
    and run the program that way. I've never done this but I'm told
    it works. (I didn't find out about this until I was done.)

    I think it is crashing in the return instruction of gc_m_ptr:

    0000000000021bc0 <runtime.gc_m_ptr>:
    [...]
        21bf7: 83 c4 08 add $0x8,%esp
        21bfa: 4c 01 fc add %r15,%rsp
        21bfd: 0f 1f 00 nopl (%rax)
        21c00: 5e pop %rsi
        21c01: 83 e6 e0 and $0xffffffe0,%esi
        21c04: 4c 01 fe add %r15,%rsi
        21c07: ff e6 jmpq *%rsi

    Here is what I observe in gdb:
    (gdb) info reg
    rax 0x15e2c0 1434304
    rbx 0xfeef0f3c 4277079868
    rcx 0x0 0
    rdx 0x0 0
    rsi 0x144400000000 22282290331648
    rdi 0x1444feef0f30 22286567411504
    rbp 0x144400298be0 0x144400298be0
    rsp 0x1444feef0f30 0x1444feef0f30
    r8 0x0 0
    r9 0x0 0
    r10 0x0 0
    r11 0x1444000569e0 22282290686432
    r12 0x0 0
    r13 0x0 0
    r14 0x0 0
    r15 0x144400000000 22282290331648
    rip 0x144400000000 0x144400000000
    (gdb) x/32xw 0x1444feef0f20
    0x1444feef0f20: 0x00000000 0x00000000 0x00000000 0x00000000
    0x1444feef0f30: 0xfeef0f3c 0xfeef0f3c 0x00293d9f 0x0015e2c0
    0x1444feef0f40: 0x00000000 0x00000001 0x00036760 0x00001444
    0x1444feef0f50: 0x00000000 0x0003bba0 0x00000004 0xfeef0f90
    0x1444feef0f60: 0x00000000 0x00293b18 0x000339c0 0x00001444
    0x1444feef0f70: 0x00293b0e 0xfeef0f8c 0x00000000 0x00000000
    0x1444feef0f80: 0x00034ce0 0x00001444 0x0003bba0 0x00000000
    0x1444feef0f90: 0x00000000 0x00000000 0x00000000 0x00000000

    0x36760 (at 0xfeef0f4c) is the return address of call allocm in newm.
    0x34ce0 (at 0xfeef0f80) is the return address of call newm un runtime.main

    I don't see anywhere the return address of allocm->gc_m_ptr(0xfeef0f3c)
    [a printf in the runtime shows it is indeed the *interface{} argument].
    Also 0xfeef0f3c is already filled with the type pointer 15e2c0.

    Oh, I think I understand. The return address was probably stored at
    0x1444feef0f28.
    For some reason, at entry in gc_m_ptr we do:

    0000000000021bc0 <runtime.gc_m_ptr>:
        21bc0: 83 ec 08 sub $0x8,%esp
        21bc3: 4c 01 fc add %r15,%rsp
        21bc6: 48 31 c0 xor %rax,%rax
        21bc9: 48 c7 c1 02 00 00 00 mov $0x2,%rcx
        21bd0: 48 8d 3c 24 lea (%rsp),%rdi
        21bd4: 89 ff mov %edi,%edi
        21bd6: 49 8d 3c 3f lea (%r15,%rdi,1),%rdi
        21bda: f3 48 ab rep stos %rax,%es:(%rdi)

    thus zeroing it. Then it crashes by trying to jump at 0x0 (actually
    R15+0x0). And there is a bug in 6g: the stack zeroing code counts how
    many pointer-sized words it must clear but then uses REP STOSQ
    inconditionally to do it, and corrupts the stack.

    Rémy.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 13, 2014 at 6:42 am

    2014-03-13 7:06 GMT+01:00 Rémy Oudompheng <remyoudompheng@gmail.com>:
    For some reason, at entry in gc_m_ptr we do:

    0000000000021bc0 <runtime.gc_m_ptr>:
    21bc0: 83 ec 08 sub $0x8,%esp
    21bc3: 4c 01 fc add %r15,%rsp
    21bc6: 48 31 c0 xor %rax,%rax
    21bc9: 48 c7 c1 02 00 00 00 mov $0x2,%rcx
    21bd0: 48 8d 3c 24 lea (%rsp),%rdi
    21bd4: 89 ff mov %edi,%edi
    21bd6: 49 8d 3c 3f lea (%r15,%rdi,1),%rdi
    21bda: f3 48 ab rep stos %rax,%es:(%rdi)

    thus zeroing it. Then it crashes by trying to jump at 0x0 (actually
    R15+0x0). And there is a bug in 6g: the stack zeroing code counts how
    many pointer-sized words it must clear but then uses REP STOSQ
    inconditionally to do it, and corrupts the stack.
    Dave, can you try https://codereview.appspot.com/75240043/ ?
    Now instead of crashing binaries we have a dozen of compiler bugs to fix :)

    Rémy.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Mar 13, 2014 at 6:57 am
    Replied. That certainly fixed the problem, nice catch that stack
    zeroing was wiping 2x to much stack.

    I'm looking at the left over pieces from
    https://codereview.appspot.com/15680044/, specifically reflect and
    feeling out of my depth. The relect/* changes didn't merge cleanly as
    much of that file has been rewritten for 1.3

    On Thu, Mar 13, 2014 at 5:42 PM, Rémy Oudompheng
    wrote:
    2014-03-13 7:06 GMT+01:00 Rémy Oudompheng <remyoudompheng@gmail.com>:
    For some reason, at entry in gc_m_ptr we do:

    0000000000021bc0 <runtime.gc_m_ptr>:
    21bc0: 83 ec 08 sub $0x8,%esp
    21bc3: 4c 01 fc add %r15,%rsp
    21bc6: 48 31 c0 xor %rax,%rax
    21bc9: 48 c7 c1 02 00 00 00 mov $0x2,%rcx
    21bd0: 48 8d 3c 24 lea (%rsp),%rdi
    21bd4: 89 ff mov %edi,%edi
    21bd6: 49 8d 3c 3f lea (%r15,%rdi,1),%rdi
    21bda: f3 48 ab rep stos %rax,%es:(%rdi)

    thus zeroing it. Then it crashes by trying to jump at 0x0 (actually
    R15+0x0). And there is a bug in 6g: the stack zeroing code counts how
    many pointer-sized words it must clear but then uses REP STOSQ
    inconditionally to do it, and corrupts the stack.
    Dave, can you try https://codereview.appspot.com/75240043/ ?
    Now instead of crashing binaries we have a dozen of compiler bugs to fix :)

    Rémy.
    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Mar 13, 2014 at 8:02 am
    Some good progress, thanks Remy!

    lucky(~/src) % env GOARCH=amd64p32 GOOS=nacl go run whoami.go
    Hello from nacl/amd64p32

    Looks like most of https://codereview.appspot.com/15540045 was merged
    correctly, which is good.

    A lot of the test failures relate to the missing filesystem support
    which I'll try to address by getting everyone to switch to these
    loader scripts when they land, https://codereview.appspot.com/75080043

    Cheers

    Dave
    On Thu, Mar 13, 2014 at 5:57 PM, Dave Cheney wrote:
    Replied. That certainly fixed the problem, nice catch that stack
    zeroing was wiping 2x to much stack.

    I'm looking at the left over pieces from
    https://codereview.appspot.com/15680044/, specifically reflect and
    feeling out of my depth. The relect/* changes didn't merge cleanly as
    much of that file has been rewritten for 1.3

    On Thu, Mar 13, 2014 at 5:42 PM, Rémy Oudompheng
    wrote:
    2014-03-13 7:06 GMT+01:00 Rémy Oudompheng <remyoudompheng@gmail.com>:
    For some reason, at entry in gc_m_ptr we do:

    0000000000021bc0 <runtime.gc_m_ptr>:
    21bc0: 83 ec 08 sub $0x8,%esp
    21bc3: 4c 01 fc add %r15,%rsp
    21bc6: 48 31 c0 xor %rax,%rax
    21bc9: 48 c7 c1 02 00 00 00 mov $0x2,%rcx
    21bd0: 48 8d 3c 24 lea (%rsp),%rdi
    21bd4: 89 ff mov %edi,%edi
    21bd6: 49 8d 3c 3f lea (%r15,%rdi,1),%rdi
    21bda: f3 48 ab rep stos %rax,%es:(%rdi)

    thus zeroing it. Then it crashes by trying to jump at 0x0 (actually
    R15+0x0). And there is a bug in 6g: the stack zeroing code counts how
    many pointer-sized words it must clear but then uses REP STOSQ
    inconditionally to do it, and corrupts the stack.
    Dave, can you try https://codereview.appspot.com/75240043/ ?
    Now instead of crashing binaries we have a dozen of compiler bugs to fix :)

    Rémy.
    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Mar 13, 2014 at 1:43 pm
    thanks very much for getting this working. you have been doing an amazing
    job.

    i have some code i never checked in that prepares the file system image you
    need to run all.bash. i'll dig it up.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Mar 14, 2014 at 11:12 pm

    On 14 Mar 2014, at 0:42, Russ Cox wrote:

    thanks very much for getting this working. you have been doing an amazing job.
    Thanks for your kind words Russ. The credit goes to Rémy who took what I had merged and has run with it

    Cheers

    Dave
    i have some code i never checked in that prepares the file system image you need to run all.bash. i'll dig it up.
    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 25, 2014 at 8:50 pm

    2014-03-13 14:42 GMT+01:00 Russ Cox <rsc@golang.org>:
    thanks very much for getting this working. you have been doing an amazing
    job.

    i have some code i never checked in that prepares the file system image you
    need to run all.bash. i'll dig it up.
    Hello Russ,

    Did you manage to find that code ? I think all.bash is very near from
    fully passing.

    Thanks,
    Rémy.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Mar 27, 2014 at 7:09 pm
    CL https://codereview.appspot.com/81290044 has the code I used to make a
    zip file that would pass the tests.
    Presumably we could ship a script like this in misc/nacl (and the mkzip.go
    program can be copied there too) and have the nacl builder run it before
    all.bash.
    mkzip is from code.google.com/p/rsc/cmd/mkzip.

    here are the files referred to by the proto file from /Users/rsc:

    g% cat ~/empty
    g% cat ~/group
    nobody:*:-2:
    nogroup:*:-1:
    wheel:*:0:root
    daemon:*:1:root
    kmem:*:2:root
    sys:*:3:root
    tty:*:4:root
    operator:*:5:root
    g% cat ~/hosts
    127.0.0.1 localhost
    g%

    russ

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 14, 2014 at 7:34 am

    2014-03-13 9:02 GMT+01:00 Dave Cheney <dave@cheney.net>:
    Some good progress, thanks Remy!

    lucky(~/src) % env GOARCH=amd64p32 GOOS=nacl go run whoami.go
    Hello from nacl/amd64p32

    Looks like most of https://codereview.appspot.com/15540045 was merged
    correctly, which is good.

    A lot of the test failures relate to the missing filesystem support
    which I'll try to address by getting everyone to switch to these
    loader scripts when they land, https://codereview.appspot.com/75080043

    Cheers

    Dave
    A large number of runtime issues are caused by CL 15790043
    (https://code.google.com/r/rsc-go13nacl/source/detail?r=8d31081ea) not
    being merged. Many calls into the C runtime are misaligned and cause
    corruptions and segfaults whenever a map is accessed.
    Will you handle merging it ?

    Rémy.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 14, 2014 at 8:09 am

    2014-03-14 8:34 GMT+01:00 Rémy Oudompheng <remyoudompheng@gmail.com>:
    2014-03-13 9:02 GMT+01:00 Dave Cheney <dave@cheney.net>:
    Some good progress, thanks Remy!

    lucky(~/src) % env GOARCH=amd64p32 GOOS=nacl go run whoami.go
    Hello from nacl/amd64p32

    Looks like most of https://codereview.appspot.com/15540045 was merged
    correctly, which is good.

    A lot of the test failures relate to the missing filesystem support
    which I'll try to address by getting everyone to switch to these
    loader scripts when they land, https://codereview.appspot.com/75080043

    Cheers

    Dave
    A large number of runtime issues are caused by CL 15790043
    (https://code.google.com/r/rsc-go13nacl/source/detail?r=8d31081ea) not
    being merged. Many calls into the C runtime are misaligned and cause
    corruptions and segfaults whenever a map is accessed.
    Will you handle merging it ?
    Oh actually, there weren't so many things missing. I have written
    https://codereview.appspot.com/75820044.

    test/run.go runs essentially out of the box (compile using host arch,
    then run with GOOS=nacl GOARCH=amd64p32).

    There are only 3 failures left:

    % GOARCH=amd64p32 GOOS=nacl ./run
    # go run run.go -- env.go
    incorrect output
    $GOARCH=!= runtime.GOARCH=amd64p32
    exit status 1

    FAIL env.go 0.192s
    # go run run.go -- sizeof.go
    incorrect output
    # command-line-arguments
    0 0
    1 0
    2 0
    3 40adc5
    4 0
    5 0
    6 0
    7 0
    8 40adc5
    9 40adc5
    10 40adc5
    11 40adc5
    12 40adc5
    13 40b395
    14 40b3d0
    15 0
    ./sizeof.go:1: internal compiler error: out of fixed registers

    FAIL sizeof.go 0.092s
    # go run run.go -- chan/select5.go
    incorrect output
    fatal error: all goroutines are asleep - deadlock!

    goroutine 16 [select (no cases)]:
    main.init·5()
         /tmp/310793298/tmp__.go:95588 +0x40
    main.init()
         /tmp/310793298/tmp__.go:105824 +0x1a0
    exit status 2

    FAIL chan/select5.go 6.114s

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Mar 14, 2014 at 8:21 am

    On 14 Mar 2014, at 19:09, Rémy Oudompheng wrote:

    2014-03-14 8:34 GMT+01:00 Rémy Oudompheng <remyoudompheng@gmail.com>:
    2014-03-13 9:02 GMT+01:00 Dave Cheney <dave@cheney.net>:
    Some good progress, thanks Remy!

    lucky(~/src) % env GOARCH=amd64p32 GOOS=nacl go run whoami.go
    Hello from nacl/amd64p32

    Looks like most of https://codereview.appspot.com/15540045 was merged
    correctly, which is good.

    A lot of the test failures relate to the missing filesystem support
    which I'll try to address by getting everyone to switch to these
    loader scripts when they land, https://codereview.appspot.com/75080043

    Cheers

    Dave
    A large number of runtime issues are caused by CL 15790043
    (https://code.google.com/r/rsc-go13nacl/source/detail?r=8d31081ea) not
    being merged. Many calls into the C runtime are misaligned and cause
    corruptions and segfaults whenever a map is accessed.
    Will you handle merging it ?
    Oh actually, there weren't so many things missing. I have written
    https://codereview.appspot.com/75820044.
    Sorry for the short reply, I'll reply more later. That CL was mostly superceeded by a change Russ landed out of sequence as it involved some tricky changes to the .goc processing.
    test/run.go runs essentially out of the box (compile using host arch,
    then run with GOOS=nacl GOARCH=amd64p32).

    There are only 3 failures left:

    % GOARCH=amd64p32 GOOS=nacl ./run
    # go run run.go -- env.go
    incorrect output
    $GOARCH=!= runtime.GOARCH=amd64p32
    exit status 1

    FAIL env.go 0.192s
    # go run run.go -- sizeof.go
    incorrect output
    # command-line-arguments
    0 0
    1 0
    2 0
    3 40adc5
    4 0
    5 0
    6 0
    7 0
    8 40adc5
    9 40adc5
    10 40adc5
    11 40adc5
    12 40adc5
    13 40b395
    14 40b3d0
    15 0
    ./sizeof.go:1: internal compiler error: out of fixed registers

    FAIL sizeof.go 0.092s
    # go run run.go -- chan/select5.go
    incorrect output
    fatal error: all goroutines are asleep - deadlock!

    goroutine 16 [select (no cases)]:
    main.init·5()
    /tmp/310793298/tmp__.go:95588 +0x40
    main.init()
    /tmp/310793298/tmp__.go:105824 +0x1a0
    exit status 2

    FAIL chan/select5.go 6.114s
    Great result. Are you using the scripts in misc/nacl I mailed this morning.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 14, 2014 at 9:27 pm

    2014-03-14 9:09 GMT+01:00 Rémy Oudompheng <remyoudompheng@gmail.com>:
    2014-03-14 8:34 GMT+01:00 Rémy Oudompheng <remyoudompheng@gmail.com>:
    2014-03-13 9:02 GMT+01:00 Dave Cheney <dave@cheney.net>:
    Some good progress, thanks Remy!

    lucky(~/src) % env GOARCH=amd64p32 GOOS=nacl go run whoami.go
    Hello from nacl/amd64p32

    Looks like most of https://codereview.appspot.com/15540045 was merged
    correctly, which is good.

    A lot of the test failures relate to the missing filesystem support
    which I'll try to address by getting everyone to switch to these
    loader scripts when they land, https://codereview.appspot.com/75080043

    Cheers

    Dave
    A large number of runtime issues are caused by CL 15790043
    (https://code.google.com/r/rsc-go13nacl/source/detail?r=8d31081ea) not
    being merged. Many calls into the C runtime are misaligned and cause
    corruptions and segfaults whenever a map is accessed.
    Will you handle merging it ?
    Oh actually, there weren't so many things missing. I have written
    https://codereview.appspot.com/75820044.

    test/run.go runs essentially out of the box (compile using host arch,
    then run with GOOS=nacl GOARCH=amd64p32).

    There are only 3 failures left:

    % GOARCH=amd64p32 GOOS=nacl ./run
    # go run run.go -- env.go
    # go run run.go -- sizeof.go
    # go run run.go -- chan/select5.go
    On 386 the situation is better. test/run completes successfully:

    % GOARCH=386 GOOS=nacl ./run -show_skips
    skip mapnan.go : +build darwin linux
    skip fixedbugs/bug385_64.go: +build amd64
    skip fixedbugs/issue6036.go: +build amd64

    This requires:
    https://codereview.appspot.com/76050044 (already submitted)
    https://codereview.appspot.com/76250043 (pending)

    Rémy.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Mar 14, 2014 at 2:54 pm

    On Wed, Mar 12, 2014 at 11:57 PM, Dave Cheney wrote:
    I'm looking at the left over pieces from
    https://codereview.appspot.com/15680044/, specifically reflect and
    feeling out of my depth. The relect/* changes didn't merge cleanly as
    much of that file has been rewritten for 1.3
    I believe the correct fix for the reflect change is rather simpler:
    https://codereview.appspot.com/76090043 . But I have not tried to
    test this. And it's not clear to me that this fixes any existing
    failures--if not, it might be interesting to figure out why not.

    Ian

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dave Cheney at Mar 14, 2014 at 10:53 pm
    Thanks Ian, that does look simpler.
    On 15 Mar 2014, at 1:54, Ian Lance Taylor wrote:

    On Wed, Mar 12, 2014 at 11:57 PM, Dave Cheney wrote:

    I'm looking at the left over pieces from
    https://codereview.appspot.com/15680044/, specifically reflect and
    feeling out of my depth. The relect/* changes didn't merge cleanly as
    much of that file has been rewritten for 1.3
    I believe the correct fix for the reflect change is rather simpler:
    https://codereview.appspot.com/76090043 . But I have not tried to
    test this. And it's not clear to me that this fixes any existing
    failures--if not, it might be interesting to figure out why not.

    Ian
    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Lance Taylor at Mar 14, 2014 at 10:54 pm

    On Fri, Mar 14, 2014 at 3:53 PM, Dave Cheney wrote:
    Thanks Ian, that does look simpler.
    Let me know if you think it's needed, it sounds like all the tests are
    passing anyhow.

    Ian

    On 15 Mar 2014, at 1:54, Ian Lance Taylor wrote:

    On Wed, Mar 12, 2014 at 11:57 PM, Dave Cheney wrote:

    I'm looking at the left over pieces from
    https://codereview.appspot.com/15680044/, specifically reflect and
    feeling out of my depth. The relect/* changes didn't merge cleanly as
    much of that file has been rewritten for 1.3
    I believe the correct fix for the reflect change is rather simpler:
    https://codereview.appspot.com/76090043 . But I have not tried to
    test this. And it's not clear to me that this fixes any existing
    failures--if not, it might be interesting to figure out why not.

    Ian
    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 15, 2014 at 4:45 pm

    2014-03-14 23:54 GMT+01:00 Ian Lance Taylor <iant@golang.org>:
    On Fri, Mar 14, 2014 at 3:53 PM, Dave Cheney wrote:
    Thanks Ian, that does look simpler.
    Let me know if you think it's needed, it sounds like all the tests are
    passing anyhow.

    Ian
    This CL only fixes GC instructions for the argument layout struct used
    in reflect calls. rsc's original patch is needed to fix padding
    convention when calling functions from reflect.

    One of the resulting failures is the chan/select5.go one:

    # go run run.go -- chan/select5.go
    incorrect output
    fatal error: all goroutines are asleep - deadlock!

    goroutine 16 [select (no cases)]:
    main.init·5()
         /tmp/310793298/tmp__.go:95588 +0x40
    main.init()
         /tmp/310793298/tmp__.go:105824 +0x1a0
    exit status 2

    FAIL chan/select5.go 6.114s

    It is a runoutput test and the generation of the test code is made by
    a nacl/amd64p32 program. chan/select5.go uses text/template and it
    calls methods through reflection. Due to the alignement bug it will
    get the wrong value and print out empty select{}'s instead of the
    expected tests, resulting in deadlocks.

    Additionnally, there is a subtlety in reflect-generated method values,
    which is that the padding of a method value call may be different from
    the padding of the method call itself (causes a failure in TestMethod5
    in reflect tests).

    This test involves a method with signature:

    func (*T) Method(int, bool) (bool, int)

    when used as a method, the arguments are (*T, int, bool), rounded to
    16 bytes for 64-bit alignment (7 padding bytes after the bool).
    When used as a method value, the signature becomes func(int, bool)
    (bool, int), so the argument part must be rounded to 8 bytes (3
    padding bytes).

    It is fixed in rsc's original patch but it doesn't apply anymore
    because the current reflect code copies the whole argument+return
    frame, since on traditional architectures the padding of the method
    call, and of the call of the method value are the same.

    Rémy.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Rémy Oudompheng at Mar 15, 2014 at 5:16 pm

    2014-03-15 17:37 GMT+01:00 Rémy Oudompheng <remyoudompheng@gmail.com>:
    2014-03-14 23:54 GMT+01:00 Ian Lance Taylor <iant@golang.org>:
    On Fri, Mar 14, 2014 at 3:53 PM, Dave Cheney wrote:
    Thanks Ian, that does look simpler.
    Let me know if you think it's needed, it sounds like all the tests are
    passing anyhow.

    Ian
    This CL only fixes GC instructions for the argument layout struct used
    in reflect calls. rsc's original patch is needed to fix padding
    convention when calling functions from reflect.
    Following this observation I propose:
    https://codereview.appspot.com/76150044

    Rémy.

    --

    ---
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedMar 6, '14 at 11:42p
activeMar 27, '14 at 7:09p
posts32
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase