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

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

Open
thanm opened this issue May 27, 2021 · 2 comments
Open

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

thanm opened this issue May 27, 2021 · 2 comments
Assignees
Milestone

Comments

@thanm
Copy link
Member

@thanm thanm commented May 27, 2021

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.

@thanm thanm added this to the Go1.17 milestone May 27, 2021
@thanm thanm self-assigned this May 27, 2021
@hyangah
Copy link
Contributor

@hyangah hyangah commented May 28, 2021

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

@thanm
Copy link
Member Author

@thanm thanm commented May 28, 2021

@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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants