I was noticing that values printed in the debugger often seem to be uninitialized when stepping past a line that initializes them. It appears that the DWARF line tables are advancing the line number one instruction too early. For example, with this go code
The text was updated successfully, but these errors were encountered:
ianlancetaylor
changed the title
DWARF line tables seem to be off by 1 instruction
cmd/link: DWARF line tables seem to be off by 1 instruction
Oct 14, 2015
I looked at gc's assembly output, and it shows the same issue, so this isn't a problem with the dwarf generation. Also I can't seem to reproduce it if I use --gcflags "-N -l" to disable optimization, so it may not be worth digging in to.
It's not an off-by-one. The instruction you identified is the spill of a variable to memory. Spills don't really have a "correct" line number. They can be arbitrarily delayed, too, so certainly line 24 could end and parts of line 25 could continue to execute before the spill happened. In this sense the current line number reporting is probably better. Anyway, it's a very hard problem.
In that case I guess that the problem is that the debug info says the variable is located in memory for the entire function, but it should instead reference the register at this instruction.
go version go1.5.1 darwin/amd64
I was noticing that values printed in the debugger often seem to be uninitialized when stepping past a line that initializes them. It appears that the DWARF line tables are advancing the line number one instruction too early. For example, with this go code
dwarfdump shows this for the line table:
It shows line 25 starting at 0x4002f3a. However, from the disassembly this appears to be the last instruction of line 24. Line 25 starts at 0x4002f42:
The text was updated successfully, but these errors were encountered: