Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: Finer grained visibility debug info for variables #36125

aarzilli opened this issue Dec 13, 2019 · 0 comments

cmd/compile: Finer grained visibility debug info for variables #36125

aarzilli opened this issue Dec 13, 2019 · 0 comments
Debugging NeedsInvestigation


Copy link

@aarzilli aarzilli commented Dec 13, 2019

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

@toothrot toothrot added the NeedsInvestigation label Dec 13, 2019
@toothrot toothrot added this to the Backlog milestone Dec 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Debugging NeedsInvestigation
None yet

No branches or pull requests

3 participants