profile
viewpoint

thanm/dragongo 15

LLVM IR generation "middle end" for LLVM-based go compiler.

4ad/go 12

Go development tree for the sparc64 port

issue commentgolang/go

cmd/compile: inconsistent signaling NaN behavior on mips64le

The softfloat code is used on GOARM=5, or GOMIPS=softfloat, or compiler's -d softfloat flag. Yeah, the arm5 builder is down, and I don't think the MIPS builders are running in that mode.

randall77

comment created time in 21 hours

issue closedgolang/go

cmd/go: GOOS=js GOARCH=wasm go build -o [non-empty parent dir] ./... fails on Windows host

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

<pre> $ go version go version go1.14 windows/amd64 </pre>

Does this issue reproduce with the latest release?

Yes

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

<details><summary><code>go env</code> Output</summary><br><pre> $ go env set GO111MODULE= set GOARCH=amd64 set GOBIN= set GOCACHE=C:\Users\gledr\AppData\Local\go-build set GOENV=C:\Users\gledr\AppData\Roaming\go\env set GOEXE=.exe set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOINSECURE= set GONOPROXY= set GONOSUMDB= set GOOS=windows set GOPATH=C:\Users\gledr\Polyapp_Apps\gocode set GOPRIVATE= set GOPROXY=https://proxy.golang.org,direct set GOROOT=C:\Go set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64 set GCCGO=gccgo set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD=C:\Users\gledr\Polyapp_Apps\gocode\src\gitlab.com\polyapp-open-source\poly\go.mod set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\gledr\AppData\Local\Temp\go-build442293962=/tmp/go-build -gno-record-gcc-switches

</pre></details>

What did you do?

I was checking out the changes in #14295 and they work great most of the time, but I might have found an edge case where they fail. <details><summary>The changes in #14295 work great with regular GOOS and GOARCH on non-empty directories (nice work!):</summary>

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ go list ./...
gitlab.com/polyapp-open-source/poly/testdata/cmd
gitlab.com/polyapp-open-source/poly/testdata/cmd/hello

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ ls ./cmd
hello  main.go  wasm1  wasm2  wasm3

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ go build -o ./cmd ./...

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ ls ./cmd
cmd.exe  hello  hello.exe  main.go  wasm1  wasm2  wasm3

</details>

But doesn't work with GOOS=js GOARCH=wasm

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ GOOS=js GOARCH=wasm go list ./...
gitlab.com/polyapp-open-source/poly/testdata/cmd
gitlab.com/polyapp-open-source/poly/testdata/cmd/hello
gitlab.com/polyapp-open-source/poly/testdata/cmd/wasm1
gitlab.com/polyapp-open-source/poly/testdata/cmd/wasm2
gitlab.com/polyapp-open-source/poly/testdata/cmd/wasm3

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ ls ./cmd
hello  main.go  wasm1  wasm2  wasm3

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ GOOS=js GOARCH=wasm go build -o ./cmd ./...
go build gitlab.com/polyapp-open-source/poly/testdata/cmd/wasm1: build output "cmd\\wasm1" already exists and is a directory
go build gitlab.com/polyapp-open-source/poly/testdata/cmd/wasm2: build output "cmd\\wasm2" already exists and is a directory
go build gitlab.com/polyapp-open-source/poly/testdata/cmd/wasm3: build output "cmd\\wasm3" already exists and is a directory
go build gitlab.com/polyapp-open-source/poly/testdata/cmd/hello: build output "cmd\\hello" already exists and is a directory

<details><summary>It works great with GOOS=js GOARCH=wasm if I make a new directory:</summary>

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata
(CI-expansion)
$ ls ./cmd
hello  main.go  wasm1  wasm2  wasm3

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata
(CI-expansion)
$ ls ./bin
ls: cannot access './bin': No such file or directory

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ GOOS=js GOARCH=wasm go list ./...
gitlab.com/polyapp-open-source/poly/testdata/cmd
gitlab.com/polyapp-open-source/poly/testdata/cmd/hello
gitlab.com/polyapp-open-source/poly/testdata/cmd/wasm1
gitlab.com/polyapp-open-source/poly/testdata/cmd/wasm2
gitlab.com/polyapp-open-source/poly/testdata/cmd/wasm3

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata
(CI-expansion)
$ mkdir ./bin

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ GOOS=js GOARCH=wasm go build -o ./bin ./...

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ ls ./bin
cmd  hello  wasm1  wasm2  wasm3

</details>

<details><summary>And it works great if I rebuild into the bin directory:</summary>

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ GOOS=js GOARCH=wasm go build -o ./bin ./...

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ rm ./bin/cmd ./bin/hello ./bin/wasm2

gledr@LAPTOP-AH6IAHBO MINGW64 ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata (CI-expansion)
$ GOOS=js GOARCH=wasm go build -o ./bin ./...

</details>

Is this intended to work with non-empty parent directories of the binaries? Why does it work with GOOS=windows GOARCH=amd64 but not GOOS=js GOARCH=wasm?

<details><summary>My directory structure lives inside $GOPATH at ~/Polyapp_Apps/gocode/src/gitlab.com/polyapp-open-source/poly/testdata because, setting the exact issue aside, I'm writing some tools to make linting, testing, building, and running my multi-arch. programs a bit easier.</summary>

testdata/
    cmd/
        hello/
            main.go
            main_test.go
        wasm1/
            main_js_wasm.go
        wasm2/
            main_js_wasm.go
        wasm3/
            main.go
        main.go

</details>

<details><summary>Here are my test files in order of the directory structure. Some files have perhaps changed a bit since I ran the commands above - I don't recall if the test file existed before</summary>

testdata/cmd/hello/main.go

package main

import (
	"fmt"
	"os"
)

func main() {
	fmt.Println("Hello from poly/testdata/cmd/hello/main.go")

	osCheck()
}

// osCheck returns true for success using syscalls and false otherwise
func osCheck() bool {
	_, err := os.Stat(".")
	if err != nil {
		fmt.Println("os.Stat failed: " + err.Error())
		return false
	}
	return true
}

testdata/cmd/hello/main_test.go

package main

import "testing"

func TestOsCheck(t *testing.T) {
	chk := osCheck()
	if chk == false {
		t.Fatal("couldn't stat")
	}
}

testdata/cmd/wasm1/main_js_wasm.go

// +build js

package main

import "fmt"

func main() {
	fmt.Println("hello from testdata/cmd/wasm1/main_js_wasm.go")
}

testdata/cmd/wasm2/main_js_wasm.go

// +build js

package main

import "fmt"

func main() {
	fmt.Println("hello from testdata/cmd/wasm2/main_js_wasm.go")
}

testdata/cmd/wasm3/main.go

// +build js

package main

import "fmt"

func main() {
	fmt.Println("Hello from testdata/cmd/wasm3/main.go")
}

testdata/cmd/main.go

package main

import "fmt"

func main() {
	fmt.Println("Hello from poly/testdata/cmd/main.go")
}

</details>

closed time in 2 days

Gregory-Ledray

issue commentgolang/go

cmd/go: GOOS=js GOARCH=wasm go build -o [non-empty parent dir] ./... fails on Windows host

Closing as this works as intended.

Gregory-Ledray

comment created time in 2 days

issue commentgolang/go

cmd/go: GOOS=js GOARCH=wasm go build -o [non-empty parent dir] ./... fails on Windows host

$ GOOS=js GOARCH=wasm go build -o ./cmd ./...

You're trying to write output files cmd/wasm1, cmd/wasm2, etc., but these paths already exist and are directories, so it cannot overwrite it, as the error message clearly stated.

Writing to any other directories where there aren't such paths should work.

Why does it work with GOOS=windows GOARCH=amd64 but not GOOS=js GOARCH=wasm?

Because cmd/wasm1, etc. are build-tagged for wasm. It doesn't build on windows.

Gregory-Ledray

comment created time in 2 days

issue commentgolang/go

runtime: compression benchmark regression in go1.14 due to async preemption

Yeah, I think this is consistent with our previous analysis. There is no contention if there is just one thread. The more threads, the more threads trying to preempt each other, thus the heavier contention.

klauspost

comment created time in 2 days

issue commentgolang/go

internal/go115: add package

I think the idea is to gate large changes that are hard to revert. For small changes we can just revert them in the case that it is necessary, without gating.

josharian

comment created time in 2 days

issue commentgolang/go

cmd/compile: inconsistent signaling NaN behavior on mips64le

I think it should generate a quiet NaN. The MIPS manual said

An SNaN is never produced as a result value.

Also

SNaN operands cause the Invalid Operation exception for arithmetic operations. ... The result, when the exception condition occurs without a precise trap, is a quiet NaN.

randall77

comment created time in 3 days

issue commentgolang/go

x/text/unicode/norm: TestLinking consistently failing on multiple builders

Or the test can use linker's -R flag to reduce the alignment. This might cause problems at run time, but we don't run the resulted binaries.

bcmills

comment created time in 3 days

issue commentgolang/go

x/text/unicode/norm: TestLinking consistently failing on multiple builders

Or it can add the size of sections without the paddings. But then it needs to be OS dependent: will need codepaths for ELF, Mach-O, xcoff, etc..

bcmills

comment created time in 3 days

issue commentgolang/go

x/text/unicode/norm: TestLinking consistently failing on multiple builders

My guess is that this is due to alignment padding between segments. It seems the failures are all on architectures with large alignment (usually 0x10000 i.e. 64K). Worst case the alignment padding can increase the binary size by 64K, which can shadow the 50K difference we're looking for.

If the test is checking if the table is dropped by the linker, maybe use the nm command to look for particular symbols?

bcmills

comment created time in 3 days

issue commentgolang/go

cmd/compile: bad types originating from ssa rule to inline memmove

I think memmove is only used for pointerless types. For pointerful types, it needs a write barrier so it will use typedmemmove.

josharian

comment created time in 3 days

issue commentgolang/go

x/build: linux-arm trybot failure

In the mean time, I have been using gomote for ARM. Using android-arm is another option, which is not the same as linux-arm but also has many similarities.

cherrymui

comment created time in 4 days

issue commentgolang/go

runtime: "interface {} is nil, not *main.T" on linux-amd64-noopt builder

Perhaps some operation that the runtime assumes to be atomic no longer is in noopt mode?

I didn't mean that some atomic operations are not atomic in noopt mode. I meant it may be not intrinsified, which affects where the safe points are. That is specific to #36110.

bcmills

comment created time in 4 days

issue commentgolang/go

cmd/compile: bad types originating from ssa rule to inline memmove

The type Aux for Move is used for the write barrier pass to insert write barriers. But for types that don't contain pointers, it doesn't really matter -- the write barrier pass just needs to know it doesn't contain pointers. (For pointerful types, it does need to be correct.)

Also, on some architectures, the type's alignment is used in lowering.

So for the memmove case, it is fine to use byte type (for now), which is pointerless and has minimum alignment. Maybe leave a comment?

josharian

comment created time in 5 days

issue commentgolang/go

cmd/link: -X does not work on variables with non-constant default values

This is a bit harder. The linker has to understand it is initialized dynamically. I don't think we want the linker to walk the init functions to find out this. Maybe the compiler could emit a marker when a string variable is initialized dynamically, for the linker to check.

jayconrod

comment created time in 7 days

issue commentgolang/go

cmd/link: -X does not work on variables with non-constant default values

Related to #34675. It looks to me that this is the opposite.

We used to forward the static initializer of DEFAULT to STAMP at compile time. But then if a -X flag is set on DEFAULT, it won't affect STAMP as STAMP is statically initialized with the old value. For this reason (i.e. #34675), we stopped forwarding the static initializer. Now STAMP is assigned dynamically (to the value of DEFAULT at that time), so it is not affected by link time modification.

This or #34675, it seems to me that we can only choose one, at least without a much more complex logic. var x = f() is already not affected by the -X flag, as we have to do the assignment dynamically. It looks to me that it is consistent to treat var x = y also as a dynamic assignment.

jayconrod

comment created time in 7 days

issue commentgolang/go

cmd/compile: illegal instruction (core dumped) on FreeBSD ARM64

Reading the manual, it looks to me the register id_aa64isar0_el1 is privileged. It seems accessing the register is user mode is "UNDEFINED". Maybe @zhangfannie can confirm.

artooro

comment created time in 7 days

issue openedgolang/go

cmd/go: confusing cache behavior for GOSSAFUNC

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

tip (631b49886c)

Does this issue reproduce with the latest release?

Yes

What did you do?

I generated a ssa.html using GOSSAFUNC, and somehow lost it, e.g. overwritten by another one. I try to generate it again.

$ GOSSAFUNC=F go build p.go
# command-line-arguments
dumped SSA to ./ssa.html

$ ls ssa.html 
ssa.html

$ rm ssa.html                  # somehow I lost it, e.g. overwritten by another one

$ GOSSAFUNC=F go build p.go    # try to generate it again
# command-line-arguments
dumped SSA to ./ssa.html

$ ls ssa.html
ls: ssa.html: No such file or directory

The second time, the build is cached, along with its stdout, which said ssa.html is generated. But the html is not cached and not regenerated. This is confusing. To actually regenerate the html I have to make a trivial change to the source file. It would be nice if I don't have to do it this way.

cc @rsc @bcmills

created time in 8 days

issue commentgolang/go

runtime: can't atomic access of first word of tiny-allocated struct on 32-bit architecture

It looks like this problem is wholly #36606 as @cherrymui mentioned, so we might want to just close this as a duplicate?

Not exactly. Fixing #36606 will make this go away, but we can also fix this separately. This issue is specific to the first word of an allocation, which we try to make it still 8-byte aligned, as mentioned in https://golang.org/pkg/sync/atomic/#pkg-note-BUG . Currently it is mostly aligned, except for tinyalloc (and sbrk mode).

NewbMiao

comment created time in 8 days

issue commentgolang/go

cmd/link: unexpected fault address (when low on disk space?)

Yeah, this is writing to mmap'd memory backed by the output file. SIGBUS may occur if write to mmap'd memory fails (maybe cannot flush to disk?).

It would be good if we can fail nicely. But I don't know how. Maybe write (using file IO) to the last byte of the output file before mmap? If that write fails we can exit with a nice error. Does it work? cc @aclements

bradfitz

comment created time in 8 days

issue commentgolang/go

gollvm: find a better way to deal with g

Personally I'd really like a way to let the backend not cache TLS addresses in GCC and LLVM. I don't think this is specific to Go. In C, if you use getcontext/setcontext with TLS variables, this problem can also happen. But I guess getcontext/setcontext are not used very common. As you said, this probably won't happen soon.

Follow the practice of main go, reserve a register to store g.

I thought about that. The tricky thing is that the libgo runtime uses C for many things, including external C code, libbacktrace, libffi, libgcc, and syscall wrappers from libc. If we reserve a register globally, all these C code need to be compiled in a special way. Or we have to have some wrapper that save/restore the reserved register at C library boundaries.

Store g in a suitable location on the stack.

I'm not sure how this is going to work. Also, the C code seems to need special compilation.

Maybe a possibility is with the current approach, and add a machine-IR pass, runs after CSE, that inlines getg calls back in. This will be machine dependent. And I'm not sure if this can be done for gccgo.

erifan

comment created time in 9 days

issue commentgolang/go

cmd/compile: cant atomic access of first word of allocated struct occasionally?

I think this can only happen for a size 9-15 object on a 32-bit architecture. Maybe we round up for only this case. I don't think it is too bad.

NewbMiao

comment created time in 10 days

issue commentgolang/go

cmd/compile: cant atomic access of first word of allocated struct occasionally?

typ.align doesn't help in the current way. On 32-bit architectures it is 4 for int64. This is what #36606 is for.

NewbMiao

comment created time in 10 days

issue commentgolang/go

runtime: invalid pc-encoded table when running Openshift tests using go1.14rc1 on ppc64le

@laboger does CL https://go-review.googlesource.com/c/go/+/219717 help? Thanks!

laboger

comment created time in 12 days

issue commentgolang/go

runtime: callstack seems fall into infinite loop with CGO on GOOS=linux GOARCH=arm64

crosscall1 is basically the bottom of the stack. Maybe we could do something so gdb has the correct unwind info.

It does not affect program execution.

iswade

comment created time in 12 days

issue commentgolang/go

runtime: invalid pc-encoded table when running Openshift tests using go1.14rc1 on ppc64le

Thanks, @laboger . Yeah, I think the trampolines inserted by the external linker might be the problem. If a preemption signal lands in such trampoline, it may get this error. I'll try to make a fix.

laboger

comment created time in 14 days

issue commentgolang/go

runtime: invalid pc-encoded table when running Openshift tests using go1.14rc1 on ppc64le

My guess is that our func table assumes the address space of text is contiguous, and if there are functions inserted by the external linker in the middle, the logic falls apart. In particular, if we ask for the pc table for a PC that belongs to the inserted function, it will find the wrong function, because the func table doesn't contain an entry of such function.

laboger

comment created time in 15 days

issue commentgolang/go

runtime: invalid pc-encoded table when running Openshift tests using go1.14rc1 on ppc64le

@laboger is the binary internally linked or externally linked? Is it possible that I could get the binary? (I probably don't need to run it, just examining the content may be enough.) Thanks!

laboger

comment created time in 15 days

issue commentgolang/go

runtime: invalid pc-encoded table when running Openshift tests using go1.14rc1 on ppc64le

@laboger thanks! This is very helpful. Apparently findfunc returns a wrong function for the PC in PLT. I'll look into it.

laboger

comment created time in 15 days

issue commentgolang/go

runtime: invalid pc-encoded table when running Openshift tests using go1.14rc1 on ppc64le

@laboger could you take a look at what function PC 0x11c0f9c0 belongs to? Does it belong to function github.com/openshift/origin/vendor/k8s.io/api/imagepolicy/v1alpha1.(*ImageReview).SetOwnerReferences? What is the start and end addresses of that function? Or whatever targetpc and f is, if you get a different invalid pc-encoded table failre. Thanks!

laboger

comment created time in 15 days

issue commentgolang/go

runtime: go1.14rc1 fatal error: invalid runtime symbol table: runtime: unexpected return pc for runtime.sigreturn called from 0x7

Yeah, there might be one ~next week or so. You could also check out Go tip, which is very close to 1.14rc1, with just a small number of fixes. Thanks!

tonyghita

comment created time in 15 days

issue commentgolang/go

runtime: go1.14rc1 fatal error: invalid runtime symbol table: runtime: unexpected return pc for runtime.sigreturn called from 0x7

@laboger yeah, I think it's better to open a new one. Quick question: do you have profiling turned on? If not, it is clearly a different problem.

tonyghita

comment created time in 15 days

issue commentgolang/go

runtime: go1.14rc1 fatal error: invalid runtime symbol table: runtime: unexpected return pc for runtime.sigreturn called from 0x7

Given that the crash is hard to reproduce, I cannot tell for sure whether the problem goes away with this, so "may fix". I guess we can close this and, if it didn't work, reopen it. Or we keep it open and let the reporter confirm.

tonyghita

comment created time in 15 days

issue closedgolang/go

cmd/objdump: autogenerated code is not dumped

<!-- Please answer these questions before submitting your issue. Thanks! For questions please use one of our forums: https://github.com/golang/go/wiki/Questions -->

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

<pre> $ go version go version go1.13.4 darwin/amd64 </pre>

Does this issue reproduce with the latest release?

Yes, the autogenerated code does not appear in 1.13 and 1.14rc1. But 1.12.6 is OK.

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

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/changkun/Library/Caches/go-build" GOENV="/Users/changkun/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/changkun/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/Cellar/go/1.13.4/libexec" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/Cellar/go/1.13.4/libexec/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="" 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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/j_/h4j7spgj3znbfxcbbph5fp4w0000gn/T /go-build516351997=/tmp/go-build -gno-record-gcc-switches -fno-common" </pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

package main

import (
	"fmt"
	_ "net/http"
)

func init() {
	println("func main.init")
}

func main() {
	fmt.Printf("hello, %s", "world!")
}
$ go build -gcflags "-N -l" -ldflags=-compressdwarf=false -o ~/main.out ~/main.go
$ go tool objdump -s main.init main.out > main.S

What did you expect to see?

TEXT main.init.0(SB) /Users/changkun/main.go
  main.go:8		0x1224cb0		65488b0c2530000000	MOVQ GS:0x30, CX			
  main.go:8		0x1224cb9		483b6110		CMPQ 0x10(CX), SP			
  main.go:8		0x1224cbd		763b			JBE 0x1224cfa				
  main.go:8		0x1224cbf		4883ec18		SUBQ $0x18, SP				
  main.go:8		0x1224cc3		48896c2410		MOVQ BP, 0x10(SP)			
  main.go:8		0x1224cc8		488d6c2410		LEAQ 0x10(SP), BP			
  main.go:9		0x1224ccd		e87e89e0ff		CALL runtime.printlock(SB)		
  main.go:9		0x1224cd2		488d0586ae0800		LEAQ go.string.*+9951(SB), AX		
  main.go:9		0x1224cd9		48890424		MOVQ AX, 0(SP)				
  main.go:9		0x1224cdd		48c74424080f000000	MOVQ $0xf, 0x8(SP)			
  main.go:9		0x1224ce6		e89592e0ff		CALL runtime.printstring(SB)		
  main.go:9		0x1224ceb		e8e089e0ff		CALL runtime.printunlock(SB)		
  main.go:10		0x1224cf0		488b6c2410		MOVQ 0x10(SP), BP			
  main.go:10		0x1224cf5		4883c418		ADDQ $0x18, SP				
  main.go:10		0x1224cf9		c3			RET					
  main.go:8		0x1224cfa		e80118e3ff		CALL runtime.morestack_noctxt(SB)	
  main.go:8		0x1224cff		ebaf			JMP main.init.0(SB)			
  :-1			0x1224d01		cc			INT $0x3				
  :-1			0x1224d02		cc			INT $0x3				
  :-1			0x1224d03		cc			INT $0x3				
  :-1			0x1224d04		cc			INT $0x3				
  :-1			0x1224d05		cc			INT $0x3				
  :-1			0x1224d06		cc			INT $0x3				
  :-1			0x1224d07		cc			INT $0x3				
  :-1			0x1224d08		cc			INT $0x3				
  :-1			0x1224d09		cc			INT $0x3				
  :-1			0x1224d0a		cc			INT $0x3				
  :-1			0x1224d0b		cc			INT $0x3				
  :-1			0x1224d0c		cc			INT $0x3				
  :-1			0x1224d0d		cc			INT $0x3				
  :-1			0x1224d0e		cc			INT $0x3				
  :-1			0x1224d0f		cc			INT $0x3				

TEXT main.init(SB) <autogenerated>
  <autogenerated>:1	0x1224dd0		65488b0c2530000000	MOVQ GS:0x30, CX			
  <autogenerated>:1	0x1224dd9		483b6110		CMPQ 0x10(CX), SP			
  <autogenerated>:1	0x1224ddd		7658			JBE 0x1224e37				
  <autogenerated>:1	0x1224ddf		4883ec08		SUBQ $0x8, SP				
  <autogenerated>:1	0x1224de3		48892c24		MOVQ BP, 0(SP)				
  <autogenerated>:1	0x1224de7		488d2c24		LEAQ 0(SP), BP				
  <autogenerated>:1	0x1224deb		803d719e2b0001		CMPB $0x1, main.initdone.(SB)		
  <autogenerated>:1	0x1224df2		7702			JA 0x1224df6				
  <autogenerated>:1	0x1224df4		eb09			JMP 0x1224dff				
  <autogenerated>:1	0x1224df6		488b2c24		MOVQ 0(SP), BP				
  <autogenerated>:1	0x1224dfa		4883c408		ADDQ $0x8, SP				
  <autogenerated>:1	0x1224dfe		c3			RET					
  <autogenerated>:1	0x1224dff		803d5d9e2b0001		CMPB $0x1, main.initdone.(SB)		
  <autogenerated>:1	0x1224e06		7402			JE 0x1224e0a				
  <autogenerated>:1	0x1224e08		eb07			JMP 0x1224e11				
  <autogenerated>:1	0x1224e0a		e8416be0ff		CALL runtime.throwinit(SB)		
  <autogenerated>:1	0x1224e0f		0f0b			UD2					
  <autogenerated>:1	0x1224e11		c6054b9e2b0001		MOVB $0x1, main.initdone.(SB)		
  <autogenerated>:1	0x1224e18		e8b3b9e8ff		CALL fmt.init(SB)			
  <autogenerated>:1	0x1224e1d		e86e8affff		CALL net/http.init(SB)			
  <autogenerated>:1	0x1224e22		e889feffff		CALL main.init.0(SB)			
  <autogenerated>:1	0x1224e27		c605359e2b0002		MOVB $0x2, main.initdone.(SB)		
  <autogenerated>:1	0x1224e2e		488b2c24		MOVQ 0(SP), BP				
  <autogenerated>:1	0x1224e32		4883c408		ADDQ $0x8, SP				
  <autogenerated>:1	0x1224e36		c3			RET					
  <autogenerated>:1	0x1224e37		e8c416e3ff		CALL runtime.morestack_noctxt(SB)	
  <autogenerated>:1	0x1224e3c		eb92			JMP main.init(SB)			

What did you see instead?

TEXT main.init.0(SB) /Users/changkun/main.go
  main.go:8		0x1233e80		65488b0c2530000000	MOVQ GS:0x30, CX			
  main.go:8		0x1233e89		483b6110		CMPQ 0x10(CX), SP			
  main.go:8		0x1233e8d		763b			JBE 0x1233eca				
  main.go:8		0x1233e8f		4883ec18		SUBQ $0x18, SP				
  main.go:8		0x1233e93		48896c2410		MOVQ BP, 0x10(SP)			
  main.go:8		0x1233e98		488d6c2410		LEAQ 0x10(SP), BP			
  main.go:9		0x1233e9d		e8beb1dfff		CALL runtime.printlock(SB)		
  main.go:9		0x1233ea2		488d05ef280900		LEAQ go.string.*+10552(SB), AX		
  main.go:9		0x1233ea9		48890424		MOVQ AX, 0(SP)				
  main.go:9		0x1233ead		48c74424080f000000	MOVQ $0xf, 0x8(SP)			
  main.go:9		0x1233eb6		e8e5badfff		CALL runtime.printstring(SB)		
  main.go:9		0x1233ebb		e820b2dfff		CALL runtime.printunlock(SB)		
  main.go:10		0x1233ec0		488b6c2410		MOVQ 0x10(SP), BP			
  main.go:10		0x1233ec5		4883c418		ADDQ $0x18, SP				
  main.go:10		0x1233ec9		c3			RET					
  main.go:8		0x1233eca		e8a149e2ff		CALL runtime.morestack_noctxt(SB)	
  main.go:8		0x1233ecf		ebaf			JMP main.init.0(SB)			
  :-1			0x1233ed1		cc			INT $0x3				
  :-1			0x1233ed2		cc			INT $0x3				
  :-1			0x1233ed3		cc			INT $0x3				
  :-1			0x1233ed4		cc			INT $0x3				
  :-1			0x1233ed5		cc			INT $0x3				
  :-1			0x1233ed6		cc			INT $0x3				
  :-1			0x1233ed7		cc			INT $0x3				
  :-1			0x1233ed8		cc			INT $0x3				
  :-1			0x1233ed9		cc			INT $0x3				
  :-1			0x1233eda		cc			INT $0x3				
  :-1			0x1233edb		cc			INT $0x3				
  :-1			0x1233edc		cc			INT $0x3				
  :-1			0x1233edd		cc			INT $0x3				
  :-1			0x1233ede		cc			INT $0x3				
  :-1			0x1233edf		cc			INT $0x3				

closed time in 16 days

changkun

issue commentgolang/go

cmd/objdump: autogenerated code is not dumped

That is because we no longer generate main.init function. Instead we generate a variable for running the init routines. Autogenerated functions in general, e.g. type equality functions, still present.

changkun

comment created time in 16 days

issue commentgolang/go

runtime: Darwin slow when using signals + int->float instructions

I also tried adding VZEROUPPER to asyncPreempt, it didn't help either.

That was not true. I had nosplit in mulFast/mulSlow left for previous experiments, which caused it not to actually inject the call. Removing the nosplit makes it work, and it actually faster.

Before:

$ go-tmp test -bench=. .
goos: darwin
goarch: amd64
BenchmarkFast-8   	14685382	        90.9 ns/op
BenchmarkSlow-8   	 8348937	       184 ns/op
PASS
ok  	_/tmp/pp	3.121s

After:

$ go-tmp test -bench=. .
goos: darwin
goarch: amd64
BenchmarkFast-8   	24309422	        48.6 ns/op
BenchmarkSlow-8   	25514097	        49.0 ns/op
PASS
ok  	_/tmp/pp	2.553s
randall77

comment created time in 17 days

issue commentgolang/go

runtime: Darwin slow when using signals + int->float instructions

@dr2chase tried that, it didn't help. I also tried adding VZEROUPPER to asyncPreempt, it didn't help either. I also tried to change sigtramp to immediately return, it also didn't help...

randall77

comment created time in 17 days

issue commentgolang/go

cmd/link: go version fails on internally linked PIE

I think 2 doesn't work, because there are also address references in the string header referenced by those symbols, which also need to apply statically. We'll probably have to do 1...

cherrymui

comment created time in 17 days

issue openedgolang/go

cmd/link: go version fails on internally linked PIE

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

tip (1c241d28792fad017cbd64bae72ea3f3ee51e4df)

Does this issue reproduce with the latest release?

yes

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

linux/amd64

What did you do?

Related to issue #31861, go version still fails on internally linked PIE.

$ go build -buildmode=pie -ldflags=-linkmode=internal hello.go 
$ go version hello
hello: go version not found

It seems the problem is that for building PIE, we generate dynamic relocations for address references. This includes the address references for the build info, specifically in symbols .go.buildinfo, runtime.buildVersion, and runtime.modinfo. When we generate dynamic relocations, we just leave the bytes in the binary unset (as zero), as the dynamic linker will overwrite it at run time anyway. But go version examines the file, so it won't be able to follow the address references.

I see the following ways for fixing this:

  1. when generating dynamic relocations, also apply the relocations statically (to the address without the base), so the file content can be used to find the reference. However, this will make the linker resolve more relocations that are unnecessary.
  2. only apply the static relocations to specific symbols (namely, .go.buildinfo, runtime.buildVersion, and runtime.modinfo). We need to keep the list of special symbols in sync with the runtime and the go command, though.
  3. teach go version about resolving dynamic relocations. Seems overkill.

@ianlancetaylor @rsc @bcmills for thoughts. I can do the implementation once we decide which way to go.

created time in 17 days

issue commentgolang/go

runtime: go1.14rc1 fatal error: invalid runtime symbol table: runtime: unexpected return pc for runtime.sigreturn called from 0x7

I think this may be related to CL https://go-review.googlesource.com/c/go/+/212079 . The code saving vdsoPC in walltime1/nanotime1 assumes the function has no frame https://go-review.googlesource.com/c/go/+/212079/3/src/runtime/sys_linux_amd64.s#224 Now the functions do have frame, so the offset needs adjustment.

That said, if my assumption is right, the PPC64 failure is probably a different one.

tonyghita

comment created time in 17 days

issue commentgolang/go

misc/wasm: deadlock from http.Get in syscall/js.FuncOf

The doc of FuncOf, https://golang.org/pkg/syscall/js/#FuncOf , said that blocking operations in the wrapped function will block the event loop. So I think you want to move blocking operations out of FuncOf, e.g. to main as you did.

QFleet

comment created time in 20 days

issue commentgolang/go

runtime: golang 1.14.rc1 3-5% performance regression from golang 1.13 during protobuf marshalling

I think if regular memory check is true, we could special case 32-bit and 64-bit sizes?

howardjohn

comment created time in 21 days

issue commentgolang/go

runtime: async preemption support on ARM64 breaks ARM64 on QEMU

As @bcmills said, QEMU user mode is not actually supported. I think this is a QEMU bug in handling async signals, especially with signal context modifications. And it's not only ARM64, but also other architectures. For reference, for AMD64, qemu-x86_64 doesn't work since at least Go 1.6 (due to other reasons, not async signal).

$ go1.6 build hello.go
$ qemu-x86_64 ./hello
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
kortschak

comment created time in 25 days

issue closedgolang/go

gollvm: build failure: no matching function for call to [std::string](llvm::StringRef, int, const int&)

Hello!

On a work machine, with some of the repositories set up before I started, I'm trying to get a build of gollvm working following these instructions. After making sure the repositories were up to date--namely, according to git remote -v and git log:

  • https://github.com/llvm/llvm-project.git: llvm/llvm-project@480391035c730b7b8a58601ef54e0543824ba931
  • https://go.googlesource.com/gollvm: c1e41505d0c621c29ff9e35fa776699121bc90ab
  • https://go.googlesource.com/gofrontend: d796680b5a78f686ed118578e81d5b1adf48508d
  • https://github.com/libffi/libffi.git: libffi/libffi@b844a9c7f1ca792a1dfb0c09d5dae576178e6729
  • https://github.com/ianlancetaylor/libbacktrace.git: ianlancetaylor/libbacktrace@559ab7cab4a6002124863d493bd09a376a690e76

...the build fails with the following error in [gollvm]/bridge/go-sha1.cpp (not a code block to allow that long CFLAGS line to wrap):

[327/1929] Building CXX object tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-sha1.cpp.o FAILED: tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-sha1.cpp.o /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/gollvm/bridge -I/home/alshamar/llvm-project/llvm/tools/gollvm/bridge -I/usr/include/libxml2 -Iinclude -I/home/alshamar/llvm-project/llvm/include -Itools/gollvm/external/install/include -I/home/alshamar/llvm-project/llvm/tools/gollvm/gofrontend/go -fPIC -fvisibility-inlines-hidden -Werror=date-time -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -g -fno-exceptions -fno-rtti -std=c++14 -MD -MT tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-sha1.cpp.o -MF tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-sha1.cpp.o.d -o tools/gollvm/bridge/CMakeFiles/LLVMCppGoFrontEnd.dir/go-sha1.cpp.o -c /home/alshamar/llvm-project/llvm/tools/gollvm/bridge/go-sha1.cpp /home/alshamar/llvm-project/llvm/tools/gollvm/bridge/go-sha1.cpp: In member function ‘virtual std::__cxx11::string Llvm_Sha1_Helper::finish()’: /home/alshamar/llvm-project/llvm/tools/gollvm/bridge/go-sha1.cpp:49:52: error: no matching function for call to ‘std::_cxx11::basic_string<char>::basic_string(llvm::StringRef, int, const int&)’ std::string result(ctx->final(), 0, checksum_len); ^ In file included from /usr/include/c++/8/string:52, from /home/alshamar/llvm-project/llvm/tools/gollvm/bridge/go-system.h:10, from /home/alshamar/llvm-project/llvm/tools/gollvm/gofrontend/go/go-sha1.h:10, from /home/alshamar/llvm-project/llvm/tools/gollvm/bridge/go-sha1.cpp:12:

(Omitted thereafter is an inane amount of "note: candidate" suggestions.)

Any help getting this build working would be appreciated :)

closed time in a month

Grissess

issue commentgolang/go

cmd/compile: possible latent codegen issue on amd64 removing zero extensions

Same for me. I'm also not super happy about the extension removing.

(ANDLconst [c] x) && int32(c)==-1 -> x

I think we should only do this if the type is 32-bit wide or smaller. But how good are we keeping the types accurate?

(MOVLQZX x) && zeroUpper32Bits(x,3) -> x

The LHS is 64-bit wide, whereas the RHS is 32-bit wide. This kind of rules have always troubled me. Maybe we could have a way of doing this in a type-preserving way? Something like (op x:(op2 ...)) -> (op2 <t> ...) ?

josharian

comment created time in a month

issue commentgolang/go

cmd/compile: floating-point broken on android-arm-corellium builder

cc @eliasnaur

bcmills

comment created time in a month

issue commentgolang/go

cmd/compile: floating-point broken on android-arm-corellium builder

Thanks. So it is probably indeed a hardware/OS bug...

bcmills

comment created time in a month

issue commentgolang/go

cmd/compile: floating-point broken on android-arm-corellium builder

GOARM=5 implies softfloat. I don't think android-arm is a softfloat builder. But we do have some softfloat tests that runs everywhere.

The arm5 builder is a softfloat builder (and the only one).

bcmills

comment created time in a month

issue commentgolang/go

cmd/compile: floating-point broken on android-arm-corellium builder

Does it work if we disable async preemption? GODEBUG=asyncpreemptoff=1

bcmills

comment created time in a month

issue commentgolang/go

cmd/compile: ppc64 builds failing with ssa checker on

Tests in cmd/compile/internal/gc/ssa_test.go are run with SSA check enabled (on each host architecture). It covers basic operations but is not as complete as building std.

josharian

comment created time in a month

issue commentgolang/go

cmd/compile: arm64 ssa check compilation failure

It's not very concerning. It is just that the Value's AuxInt doesn't fit in int32 while the AuxInt type is specified as int32. I think the high bits are never used and so don't actually matter. So it shouldn't affect anything when SSA check is not on.

josharian

comment created time in a month

issue commentgolang/go

cmd/compile: ppc64 builds failing with ssa checker on

CL https://go-review.googlesource.com/c/go/+/216379 should fix the immediate problem.

When SSA check is on, the Values are reordered, which affects the ordering of rewriting rules firing (and eventually whether some rules are fired or not), which affects the compilation result.

josharian

comment created time in a month

issue commentgolang/go

cmd/compile: ppc64 builds failing with ssa checker on

Running with the SSA checker on shouldn't impact the generated code (I thought?).

I also thought so. But then I found this https://go.googlesource.com/go/+/refs/heads/master/src/cmd/compile/internal/ssa/compile.go#80

My guess is that it might catch a real bug that we (accidentally) depended on value ordering.

josharian

comment created time in a month

issue commentgolang/go

cmd/compile: ppc64 builds failing with ssa checker on

I think the SSA check builder only runs for AMD64. It doesn't do cross compilations.

josharian

comment created time in a month

issue commentgolang/go

libgo: regression in runtime test TestCallersNilPointerPanic on ppc64le with Go 1.14beta1 update

This test also fails with gollvm (linux/amd64). I think it is because gollvm always generate an explicit nil check first, and may optimize it out at a late stage if there is a load or store. In this test, where we do var p *int; *p = 3, the backend sees p is constant nil so the faulting branch in the explicit nil check is certainly taken, and it eliminates the load and compiles it to a call to panicmem. This happens before the optimization of nil checks.

The PPC failure is probably different, if it uses implicit nil check (which I think it does for gccgo).

laboger

comment created time in a month

issue commentgolang/go

runtime: "found bad pointer in Go heap" on linux-mips64le-mengzhuo builder

I looked at a few new MIPS failures and they all look like the ones before, and are consistent with my previous comment. The "bad pointer" seems from g._defer, which points to the stack (within the stack bounds), but spanOf returns a different span. I don't yet understand how this could happen.

The freebsd-arm64 one is different, and may be fixed by CL https://go-review.googlesource.com/c/go/+/212626 .

bcmills

comment created time in a month

issue commentgolang/go

gollvm: document that building requires bash(?)

I don't think it requires bash in particular, but it does require a POSIX shell. I think this is also the requirement for gccgo (and gcc in general). In particular, gofrontend/libgo/match.sh is part of gccgo.

cdisselkoen

comment created time in a month

issue commentgolang/go

panic: runtime error: slice bounds out of range

Is the code being disassembled is an infinite loop?

javasgl

comment created time in a month

issue commentgolang/go

cmd/objdump: panic: runtime error: index out of range [1048574] when disassembling empty infinite loop

I guess we could just ignore the bad line numbers.

bigwhite

comment created time in a month

issue commentgolang/go

runtime: Windows binaries built with -race occasionally deadlock

I think we can unpin this now.

bcmills

comment created time in 2 months

issue commentgolang/go

runtime: TestStackWrapperStackPanic failure on windows-amd64-2016

Yes, by option 2 I meant overwriting the asyncPreempt frame. Thanks.

bcmills

comment created time in 2 months

issue commentgolang/go

runtime: TestStackWrapperStackPanic failure on windows-amd64-2016

I implemented both approaches. Using @aclements's repro, both fix this.

Personally, I prefer option 2.

bcmills

comment created time in 2 months

issue commentgolang/go

runtime: TestStackWrapperStackPanic failure on windows-amd64-2016

Maybe it's possible in Windows for SuspendThread to stop a thread between when it causes an exception and when the VEH runs?

This is also my previous guess. One possibility would be printing the wrapper function if the previous frame is asyncPreempt. This will make the wrapper included in the stack trace. But the stack trace will look like

sigpanic
asyncPreempt
wrapper
...

which looks like asyncPreempt itself panics. I think this can happen with nil pointer dereference panics in general.

Another possibility is that when injecting a sigpanic, if the PC is the entry PC of asyncPreempt, just overwrite the PC instead of pushing another frame. This will make the stack trace correct. Losing preemption is probably not a problem, as sigpanic enters the runtime, which will probably preempt it synchronously at some point.

bcmills

comment created time in 2 months

issue commentgolang/go

x/crypto/chacha20poly1305: segmentation fault on arm

The assembly file in x/crypto/poly1305 is broken. It uses the G register as a temporary register, which violates the Go ABI. E.g. https://go.googlesource.com/crypto/+/refs/heads/master/poly1305/sum_arm.s#33

This is not signal safe. We already don't preempt assembly functions. But the signal handler needs the G register. It is not only the preemption signal, but any signals, including profiling or using os/signal package, that could crash the program. E.g. running on the Linux/ARM builder with async preemption disabled but profiling enabled,

# GODEBUG=asyncpreemptoff=1 ./chacha20poly1305.test -test.v -test.short -test.cpuprofile=/tmp/x
=== RUN   TestVectors
--- PASS: TestVectors (0.02s)
=== RUN   TestRandom
=== RUN   TestRandom/Standard
Segmentation fault (core dumped)

Turning on profiling, it also fails with Go 1.13.

FiloSottile

comment created time in 2 months

issue commentgolang/go

gccgo: encoding/binary not working as expected

Thanks. It is indeed an escape analysis bug. The problem is how we handle slicing an array. In the gc compiler, slicing an array is represented in AST with an implicit OADDR node. In gccgo AST, it doesn't have that node. The escape analysis is already inserting a fake node for an & operation, but the "loop depth" is not computed correctly for that node. I'm working on a CL.

zhsj

comment created time in 2 months

issue commentgolang/go

runtime: signal handling changed by signal.Notify

I remember the old behavior, and didn't realize the behavior has changed (probably accidentally).

stevenh

comment created time in 2 months

issue commentgolang/go

runtime: linux-arm cross-compiled binary segfaults at start on raspberry pi

Thanks @AndrewGMorgan !

After cmd/asm/internal/lex it will be the compiler's tests. It takes large amount of memory to build and run. How much memory does your machine have? It is possible that it hangs, or just slow, due to the large memory usage, even using swaps.

AndrewGMorgan

comment created time in 2 months

issue commentgolang/go

runtime: linux-arm cross-compiled binary segfaults at start on raspberry pi

@cpuguy83 that looks like a different issue. Could you open a new issue?

Did you mean that your case fails with Go 1.12 and 1.13 as well? Does your C code use thread local storage?

AndrewGMorgan

comment created time in 2 months

issue commentgolang/go

runtime: pclntab grows superlinearly

@aclements here is a breakdown of the pcdata:

			hello world	cmd/compile
.text			589993		10072652
pclntab			461293		 5254373
  func table		 28364		  166220
  _func structs		145376		  879432
  pcsp			 18305		  175053
  psfile		 13466		  208905
  pcline		 80049		 1339649
  pcdata		108492		 1947840
    [0]			 56055		 1211541
    [1]			 35454		  465937
    [2]			 16983		  270362
  strings		 56025		  496601
  file table		 11216		   40673

The register maps are the most of them.

robpike

comment created time in 2 months

issue commentgolang/go

runtime: pclntab grows superlinearly

@aclements I just added print statements in the linker. I can do that for the pcdata tables.

robpike

comment created time in 2 months

issue commentgolang/go

runtime: pclntab grows superlinearly

Yes, as @heschik said, there are several tables in pclntab.

Here is a breakdown:

			hello world	cmd/compile
.text			589993		10072652
pclntab			461293		 5254373
  func table		 28364		  166220
  _func structs		145376		  879432
  pcsp			 18305		  175053
  psfile		 13466		  208905
  pcline		 80049		 1339649
  pcdata		108492		 1947840
  strings		 56025		  496601
  file table		 11216		   40673

The strings are not large portion of the pclntab.

I have another confusion: the "growth" is growing over time, or the output size grows as the input size grows? I.e. are CockroachDB v19.1 and v1.0 built with same version of Go?

For the former, there are some growth over time, as we added more kinds of tables including e.g. inline tables, stack objects, and register maps, as mentioned in #27266.

For the latter, it seems growing linearly, at least from the table above.

robpike

comment created time in 2 months

issue commentgolang/go

runtime: linux-arm cross-compiled binary segfaults at start on raspberry pi

@AndrewGMorgan thanks for reporting!

Could you test if the CL above fixes the problem? (The code path is not exercised on the builder, so I cannot test it myself.) Thanks!

AndrewGMorgan

comment created time in 2 months

issue commentgolang/go

runtime: sweep increased allocation count crash on arm64

Thanks @jing-rui . I'm able to reproduce this with https://github.com/jing-rui/go-issue-36101 on the Linux/ARM64 builder. Running with GOGC=1 GODEBUG=gccheckmark=1, it fails in an hour or two. I looked into a few failures, but I haven't been able to completely understand it. However, I have a guess. It may be that we didn't always write pointers atomically, so the GC observed a partially updated pointer, which may point to bad memory. I made CL http://golang.org/cl/212626 , which ensures atomic pointer writes in memmove. With the CL I haven't gotten a crash running 10+ hours. As the failure is pretty rare, I cannot be sure, though.

@jing-rui , could you test CL http://golang.org/cl/212626 ? Thanks.

jing-rui

comment created time in 2 months

issue closedgolang/go

encoding/json: cause sweep increased allocation count crash on arm64

<!-- Please answer these questions before submitting your issue. Thanks! -->

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

<pre> $ go version go version go1.14.0 linux/arm64 </pre>

go1.14.0 is build use commit 22d28a24c8

Does this issue reproduce with the latest release?

Yes, we use master golang branch commit 22d28a24c8 without modify.

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

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="arm64" GOBIN="" GOCACHE="/root/.cache/go-build" GOENV="/root/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="arm64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/root/go" GOPRIVATE="" GOPROXY="https://goproxy.cn,direct" GOROOT="/usr/lib/golang" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/lib/golang/pkg/tool/linux_arm64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build455143019=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

We write a program repeatedly unmarshal config.json file on arm64, run 10 process and wait about an hour some process will crash. When we switch to use jsoniter package, no crash occurs after running 3 days.

Reproduce program https://github.com/jing-rui/go-issue-36101

What did you expect to see?

no process crash

What did you see instead?

ref #36101

closed time in 2 months

jing-rui

issue commentgolang/go

encoding/json: cause sweep increased allocation count crash on arm64

Let's discuss this in a single place. Closing this as a dup.

Also, I think this is more like a runtime issue than a json issue.

jing-rui

comment created time in 2 months

issue closedgolang/go

runtime: syscall hangs during STW

<!-- Please answer these questions before submitting your issue. Thanks! -->

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

<pre> $ go version go version devel +48ed1e6113 Tue Dec 24 04:59:06 2019 +0000 darwin/amd64 and go1.13.3 </pre>

Does this issue reproduce with the latest release?

Yes

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

<details><summary><code>go env</code> Output</summary><br><pre> $ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/wangdeyu/Library/Caches/go-build" GOENV="/Users/wangdeyu/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/wangdeyu/Project/GOPATH" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/Users/wangdeyu/Local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/Users/wangdeyu/Local/go/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="" 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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/09/p8vzp3rn55ggpkq_rv1_hg100000gn/T/go-build532421777=/tmp/go-build -gno-record-gcc-switches -fno-common"

</pre></details>

What did you do?

<!-- If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link on play.golang.org is best. -->

package main

//#include <stdio.h>
//#include <stdlib.h>
//#include <unistd.h>
// int mysleep(){
// usleep(1000000);
// return 0;
// }
import "C"
import (
   "log"
   "time"
)

//go:linkname stopTheWorld runtime.stopTheWorld
func stopTheWorld(reason string)

//go:linkname startTheWorld runtime.startTheWorld
func startTheWorld()

func loopDoAdd() {
   for {
      ans := 0
      for i := 0; i < 1000000; i++ {
             ans++
      }
   }
   time.Sleep(time.Microsecond * 10)
}

func main() {
    // Just keep the application busy.
   for i := 0; i < 20; i++ {
      go loopDoAdd()
   }

   for {
      stopTheWorld("TEST")
      C.mysleep()
      startTheWorld()
      log.Println("Done")
      time.Sleep(time.Millisecond)
   }
}

and need to add a empty.s file.

What did you expect to see?

continuously output Done

What did you see instead?

2019/12/24 22:02:16 Done
2019/12/24 22:02:17 Done

...

and hungup.

I was able to reproduce the problem on macos and one Ubuntu, but another Ubuntu will not reproduce (I am not sure of the retake strategy, and sysmon retake will not be triggered on this machine).

I found, if do syscall during STW, and the P where this goroutine is located is retaken by sysmon, this phenomenon will occur.

I have analyzed that this problem occurs when exitsyscall, exitsyscallfast fail->exitsyscall0->globrunqput(gp)->stopm

But in STW, schedule() has no chance to call globrunqget, so it will hungup.

I tried to make the following modification in func retake(now int64) uint32 of proc.go to avoid this problem.

But this is not a perfect solution, I guess handoffp has problem with P's status processing in STW.

func retake(now int64) uint32 {
   n := 0
   lock(&allpLock)
   for i := 0; i < len(allp); i++ {
      _p_ := allp[i]
      if _p_ == nil {
         continue
      }
      pd := &_p_.sysmontick
      s := _p_.status
      
			// skip syscall P in STW.
      if s == _Psyscall && sched.gcwaiting != 0 {
         continue
      }
     ……
     ……

closed time in 2 months

WangLeonard

issue commentgolang/go

runtime: syscall hangs during STW

stopTheWorld is a runtime internal function. Calling stopTheWorld from user code is not supported.

WangLeonard

comment created time in 2 months

issue commentgolang/go

cmd/asm: doesn't handle register offset correctly when GOARCH=arm

Try

MOVW.W	R2<<0(R1), R0
MOVW.W	R2@>1(R1), R0

It is unfortunate that the objdump output syntax doesn't match the input. We could fix objdump.

ClarkGuan

comment created time in 2 months

issue commentgolang/go

cmd/asm: doesn't handle register offset correctly when GOARCH=arm

Try MOVW R0, R1<<0(R13).

I'm sorry the syntax is different. We should handle (R1)(R13) syntax as well.

ClarkGuan

comment created time in 2 months

issue commentgolang/go

runtime: Windows binaries built with -race occasionally deadlock

Put a lock on each M? Lock the lock when the M is entering cgo call, and before SuspendThread on that M. So we won't suspend a thread running C code. This is fine as we won't preempt C code anyway.

In fact, if we want to SuspendThread on an M for which the lock is locked, meaning that it is running C code, we don't need to suspend it anyway, so we don't need to wait on the lock. If the M is about to enter C, and the lock is locked, meaning that there is a pending suspend, it can just preempt itself.

bcmills

comment created time in 2 months

issue commentgolang/go

runtime: TestDebugCallUnsafePoint failure on noopt builder

I think the idea is that function debugCallUnsafePointWorker (https://go.googlesource.com/go/+/refs/heads/master/src/runtime/debug_test.go#188) does not contain any safe points after the atomic variable ready is set to 1. But this is not true for noopt build, where the atomic functions are not intrinsified and are calls (therefore safe points). I guess we should either skip the test on noopt build, or rewrite the worker function in a way that contains no calls even with noopt (I don't know how).

It doesn't seem related to preemption.

bcmills

comment created time in 2 months

issue commentgolang/go

x/build/env/linux-arm64/packet: restrict CPUs to a reasonable number of cores

We almost never see such a OOM failure on the builder dashboard, but we do see this when building the release. I also sometimes saw the failure when running all.bash manually on gomote. Do you know what the difference is?

As Bryan said, it is helpful to have this builder with very high core count. I think it would be much better if we could limit the number of parallel processes in building the release or running all.bash, but not limiting the number of accessible cores (for each individual process). But I'm not sure how to do this.

toothrot

comment created time in 2 months

issue commentgolang/go

runtime: "slice bounds out of range" in runtime.(*addrRanges).add on js-wasm builder

https://go.googlesource.com/go/+/refs/heads/master/src/runtime/mranges.go#134 Looks like this should be len(oldRanges)+1.

bcmills

comment created time in 3 months

issue commentgolang/go

cmd/link: crash with -E <nonexisting symbol>

Hmmm. -E nonexistent clearly won't work. What would you expect? A clean exit with an error?

eliasnaur

comment created time in 3 months

issue closedgolang/go

gccgo: missing type descriptor for pointer to type alias defined in another package

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

go version go1.13 gccgo (GCC) 10.0.0 20191210 (experimental) linux/amd64

What did you do?

p.go

package p

type W = map[int32]interface{}

main.go

package main

import "p"

var w p.W
var X interface{} = &w

func main() {}

What did you expect to see?

Build succeeds.

What did you see instead?

# main
/tmp/src/main/main.go:6: error: undefined reference to 'type...1map.6int32.7interface.4.5'
collect2: error: ld returned 1 exit status

closed time in 3 months

cherrymui

issue commentgolang/go

gccgo: missing type descriptor for pointer to type alias defined in another package

Fixed in http://golang.org/cl/210787 .

cherrymui

comment created time in 3 months

issue openedgolang/go

gccgo: missing type descriptor for pointer to type alias defined in another package

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

go version go1.13 gccgo (GCC) 10.0.0 20191210 (experimental) linux/amd64

What did you do?

p.go

package p

type W = map[int32]interface{}

main.go

package main

import "p"

var w p.W
var X interface{} = &w

func main() {}

What did you expect to see?

Build succeeds.

What did you see instead?

# main
/tmp/src/main/main.go:6: error: undefined reference to 'type...1map.6int32.7interface.4.5'
collect2: error: ld returned 1 exit status

created time in 3 months

issue commentgolang/go

runtime: TestCallersDeferNilFuncPanic failed in generating traceback (linux/arm64)

GO_GCFLAGS is only used in make.bash/all.bash. After that it is not used. Use -gcflags instead.

shawn-xdji

comment created time in 3 months

issue commentgolang/go

cmd/compile: escape analysis report mismatch with allocations

I think it means that if creating the closure needs allocation, it will allocate. But in this case it is a static function literal so there is no allocation.

eliasnaur

comment created time in 3 months

issue commentgolang/go

cmd/link: test TestPIESize fails for ppc64le added in CL 208897

Thanks @ianlancetaylor ! This makes sense. I guess this only shows up on PPC64 because it has a large page size.

laboger

comment created time in 3 months

issue commentgolang/go

cmd/link: test TestPIESize fails for ppc64le added in CL 208897

@laboger on the builder, it has ld 2.31.1 and gcc 8.3.0. When linking PIE, the Go linker passes -pie to gcc, and gcc indeed passes -pie to ld.

laboger

comment created time in 3 months

issue commentgolang/go

cmd/link: test TestPIESize fails for ppc64le added in CL 208897

The test starts to fail after I checked in CL https://go-review.googlesource.com/c/go/+/209659, which doesn't seem to be quite related. That CL could make the file size increases or decreases slightly (as it changes some PCDATA), for both exe and pie.

What seems weird to me is that the file size of PIE binary increases significantly, but none of the sections' sizes actually increase much. For example, the sizes reported by the size command is actually very close.

ls -l (the first is old, the second is new):

-rwxr-xr-x 1 root root 2527816 Dec  6 19:21 /tmp/go-link-TestPieSize-external318734918/pieexternal
-rwxr-xr-x 1 root root 2593272 Dec  6 19:12 /tmp/go-link-TestPieSize-external338302853/pieexternal

Difference is 65456.

size command:

   text	   data	    bss	    dec	    hex	filename
1183569	 738251	 247224	2169044	 2118d4	/tmp/go-link-TestPieSize-external318734918/pieexternal
1183569	 742859	 247224	2173652	 212ad4	/tmp/go-link-TestPieSize-external338302853/pieexternal

Difference is 4608.

readelf -S output are attached at the end. .data.rel.ro section size increases slightly due to PCDATA change, which should be fine.

old:

  [21] .data.rel.ro      PROGBITS         00000000001312c0  001212c0
       000000000009ea13  0000000000000000  WA       0     0     32

new:

  [21] .data.rel.ro      PROGBITS         00000000001400c0  001300c0
       000000000009fc13  0000000000000000  WA       0     0     32

What's interesting is that the file offset of .tbss section changes significantly, even all the previous sections sizes and offsets are identical, and the alignments of all the sections are identical and small.

old:

  [17] .eh_frame         PROGBITS         0000000000120edc  00120edc
       0000000000000310  0000000000000000   A       0     0     4
  [18] .tbss             NOBITS           00000000001312b0  001212b0
       0000000000000010  0000000000000000 WAT       0     0     8

new:

  [17] .eh_frame         PROGBITS         0000000000120edc  00120edc
       0000000000000310  0000000000000000   A       0     0     4
  [18] .tbss             NOBITS           00000000001400b0  001300b0
       0000000000000010  0000000000000000 WAT       0     0     8

@ianlancetaylor any idea why the file offset changes so much? If the external linker could just leave holes in the binaries, I wonder if we want to check the sizes of all the sections, instead of file sizes?

===========================

Full readelf -S output: old:

File: pieexternal
There are 45 section headers, starting at offset 0x268708:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         0000000000000270  00000270
       0000000000000011  0000000000000000   A       0     0     1
  [ 2] .note.ABI-tag     NOTE             0000000000000284  00000284
       0000000000000020  0000000000000000   A       0     0     4
  [ 3] .note.go.buildid  NOTE             00000000000002a4  000002a4
       0000000000000064  0000000000000000   A       0     0     4
  [ 4] .note.gnu.build-i NOTE             0000000000000308  00000308
       0000000000000024  0000000000000000   A       0     0     4
  [ 5] .gnu.hash         GNU_HASH         0000000000000330  00000330
       00000000000000f0  0000000000000000   A       6     0     8
  [ 6] .dynsym           DYNSYM           0000000000000420  00000420
       00000000000005d0  0000000000000018   A       7     3     8
  [ 7] .dynstr           STRTAB           00000000000009f0  000009f0
       0000000000000354  0000000000000000   A       0     0     1
  [ 8] .gnu.version      VERSYM           0000000000000d44  00000d44
       000000000000007c  0000000000000002   A       6     0     2
  [ 9] .gnu.version_r    VERNEED          0000000000000dc0  00000dc0
       0000000000000040  0000000000000000   A       7     2     8
  [10] .rela.dyn         RELA             0000000000000e00  00000e00
       000000000006afb0  0000000000000018   A       6     0     8
  [11] .rela.plt         RELA             000000000006bdb0  0006bdb0
       0000000000000258  0000000000000018  AI       6    24     8
  [12] .init             PROGBITS         000000000006c020  0006c020
       000000000000005c  0000000000000000  AX       0     0     32
  [13] .text             PROGBITS         000000000006c080  0006c080
       00000000000978f4  0000000000000000  AX       0     0     32
  [14] .fini             PROGBITS         0000000000103974  00103974
       0000000000000024  0000000000000000  AX       0     0     4
  [15] .rodata           PROGBITS         00000000001039a0  001039a0
       000000000001d490  0000000000000000   A       0     0     32
  [16] .eh_frame_hdr     PROGBITS         0000000000120e30  00120e30
       00000000000000ac  0000000000000000   A       0     0     4
  [17] .eh_frame         PROGBITS         0000000000120edc  00120edc
       0000000000000310  0000000000000000   A       0     0     4
  [18] .tbss             NOBITS           00000000001312b0  001212b0
       0000000000000010  0000000000000000 WAT       0     0     8
  [19] .init_array       INIT_ARRAY       00000000001312b0  001212b0
       0000000000000008  0000000000000008  WA       0     0     8
  [20] .fini_array       FINI_ARRAY       00000000001312b8  001212b8
       0000000000000008  0000000000000008  WA       0     0     8
  [21] .data.rel.ro      PROGBITS         00000000001312c0  001212c0
       000000000009ea13  0000000000000000  WA       0     0     32
  [22] .dynamic          DYNAMIC          00000000001cfcd8  001bfcd8
       0000000000000210  0000000000000010  WA       7     0     8
  [23] .got              PROGBITS         00000000001cff00  001bff00
       0000000000000048  0000000000000008  WA       0     0     256
  [24] .plt              NOBITS           00000000001d0000  001bff48
       00000000000000d8  0000000000000008  WA       0     0     8
  [25] .data             PROGBITS         00000000001d00e0  001c00e0
       0000000000007730  0000000000000000  WA       0     0     32
  [26] .go.buildinfo     PROGBITS         00000000001d7810  001c7810
       0000000000000020  0000000000000000  WA       0     0     16
  [27] .noptrdata        PROGBITS         00000000001d7840  001c7840
       000000000000e000  0000000000000000  WA       0     0     32
  [28] .bss              NOBITS           00000000001e5840  001d5840
       000000000002fb08  0000000000000000  WA       0     0     32
  [29] .noptrbss         NOBITS           0000000000215360  001d5840
       000000000000c9c8  0000000000000000  WA       0     0     32
  [30] .comment          PROGBITS         0000000000000000  001d5840
       000000000000001c  0000000000000001  MS       0     0     1
  [31] .zdebug_aranges   PROGBITS         0000000000000000  001ffa30
       0000000000000084  0000000000000000           0     0     16
  [32] .zdebug_pubnames  PROGBITS         0000000000000000  001ffab4
       00000000000021f3  0000000000000000           0     0     1
  [33] .zdebug_info      PROGBITS         0000000000000000  00201ca7
       000000000002fe4a  0000000000000000           0     0     1
  [34] .zdebug_abbrev    PROGBITS         0000000000000000  00231af1
       000000000000038b  0000000000000000           0     0     1
  [35] .zdebug_line      PROGBITS         0000000000000000  00231e7c
       0000000000015271  0000000000000000           0     0     1
  [36] .zdebug_frame     PROGBITS         0000000000000000  002470ed
       0000000000004a47  0000000000000000           0     0     1
  [37] .zdebug_str       PROGBITS         0000000000000000  0024bb34
       00000000000003ad  0000000000000001  MS       0     0     1
  [38] .zdebug_loc       PROGBITS         0000000000000000  0024bee1
       0000000000012eae  0000000000000000           0     0     1
  [39] .zdebug_pubtypes  PROGBITS         0000000000000000  0025ed8f
       000000000000323b  0000000000000000           0     0     1
  [40] .zdebug_ranges    PROGBITS         0000000000000000  00261fca
       0000000000006530  0000000000000000           0     0     1
  [41] .debug_gdb_script PROGBITS         0000000000000000  002684fa
       0000000000000028  0000000000000000           0     0     1
  [42] .symtab           SYMTAB           0000000000000000  001d5860
       0000000000016188  0000000000000018          43   3712     8
  [43] .strtab           STRTAB           0000000000000000  001eb9e8
       000000000001403d  0000000000000000           0     0     1
  [44] .shstrtab         STRTAB           0000000000000000  00268522
       00000000000001e4  0000000000000000           0     0     1

new:

File: pieexternal
There are 45 section headers, starting at offset 0x2786b8:

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         0000000000000270  00000270
       0000000000000011  0000000000000000   A       0     0     1
  [ 2] .note.ABI-tag     NOTE             0000000000000284  00000284
       0000000000000020  0000000000000000   A       0     0     4
  [ 3] .note.go.buildid  NOTE             00000000000002a4  000002a4
       0000000000000064  0000000000000000   A       0     0     4
  [ 4] .note.gnu.build-i NOTE             0000000000000308  00000308
       0000000000000024  0000000000000000   A       0     0     4
  [ 5] .gnu.hash         GNU_HASH         0000000000000330  00000330
       00000000000000f0  0000000000000000   A       6     0     8
  [ 6] .dynsym           DYNSYM           0000000000000420  00000420
       00000000000005d0  0000000000000018   A       7     3     8
  [ 7] .dynstr           STRTAB           00000000000009f0  000009f0
       0000000000000354  0000000000000000   A       0     0     1
  [ 8] .gnu.version      VERSYM           0000000000000d44  00000d44
       000000000000007c  0000000000000002   A       6     0     2
  [ 9] .gnu.version_r    VERNEED          0000000000000dc0  00000dc0
       0000000000000040  0000000000000000   A       7     2     8
  [10] .rela.dyn         RELA             0000000000000e00  00000e00
       000000000006afb0  0000000000000018   A       6     0     8
  [11] .rela.plt         RELA             000000000006bdb0  0006bdb0
       0000000000000258  0000000000000018  AI       6    24     8
  [12] .init             PROGBITS         000000000006c020  0006c020
       000000000000005c  0000000000000000  AX       0     0     32
  [13] .text             PROGBITS         000000000006c080  0006c080
       00000000000978f4  0000000000000000  AX       0     0     32
  [14] .fini             PROGBITS         0000000000103974  00103974
       0000000000000024  0000000000000000  AX       0     0     4
  [15] .rodata           PROGBITS         00000000001039a0  001039a0
       000000000001d490  0000000000000000   A       0     0     32
  [16] .eh_frame_hdr     PROGBITS         0000000000120e30  00120e30
       00000000000000ac  0000000000000000   A       0     0     4
  [17] .eh_frame         PROGBITS         0000000000120edc  00120edc
       0000000000000310  0000000000000000   A       0     0     4
  [18] .tbss             NOBITS           00000000001400b0  001300b0
       0000000000000010  0000000000000000 WAT       0     0     8
  [19] .init_array       INIT_ARRAY       00000000001400b0  001300b0
       0000000000000008  0000000000000008  WA       0     0     8
  [20] .fini_array       FINI_ARRAY       00000000001400b8  001300b8
       0000000000000008  0000000000000008  WA       0     0     8
  [21] .data.rel.ro      PROGBITS         00000000001400c0  001300c0
       000000000009fc13  0000000000000000  WA       0     0     32
  [22] .dynamic          DYNAMIC          00000000001dfcd8  001cfcd8
       0000000000000210  0000000000000010  WA       7     0     8
  [23] .got              PROGBITS         00000000001dff00  001cff00
       0000000000000048  0000000000000008  WA       0     0     256
  [24] .plt              NOBITS           00000000001e0000  001cff48
       00000000000000d8  0000000000000008  WA       0     0     8
  [25] .data             PROGBITS         00000000001e00e0  001d00e0
       0000000000007730  0000000000000000  WA       0     0     32
  [26] .go.buildinfo     PROGBITS         00000000001e7810  001d7810
       0000000000000020  0000000000000000  WA       0     0     16
  [27] .noptrdata        PROGBITS         00000000001e7840  001d7840
       000000000000e000  0000000000000000  WA       0     0     32
  [28] .bss              NOBITS           00000000001f5840  001e5840
       000000000002fb08  0000000000000000  WA       0     0     32
  [29] .noptrbss         NOBITS           0000000000225360  001e5840
       000000000000c9c8  0000000000000000  WA       0     0     32
  [30] .comment          PROGBITS         0000000000000000  001e5840
       000000000000001c  0000000000000001  MS       0     0     1
  [31] .zdebug_aranges   PROGBITS         0000000000000000  0020fa30
       0000000000000084  0000000000000000           0     0     16
  [32] .zdebug_pubnames  PROGBITS         0000000000000000  0020fab4
       00000000000021ee  0000000000000000           0     0     1
  [33] .zdebug_info      PROGBITS         0000000000000000  00211ca2
       000000000002fe42  0000000000000000           0     0     1
  [34] .zdebug_abbrev    PROGBITS         0000000000000000  00241ae4
       000000000000038b  0000000000000000           0     0     1
  [35] .zdebug_line      PROGBITS         0000000000000000  00241e6f
       0000000000015271  0000000000000000           0     0     1
  [36] .zdebug_frame     PROGBITS         0000000000000000  002570e0
       0000000000004a47  0000000000000000           0     0     1
  [37] .zdebug_str       PROGBITS         0000000000000000  0025bb27
       00000000000003ad  0000000000000001  MS       0     0     1
  [38] .zdebug_loc       PROGBITS         0000000000000000  0025bed4
       0000000000012e70  0000000000000000           0     0     1
  [39] .zdebug_pubtypes  PROGBITS         0000000000000000  0026ed44
       0000000000003238  0000000000000000           0     0     1
  [40] .zdebug_ranges    PROGBITS         0000000000000000  00271f7c
       000000000000652a  0000000000000000           0     0     1
  [41] .debug_gdb_script PROGBITS         0000000000000000  002784a6
       0000000000000028  0000000000000000           0     0     1
  [42] .symtab           SYMTAB           0000000000000000  001e5860
       0000000000016188  0000000000000018          43   3712     8
  [43] .strtab           STRTAB           0000000000000000  001fb9e8
       000000000001403d  0000000000000000           0     0     1
  [44] .shstrtab         STRTAB           0000000000000000  002784ce
       00000000000001e4  0000000000000000           0     0     1
laboger

comment created time in 3 months

issue commentgolang/go

cmd/link: test TestPIESize fails for ppc64le added in CL 208897

Yeah, I'm looking at it.

laboger

comment created time in 3 months

issue commentgolang/go

proposal: testing: add TB.TempDir() string

@bradfitz Good to know. Thanks!

bradfitz

comment created time in 3 months

issue commentgolang/go

runtime: TestStackWrapperStackPanic failure on windows-amd64-2016

If we preempt the thread right at the point of the exception, we may inject a asyncPreempt call, and then the exception handler runs (before asyncPreempt runs), which injects a sigpanic call. Then we could see sigpanic right on top of asyncPreempt. In traceback, normally we would not elide wrappers if it is the immediate caller of sigpanic, but we will if the immediate caller is asyncPreempt. If this is the case, we could see the stack trace like that.

I'm not familiar about the ordering of Windows' SuspendThread/ResumeThread and exception handling, so not sure if this could actually happen.

bcmills

comment created time in 3 months

issue commentgolang/go

proposal: testing: add TB.TempDir() string

Yeah, the artifacts could be useful for debugging. If there is an explicit os.RemoveAll, I can just comment that out when debugging. With the new function I guess I can do the same by digging into the testing package and commenting out that line, but that is more complicated. Maybe add a new helper that keeps the artifacts that can be used for debugging? t.Keep()? t.NoCleanup?

bradfitz

comment created time in 3 months

issue commentgolang/go

cmd/compile: ICE: two stores live simultaneously

Before fuse, it is the correct diamond-shaped control flow.

b1:-
  v1 (?) = InitMem <mem>
  v5 (3) = Arg <bool> {b} (b[bool])
If v5 → b3 b4 (+4)

b2: ← b3 b4
Plain → b7 (+9)

b3: ← b1-
  v7 (+5) = StaticCall <mem> {"".g} v1
Plain → b2 (5)

b4: ← b1-
  v9 (+7) = StaticCall <mem> {"".h} v1
Plain → b2 (7)

b7: ← b2 b7
Plain → b7 (+9)

Fuse moves both branches into the same block...

b1:
BlockInvalid (+4)

b2:-
  v1 (?) = InitMem <mem>
  v5 (3) = Arg <bool> {b} (b[bool])
  v7 (+5) = StaticCall <mem> {"".g} v1
  v9 (+7) = StaticCall <mem> {"".h} v1
Plain → b7 (+9)

b3:
BlockInvalid (5)

b4:
BlockInvalid (7)

b7: ← b2 b7
Plain → b7 (+9)
cherrymui

comment created time in 3 months

issue commentgolang/go

cmd/compile: ICE: two stores live simultaneously

package p

var x int

func F(b bool) {
	if b {
		g()
	} else {
		h()
	}
	for {}
}

func g()
func h()

This ICE on all architectures.

cherrymui

comment created time in 3 months

more