You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
cmd/compile: fix bug in dwarf-gen var location generation
This patch fixes a bug in the SSA back end's DWARF generation code
that determines variable locations / lifetimes.
The code in question was written to handle sequences of initial
pseudo-ops (zero width instructions such as OpPhi, OpArg, etc) in a
basic block, detecting these ops at the start of a block and then
treating the values specially when emitting ranges for the variables
in those values. The logic in this code wasn't quite correct, meaning
that a flag variable wasn't being set properly to record the presence
of a block of zero-width value-bearing ops, leading to incorrect or
missing DWARF locations for register params.
Also in this patch is a tweak to some sanity-checking code intended to
catch scheduling problems with OpArg/OpPhi etc. The checks need to
allow for the possibility of an Arg op scheduled after a spill of an
incoming register param inserted by the register allocator. Example:
b1:
v13 = ArgIntReg <int> {p1+16} [2] : CX
v14 = ArgIntReg <int> {p2+16} [5] : R8
v38 = ArgIntReg <int> {p3+16} [8] : R11
v35 = ArgIntReg <int> {p1+0} [0] : AX
v15 = StoreReg <int> v35 : .autotmp_4[int]
v40 = Arg <int> {p4} [16] : p4+16[int]
v1 = InitMem <mem>
v3 = SB <uintptr> : SB
v18 = CMPQ <flags> v14 v13
NE v18 → b3 b2 (unlikely) (18)
Here the register allocator has decided to spill v35, meaning that the
OpArg v40 is no longer going to be positioned prior to all other
non-zero-width ops; this is a valid scenario and needs to be handled
properly by the debug code.
Fixes#46425.
Change-Id: I239b3ad56a9c1b8ebf68af42e1f57308293ed7e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/332269
Trust: Than McIntosh <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>
Run-TryBot: Than McIntosh <[email protected]>
TryBot-Result: Go Bot <[email protected]>
// These ranges begin at true beginning of block, not after first instruction
1130
-
ifzeroWidthPending {
1131
-
panic(fmt.Errorf("Unexpected op '%s' mixed with OpArg/OpPhi/OpLoweredGetClosurePtr at beginning of block %s in %s\n%s", v.LongString(), b, b.Func.Name, b.Func))
1136
+
ifblockPrologComplete&&mustBeFirst(v) {
1137
+
panic(fmt.Errorf("Unexpected placement of op '%s' appearing after non-pseudo-op at beginning of block %s in %s\n%s", v.LongString(), b, b.Func.Name, b.Func))
0 commit comments