gollvm: #cgo LDFLAGS repeated thrice #60287

andreybokhanko · 2023-05-18T16:00:18Z

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

$ go version
go version go1.18 gollvm LLVM 15.0.0git 20230518 (experimental) linux/amd64

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="amd64"
GOBIN=""
GOCACHE="/home/abokhanko/.cache/go-build"
GOENV="/home/abokhanko/.config/go/env"
GOEXE=""
GOEXPERIMENT="fieldtrack,regabiwrappers"
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/abokhanko/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/abokhanko/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/abokhanko/gotrunk"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/abokhanko/gollvm/tools"
GOVCS=""
GOVERSION="go1.18 gollvm LLVM 15.0.0git 20230518 (experimental)"
GCCGO="/home/abokhanko/gollvm/bin/llvm-goc"
GOAMD64="v1"
AR="ar"
CC="/usr/bin/cc"
CXX="/usr/bin/c++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
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-build3136632811=/tmp/go-build -gno-record-gcc-switches -funwind-tables"

What did you do?

$ cat cpart.c
#include 
#include 
extern void HelloFromC() {
        printf("Hello from C!\n");
}

$ cat goapp.go
package main

// #cgo LDFLAGS: ${SRCDIR}/cpart.o
import "C"

//go:linkname HelloFromC HelloFromC
func HelloFromC()

func main() {
        HelloFromC()
}

$ gcc -c cpart.c

$ go build goapp.go
# command-line-arguments
/usr/bin/ld.gold: error: /home/abokhanko/test/issue604/cpart.o: multiple definition of 'HelloFromC'
/usr/bin/ld.gold: /home/abokhanko/test/issue604/cpart.o: previous definition here
/usr/bin/ld.gold: error: /home/abokhanko/test/issue604/cpart.o: multiple definition of 'HelloFromC'
/usr/bin/ld.gold: /home/abokhanko/test/issue604/cpart.o: previous definition here
/usr/bin/ld.gold: error: $WORK/b001/_pkg1_.a(_cgo_defun.o): failed to match split-stack sequence at section 1 offset 0
/usr/bin/ld.gold: error: $WORK/b001/_pkg1_.a(_cgo_defun.o): failed to match split-stack sequence at section 1 offset 96
/usr/bin/ld.gold: error: $WORK/b001/_pkg1_.a(_cgo_defun.o): failed to match split-stack sequence at section 1 offset 106
/usr/bin/ld.gold: error: $WORK/b001/_pkg1_.a(_cgo_defun.o): failed to match split-stack sequence at section 1 offset 1b5
/usr/bin/ld.gold: error: $WORK/b001/_pkg1_.a(_cgo_defun.o): failed to match split-stack sequence at section 1 offset 23e

What did you expect to see?

goapp.go building successfully.

What did you see instead?

Errors caused by #cgo LDFLAGS (/home/abokhanko/test/issue604/cpart.o) being repeated thrice in the linker's command line:

$ go build -x goapp.go
WORK=/tmp/go-build2518111976
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg.link << 'EOF' # internal
packagefile command-line-arguments=/home/abokhanko/.cache/go-build/b0/b04da2f53bf1f5c55adb13031ca2219feee680950bb17d7b87546d3d22b9a7d6-d
modinfo "0w\xaf\f\x92t\b\x02A\xe1\xc1\a\xe6\xd6\x18\xe6path\tcommand-line-arguments\nbuild\t-compiler=gccgo\nbuild\tCGO_ENABLED=1\nbuild\tCGO_CFLAGS=\nbuild\tCGO_CPPFLAGS=\nbuild\tCGO_CXXFLAGS=\nbuild\tCGO_LDFLAGS=\nbuild\tGOARCH=amd64\nbuild\tGOEXPERIMENT=fieldtrack\nbuild\tGOOS=linux\nbuild\tGOAMD64=v1\n\xf92C1\x86\x18 r\x00\x82B\x10A\x16\xd8\xf2"
EOF
mkdir -p $WORK/b001/exe/
cp /home/abokhanko/.cache/go-build/b0/b04da2f53bf1f5c55adb13031ca2219feee680950bb17d7b87546d3d22b9a7d6-d $WORK/b001/_pkg1_.a
cd $WORK/b001/
ar x ./_pkg1_.a _cgo_flags
cd .
ar d $WORK/b001/_pkg1_.a _cgo_flags
/home/abokhanko/gollvm/bin/llvm-goc -o $WORK/b001/exe/a.out "-Wl,-(" -m64 -Wl,--whole-archive $WORK/b001/_pkg1_.a -Wl,--no-whole-archive /home/abokhanko/test/issue604/cpart.o /home/abokhanko/test/issue604/cpart.o /home/abokhanko/test/issue604/cpart.o "-Wl,-)" -Wl,--build-id=0x516d37472d54316a7067466575666b743157326c2f4937504e7a6f6558467645376a4e712d2d4e526c2f643266584a4f734d4a3963464462653866594f572f516d37472d54316a7067466575666b743157326c -Wl,-E
# command-line-arguments
/usr/bin/ld.gold: error: /home/abokhanko/test/issue604/cpart.o: multiple definition of 'HelloFromC'
/usr/bin/ld.gold: /home/abokhanko/test/issue604/cpart.o: previous definition here
/usr/bin/ld.gold: error: /home/abokhanko/test/issue604/cpart.o: multiple definition of 'HelloFromC'
/usr/bin/ld.gold: /home/abokhanko/test/issue604/cpart.o: previous definition here
/usr/bin/ld.gold: error: $WORK/b001/_pkg1_.a(_cgo_defun.o): failed to match split-stack sequence at section 1 offset 0
/usr/bin/ld.gold: error: $WORK/b001/_pkg1_.a(_cgo_defun.o): failed to match split-stack sequence at section 1 offset 96
/usr/bin/ld.gold: error: $WORK/b001/_pkg1_.a(_cgo_defun.o): failed to match split-stack sequence at section 1 offset 106
/usr/bin/ld.gold: error: $WORK/b001/_pkg1_.a(_cgo_defun.o): failed to match split-stack sequence at section 1 offset 1b5
/usr/bin/ld.gold: error: $WORK/b001/_pkg1_.a(_cgo_defun.o): failed to match split-stack sequence at section 1 offset 23e

The text was updated successfully, but these errors were encountered:

gopherbot · 2023-05-18T16:27:05Z

Change https://go.dev/cl/496195 mentions this issue: cgo: Fix handling of #cgo LDFLAGS

ianlancetaylor · 2023-05-23T00:56:52Z

When you put a .c file in the same directory as the .go files in your package, the go tool will automatically compile the .c file and include it in the link. So there doesn't seem to be any need for the #cgo LDFLAGS line in this example.

That said, if there is only a cpart.o file, and no cpart.c file, then I agree that when using gccgo the LDFLAGS are repeated. But I don't think the fix is to discard duplicates. I think the fix is to only include them once. I think the problem is that go tool both includes LDFLAGS from the Package struct and from cmd/cgo.

I think that something along the lines of https://go.dev/cl/497117 would be a better approach.

gopherbot · 2023-05-23T01:02:26Z

Change https://go.dev/cl/497117 mentions this issue: cmd/go: don't collect package CGOLDFLAGS when using gccgo

andreybokhanko · 2023-05-23T13:31:30Z

@ianlancetaylor Giving that you're already working on a more proper fix, do you suggest me to abandon https://go.dev/cl/496195 ?

ianlancetaylor · 2023-05-23T17:09:09Z

Yes, I don't think we want the approach in 496195. Thanks. If you want to test 497117 that would be helpful. Thanks.

andreybokhanko · 2023-05-24T10:12:02Z

Yes, I don't think we want the approach in 496195. Thanks. If you want to test 497117 that would be helpful. Thanks.

Yep, I tested it on my case, and as expected, it works flawlessly.

(sorry, closed by mistake; then reopened)

andreybokhanko · 2023-06-15T14:42:59Z

@ianlancetaylor it seems https://go-review.googlesource.com/c/go/+/497117 is in review limbo... Not sure I can help in any way to push it through?

ianlancetaylor · 2023-06-15T19:36:17Z

@andreybokhanko I think it mainly needs a test. It hasn't seemed too urgent since there isn't going to be another GCC release for months.

andreybokhanko · 2023-06-26T09:19:42Z

@andreybokhanko I think it mainly needs a test. It hasn't seemed too urgent since there isn't going to be another GCC release for months.

BTW, it's easy enough to write a test using LLVM's lit testing machinery:

// RUN: GOCACHE=%T not go run -x -a %s 2>&1 | FileCheck %s

package main

// #cgo LDFLAGS: ${SRCDIR}/cpart.o
import "C"

//go:linkname HelloFromC HelloFromC
func HelloFromC()

func main() {
HelloFromC()
}

// CHECK: llvm-goc{{.*}}cpart.o
// CHECK-NOT: llvm-goc{{.*}}cpart.o.*cpart.o

Though I guess due to presence of gccgo, this is not really suitable, right?

gopherbot · 2023-07-20T18:22:28Z

Change https://go.dev/cl/511675 mentions this issue: cmd/go: don't collect package CGOLDFLAGS when using gccgo

They are already collected via cmd/cgo. The gccgo_link_c test is tweaked to do real linking as with this change the cgo ldflags are not fully reflected in go build -n output, since they now only come from the built archive. This is a backport of https://go.dev/cl/497117 from the main repo. For golang/go#60287 Change-Id: Ie0bf76b588724265d75dd9a96984dd6cc207f84e Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/511675 Reviewed-by: Than McIntosh <[email protected]> Reviewed-by: Cherry Mui <[email protected]>

They are already collected via cmd/cgo. The gccgo_link_c test is tweaked to do real linking as with this change the cgo ldflags are not fully reflected in go build -n output, since they now only come from the built archive. This is a backport of https://go.dev/cl/497117 from the main repo. For golang/go#60287 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/511675

andreybokhanko changed the title ~~gollvm: #cgp LDFLAGS repeated thrice~~ gollvm: #cgo LDFLAGS repeated thrice May 18, 2023

thanm self-assigned this May 19, 2023

seankhliao added this to the gollvm milestone May 19, 2023

seankhliao added the NeedsFix The path to resolution is known, but the work has not been done. label May 19, 2023

andreybokhanko closed this as completed May 24, 2023

andreybokhanko reopened this May 24, 2023

gopherbot closed this as completed in d3e3e11 Jul 20, 2023

golang locked and limited conversation to collaborators Jul 19, 2024

gopherbot added the FrozenDueToAge label Jul 19, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gollvm: #cgo LDFLAGS repeated thrice #60287

gollvm: #cgo LDFLAGS repeated thrice #60287

andreybokhanko commented May 18, 2023

gopherbot commented May 18, 2023

ianlancetaylor commented May 23, 2023

gopherbot commented May 23, 2023

andreybokhanko commented May 23, 2023

ianlancetaylor commented May 23, 2023

andreybokhanko commented May 24, 2023 •

edited

Loading

andreybokhanko commented Jun 15, 2023

ianlancetaylor commented Jun 15, 2023

andreybokhanko commented Jun 26, 2023

gopherbot commented Jul 20, 2023

gollvm: #cgo LDFLAGS repeated thrice #60287

gollvm: #cgo LDFLAGS repeated thrice #60287

Comments

andreybokhanko commented May 18, 2023

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

gopherbot commented May 18, 2023

ianlancetaylor commented May 23, 2023

gopherbot commented May 23, 2023

andreybokhanko commented May 23, 2023

ianlancetaylor commented May 23, 2023

andreybokhanko commented May 24, 2023 • edited Loading

andreybokhanko commented Jun 15, 2023

ianlancetaylor commented Jun 15, 2023

andreybokhanko commented Jun 26, 2023

gopherbot commented Jul 20, 2023

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

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

andreybokhanko commented May 24, 2023 •

edited

Loading