[PATCH] D113741: [RFC][DwarfDebug][AsmPrinter] Support emitting function-local declaration for a lexical block

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 24 09:36:10 PST 2022


dblaikie added a comment.

In D113741#3343268 <https://reviews.llvm.org/D113741#3343268>, @krisb wrote:

> @dblaikie I've updated the patch with a fix for split dwarf issue (the test is included). Could I ask you to check the full build on your side?
>
> The issue was in wrong assumptions about in which CUs we need to create those local entities. Basically, they [CUs] should match the ones where the parent subprogram was emitted.
> It's not an easy thing to find the particular list of suited CUs while we are in `endModule()` (especially, because split-dwarf and split-dwarf inlining introduce a tricky logic around), so I chose to collect this information during subprograms emission.
> The solution still looks a bit hacky, but I hope this is a step forward.
>
> What about the second issue, unfortunately (or fortunately? :)), I'm still able to reproduce the crash on ToT of `main`, so I'm not sure this patch may cause the issue. I'll appreciate if could check it once again.
>
> Thank you and sorry for the long delay.

All good.

I'm not immediately following why a list of CUs is needed/why we'd create the variable in more than one CU - could you explain that?



================
Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:1408-1409
+    }
+    DwarfCompileUnit *const *TheCUPtr = &TheCU;
+    return llvm::make_range(TheCUPtr, TheCUPtr + 1);
+  };
----------------
This looks buggy - it's returning a pointer to a local variable (the `TheCU` pointer) which means it'll be dangling once the function returns, yeah? (I'd expect msan to catch this, for instance)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113741/new/

https://reviews.llvm.org/D113741



More information about the llvm-commits mailing list