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

[hyangah]

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]

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]

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

[thanm]

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]

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