[PATCH] D11180: Fixed debug info generation for function static variables, typedef, and records

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 10 09:08:40 PDT 2015


dblaikie added a comment.

Thanks again for your reminders and patience...


================
Comment at: lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:340-341
@@ +339,4 @@
+    if (!includeMinimalInlineScopes()) {
+      auto LocalDeclNodeRangeForScope = DD->findLocalDeclNodesForScope(DS);
+      for (const auto &DI : LocalDeclNodeRangeForScope) {
+        if (auto *IE = dyn_cast<DIImportedEntity>(DI.second))
----------------
Could probably just roll the local variable into the for loop header.

================
Comment at: lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:342-343
@@ +341,4 @@
+      for (const auto &DI : LocalDeclNodeRangeForScope) {
+        if (auto *IE = dyn_cast<DIImportedEntity>(DI.second))
+          Children.push_back(constructImportedEntityDIE(IE));
+        else if (RegularScope) {
----------------
Should we be adding imported entity DIEs in inlined or abstract definitions? Not sure... I suppose maybe.

What does it mean not to add the types and static variables to these cases? (if we inline away all uses of a function - won't we lose the local types and static variables & the user won't be able to print/interact with them?)

================
Comment at: lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:351-352
@@ +350,4 @@
+                getOrCreateGlobalVariableDIE(GV, /* SkipContext */ true));
+          }
+          else if (auto *RT = dyn_cast<DIType>(DI.second)) {
+            if (getDIE(RT))
----------------
Formatting (run clang-format over your change?)

================
Comment at: lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:353-355
@@ +352,5 @@
+          else if (auto *RT = dyn_cast<DIType>(DI.second)) {
+            if (getDIE(RT))
+              // Type was already created, nothing to do.
+              continue;
+            Children.push_back(getOrCreateTypeDIE(RT, /* SkipContext */ true));
----------------
Doesn't "getOrCreateTypeDIE" already do the getDIE check? (that would be implied by the "get" part of "get or create" in the name, I would hope)

================
Comment at: lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:377-389
@@ -353,4 +376,15 @@
     }
-    ScopeDIE = constructLexicalScopeDIE(Scope);
-    assert(ScopeDIE && "Scope DIE should not be null.");
+    // Lexical block of non-inline function is stored in the lexical scope map.
+    if (RegularScope)
+      ScopeDIE = getDIE(DS);
+    if (ScopeDIE) {
+      // Mapped lexical scope should be already attached to its parent scope.
+      assert(ScopeDIE->getParent() && "Scope DIE was not attached to parent.");
+      AddScopeDieToFinalChildren = false;
+    } else {
+      ScopeDIE = constructLexicalScopeDIE(Scope);
+      assert(ScopeDIE && "Scope DIE should not be null.");
+      if (RegularScope)
+        insertDIE(Scope->getScopeNode(), ScopeDIE);
+    }
   }
----------------
I'm somewhat confused about what this code is about/for. Could you help explain it further?

================
Comment at: lib/CodeGen/AsmPrinter/DwarfUnit.cpp:742-743
@@ +741,4 @@
+  if (!ContextDIE && !SkipContext) {
+    // Can reach this point when the parent scope is a lexical block.
+    // Which was not created yet, or that does not contain code, create it.
+    assert(isa<DILexicalBlockBase>(Context) && "Expected lexical block scope");
----------------
When do we do this while not skipping context?

(also - creating a lexical block that doesn't contain any code may be rather useless - the debugger will never be at a location inside that scope, so it may be difficult to access the variables, etc, there if the debugger implements correct scoping rules... - but I'm not sure. What do other compilers do here?)

================
Comment at: test/DebugInfo/X86/lexical-block-inline.ll:20
@@ +19,3 @@
+;; This test was generated by running following command:
+;; clang -cc1 -O2 -g -emit-llvm foo.cpp 
+;; Where foo.cpp
----------------
Rather than using -O2 which changes a bunch of other stuff in the debug info too, it would be preferable to use no optimizations and add __attribute__((alwaysinline)) (or is it forceinline? I always forget the name) to the function that must be inlined.


Repository:
  rL LLVM

http://reviews.llvm.org/D11180





More information about the llvm-commits mailing list