cmd/compile: .closureptr elided in optimized binaries

[aarzilli]

$ go version
go version go1.23.0 linux/amd64

(also reproduces on tip)

Given this sample program using range-over-func the DIE emitted for main.PrintAllElements[go.shape.string]-range1 when optimizations are enabled is:

 <1><216c>: Abbrev Number: 3 (DW_TAG_subprogram)
    <216d>   DW_AT_name        : main.PrintAllElements[go.shape.string]-range1
    <219b>   DW_AT_low_pc      : 0x48f520
    <21a3>   DW_AT_high_pc     : 0x48f605
    <21ab>   DW_AT_frame_base  : 1 byte block: 9c       (DW_OP_call_frame_cfa)
    <21ad>   DW_AT_decl_file   : 0x2
    <21b1>   DW_AT_decl_line   : 47
    <21b2>   DW_AT_external    : 1
 <2><21b3>: Abbrev Number: 31 (DW_TAG_typedef)
    <21b4>   DW_AT_name        : .param3
    <21bc>   DW_AT_type        : <0x27e86>
    <21c0>   Unknown AT value: 2906: 3
 <2><21c1>: Abbrev Number: 44 (DW_TAG_formal_parameter)
    <21c2>   DW_AT_name        : v
    <21c4>   DW_AT_variable_parameter: 0
    <21c5>   DW_AT_decl_line   : 47
    <21c6>   DW_AT_type        : <0x21b3>
    <21ca>   DW_AT_location    : 0x1799 (location list)
 <2><21ce>: Abbrev Number: 9 (DW_TAG_inlined_subroutine)
    <21cf>   DW_AT_abstract_origin: <0x1e48>
    <21d3>   DW_AT_ranges      : 0x980
    <21d7>   DW_AT_call_file   : 0x2
    <21db>   DW_AT_call_line   : 49
 <3><21dc>: Abbrev Number: 41 (DW_TAG_formal_parameter)
    <21dd>   DW_AT_abstract_origin: <0x1e59>
    <21e1>   DW_AT_location    : 0 byte block:  ()
 <3><21e2>: Abbrev Number: 0
 <2><21e3>: Abbrev Number: 0

No entries for .closureptr are generated, presumably because all the stores related to .closureptr are optimized away.

Originally reported as go-delve/delve#3806 (where it triggers other related delve bugs).

We could also say that with optimized binaries we do not correlate closure bodies with their parent in the debugger, or that we do a best effort thing and occasionally get it wrong (I suspect actually keeping track of .closureptr could have negative performance effects).

cc @dr2chase

[gabyhelp]

Related Issues and Documentation

• cmd/compile: function argument debug_info locations always wrong without GOEXPERIMENT=noregabi #45720 (closed)
• cmd/compile: zero sized variables no longer have DIEs #54615 (closed)
• cmd/compile: DWARF information for local variables missing #14744 (closed)
• cmd/compile: missing DWARF location lists for return values #50990
• cmd/compile: missing variables in debug_info for inlined subroutines #24460 (closed)
• cmd/link: bad debug_info on macOS 10.12.1 when using cgo (but only under very specific circumstances) #17897 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[cuonglm]

Maybe related #67918

[dr2chase]

This is going to be a problem, because in at least one optimized binary where the closureptr is NOT elided, it causes reduced performance compared to foreach call of a plain closure. I'd actually like to get rid of it in optimized binaries completely; I'm not sure what's the best path.