cmd/compile: incorrect DWARF location for runtime.throw's in-param

[thanm]

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

$ go version
go version devel go1.17-15a374d5c1 Wed May 19 01:09:20 2021 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes. This is only on tip.

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

linux/amd64

What did you do?

Compile a small program like

https://play.golang.org/p/1wRyGFu3wca

then run it in the debugger. Set a breakpoint in runtime.throw, then run. print "s"

What did you expect to see?

(gdb) p s
$1 = 0x47bfb6 "all goroutines are asleep - deadlock!"

What did you see instead?

(gdb) p s
$2 = 0x0 <error: Cannot access memory at address 0x0>

This is a bug in the Go compiler's debug location analysis phase, being triggered by the register ABI. Things seem to work when the register ABI is disabled, but I think mainly because the incoming locations for "s" are never killed, e.g. the stack location is essentially always available. When "s" is passed in RAX/RAB, it correctly tracks this fact, but then doesn't record the correct entry location when those registers are overwritten. I am not entirely sure what is going wrong, more analysis needed.

[hyangah]

@cherrymui @suzmue reported this problem in go1.16 too (I am not sure if it's the same problem)

[thanm]

@cherrymui @suzmue reported this problem in go1.16 too (I am not sure if it's the same problem)

I looked at the DWARF produced by the 1.16 compiler. It is indeed broken, but it looks like in a different way (two different bugs).

[gopherbot]

Change https://golang.org/cl/332269 mentions this issue: cmd/compile: fix bug in dwarf-gen var location generation

[suzmue]

With Go 1.17rc1, I am seeing that the location is correct within the systemstack call, but it is optimized out in the body of runtime.throw. Delve sets a breakpoint at runtime.fatalthrow for users to inspect the program state, so this is the point that it would be helpful to have access to the value of s.

suzmue@cloudshell:~/delve$ gdb fatalerror 
...
(gdb) b runtime.throw
Breakpoint 1 at 0x433820: file /usr/local/go/src/runtime/panic.go, line 1107.
(gdb) b runtime.fatalthrow
Breakpoint 2 at 0x433a20: file /usr/local/go/src/runtime/panic.go, line 1163.
(gdb) b /usr/local/go/src/runtime/panic.go:1111
Breakpoint 3 at 0x460eaf: file /usr/local/go/src/runtime/panic.go, line 1111.
(gdb) run
Starting program: /home/suzmue/delve/fatalerror 
...
Thread 1 "fatalerror" hit Breakpoint 1, runtime.throw (s=...) at /usr/local/go/src/runtime/panic.go:1107
1107    func throw(s string) {
(gdb) p s
$1 = <optimized out>
(gdb) c
Continuing.

Thread 1 "fatalerror" hit Breakpoint 3, runtime.throw.func1 () at /usr/local/go/src/runtime/panic.go:1111
1111                    print("fatal error: ", s, "\n")
(gdb) p s
$2 = 0x480a79 "go of nil func value"
(gdb) c
Continuing.
fatal error: go of nil func value

Thread 1 "fatalerror" hit Breakpoint 2, runtime.fatalthrow () at /usr/local/go/src/runtime/panic.go:1163
1163    func fatalthrow() {
(gdb) frame 1
#1  0x0000000000433892 in runtime.throw (s=...) at /usr/local/go/src/runtime/panic.go:1117
1117            fatalthrow()
(gdb) p s
$3 = <optimized out>

If this would be more appropriate as a new issue to open, since it seems that the incorrect location seems to be fixed I can do so.

[cherrymui]

Interesting. At the point of fatalthow call s is no longer live. Maybe we could keep it live in throw.

Why does it set a breakpoint in fatalthrow instead of throw?

[suzmue]

I think its historical from when fatalpanic and fatalthrow split, but I'm not sure @derekparker @aarzilli would know better.

In both Go 1.16 and Go 1.17 the location info appears to only be available in the print function in runtime.throw:

systemstack(func() {
	print("fatal error: ", s, "\n")
})

It seems that s should also be live at the start of runtime.throw since it is not used print("fatal error: ", s, "\n"). Would it be possible to get the location information available then at least?