Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/link: incorrect offset generated for indirect calls on amd64 #15609

Closed
wedsonaf opened this issue May 9, 2016 · 3 comments

Comments

Projects
None yet
5 participants
@wedsonaf
Copy link
Contributor

commented May 9, 2016

Please answer these questions before submitting your issue. Thanks!

  1. What version of Go are you using (go version)?

    go version go1.5.1 linux/amd64
    
  2. What operating system and processor architecture are you using (go env)?

    GOARCH="amd64"
    GOBIN=""
    GOEXE=""
    GOHOSTARCH="amd64"
    GOHOSTOS="linux"
    GOOS="linux"
    GOPATH="/home/wedsonaf/go"
    GORACE=""
    GOROOT="/usr/local/go"
    GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
    GO15VENDOREXPERIMENT=""
    CC="gcc"
    GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
    CXX="g++"
    CGO_ENABLED="1"
    
  3. What did you do?
    I compiled a program that included an indirect call. Repro steps are below:

    $ cat call.s
    #include "textflag.h"
    DATA ·pointer(SB)/8, $·target(SB)
    GLOBL ·pointer(SB),RODATA,$8
    TEXT ·jump(SB),NOSPLIT,$0-28
            CALL *·pointer(SB)
            RET
    
    $ cat test.go
    package main
    func jump()
    func target() {}
    func main() {
            jump()
    }
    $ go build
    $ ./badoffset 
    unexpected fault address 0x889ae6
    fatal error: fault
    [signal 0xb code=0x1 addr=0x889ae6 pc=0x401080]
    
    goroutine 1 [running]:
    runtime.throw(0x46f9e8, 0x5)
            /usr/local/go/src/runtime/panic.go:527 +0x90 fp=0xc820041ef0 sp=0xc820041ed8
    runtime.sigpanic()
            /usr/local/go/src/runtime/sigpanic_unix.go:27 +0x2ab fp=0xc820041f40 sp=0xc820041ef0
    main.jump(0x4234e0, 0xc820020060, 0x0)
            /home/wedsonaf/repro/badoffset/call.s:7 fp=0xc820041f48 sp=0xc820041f40
    main.main()
            /home/wedsonaf/repro/badoffset/test.go:8 +0x14 fp=0xc820041f50 sp=0xc820041f48
    runtime.main()
            /usr/local/go/src/runtime/proc.go:111 +0x2b0 fp=0xc820041fa0 sp=0xc820041f50
    runtime.goexit()
            /usr/local/go/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc820041fa8 sp=0xc820041fa0
    
  4. What did you expect to see?

    I expected the program above to run.

  5. What did you see instead?

    It crashed.

Upon closer inspection, I noticed that the offset in the call instruction is wrong. In particular, it's an absolute value instead of being relative to PC. Here's the generated code for main.jump:

0000000000401080 <main.jump>:
  401080:       ff 15 60 8a 48 00       callq  *0x488a60(%rip)        # 889ae6 <runtime.end+0x3afda6>
  401086:       c3                      retq

Note that 0x488a60 is actually the address of main.pointer:

0000000000488a60 g     O .rodata        0000000000000008 main.pointer

So instead of reading from 0x488a60 we're trying to read from 0x889ae6 instead, which is 0x488a60 + 0x401086 (offset + rip).

@gopherbot

This comment has been minimized.

Copy link

commented May 9, 2016

CL https://golang.org/cl/22950 mentions this issue.

@bradfitz bradfitz changed the title Incorrect offset generated for indirect calls on amd64 cmd/link: incorrect offset generated for indirect calls on amd64 May 9, 2016

@bradfitz

This comment has been minimized.

Copy link
Member

commented May 9, 2016

Was this always broken?

/cc @ianlancetaylor for triage. Assigning Go 1.8 by default, but Ian can adjust.

@bradfitz bradfitz added this to the Go1.8 milestone May 9, 2016

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented May 9, 2016

This was broken in 1.5 and 1.6, which use the new assembler. I don't know how to write this instruction with the old assembler, so I don't know whether it was broken then.

There is a reasonably easy workaround:
MOVL ·pointer(SB),AX
CALL AX

I think 1.8 is the right target. We could consider a clearly correct fix for 1.7 but I don't see the CL that was sent out as clearly correct.

@quentinmit quentinmit added the NeedsFix label Oct 7, 2016

@gopherbot gopherbot closed this in 13c829e Oct 9, 2016

@golang golang locked and limited conversation to collaborators Oct 9, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.