golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
122.89k stars 17.52k forks source link

cmd/compile: .closureptr elided in optimized binaries #69307

Open aarzilli opened 1 week ago

aarzilli commented 1 week ago
$ 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 https://github.com/go-delve/delve/issues/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 commented 1 week ago

Related Issues and Documentation

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

cuonglm commented 1 week ago

Maybe related https://github.com/golang/go/issues/67918