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.

Sign up for GitHub

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

panic: runtime listed a std package we can't find: atomic #619

Closed
klauspost opened this issue Dec 19, 2022 · 1 comment · Fixed by #643
Closed

panic: runtime listed a std package we can't find: atomic #619

klauspost opened this issue Dec 19, 2022 · 1 comment · Fixed by #643

Comments

@klauspost
Copy link

What version of Garble and Go are you using?

$ go install mvdan.cc/garble@latest

garble@v0.8.0 (from panic)

$ go version
go version go1.19.4 linux/amd64

What environment are you running Garble on?

go env Output
$ go env
  GO111MODULE=""
  GOARCH="amd64"
  GOBIN=""
  GOCACHE="/home/runner/.cache/go-build"
  GOENV="/home/runner/.config/go/env"
  GOEXE=""
  GOEXPERIMENT=""
  GOFLAGS=""
  GOHOSTARCH="amd64"
  GOHOSTOS="linux"
  GOINSECURE=""
  GOMODCACHE="/home/runner/go/pkg/mod"
  GONOPROXY=""
  GONOSUMDB=""
  GOOS="linux"
  GOPATH="/home/runner/go"
  GOPRIVATE=""
  GOPROXY="https://proxy.golang.org,direct"
  GOROOT="/opt/hostedtoolcache/go/1.19.4/x64"
  GOSUMDB="sum.golang.org"
  GOTMPDIR=""
  GOTOOLDIR="/opt/hostedtoolcache/go/1.19.4/x64/pkg/tool/linux_amd64"
  GOVCS=""
  GOVERSION="go1.19.4"
  GCCGO="gccgo"
  GOAMD64="v1"
  AR="ar"
  CC="gcc"
  CXX="g++"
  CGO_ENABLED="0"
  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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3[18](https://github.com/klauspost/compress/actions/runs/3724454705/jobs/6316617540#step:2:19)[29](https://github.com/klauspost/compress/actions/runs/3724454705/jobs/6316617540#step:2:30)08879=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Running goreleaser in CICD fails

What did you expect to see?

Build.

What did you see instead?

• building binaries
[....]
      • building                  binary=dist/s2c_linux_ppc64le/s2c
⨯ release failed after 572.45s error=failed to build for linux_mips64_hardfloat: exit status 1: # runtime/internal/atomic
panic: runtime listed a std package we can't find: atomic

goroutine 1 [running]:
main.listPackage({0xc000177[62](https://github.com/klauspost/compress/actions/runs/3724454705/jobs/6316617540#step:9:63)0, 0x6})
	/home/runner/go/pkg/mod/mvdan.cc/garble@v0.8.0/shared.go:392 +0x[63](https://github.com/klauspost/compress/actions/runs/3724454705/jobs/6316617540#step:9:64)4
main.replaceAsmNames(0x6916a0?, {0xc000182000?, 0xc000177400?, 0xa?})
	/home/runner/go/pkg/mod/mvdan.cc/garble@v0.8.0/main.go:734 +0x1a7
main.transformAsm({0xc0000b8030, 0x13, 0x13})
	/home/runner/go/pkg/mod/mvdan.cc/garble@v0.8.0/main.go:[66](https://github.com/klauspost/compress/actions/runs/3724454705/jobs/6316617540#step:9:67)8 +0x426
main.mainErr({0xc0000b8010, 0x15, 0x15})
	/home/runner/go/pkg/mod/mvdan.cc/garble@v0.8.0/main.go:423 +0x7ed
main.main1()
	/home/runner/go/pkg/mod/mvdan.cc/garble@v0.8.0/main.go:227 +0x16e
main.main()
	/home/runner/go/pkg/mod/mvdan.cc/garble@v0.8.0/main.go:134 +0x19
exit status 2

Edit: Simpler repro:

Check out https://github.com/klauspost/compress

λ cd s2/cmd/s2c
λ go install mvdan.cc/garble@latest
λ set GOOS=linux
λ set GOARCH=mips64
λ garble build
# runtime/internal/atomic
panic: runtime listed a std package we can't find: atomic

goroutine 1 [running]:
main.listPackage({0xc0001e9ba0, 0x6})
        e:/gopath/pkg/mod/mvdan.cc/garble@v0.8.0/shared.go:392 +0x634
main.replaceAsmNames(0x843200?, {0xc0001f2000?, 0xc0001e9980?, 0xa?})
        e:/gopath/pkg/mod/mvdan.cc/garble@v0.8.0/main.go:734 +0x1a7
main.transformAsm({0xc0000ca030, 0x13, 0x1d})
        e:/gopath/pkg/mod/mvdan.cc/garble@v0.8.0/main.go:668 +0x41f
main.mainErr({0xc0000ca010, 0x15, 0x1f})
        e:/gopath/pkg/mod/mvdan.cc/garble@v0.8.0/main.go:423 +0x75f
main.main1()
        e:/gopath/pkg/mod/mvdan.cc/garble@v0.8.0/main.go:227 +0x16e
main.main()
        e:/gopath/pkg/mod/mvdan.cc/garble@v0.8.0/main.go:134 +0x19
exit status 2

Compare to go build
@mvdan
Copy link
Member

mvdan commented Dec 19, 2022

Thanks for the report. I think it's caused by this bit of code:

$ git grep '\satomic·'
src/runtime/internal/atomic/atomic_loong64.s:   JMP atomic·Load(SB)
src/runtime/internal/atomic/atomic_loong64.s:   JMP atomic·Load64(SB)
src/runtime/internal/atomic/atomic_loong64.s:   JMP     atomic·Load64(SB)
src/runtime/internal/atomic/atomic_mips64x.s:   JMP atomic·Load(SB)
src/runtime/internal/atomic/atomic_mips64x.s:   JMP atomic·Load64(SB)
src/runtime/internal/atomic/atomic_mips64x.s:   JMP atomic·Load64(SB)

That would explain why you're the first to run into this issue. Our tests do build all of std for amd64, but not for mips or loong. We do have one test that ensures we can cross-build fine, but it doesn't cover all GOOS/GOARCH combinations due to cost.

I'm a bit perplexed by this qualified name. There's no atomic package in the standard library, only sync/atomic and runtime/internal/atomic, which is why we panic. I wonder if the assembler picks the current package, since we're building runtime/internal/atomic itself.

mvdan added a commit to mvdan/garble-fork that referenced this issue Jan 12, 2023
@mvdan
support assembly references to package names
aea335b 
Go's package runtime/internal/atomic contains references to functions
which refer to the current package by its package name alone:

	src/runtime/internal/atomic/atomic_loong64.s:   JMP atomic·Load(SB)
	src/runtime/internal/atomic/atomic_loong64.s:   JMP atomic·Load64(SB)
	src/runtime/internal/atomic/atomic_loong64.s:   JMP atomic·Load64(SB)
	src/runtime/internal/atomic/atomic_mips64x.s:   JMP atomic·Load(SB)
	src/runtime/internal/atomic/atomic_mips64x.s:   JMP atomic·Load64(SB)
	src/runtime/internal/atomic/atomic_mips64x.s:   JMP atomic·Load64(SB)

We could only handle unqualified or fully qualified references, like:

	JMP ·Load64(SB)
	JMP runtime∕internal∕atomic·Load64(SB)

Apparently, all three forms are equally valid.
Add a test case and fix it.

I checked whether referencing an imported package by its name worked;
it does not seem to be the case.
This feature appears to be restricted to the current package alone.

While here, we only need goPkgPath when we need to call listPackage.

Fixes burrowers#619.
@mvdan mvdan mentioned this issue Jan 12, 2023
Merged
mvdan added a commit that referenced this issue Jan 12, 2023
@mvdan
support assembly references to package names
5dd6b2d 
Go's package runtime/internal/atomic contains references to functions
which refer to the current package by its package name alone:

	src/runtime/internal/atomic/atomic_loong64.s:   JMP atomic·Load(SB)
	src/runtime/internal/atomic/atomic_loong64.s:   JMP atomic·Load64(SB)
	src/runtime/internal/atomic/atomic_loong64.s:   JMP atomic·Load64(SB)
	src/runtime/internal/atomic/atomic_mips64x.s:   JMP atomic·Load(SB)
	src/runtime/internal/atomic/atomic_mips64x.s:   JMP atomic·Load64(SB)
	src/runtime/internal/atomic/atomic_mips64x.s:   JMP atomic·Load64(SB)

We could only handle unqualified or fully qualified references, like:

	JMP ·Load64(SB)
	JMP runtime∕internal∕atomic·Load64(SB)

Apparently, all three forms are equally valid.
Add a test case and fix it.

I checked whether referencing an imported package by its name worked;
it does not seem to be the case.
This feature appears to be restricted to the current package alone.

While here, we only need goPkgPath when we need to call listPackage.

Fixes #619.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

support assembly references to package names mvdan/garble-fork
2 participants
@mvdan @klauspost