Grokbase › Groups › Go › golang-nuts › August 2015
FAQ
While spelunking how Syscall handles negative return values for uintptr, I
saw the following inconsistency (no r2 return value on windows amd64?) in
the "TEXT runtime·asmstdcall(SB),NOSPLIT,$0" assembly:

   // file: runtime/sys_windows_386.go
   ...
   // Return result.
   MOVL fn+0(FP), BX
   MOVL AX, libcall_r1(BX)
   MOVL DX, libcall_r2(BX)


   // file: runtime/sys_windows_amd64.go
   ...
   // Return result.
   POPQ CX
   MOVQ AX, libcall_r1(CX)


The corresponding assembly for darwin, linux, and freebsd in
syscall/asm_*.s all appear to return r2 from DX for both 386 and amd64
similar to the following linux assembly:

   // file: syscall/asm_linux_386.s
   ...
   ok:
       MOVL AX, r1+16(FP)
       MOVL DX, r2+20(FP)
       MOVL $0, err+24(FP)
       CALL runtime·exitsyscall(SB)
       RET


   // file: syscall/asm_linux_amd64.s
   ...
   ok:
       MOVQ AX, r1+32(FP)
       MOVQ DX, r2+40(FP)
       MOVQ $0, err+48(FP)
       CALL runtime·exitsyscall(SB)
       RET

Is this a bug for syscall on windows amd64, or do I not yet grok the go
assembly? If a bug, what is the real-world impact?

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

Search Discussions

  • Ian Lance Taylor at Aug 4, 2015 at 5:45 pm ⇧

    On Tue, Aug 4, 2015 at 9:00 AM, wrote:
    While spelunking how Syscall handles negative return values for uintptr, I
    saw the following inconsistency (no r2 return value on windows amd64?) in
    the "TEXT runtime·asmstdcall(SB),NOSPLIT,$0" assembly:

    // file: runtime/sys_windows_386.go
    ...
    // Return result.
    MOVL fn+0(FP), BX
    MOVL AX, libcall_r1(BX)
    MOVL DX, libcall_r2(BX)


    // file: runtime/sys_windows_amd64.go
    ...
    // Return result.
    POPQ CX
    MOVQ AX, libcall_r1(CX)


    The corresponding assembly for darwin, linux, and freebsd in syscall/asm_*.s
    all appear to return r2 from DX for both 386 and amd64 similar to the
    following linux assembly:

    // file: syscall/asm_linux_386.s
    ...
    ok:
    MOVL AX, r1+16(FP)
    MOVL DX, r2+20(FP)
    MOVL $0, err+24(FP)
    CALL runtime·exitsyscall(SB)
    RET


    // file: syscall/asm_linux_amd64.s
    ...
    ok:
    MOVQ AX, r1+32(FP)
    MOVQ DX, r2+40(FP)
    MOVQ $0, err+48(FP)
    CALL runtime·exitsyscall(SB)
    RET

    Is this a bug for syscall on windows amd64, or do I not yet grok the go
    assembly? If a bug, what is the real-world impact?
    It's definitely a bit sloppy, and the code in
    runtime/sys_windows_amd64.s really ought to see the r2 field, to 0 if
    nothing else. Please open an issue for this.

    In practice it only matters if some code calls Syscall or friends and
    looks at the r2 result. In practice, on pretty much all systems,
    including Windows as far as I know, code only looks at the r1 and err
    results. The only exceptions I'm aware of are SYS_PIPE and SYS_LSEEK
    on some BSD based systems.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Jon Forums at Aug 4, 2015 at 6:28 pm ⇧

    On Tuesday, August 4, 2015 at 1:45:49 PM UTC-4, Ian Lance Taylor wrote:
    On Tue, Aug 4, 2015 at 9:00 AM, <[email protected] <javascript:>>
    wrote:
    While spelunking how Syscall handles negative return values for uintptr, I
    saw the following inconsistency (no r2 return value on windows amd64?) in
    the "TEXT runtime·asmstdcall(SB),NOSPLIT,$0" assembly:

    // file: runtime/sys_windows_386.go
    ...
    // Return result.
    MOVL fn+0(FP), BX
    MOVL AX, libcall_r1(BX)
    MOVL DX, libcall_r2(BX)


    // file: runtime/sys_windows_amd64.go
    ...
    // Return result.
    POPQ CX
    MOVQ AX, libcall_r1(CX)


    The corresponding assembly for darwin, linux, and freebsd in
    syscall/asm_*.s
    all appear to return r2 from DX for both 386 and amd64 similar to the
    following linux assembly:

    // file: syscall/asm_linux_386.s
    ...
    ok:
    MOVL AX, r1+16(FP)
    MOVL DX, r2+20(FP)
    MOVL $0, err+24(FP)
    CALL runtime·exitsyscall(SB)
    RET


    // file: syscall/asm_linux_amd64.s
    ...
    ok:
    MOVQ AX, r1+32(FP)
    MOVQ DX, r2+40(FP)
    MOVQ $0, err+48(FP)
    CALL runtime·exitsyscall(SB)
    RET

    Is this a bug for syscall on windows amd64, or do I not yet grok the go
    assembly? If a bug, what is the real-world impact?
    It's definitely a bit sloppy, and the code in
    runtime/sys_windows_amd64.s really ought to see the r2 field, to 0 if
    nothing else. Please open an issue for this.

    In practice it only matters if some code calls Syscall or friends and
    looks at the r2 result. In practice, on pretty much all systems,
    including Windows as far as I know, code only looks at the r1 and err
    results. The only exceptions I'm aware of are SYS_PIPE and SYS_LSEEK
    on some BSD based systems.

    Ian
    On windows I think r2 (field of libcall struct) will get set to 0 in
    runtime/runtime2.go:L338 as part of m struct's init, so this one likely
    works out ok in practice. I'll file an issue.




    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/d/optout.
  • Jon Forums at Aug 5, 2015 at 5:05 pm ⇧

    On Tuesday, August 4, 2015 at 2:28:53 PM UTC-4, [email protected] wrote:

    On Tuesday, August 4, 2015 at 1:45:49 PM UTC-4, Ian Lance Taylor wrote:
    On Tue, Aug 4, 2015 at 9:00 AM, wrote:

    While spelunking how Syscall handles negative return values for
    uintptr, I
    saw the following inconsistency (no r2 return value on windows amd64?) in
    the "TEXT runtime·asmstdcall(SB),NOSPLIT,$0" assembly:

    // file: runtime/sys_windows_386.go
    ...
    // Return result.
    MOVL fn+0(FP), BX
    MOVL AX, libcall_r1(BX)
    MOVL DX, libcall_r2(BX)


    // file: runtime/sys_windows_amd64.go
    ...
    // Return result.
    POPQ CX
    MOVQ AX, libcall_r1(CX)


    The corresponding assembly for darwin, linux, and freebsd in
    syscall/asm_*.s
    all appear to return r2 from DX for both 386 and amd64 similar to the
    following linux assembly:

    // file: syscall/asm_linux_386.s
    ...
    ok:
    MOVL AX, r1+16(FP)
    MOVL DX, r2+20(FP)
    MOVL $0, err+24(FP)
    CALL runtime·exitsyscall(SB)
    RET


    // file: syscall/asm_linux_amd64.s
    ...
    ok:
    MOVQ AX, r1+32(FP)
    MOVQ DX, r2+40(FP)
    MOVQ $0, err+48(FP)
    CALL runtime·exitsyscall(SB)
    RET

    Is this a bug for syscall on windows amd64, or do I not yet grok the go
    assembly? If a bug, what is the real-world impact?
    It's definitely a bit sloppy, and the code in
    runtime/sys_windows_amd64.s really ought to see the r2 field, to 0 if
    nothing else. Please open an issue for this.

    In practice it only matters if some code calls Syscall or friends and
    looks at the r2 result. In practice, on pretty much all systems,
    including Windows as far as I know, code only looks at the r1 and err
    results. The only exceptions I'm aware of are SYS_PIPE and SYS_LSEEK
    on some BSD based systems.

    Ian
    On windows I think r2 (field of libcall struct) will get set to 0 in
    runtime/runtime2.go:L338 as part of m struct's init, so this one likely
    works out ok in practice. I'll file an issue.
    After finding these docs

    https://msdn.microsoft.com/en-us/library/7572ztz4.aspx
    http://www.x86-64.org/documentation.html

    my "discovery" appears to be a non-issue, not a bug.

    If the MSFT doc is complete, RAX is the primary return register and go's
    current windows syscall impl in runtime/syscall_windows.go makes sense to
    me: grab a go allocated libcall struct, config, pass it to go asm, and go
    asm returns r1 uintptr as per MSFT x64 ABI and any additional info in err
    uintptr.

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 4, '15 at 4:00p
activeAug 5, '15 at 5:05p
posts4
users2
websitegolang.org

2 users in discussion

Jon Forums: 3 posts Ian Lance Taylor: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase