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: build failing on plan9/amd64 #41137

fhs opened this issue Aug 30, 2020 · 9 comments

all: build failing on plan9/amd64 #41137

fhs opened this issue Aug 30, 2020 · 9 comments


Copy link

@fhs fhs commented Aug 30, 2020

plan9/amd64 build has been failing for a while now. Example builder failure: It's also failing for me locally on my machine.

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

master: ba0fab3

What did you do?

cpu% cd src
cpu% ./make.rc

What did you expect to see?

Successful build

What did you see instead?

Building Go cmd/dist using /usr/fhs/go-plan9-amd64-bootstrap
Building Go toolchain1 using /usr/fhs/go-plan9-amd64-bootstrap.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
sys: trap: invalid opcode pc=0x38d2c8

goroutine 1 [running, locked to thread]:
	/home/big/go/src/cmd/internal/objabi/util.go:24 +0x3a8 fp=0x28044910 sp=0x28044908 pc=0x38d2c8
fmt.(*pp).handleMethods(0x28084ea0, 0x76, 0x2808f601)
	/home/big/go/src/fmt/print.go:626 +0x314 fp=0x28044b80 sp=0x28044910 pc=0x2d1154
fmt.(*pp).printArg(0x28084ea0, 0x5d2600, 0x28024650, 0x76)
	/home/big/go/src/fmt/print.go:709 +0x216 fp=0x28044c18 sp=0x28044b80 pc=0x2d1736
fmt.(*pp).doPrint(0x28084ea0, 0x28022550, 0x1, 0x1)
	/home/big/go/src/fmt/print.go:1157 +0x105 fp=0x28044ca0 sp=0x28044c18 pc=0x2d5f05
fmt.Sprint(0x28022550, 0x1, 0x1, 0x28024650, 0x280244f8)
	/home/big/go/src/fmt/print.go:249 +0x57 fp=0x28044cf0 sp=0x28044ca0 pc=0x2ce177
	/home/big/go/src/cmd/go/internal/cfg/cfg.go:248 +0x6c7 fp=0x28044ee8 sp=0x28044cf0 pc=0x38f067
	/home/big/go/src/runtime/proc.go:5627 +0x8f fp=0x28044f18 sp=0x28044ee8 pc=0x2443ef
	/home/big/go/src/runtime/proc.go:5622 +0x5c fp=0x28044f48 sp=0x28044f18 pc=0x2443bc
	/home/big/go/src/runtime/proc.go:5622 +0x5c fp=0x28044f78 sp=0x28044f48 pc=0x2443bc
	/home/big/go/src/runtime/proc.go:192 +0x228 fp=0x28044fe0 sp=0x28044f78 pc=0x237ac8
	/home/big/go/src/runtime/asm_amd64.s:1374 +0x1 fp=0x28044fe8 sp=0x28044fe0 pc=0x264f21

ax    0x38d2c8
bx    0x648de0
cx    0x28024650
dx    0x0
di    0x0
si    0x101
bp    0x28044b70
sp    0x28044908
r8    0xa22030
r9    0x38d2c8
r10   0x5b8360
r11   0x1
r12   0x0
r13   0x65
r14   0x200
r15   0x200
ip    0x38d2c8
flags 0x10246
cs    0x2b
fs    0x0
gs    0x0
go tool dist: FAILED: /home/big/go/pkg/tool/plan9_amd64/go_bootstrap install -gcflags=all= -ldflags=all= -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status: 'go_bootstrap 7175: sys: trap: invalid opcode pc=0x38d2c8'

@gopherbot add labels OS-Plan9, NeedsInvestigation

/CC @0intro

Copy link

@bcmills bcmills commented Aug 31, 2020

The last successful run I see on the dashboard is from CL 241275, back on 13 July 2020.

It's not clear to me whether the failures since then are due to a problem with the builder or a regression in the Go toolchain itself.

Copy link

@bcmills bcmills commented Aug 31, 2020

(And the builder was often very flaky even before then. If we want this configuration to stay green, we really need the builder to be up and completing CLs reliably...)

Copy link

@0intro 0intro commented Aug 31, 2020

This one isn't an issue with the builder, but a regression in the Go toolchain.

Copy link

@oridb oridb commented Oct 10, 2020

Did some bisection: I suspect that the issue is in a9a1217

Current HEAD is fine after reverting with:

% git/export a9a1217112aa8f5e01fe2f3e5f203ac880dbd566 | ape/patch -Rp1
Copy link

@oridb oridb commented Oct 12, 2020

@cherrymui : currently trying to understand exactly what's going on in this change and why it breaks in 9front.

Copy link

@cherrymui cherrymui commented Oct 12, 2020

Thanks for the report and investigation. CL should fix this.

Copy link

@gopherbot gopherbot commented Oct 12, 2020

Change mentions this issue: cmd/link: set runtime.text to the address of the first function

Copy link

@oridb oridb commented Oct 12, 2020

Awesome -- thanks! The fix mostly makes sense to me, though I wonder why Plan 9 needs the symbol rounded up.

Copy link

@cherrymui cherrymui commented Oct 12, 2020

On Plan 9 AMD64, the function alignment is 32 (as of all AMD64 platforms), the header size is 40, and FlagTextAddr = 0x200000 + size(header) is not aligned with function alignment, so we round up before laying out the first function.

This is specific to Plan 9 AMD64 (not 386 or ARM).

@gopherbot gopherbot closed this in 575ea5a Oct 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.