-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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
Comments
I'm not sure who knows c-shared well, but I'll take a guess: @thanm @cherrymui @ianlancetaylor ? |
@4a6f656c maybe? |
There is a bit more than just marking it as enabled - the other main missing piece is the |
Change https://golang.org/cl/334871 mentions this issue: |
Change https://golang.org/cl/334872 mentions this issue: |
Change https://golang.org/cl/334870 mentions this issue: |
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
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
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
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>
Change https://golang.org/cl/351859 mentions this issue: |
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>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat 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?
The text was updated successfully, but these errors were encountered: