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: DWARF line table: "morestack" sequence should have prolog file/line #39757
Comments
Change https://golang.org/cl/239286 mentions this issue: |
Change https://golang.org/cl/239287 mentions this issue: |
I sent two CLs with possible fixes for this bug. @aarzilli PTAL and let me know what you think. |
I have submitted a fix for this bug on the dev.link branch; this fix will appear on the main branch at some point when it opens up for 1.16 development (Aug?). I'll hold the bug open until then. |
…WARF line table The code in the compiler's DWARF line table generation emits line table ops at the end of each function fragment to reset the state machine registers back to an initial state, so that when the line table fragments for each function are stitched together into a compilation unit, each fragment will have a clean starting point. The set-file/set-line ops emitted in this code were being applied to the last row of the line table, however, meaning that they were overwriting the existing values. To avoid this problem, add code to advance the PC past the end of the last instruction in the function, and switch to just using an end-of-sequence operator at the end of each function instead of explicit set-file/set-line ops. Updates #39757. Change-Id: Ieb30f83444fa86fb1f2cd53862d8cc8972bb8763 Reviewed-on: https://go-review.googlesource.com/c/go/+/239286 Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org> Reviewed-by: David Chase <drchase@google.com>
Closing this bug, since the dev.link branch is now merged into master. |
Change https://golang.org/cl/258422 mentions this issue: |
During Go 1.15 development, a fix was added to the toolchain for issue information. The 1.15 line tables were slightly malformed in the way that they used the DWARF "end sequence" operator, resulting in incorrect line table info for the final instruction in the final function of a compilation unit. This problem was fixed in https://golang.org/cl/235739, which made it into Go 1.15. It now appears that while the fix works OK for linux, in certain cases it causes issues with the Darwin linker (the "address not in any section" ld64 error reported in issue #40974). During Go 1.16 development, the fix in https://golang.org/cl/235739 was revised so as to fix another related problem (described in issue #39757); the newer fix does not trigger the problem in the Darwin linker however. This CL back-ports the changes in https://golang.org/cl/239286 to the 1.15 release branch, so as to fix the Darwin linker error. Updates #38192. Updates #39757. Fixes #40974. Change-Id: I9350fec4503cd3a76b97aaea0d8aed1511662e29 Reviewed-on: https://go-review.googlesource.com/c/go/+/258422 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Trust: Than McIntosh <thanm@google.com>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes.
What operating system and processor architecture are you using (
go env
)?linux/amd64
but this problem applies on other archs as well
What did you do?
Build a small program, e.g. "go build himom.go"
Then examine generated DWARF with "objdump -dl":
What did you expect to see?
Call to "runtime.morestack" has a source position (file/line) the same as the prolog of the function.
What did you see instead?
Source position is "autogenerated:1":
This can interfere with debugging and profiling.
One could argue that since this is compiler-generated code it's ok to give it an autogenerated source position (similar to things like method wrappers), but there is also a strong argument to be made that the morestack call is logically part of the function prolog (even though it is positioned in the cold code at the tail end of the function).
It also turns out that we haven't always marked this code with "autogenerated" -- in previous versions of Go it was being given the correct position. Here is the tail end of the assembly when built with 1.12:
It looks as though the problem was introduced when the main part of DWARF line table generation was moved from the linker in to the compiler. This code here:
https://go.googlesource.com/go/+/d1a186d29ce9d917dda7c66cfaee7788f88e7b9e/src/cmd/internal/obj/dwarf.go#112
generates a sequence at the end of each function to reset the state of the line table back to its default settings. This code doesn't advance the PC before applying the new file and line, however, meaning that it overwrites the file/line for the last row in the line table, which is what's causing the "autogenerated:1" to be picked up.
This could be fixed in a couple of ways: one would be to emit an end of sequence op after each function (in which case there would be no manual file/line settting needed). A second option would be to add code to manually advanced the PC past the end of the last instruction before emitting the set file/set line ops.
The text was updated successfully, but these errors were encountered: