cmd/compile: DWARF information for local variables missing

[aarzilli]

Please answer these questions before submitting your issue. Thanks!

1. What version of Go are you using (go version)?
   go version devel +dbe54d2 Thu Mar 10 07:01:34 2016 +0000 linux/amd64
2. What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/a/n/go/"
GORACE=""
GOROOT="/usr/local/go-tip"
GOTOOLDIR="/usr/local/go-tip/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build814262766=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"

1. What did you do?
   Compiled this program with go build -gcflags='-N -l' then checked the output of objdump --dwarf ./testvariables.
2. What did you expect to see?

I expected main.foobar to have all its local variables like it did on <=1.6

1. What did you see instead?

Only few local variables survive:

 <1><7b>: Abbrev Number: 2 (DW_TAG_subprogram)
    <7c>   DW_AT_name        : main.foobar
    <88>   DW_AT_low_pc      : 0x4010e0
    <90>   DW_AT_high_pc     : 0x4025c0
    <98>   DW_AT_external    : 1
 <2><99>: Abbrev Number: 4 (DW_TAG_variable)
    <9a>   DW_AT_name        : i32
    <9e>   DW_AT_location    : 5 byte block: 9c 11 c0 77 22     (DW_OP_call_frame_cfa; DW_OP_consts: -1088; DW_OP_plus)
    <a4>   DW_AT_type        : <0x2910a>
 <2><ac>: Abbrev Number: 4 (DW_TAG_variable)
    <ad>   DW_AT_name        : a4
    <b0>   DW_AT_location    : 5 byte block: 9c 11 b0 78 22     (DW_OP_call_frame_cfa; DW_OP_consts: -976; DW_OP_plus)
    <b6>   DW_AT_type        : <0x29257>
 <2><be>: Abbrev Number: 4 (DW_TAG_variable)
    <bf>   DW_AT_name        : a11
    <c3>   DW_AT_location    : 5 byte block: 9c 11 b0 7b 22     (DW_OP_call_frame_cfa; DW_OP_consts: -592; DW_OP_plus)
    <c9>   DW_AT_type        : <0x291eb>
 <2><d1>: Abbrev Number: 5 (DW_TAG_formal_parameter)
    <d2>   DW_AT_name        : baz
    <d6>   DW_AT_location    : 1 byte block: 9c         (DW_OP_call_frame_cfa)
    <d8>   DW_AT_type        : <0x22781>
 <2><e0>: Abbrev Number: 5 (DW_TAG_formal_parameter)
    <e1>   DW_AT_name        : bar
    <e5>   DW_AT_location    : 4 byte block: 9c 11 10 22        (DW_OP_call_frame_cfa; DW_OP_consts: 16; DW_OP_plus)
    <ea>   DW_AT_type        : <0x22aeb>
 <2><f2>: Abbrev Number: 0
 <1><f3>: Abbrev Number: 2 (DW_TAG_subprogram)

[randall77]

In general you should not depend on most of these variables surviving to appear in the DWARF info. For instance, a9 never has to exist. A lot of the other variables only exist because we need to call convT2E on them, and to do so we need to put their values on the stack. People are thinking about optimizations to interface{} conversion which would eliminate that need for more cases.

That said, I think we are losing some name info at the moment. Args to convT2E can be named and we're not doing that. I'll investigate further.

[randall77]

So it looks like you just got lucky for 1.6 (and earlier). The old compiler spills, e.g., a2, then reloads it and stores it to a temporary, and then calls convT2E on that temporary. If it doesn't need to spill for whatever reason, you won't get source names in the dwarf info.

Here's an example where spills don't happen, and thus the compiler loses names for all Go versions I tested (1.5.1, 1.6, tip):

func main() {
    a := 6
    b := 7
    fmt.Printf("%d %d\n", a, b)
}

Fixing this in SSA will be difficult, as the frontend has already introduced the nameless temporary for the convT2E call.
Still worth fixing if we can, but I don't see any easy fixes.

[aarzilli]

In general you should not depend on most of these variables surviving to appear in the DWARF info

My concern isn't the test failure (I presume I can fix it by just passing the values as arguments). Rather I was worried about user experience: isn't this a bit too aggressive for -N?

[gopherbot]

CL https://golang.org/cl/22681 mentions this issue.

[aarzilli]

Thanks for fixing this!