[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