Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/compile: DWARF information for local variables missing #14744

Closed
aarzilli opened this issue Mar 10, 2016 · 5 comments
Closed

cmd/compile: DWARF information for local variables missing #14744

aarzilli opened this issue Mar 10, 2016 · 5 comments
Labels
FrozenDueToAge
Milestone
Go1.7

Comments

@aarzilli
Copy link
Contributor

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)
@ianlancetaylor ianlancetaylor changed the title DWARF information for local variables missing cmd/compile: DWARF information for local variables missing Mar 10, 2016
@ianlancetaylor ianlancetaylor added this to the Go1.7 milestone Mar 10, 2016
@randall77
Copy link
Contributor

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 randall77 self-assigned this Mar 10, 2016
@randall77
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link

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

@aarzilli
Copy link
Contributor Author

aarzilli commented May 7, 2016

Thanks for fixing this!

@golang golang locked and limited conversation to collaborators May 7, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.7
Development

No branches or pull requests
4 participants
@aarzilli @ianlancetaylor @randall77 @gopherbot