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

hyangah opened this issue Jul 3, 2018 · 4 comments

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

hyangah opened this issue Jul 3, 2018 · 4 comments


Copy link

@hyangah 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


Copy link

@heschik heschik commented Jul 3, 2018

Peculiar. Running with -d dwarfinl=2:

assembling DWARF inlined routine info for "".main
putscope("".main,0): vars:

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

Copy link

@randall77 randall77 commented Jul 3, 2018

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.


@heschik heschik added the Debugging label Jul 10, 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
Copy link

@thanm 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:


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.

Copy link

@thanm 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
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants