[llvm-dev] How to handle DWARF Missing due to function elimination?

[chuanqi.xcq via llvm-dev]

Hi,

Recently I met a problem incurred by DWARF Missing. Simply, if a function gets inlined to a call site,

the dwarf infomation for the call site maybe:

```

DW_TAG_inlined_subroutine:

    DW_AT_abstract_origin (0x0123456)

```

The gdb would blame when it finds 0x0123456 doesn't refer to any functions in dwarf format.

From my point of view, the reason there is unexist DW_AT_abstract_origin is due to function elimination.

For example,

```

static void foo() { ... } // only used by bar

void bar() {

    foo();

}

```

After foo gets inlined to bar, there is no user of foo. So the compiler could and should remove foo. However,

the compiler removes the debug info of foo, so the callsite in bar can't find definition of foo in the current module.

There is a brief introduction. I met this problem in ThinLTO. But I believe the function elimination should be the root cause.

I am not sure if this is a bug about compiler or about the debugger. For example, the debugger should emit a warning instead

of crashing. It affects how should solve this problem.

I  made a copy to some people who are familiar with debug info to my knowledge. If this is not polite and disturbing, just inform me.

Thanks,

Chuanqi

[Jeremy Morse via llvm-dev]

Hi Chuanqi,

On Thu, May 27, 2021 at 12:11 PM chuanqi.xcq
<yede...@linux.alibaba.com> wrote:
> The gdb would blame when it finds 0x0123456 doesn't refer to any functions in dwarf format.

This is really interesting -- if you run "llvm-dwarfdump -verify" on
the output file, does it too complain about an invalid DIE reference?

There's a known issue with very complicated LTO builds that causes
something similar:

https://bugs.llvm.org/show_bug.cgi?id=48790

Reverting 93592b726c7 locally will tell you whether it's that or not.

--
Thanks,
Jeremy
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

[David Blaikie via llvm-dev]

Yeah - would be good to know what the examples are - generally that is not expected (even with linker GC or other cases of symbol removal) & so is most likely something to be fixed in LLVM - but yeah, if the debugger is actually /crashing/ that's also not good, and it shouldn't do that (but lesser problem, because it also shouldn't encounter debug info like this, generally).

[chuanqi.xcq via llvm-dev]

  Hi,

Although it looks like the same problem within the link (I met this within ThinLTO and bug 48790 met in LTO), it can't help after I revert  e08f205f. (You mentioned 93592b726c7 but I believe it shouldn't be true).

I met this in a complex production code. I would try to give an minimal repro if possible.

Thanks,

Chuanqi

------------------------------------------------------------------

From:David Blaikie <dbla...@gmail.com>

Send Time:2021年5月28日(星期五) 02:01

To:Jeremy Morse <jeremy.m...@gmail.com>

Cc:chuanqi.xcq <yede...@linux.alibaba.com>; llvm...@lists.llvm.org <llvm...@lists.llvm.org>; aprantl <apr...@apple.com>

Subject:Re: How to handle DWARF Missing due to function elimination?

[chuanqi.xcq via llvm-dev]

Hi,

Sorry for disturbing. I find that I made a mistake after I revert  e08f205f / D70350. I only recompile the clang instead of the lld. However, I met this problem within ThinLTO : (. Finally, the workaround to revert e08f205f/D70350 works for my case. Thanks a lot!

Thanks,

Chuanqi

------------------------------------------------------------------

From:chuanqi.xcq <yede...@linux.alibaba.com>

Send Time:2021年5月28日(星期五) 11:23

To:Jeremy Morse <jeremy.m...@gmail.com>; David Blaikie <dbla...@gmail.com>

Cc:llvm...@lists.llvm.org <llvm...@lists.llvm.org>; aprantl <apr...@apple.com>