cmd/compile: Debugging optimized code can yield completely bogus values (sometimes) #28486
Labels
Debugging
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Comments
|
@heschik If you have any ideas about this, that might be helpful, I am currently slogging through location list construction in ssa/debug.go to figure out how it went wrong here. |
|
Can you attach the ssa.html and -d locationlists output? |
|
Also, my notes here: |
katiehockman
changed the title
katiehockman
added
the
NeedsInvestigation
heschi
changed the title
|
It looks like nothing in buildLocationLists is flushing out pending list entries at the beginning of a block when it was live in the textually previous block but dead in the current one. That will cause list entries to be extended until that list changes for some other reason. |
|
Change https://golang.org/cl/146718 mentions this issue: |
|
Change https://golang.org/cl/150097 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Dec 12, 2018
This change avoids creating zero length location lists by repairing an overly aggressive change in CL146718 and by explicitly checking for and filtering out any zero-length lists that are detected (building compiler+runtime creates a single one). Updates #28486. Change-Id: I01c571fee2376474c7f3038e801bd58fd9e0b820 Reviewed-on: https://go-review.googlesource.com/c/150097 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?tip for 1.12 development
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env)?linux and osx
What did you do?
This is debugging a program that is currently itself in a CL
( https://go-review.googlesource.com/c/tools/+/143357 )
The program in question is intended to run on OSX, though it is possible to make a copy of the its input (an OSX executable) and run it on Linux.
Line 226 is the header of this loop:
// Map out Dwarf sections (that is, this is section descriptors, not their contents).
offset := uint32(newdwarf.Offset)
for i := dwarf.Firstsect; i < dwarf.Firstsect+dwarf.Nsect; i++ {
o := exeMacho.Sections[i]
s := o.Copy()
s.Offset = offset
us := o.UncompressedSize()
if s.Size < us {
s.Size = uint64(us)
s.Align = 0 // This is apparently true for debugging sections
}
offset += uint32(us)
if strings.HasPrefix(s.Name, "z") {
s.Name = "" + s.Name[3:] // remove "z"
}
s.Reloff = 0
s.Nreloc = 0
newtoc.AddSection(s)
}
Notice how ridiculous the value of i is.
The cause appears to be an incorrect location list, but I don't know exactly where it's going wrong (yet). The PC where i is printed wrong is
which is v2338 in block 62
The location list declares that i can be found in BX, which is wrong; it appears to have inferred this because i was in BX at the end of the immediately previous block, b99.
The text was updated successfully, but these errors were encountered: