<div dir="ltr">Hi all,<br><br>In recent weeks I've been looking into fixing a few bugs in the Dwarf emitted by LLVM related to when functions are inlined.<br>* <a href="https://bugs.llvm.org/show_bug.cgi?id=30637">https://bugs.llvm.org/show_bug.cgi?id=30637</a> (static variables)<br>  * Fixed in <a href="https://reviews.llvm.org/D108492">https://reviews.llvm.org/D108492</a> (in review)<br>* <a href="https://bugs.llvm.org/show_bug.cgi?id=52159">https://bugs.llvm.org/show_bug.cgi?id=52159</a> (imported declaration)<br>  * Fixed in <a href="https://reviews.llvm.org/D110294">https://reviews.llvm.org/D110294</a> (in review)<br>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.<br><br>Here is a concrete example from <a href="https://bugs.llvm.org/show_bug.cgi?id=52159">https://bugs.llvm.org/show_bug.cgi?id=52159</a><br>```<br>namespace ns {<br>inline __attribute__((always_inline))<br>void foo() { int a = 4; }<br>}<br><br>void goo() {<br>  using ns::foo;<br>  foo();<br>}<br>```<br><br>This produces an imported declaration DIE that references an empty SP DIE even though there already exists one for foo.<br>```<br>// Abstract origin<br>0x0000002f:     DW_TAG_subprogram<br>                  DW_AT_linkage_name ("_ZN2ns3fooEv")<br>                  DW_AT_name       ("foo")<br>// Empty concrete <br>0x00000047:     DW_TAG_subprogram<br>0x00000048:     NULL<br>// Import declaration<br>0x00000069:     DW_TAG_imported_declaration<br>                  DW_AT_import       (0x00000047)<br>```<br><br>One fix is to reference the abstract origin DIE.<br>```<br>0x00000069:     DW_TAG_imported_declaration<br>                  DW_AT_import      (0x0000002f)<br>```<br><br>Another fix is to do what gcc does and fill out a specification DIE that the import references.<br>```<br>// Import declaration<br>0x0000004f:     DW_TAG_imported_declaration<br>                  DW_AT_import        (0x00000063)<br>// Specification <br>0x00000063:     DW_TAG_subprogram<br>                  DW_AT_name     ("foo")<br>                  DW_AT_declaration (true)<br>// Abstract origin <br>0x00000070:   DW_TAG_subprogram<br>                DW_AT_specification      (0x00000063 "_ZN2ns3fooEv")<br>```<br><br>Since I'm relatively new to debug info, I thought I'd ask some questions on the mailing list.<br>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?<br>2. Would it be better to follow gcc's solution and fill out specifications in these cases?<br>3. Are they more known cases/bugs to consider?<br><br>Thanks, Ellis<br></div>