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.

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

cmd/compile: debug info for inlined funcs are sometimes lost #26206

Open
hyangah opened this issue Jul 3, 2018 · 4 comments
Open

cmd/compile: debug info for inlined funcs are sometimes lost #26206

hyangah opened this issue Jul 3, 2018 · 4 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Debugging NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@hyangah
Copy link
Contributor

hyangah commented Jul 3, 2018

with go version devel +23ce272bb1 Mon Jul 2 17:50:00 2018 +0000 linux/amd64

$ cat main.go
package main

import "fmt"

func main() {
        x := &X{Foo: 10}
        y := InlineThis(x, "bar")
        fmt.Printf("Y = %+v\n", y)
}

type X struct {
        Foo int
}

func InlineThis(x *X, s string) int {
        y := x.Foo + len(s)
        return y
}

With go1.11, I expected debug info for the InlineThis would be present in the (default) optimized binary,
but it doesn't.

With --gcflags="-N", I could see some trace of InlineThis in the binary.

 <1><732df>: Abbrev Number: 3 (DW_TAG_subprogram)
    <732e0>   DW_AT_name        : main.InlineThis
    <732f0>   DW_AT_inline      : 1     (inlined)
    <732f1>   DW_AT_external    : 1

@heschik

@heschi
Copy link
Contributor

heschi commented Jul 3, 2018

Peculiar. Running with -d dwarfinl=2:

assembling DWARF inlined routine info for "".main
PutDefaultFunc(go.info."".main)
putscope(go.info."".main,0): vars:
[snip]

It looks to me like the inline call table is completely missing the call to InlineThis. @thanm might be able to help.

@randall77
Copy link
Contributor

InlineThis gets inlined and completely optimized away (to a single y:=13). I'm not sure where you would hang a reference to the now-gone function.

@dr2chase

@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 11, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.12 milestone Jul 11, 2018
@andybons andybons modified the milestones: Go1.12, Go1.13 Feb 12, 2019
@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@thanm
Copy link
Contributor

thanm commented Sep 10, 2019

I took another look at this testcase with a recent compiler (Go 1.13 / tip). Problem is still there.

As Keith says, all traces of the function in question are being optimized away -- unless there is some instruction somewhere with a "Pos" that originated in the inlined routine (and in this case we don't, they are all folded away), you don't get a record of the inline in the DWARF.

For grins I rewrote the testcase in C and compiled it with recent versions of clang and gcc. Code:

#include 
#include 

typedef struct {  int Foo; } X;

static inline int InlineThis(X *x, char *s) {
  int y = strlen(s) + x->Foo;
  return y;
}

int main() {
  X x;
  x.Foo = 10;
  int y = InlineThis(&x, "bar");
  printf("%d\n", y);
}

With clang there is also no trace of InlineThis, e.g. it does essentially the same thing as the Go compiler. With gcc there is at least a record of the inline, and it has (heroically) tried to capture the values of the parameters at the callsite:

 <2><342>: Abbrev Number: 22 (DW_TAG_GNU_call_site)
    <343>   DW_AT_low_pc      : 0x1a
    <34b>   DW_AT_abstract_origin: <0x399>
 <3><34f>: Abbrev Number: 23 (DW_TAG_GNU_call_site_parameter)
    <350>   DW_AT_location    : 1 byte block: 55 	(DW_OP_reg5 (rdi))
    <352>   DW_AT_GNU_call_site_value: 9 byte block: 3 0 0 0 0 0 0 0 0 	(DW_OP_addr: 0)
 <3><35c>: Abbrev Number: 23 (DW_TAG_GNU_call_site_parameter)
    <35d>   DW_AT_location    : 1 byte block: 54 	(DW_OP_reg4 (rsi))
    <35f>   DW_AT_GNU_call_site_value: 1 byte block: 3d 	(DW_OP_lit13)
 <3><361>: Abbrev Number: 0

however according to the DWARF above the callsite is being attributed to an instruction after the call to printf (oops) and the values of the call site parameters look pretty sketchy too (it says that we's passing a zero to InlineThis which doesn't look right).

My own feeling: not sure it is really worth while trying to support this case, or even if it is a good idea at all, given the added complexity that would be needed in the compiler, and given that other comparable compilers (with more resources than Go) aren't handling it.

@thanm
Copy link
Contributor

thanm commented Sep 10, 2019

Moving this issue from 1.14 to unplanned (please move it back if you object).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. Debugging NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

7 participants