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