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

all: add support for buildmode=c-shared on linux/riscv64 #47100

Closed
jawn-smith opened this issue Jul 8, 2021 · 7 comments
Closed

all: add support for buildmode=c-shared on linux/riscv64 #47100

jawn-smith opened this issue Jul 8, 2021 · 7 comments
Labels
FeatureRequest FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@jawn-smith
Copy link

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

$ go version
go version go1.16.5 linux/riscv64

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ go env
GO111MODULE=""
GOARCH="riscv64"
GOBIN=""
GOCACHE="/home/ubuntu/.cache/go-build"
GOENV="/home/ubuntu/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="riscv64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/ubuntu/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/ubuntu/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.16"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.16/pkg/tool/linux_riscv64"
GOVCS=""
GOVERSION="go1.16.5"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2919564126=/tmp/go-build -gno-record-gcc-switches"

What did you do?

go build -buildmode=c-shared <anything.go>

What did you expect to see?

A successful build

What did you see instead?

-buildmode=c-shared not supported on linux/riscv64

Since cgo is already implemented in linux/riscv64 would this just be a matter of marking it as enabled or is there more that needs to be done?

@mknyszek mknyszek changed the title Add support for buildmode=c-shared on linux/riscv64 cmd/go: add support for buildmode=c-shared on linux/riscv64 Jul 9, 2021
@mknyszek mknyszek changed the title cmd/go: add support for buildmode=c-shared on linux/riscv64 cmd/go,cmd/link,runtime: add support for buildmode=c-shared on linux/riscv64 Jul 9, 2021
@mknyszek mknyszek changed the title cmd/go,cmd/link,runtime: add support for buildmode=c-shared on linux/riscv64 all: add support for buildmode=c-shared on linux/riscv64 Jul 9, 2021
@mknyszek mknyszek added FeatureRequest NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jul 9, 2021
@mknyszek mknyszek added this to the Backlog milestone Jul 9, 2021
@mknyszek
Copy link
Contributor

mknyszek commented Jul 9, 2021

I'm not sure who knows c-shared well, but I'll take a guess: @thanm @cherrymui @ianlancetaylor ?

@xnox
Copy link

xnox commented Jul 9, 2021

@4a6f656c maybe?

@cherrymui cherrymui modified the milestones: Backlog, Unplanned Jul 12, 2021
@4a6f656c
Copy link
Contributor

There is a bit more than just marking it as enabled - the other main missing piece is the rt0_linux_riscv64_lib implementation (the code that starts the Go runtime). I've got a diff that makes both c-archive and c-shared work on linux/riscv64, although a c-archive test is still currently failing...

@gopherbot
Copy link

Change https://golang.org/cl/334871 mentions this issue: runtime: save and restore X3 (aka GP) for asmcgocalls on riscv64

@gopherbot
Copy link

Change https://golang.org/cl/334872 mentions this issue: all: add support for c-archive and c-shared on linux/riscv64

@gopherbot
Copy link

Change https://golang.org/cl/334870 mentions this issue: runtime/cgo: save and restore X3 (aka GP) for crosscall1 on riscv64

4a6f656c added a commit to 4a6f656c/go that referenced this issue Jul 15, 2021
The C code that is calling crosscall1 may depend on the GP register, which Go code
will currently clobber. Save and restore both X3 (aka GP) and X4 (aka TP) in this
code path (note that the Go code does not currently clobber X4, however there is
minimal downside to saving and restoring it here, which then also matches crosscall2).

Updates golang#47100

Change-Id: Icbb706d7889d5dc59de3efb2b510fa6ea2069496
4a6f656c added a commit to 4a6f656c/go that referenced this issue Jul 15, 2021
The X3 (aka GP) register will potentially be loaded with the __global_pointer$ symbol
during program start up (usually the dynamic linker). As such, non-Go code may depend
on the contents of GP, including code called via cgo. Save the original GP value on
early entry to Go, then restore it in asmcgocall prior to calling non-Go code.

An alternative would be to prevent Go from allocating the X3 register, but this seems
like a better option.

Updates golang#47100

Change-Id: I10356886babd958da019a6a0179f609fe90517da
4a6f656c added a commit to 4a6f656c/go that referenced this issue Jul 15, 2021
This provides the runtime glue (_rt0_riscv64_linux_lib) for c-archive and c-shared
support, along with enabling both of these buildmodes on linux/riscv64.

Both misc/cgo/testcarchive and misc/cgo/testcshared now pass on this platform.

Fixes golang#47100

Change-Id: I7ad75b23ae1d592dbac60d15bba557668287711f
gopherbot pushed a commit that referenced this issue Sep 17, 2021
The C code that is calling crosscall1 may depend on the GP register, which Go code
will currently clobber. Save and restore both X3 (aka GP) and X4 (aka TP) in this
code path (note that the Go code does not currently clobber X4, however there is
minimal downside to saving and restoring it here, which then also matches crosscall2).

Updates #47100

Change-Id: Icbb706d7889d5dc59de3efb2b510fa6ea2069496
Reviewed-on: https://go-review.googlesource.com/c/go/+/334870
Trust: Joel Sing <joel@sing.id.au>
Trust: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
@gopherbot
Copy link

Change https://golang.org/cl/351859 mentions this issue: cmd/asm,cmd/compile,runtime: stop using X3 (aka GP) on riscv64

gopherbot pushed a commit that referenced this issue Nov 3, 2021
The X3 (aka GP) register will potentially be loaded with the __global_pointer$ symbol
during program start up (usually by the dynamic linker). As such, non-Go code may depend
on the contents of GP and calculate offsets based on it, including code called via cgo
and signal handlers installed by non-Go code. As such, stop using the X3 register so
that there are fewer issues interacting between Go and non-Go code.

While here remove the X4 (TP) name from the assembler such that any references must
use the 'TP' name. This should reduce the likelihood of accidental use (like we do
for the 'g' register). The same applies for X3 (GP) when the -shared flag is given.

Updates #47100

Change-Id: I72e82b5ca3f80c46a781781345ca0432a4111b74
Reviewed-on: https://go-review.googlesource.com/c/go/+/351859
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Nov 5, 2021
@dmitshur dmitshur modified the milestones: Unplanned, Go1.18 Nov 5, 2021
@golang golang locked and limited conversation to collaborators Nov 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FeatureRequest FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

7 participants