Delve currently determines variable visibility by using a combination of DWARF lexical blocks and the variable declaration line: a variable is visible if the lexical block is active (current PC is contained in the range of the lexical block) and if the current line is greater than or equal to the declaration line. The reason for the "equal to" part is that variables declared in the header of a for statement are initialized on every iteration after the first one (there are other situations where this could happen, by manually setting breakpoints at specific addresses, but that's the most common case).

This is fine for the most part but when current line equals declaration line Delve will show uninitialized variables. As far as I can tell there is no way to improve this with the debug symbols currently exported by the compiler.

There has been some interest in from users of Delve in having finer grained tracking of variable visibility. Since this isn't actually a thing Delve can do anything about I think there should be a bug here about this.

DWARF offers two ways of doing this: the DW_AT_start_scope and loclists.

DW_AT_start_scope specifies an offset, from the start of the containing lexical block of a variable, where the variable begins being visible. For this to be useful there needs to be a rough correspondence between the order of statements in the source and the order of instructions in the compiled output. I don't think the SSA backend guarantees that.

Since the compiler already tracks the information needed for loclists and simply discards it when optimizations are disabled I thought loclists could be an easier solution and decided to test what would happen if I made the compiler emit loclists for non-optimized programs.

At first glance this works, however upon closer inspection it does not. I wrote a program (the program will assume there is an executable file called 'compile' in the current director and that it has been compiled with optimizations disabled) to compare visibility as determined from loclists with visibility as determined from lexical blocks and using this method we occasionally lose visibility of some variables at some statements. As a quick example the variable argID in cmd/compile/internal/ssa.critical will not be visible during the call on line critical.go:62 (incidentally I think this type of check could be also useful to test the coverage of loclists generated for optimized executables).

I don't know that the compiler should actually change anything, maybe Delve should just start showing variables as visible on the line after the declaration line.

cc @heschik @dr2chase @derekparker
@gopherbot label Debugging