[llvm-dev] [DebugInfo] Bugs when emitting debug info with inlined functions

[Ellis Hoag via llvm-dev]

Hi all,

In recent weeks I've been looking into fixing a few bugs in the Dwarf
emitted by LLVM related to when functions are inlined.
* https://bugs.llvm.org/show_bug.cgi?id=30637 (static variables)
  * Fixed in https://reviews.llvm.org/D108492 (in review)
* https://bugs.llvm.org/show_bug.cgi?id=52159 (imported declaration)
  * Fixed in https://reviews.llvm.org/D110294 (in review)
In these bugs `getOrCreateSubprogramDIE()` is used to find the SP DIE that
will become the parent of a GV DIE or the reference of an imported
declaration DIE. The problem is if the function is inlined and removed, the
concrete SP DIE will not be created and `getOrCreateSubprogramDIE()` will
return an empty DIE. Instead, I think we should be using the abstract
origin DIE of the SP which is created after processing an inlined scope.

Here is a concrete example from https://bugs.llvm.org/show_bug.cgi?id=52159
```
namespace ns {
inline __attribute__((always_inline))
void foo() { int a = 4; }
}

void goo() {
  using ns::foo;
  foo();
}
```

This produces an imported declaration DIE that references an empty SP DIE
even though there already exists one for foo.
```
// Abstract origin
0x0000002f:     DW_TAG_subprogram
                  DW_AT_linkage_name ("_ZN2ns3fooEv")
                  DW_AT_name ("foo")
// Empty concrete
0x00000047:     DW_TAG_subprogram
0x00000048:     NULL
// Import declaration
0x00000069:     DW_TAG_imported_declaration
                  DW_AT_import (0x00000047)
```

One fix is to reference the abstract origin DIE.
```
0x00000069:     DW_TAG_imported_declaration
                  DW_AT_import (0x0000002f)
```

Another fix is to do what gcc does and fill out a specification DIE that
the import references.
```
// Import declaration
0x0000004f:     DW_TAG_imported_declaration
                  DW_AT_import (0x00000063)
// Specification
0x00000063:     DW_TAG_subprogram
                  DW_AT_name ("foo")
                  DW_AT_declaration (true)
// Abstract origin
0x00000070:   DW_TAG_subprogram
                DW_AT_specification (0x00000063 "_ZN2ns3fooEv")
```

Since I'm relatively new to debug info, I thought I'd ask some questions on
the mailing list.
1. A simple solution to this class of bugs is to reference the abstract
origin SP DIE where appropriate. Do we have any rules for when to reference
the abstract origin if it exists?
2. Would it be better to follow gcc's solution and fill out specifications
in these cases?
3. Are they more known cases/bugs to consider?

Thanks, Ellis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211013/687aa7ed/attachment.html>