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

Jump to bottom

cmd/link: -buildmode=c-shared not supported on linux/mips64le #43264

Open
Mengkzhaoyun opened this issue Dec 18, 2020 · 37 comments
Open

cmd/link: -buildmode=c-shared not supported on linux/mips64le #43264

Mengkzhaoyun opened this issue Dec 18, 2020 · 37 comments
Labels
arch-mips help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Backlog

Comments

@Mengkzhaoyun
Copy link

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

$ go version
1.15.6

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="mips64le"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="mips64le"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://goproxy.cn,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_mips64le"
GCCGO="gccgo"
GOMIPS64="hardfloat"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/go/src/github.com/cilium/cilium/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -mabi=64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build215838537=/tmp/go-build -gno-record-gcc-switches"

What did you do?

When I tried to migrate Cilium to the mips64le (loongnix) platform, I got an error, among others, when I compiled a class library, Proxylib, and found that Cilium was handling it as a .so file.
Here is the compile command

$ CGO_ENABLED=1 go build -mod=vendor -ldflags ' -X "github.com/cilium/cilium/pkg/version.ciliumVersion=1.9.1 6857a8d2a 2020-12-18T01 :24:42+08:00" -s -w -X "github.com/cilium/cilium/pkg/envoy.RequestedEnvoyVersionSHA=1177896bebde79915fe5f9092409bf0254084b4e" -X " github.com/cilium/cilium/pkg/datapath/loader.DatapathSHA=3d9461ac3d8ae0b334f319c93e10ddea336d8617" -extldflags -Wl,-soname, libcilium.so.1' -tags=osusergo -o libcilium.so.1 -buildmode=c-shared
-buildmode=c-shared support on linux/mips64le

Since -buildmod=c-shared is used, this buildmod prompt does not support building on linux/mips64le, does anyone have any good solutions?

What did you expect to see?

-buildmode=c-shared support on linux/mips64le

What did you see instead?

-buildmode=c-shared not supported on linux/mips64le
@ianlancetaylor ianlancetaylor changed the title -buildmode=c-shared not supported on linux/mips64le cmd/link: -buildmode=c-shared not supported on linux/mips64le Dec 18, 2020
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 18, 2020
@ianlancetaylor ianlancetaylor added this to the Backlog milestone Dec 18, 2020
@XiaodongLoong
Copy link
Contributor

XiaodongLoong commented Dec 22, 2020 •
edited

I have analyzed this issue, and I try to develop this feature, but I have not completed it yet.
I will do it.

@hellocloudnative

This comment was marked as duplicate.

Sign in to view
@ianlancetaylor
Copy link
Contributor

@XiaodongLoong Thanks.

@XiaodongLoong
Copy link
Contributor

XiaodongLoong commented Mar 24, 2021 •
edited

@ianlancetaylor I meet a issue when I develop the -buildmod=c-shared featrue on linux/mips64le port. Could you give me a hint to fix this issule?
I just open some switches that intercept the feature on linux/mips64le port, and execute go build -a -x -work -buildmod=c-shared xxx.go the following error occors:

/root/go/pkg/tool/linux_mips64le/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -installsuffix shared -buildmode=c-shared -buildid=7oc0eGeuITC04x1PL6YA/zGmTkGzcjMksVKPwtCJC/FipDBPEiHap1g6M81mW7/7oc0eGeuITC04x1PL6YA -extld=gcc $WORK/b001/_pkg_.a
# command-line-arguments
/root/go/pkg/tool/linux_mips64le/link: running gcc failed: exit status 1
collect2: fatal error: ld terminated with signal 10 [Bus error], core dumped
compilation terminated.
/usr/bin/ld: /tmp/go-link-020946183/go.o: relocation R_MIPS_26 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.31.1 assertion fail ../../bfd/elfxx-mips.c:6550
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.31.1 assertion fail ../../bfd/elfxx-mips.c:6550
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.31.1 assertion fail ../../bfd/elfxx-mips.c:6550

@ianlancetaylor
Copy link
Contributor

This is only a guess, but my first thought would be that (*ctxt0).asmout in cmd/internal/obj/mips/asm0.go needs to check c.ctxt.Flag_shared, and, if that is true, not set rel.Type to objabi.R_CALLMIPS. It needs to generate a position independent relocation instead. Look at C code and see how the assembly differs when using -fPIC; the code in mips/asm0.go will likely need to do something similar. Also look at how other cmd/internal/obj/ARCH/asm*.go files handle Flag_shared.

This was referenced Aug 2, 2021
Closed
Closed
Closed
Closed
@gopherbot
Copy link

Change https://golang.org/cl/339049 mentions this issue: cmd/internal: support -buildmode=c-shared on linux/mips64le

@gopherbot
Copy link

Change https://golang.org/cl/339051 mentions this issue: runtime: support -buildmode=c-shared on linux/mips64le

@gopherbot
Copy link

Change https://golang.org/cl/339050 mentions this issue: cmd/compile: support -buildmode=c-shared on linux/mips64le

@XiaodongLoong
Copy link
Contributor

XiaodongLoong commented Aug 2, 2021 •
edited

@ianlancetaylor I have completed this work, thanks for your guidance.
It is OK on test cases from https://github.com/vladimirvivien/go-cshared-examples and Cilium.

@gopherbot
Copy link

Change https://golang.org/cl/339069 mentions this issue: cmd/link: support -buildmode=c-shared on linux/mips64le

@gopherbot
Copy link

Change https://golang.org/cl/339052 mentions this issue: cmd/link: support -buildmode=c-shared on linux/mips64le

@gopherbot
Copy link

Change https://golang.org/cl/348734 mentions this issue: cmd/link: support -buildmode=c-shared on linux/mips64le

@gopherbot
Copy link

Change https://golang.org/cl/348733 mentions this issue: cmd/internal: support -buildmode=c-shared on linux/mips64le

@gopherbot
Copy link

Change https://golang.org/cl/348732 mentions this issue: cmd/compile: support -buildmode=c-shared on linux/mips64le

@gopherbot
Copy link

Change https://golang.org/cl/348735 mentions this issue: runtime: support -buildmode=c-shared on linux/mips64le

@gopherbot
Copy link

Change https://golang.org/cl/354890 mentions this issue: cmd/internal/sys: open c-shared feature on linux/mips64le

@XiaodongLoong XiaodongLoong mentioned this issue Oct 12, 2021
Closed
@XiaodongLoong
Copy link
Contributor

@ianlancetaylor @cherrymui PTAL, Thanks!

@XiaodongLoong
Copy link
Contributor

A gentle ping. @ianlancetaylor @cherrymui

@cherrymui
Copy link
Member

We're still in the release freeze for Go 1.18. Will review once the tree opens for 1.19. Thanks.

@XiaodongLoong
Copy link
Contributor

@cherrymui Thanks! I rebased the code.

@XiaodongLoong
Copy link
Contributor

A gentle ping. @ianlancetaylor @cherrymui

@XiaodongLoong
Copy link
Contributor

XiaodongLoong commented Apr 18, 2022 •
edited

A gentle ping.
Thanks! ❤️

@XiaodongLoong
Copy link
Contributor

Sorry for the delay, the CLs are ready again. I expect a CR. Thanks!

@XiaodongLoong XiaodongLoong 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 Jun 15, 2022
@cherrymui
Copy link
Member

Thanks @XiaodongLoong . We're in the freeze for Go 1.19 release, so we cannot check them in until the tree opens for Go 1.20 development. The reviews can and will continue during the freeze.

@XiaodongLoong
Copy link
Contributor

OK, Thanks! 👍

@gopherbot
Copy link

Change https://go.dev/cl/414137 mentions this issue: cmd/go/internal/work: add GOBUILDMODE_shared macro to support c-shared buildmode on mips64{,le}

@gopherbot
Copy link

Change https://go.dev/cl/414136 mentions this issue: cmd/compile/internal/ssa: reserve R25 register for PIC code on mips64{,le}

@XiaodongLoong
Copy link
Contributor

@cherrymui
When I debug the "runtime.load_g" function, I find that call C function "___tls_get_addr" directly:

// src/runtime/tls_mips64x.s
MOVV	runtime·tls_g(SB), g  // in GD mode, get TLS address through ___tls_get_addr

I think it is not right, "___tls_get_addr" function should be wrapped by cgo. Then call the C funtion "___tls_get_addr" through the wrapper. And I want to hear from you.
Thanks.

@seankhliao seankhliao mentioned this issue Oct 10, 2022
Closed
@moloch-- moloch-- mentioned this issue Jan 9, 2023
Open
@mengzhuo mengzhuo mentioned this issue Apr 12, 2023
Open
@23083940 23083940 mentioned this issue Apr 12, 2023
Closed
@XiaodongLoong
Copy link
Contributor

I rebased code. PTAL. Thanks!

@XiaodongLoong
Copy link
Contributor

@cherrymui @ianlancetaylor ping.

gopherbot pushed a commit that referenced this issue Apr 21, 2023
@XiaodongLoong @gopherbot
cmd/compile: support -buildmode=c-shared on linux/mips64{,le}
d5fea50 
The modification of these rules is optimization to load/store global
variables. If there are a sequence of loads/stores nearby a global
variable address, the address can only be loaded from GOT once instead
of every time.

For #43264

Change-Id: Idedaf6c81f085955371320f51bca148ffb42a2d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/348732
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
@lhmouse

This comment was marked as spam.

Sign in to view
@cherrymui
Copy link
Member

@XiaodongLoong Sorry for getting back to you late. I don't think we want to call ___tls_get_addr via cgo. The cgo wrappers are heavy-duty and are mostly for calling C functions from user code. In the runtime, given how special ___tls_get_addr is, we should call it directly. That said, we probably should call it once at startup (or at thread entry if the result is thread dependent), and save the result somewhere, instead of calling it every time in load_g and save_g.

@XiaodongLoong
Copy link
Contributor

I am also very sorry, because I am busy with the development work in the company, I did not update the patches in time. I will update the patch as soon as possible.

Thanks!

@XiaodongLoong
Copy link
Contributor

Rebase code, PTAL.
Thanks. : )

@hyperiris

This comment was marked as off-topic.

Sign in to view
@Leanderlau

This comment was marked as duplicate.

Sign in to view
@xiangxud

This comment was marked as duplicate.

Sign in to view
@XiaodongLoong
Copy link
Contributor

I'm very sorry, I don't have enough time to update the CLs and will abandon these CLs. Anyone can continue to complete this work. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
arch-mips help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
10 participants
@hyperiris @ianlancetaylor @lhmouse @Mengkzhaoyun @gopherbot @cherrymui @hellocloudnative @Leanderlau @xiangxud @XiaodongLoong