Go version
go version devel go1.23-ae457e811d Tue Jan 30 23:37:12 2024 +0000 linux/amd64
What did you do?
I was investigating https://github.com/go-delve/delve/issues/3640 which is about DIE for variables being generated with an empty location attribute when compiling with -N -l
in go1.21.
It turns out that most of the bug seems to have been solved (accidentally?) by https://go.dev/cl/509856, however very few of those persist.
An example is net.sendFile which for its return parameters ends up having two entries for its output parameters:
<2><10dbe2>: Abbrev Number: 17 (DW_TAG_formal_parameter) <10dbe3> DW_AT_name : handled <10dbeb> DW_AT_variable_parameter: 1 <10dbec> DW_AT_decl_line : 20 <10dbed> DW_AT_type : <0x5cdb9> <10dbf1> DW_AT_location : 0 byte block: () <2><10dbf2>: Abbrev Number: 12 (DW_TAG_variable) <10dbf3> DW_AT_name : &handled <10dbfc> DW_AT_decl_line : 20 <10dbfd> DW_AT_type : <0x5cdca> <10dc01> DW_AT_location : 2 byte block: 91 68 (DW_OP_fbreg: -24)
I investigated the problem a bit and the first one, the one without location, is added by $GOROOT/src/cmd/compile/internal/dwarfgen/dwarf.go:241. In the same function I noticed that there is some weird looking code there that looks related:
if n.Esc() == ir.EscHeap {
// The variable in question has been promoted to the heap.
// Its address is in n.Heapaddr.
// TODO(thanm): generate a better location expression
}
Is this really meant to be like this? An empty if statement?
cc @thanm
Comment From: mknyszek
CC @golang/compiler
Comment From: thanm
I'll take a look. That code does seem a bit suspicious.
Comment From: derekparker
Just wanted to give a heads up I've been working on this, should have a patch to send soon.
Comment From: gopherbot
Change https://go.dev/cl/684377 mentions this issue: cmd/compile: fix loclist for heap return vars without optimizations