-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: nonsensical DWARF location lists produced for function argument #61700
Comments
I think this has something to do with the canonicalization of slots (or lack thereof). When I dump the debug logging for the building of debug information for the above function I see this:
...
The code and elsewhere in the cache seems to think that there will only be one entry for a part of a variable. go/src/cmd/compile/internal/ssa/debug.go Lines 656 to 662 in b25f555
I guess the question I have is whether indeed there should be just one |
Before this change there was a bug which can occur when an SSA'd variable or parameter has multiple different corresponding to the same piece of variable. Before this change, the locations of each type of piece would be concatenated, resulting in non-sensical location information with more pieces than there ought to be for the data type. This patch rectifies the situation by associating the slots corresponding to the same piece and computing the location of that piece by coalescing the locations of the corresponding slots. Fixes golang#61700
Before this change there was a bug which can occur when an SSA'd variable has multiple different values (slots) corresponding to the same piece of variable. Before this change, the locations of each type of a piece would be concatenated, resulting in non-sensical location information with more pieces than there ought to be for the data type. This patch rectifies the situation by associating the slots corresponding to the same piece and computing the location of that piece by coalescing the locations of the corresponding slots. Fixes golang#61700
Before this change there was a bug which can occur when an SSA'd variable has multiple different values (slots) corresponding to the same piece of variable. Before this change, the locations of each type of a piece would be concatenated, resulting in non-sensical location information with more pieces than there ought to be for the data type. This patch rectifies the situation by associating the slots corresponding to the same piece and computing the location of that piece by coalescing the locations of the corresponding slots. Fixes golang#61700
Change https://go.dev/cl/553735 mentions this issue: |
Before this change there was a bug which can occur when an SSA'd variable has multiple different values (slots) corresponding to the same piece of variable. Before this change, the locations of each type of a piece would be concatenated, resulting in non-sensical location information with more pieces than there ought to be for the data type. This patch rectifies the situation by associating the slots corresponding to the same piece and computing the location of that piece by coalescing the locations of the corresponding slots. Additionally, this change tries to clean up some of the terminology by eliminating use of the word "part" which was ambiguious with regards to slots and pieces. Fixes golang#61700
Before this change there was a bug which can occur when an SSA'd variable has multiple different values (slots) corresponding to the same piece of variable. Before this change, the locations of each type of a piece would be concatenated, resulting in non-sensical location information with more pieces than there ought to be for the data type. This patch rectifies the situation by associating the slots corresponding to the same piece and computing the location of that piece by coalescing the locations of the corresponding slots. Additionally, this change tries to clean up some of the terminology by eliminating use of the word "part" which was ambiguious with regards to slots and pieces. Fixes golang#61700
Before this change there was a bug which can occur when an SSA'd variable has multiple different values (slots) corresponding to the same piece of variable. Before this change, the locations of each type of a piece would be concatenated, resulting in nonsensical location information with more pieces than there ought to be for the data type. This patch rectifies the situation by associating the slots corresponding to the same piece and computing the location of that piece by coalescing the locations of the corresponding slots. Additionally, this change tries to clean up some of the terminology by eliminating use of the word "part" which was ambiguious with regards to slots and pieces. Fixes golang#61700
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
It also reproduces with 1.20, and maybe older versions too.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
In the CockroachDB (optimized) binary, I very commonly see broken location lists that contain duplicate pieces - so, for example, a 128-bit interface is described as a 256-bit struct, where the two halves are repeated. Playing by hand with small repros, I could also produce a case where the pieces are not even repeated, making the debug information even more confusing / nonsensical - which leads me to believe that the bug is not simply a "mechanical" one. Here's an example that shows all these problems:
https://goplay.tools/snippet/UfS5J4cYGy5
Consider this function in the snippet:
The debug info for the
ctx context.Context
function argument is the following:Notice that all the location lists contain 4 8-byte pieces, whereas they should contain 2 8-byte pieces (
context.Context
is a 16-byte interface).Some of these location lists contain duplicate information - e.g. the first one:
Notice that the RAX and RBX pieces are each repeated.
But then it gets even more funky. Notice, for example, the 3rd location list:
Here, the first piece is no longer repeated.
FWIW, what happens around the
463de0
PC location is the following:At location
463ddb
, the first word of thectx
variable is written torsp + 16
, which corresponds toFBREG - 32
. So that explains the update to the first piece. But the 2nd piece (which should not have existed in the first place) is left un-updated.What did you expect to see?
I expected the location lists for the
ctx
variable to add up to 128 bits, not 256.If someone is kindly willing to give me some clues and point me in the right direction, I might be inclined to work on some fix.
cc @dr2chase @randall77 @thanm
The text was updated successfully, but these errors were encountered: