Open andreimatei opened 2 weeks ago
The processingStart
variable, which is SSAable, is broken up by the compiler (when in optimized mode) to individual fields. It does not need a VARDEF`` for the whole thing. So yes, the
VARDEF` is missing. But there should be some sort of DWARF for its respective fields? They do get spilled to (probably 3 distinct unrelated) stack slots, but the DWARF should describe those somehow, I think.
@thanm
The reason why I clung to VarDef
missing was that in #60479 we saw that the elision of VarDef
causes location lists to go missing.
However, this present issue seems different than #60479 because, as I understand it, the regression in #60479 does not apply to pointer-ful types (and time.Time
contains a pointer), and also because I've tested the code with go1.19 (before the #60479 regression) and I still don't get location lists.
Go version
go1.22.2
Output of
go env
in your module/workspace:What did you do?
A lot of times, debug information for local variables (i.e. location lists) seem to be missing when compiling in optimized mode. When using
-gcflags="-N -l"
, the location information is there. I want to discuss a particular case where optimizations do not seem to be the problem.What did you see happen?
I believe that it is generally known that location info can be missing. I'd like to use this opportunity to understand why that is / whether there is a big general problem or many small ones and how deep or superficial the issues are. The case that I want to discuss here in particular seems more general then what I find in other issues on the topic (e.g. #60479). An interesting thing is that, as far as I can tell, optimization passes don't seem to be the problem here.
Consider the following function:
processingStart
does not get any debug info. The output ofGOSSAFUNC
seems immediately suspicious to me because, from the very beginning, there is noVarDef
node forprocessingStart
(whereas the no-optimizations build does have aVarDef
). As I understand it,ssa/debug.go
looks forVarDef
, so I'm guessing that the missingVarDef
mean that this variable never stood a chance to get location lists. Is that correct?Here is the
GOSSAFUNC
output for the function, namely the very first column (before insert phis
). TheprocessingStart
variable is declared on source line 111. Notice that there is noVarDef
there, but instead there is aStaticLECall / SelectN
.My hope is that perhaps there's a superficial reason why some variables are quickly disqualified from having location lists.
I'm asking because I'm working on debugging tooling and missing location lists is biting me a lot.
cc @randall77 @dr2chase
What did you expect to see?
Location list for the
processingStart
variable.