Commit 7b0ee534 authored by Rob Pike's avatar Rob Pike

cmd/ld: fix off-by-one in DWARF frame tables

The code generating the .debug_frame section emits pairs of "advance PC",
"set SP offset" pseudo-instructions. Before the fix, the PC advance comes
out before the SP setting, which means the emitted offset for a block is
actually the value at the end of the block, which is incorrect for the
block itself.

The easiest way to fix this problem is to emit the SP offset before the
PC advance.

One delicate point: the last instruction to come out is now an
"advance PC", which means that if there are padding intsructions after
the final RET, they will appear to have a non-zero offset. This is odd
but harmless because there is no legal way to have a PC in that range,
or to put it another way, if you get here the SP is certainly screwed up
so getting the wrong (virtual) frame pointer is the least of your worries.

LGTM=iant
R=rsc, iant, lvd
CC=golang-codereviews
https://golang.org/cl/112750043
parent c1c8c3c8
......@@ -1696,6 +1696,9 @@ enum
static void
putpccfadelta(vlong deltapc, vlong cfa)
{
cput(DW_CFA_def_cfa_offset_sf);
sleb128put(cfa / DATAALIGNMENTFACTOR);
if (deltapc < 0x40) {
cput(DW_CFA_advance_loc + deltapc);
} else if (deltapc < 0x100) {
......@@ -1708,9 +1711,6 @@ putpccfadelta(vlong deltapc, vlong cfa)
cput(DW_CFA_advance_loc4);
LPUT(deltapc);
}
cput(DW_CFA_def_cfa_offset_sf);
sleb128put(cfa / DATAALIGNMENTFACTOR);
}
static void
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment