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

gccgo: compilation fails in some scenarios #39613

Closed
WangLeonard opened this issue Jun 16, 2020 · 4 comments
Closed

gccgo: compilation fails in some scenarios #39613

WangLeonard opened this issue Jun 16, 2020 · 4 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@WangLeonard
Copy link
Contributor

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

$ go version
`go version go1.14.2 linux/amd64`

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/root/project/GOPATH"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/root/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/root/local/go/pkg/tool/linux_amd64"
GCCGO="/usr/local/bin/gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build348368620=/tmp/go-build -gno-record-gcc-switches"
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-checking=release --enable-languages=c,c++,go --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC)
gccgo -v
Using built-in specs.
COLLECT_GCC=gccgo
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-checking=release --enable-languages=c,c++,go --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC)

For gccgo, I did the following experiment.

GOPATH/src/study/main_test.go

package study001_test

import (
        "fmt"
        "testing"
)

func TestHello(t *testing.T) {
        fmt.Println("TestHello")
}
go test -v study
=== RUN   TestHello
TestHello
--- PASS: TestHello (0.00s)
PASS
ok  	study	0.006s

success

go test -v -compiler=gccgo -gccgoflags=-static-libgo study
=== RUN   TestHello
TestHello
--- PASS: TestHello (0.00s)
PASS
ok  	study	0.045s

success

go test -v runtime
=== RUN   TestCallers
    TestCallers: callers_test.go:47: functions seen: testing.tRunner runtime.goexit runtime.Callers runtime_test.f3 runtime_test.f2 runtime_test.f1 runtime_test.TestCallers
--- PASS: TestCallers (0.00s)
=== RUN   TestCallersPanic
    TestCallersPanic: callers_test.go:47: functions seen: runtime.gopanic runtime_test.f3 runtime_test.f2 runtime_test.f1 testing.tRunner runtime.goexit runtime.Callers runtime_test.TestCallersPanic.func1 runtime_test.TestCallersPanic
--- PASS: TestCallersPanic (0.00s)
=== RUN   TestCallersDoublePanic
--- PASS: TestCallersDoublePanic (0.00s)
……

success

go test -v -compiler=gccgo -gccgoflags=-static-libgo runtime
?   	runtime	[no test files]

failed

Modify the file, add linkname, and add empty.s

package study001_test

import (
        "fmt"
        "testing"
        _ "unsafe"
)

//go:linkname gcphase runtime.gcphase
var gcphase uint32

func TestHello(t *testing.T) {
        fmt.Println("TestHello")
}
go test -v study
=== RUN   TestHello
TestHello
--- PASS: TestHello (0.00s)
PASS
ok  	study	0.005s

success

go test -v -compiler=gccgo -gccgoflags=-static-libgo study
# study_test [study.test]
./main_test.go:9:3: error: gcphase is not a function; '//go:linkname' is only supported for functions
    9 | //go:linkname gcphase runtime.gcphase
      |   ^
FAIL	study [build failed]
FAIL

failed

In fact, I want to test the performance comparison of go1.14.2 gccgo and gc (runtime and application).
After compiling gccgo to prepare for testing, I found the problem described above (abstract code for the actual problem).

Am I using it incorrectly or is there a bug?

@gopherbot gopherbot added this to the Gccgo milestone Jun 16, 2020
@cherrymui
Copy link
Member

Gccgo does not support go:linkname on variables (see e.g. #25114). Why do you need to use linkname?

@WangLeonard
Copy link
Contributor Author

In some scenarios of my application, I need to get some status of the runtime for strategy optimization or new feature development.
Are there any plans to support "go:linkname var" in the future?
Also, is go test -v -compiler=gccgo -gccgoflags=-static-libgo runtime a bug?

@andybons andybons added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 17, 2020
@ianlancetaylor
Copy link
Contributor

There are no plans to support go:linkname for variables in gccgo. The problem is that since gccgo uses the system linker it needs to be able to distinguish between a use of a variable and a definition of a variable. The go:linkname syntax doesn't support that for variables. For functions it works because a function declaration has no body.

We could support something similar to go:linkname if it distinguished definitions and uses.

WIth gccgo you can't run go test on standard library packages, sorry.

@WangLeonard
Copy link
Contributor Author

ok, I got it, thank you!

@golang golang locked and limited conversation to collaborators Jun 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants