cc: @hyangah

CC @randall77 @josharian @mdempsky

(Is there a simple explanation for how the compiler currently decides which variables get a DW_TAG_variable record?)

I believe the simple explanation is we emit DWARF records for parameters (including result parameters) and for user-declared local variables that are allocated stack frame space.

Ah, thanks. So variable that are constant, are allocated to registers, are CSE'd, or escape to the heap will be missing from the debug view.

Oh, if a variable v escapes to heap, we don't emit DWARF records for v itself, but we will emit them for a synthesized &v pointer variable. There are also cases like if we decompose a composite type like string, you'll end up with separate s.len and s.ptr variables instead of a single s.

But I believe your other cases are correct: registerized and CSE'd variables are not mentioned in the DWARF output.

If it would help, I think we can easily emit records to at least declare that those variables exist in the source (e.g., so debuggers looking up an identifier don't mistakenly find a shadowed global variable instead). We're just not currently setup to track location any more fine-grained than a simple stack frame offset, so we can't emit DW_AT_location for them.

But I believe your other cases are correct: registerized and CSE'd variables are not mentioned in the DWARF output.

Furthermore, if a variable is allocated a stack slot but is registerized at a particular PC, the DWARF information will only refer to the stack slot, so you can get a stale (or uninitialized?) value. Fixing that is probably part of fixing debug info for fully registerized variables. But now that the DWARF is being emitted by the compiler instead of the linker, there's at least a hope of doing this.

I've also noticed that at some points in program execution, running info locals in GDB produces a giant dump of package-level variables. I'm not able to find a consistent repro with the current master branch, though; has that part of the DWARF info been fixed recently?

@bcmills I can't think of any significant recent DWARF changes that would have that effect.

Would it be preferable that instead of emitting DWARF entries for the pseudo-variable &v, that we instead emit a DWARF entry for v using DW_OP_deref or whatever?

Would it be preferable that instead of emitting DWARF entries for the pseudo-variable &v, that we instead emit a DWARF entry for v using DW_OP_deref or whatever?

Yes, definitely. :)

Update: as of go1.21.5, there is now an entry for s. The function main.f generally gets inlined, but whether you suppress that with go:noline or not, there is an entry for s. The location is empty as opposed to the location in memory of the string, but that could be worthy of a separate issue.

0x00062530:     DW_TAG_variable
                  DW_AT_name    ("s")
                  DW_AT_decl_line       (5)
                  DW_AT_type    (0x000000000004d624 "string")
                  DW_AT_location        (<empty>)