[PATCH] D104827: [DebugInfo] Enforce implicit constraints on `distinct` MDNodes

Scott Linder via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 6 14:48:58 PDT 2021


scott.linder added a comment.

In D104827#2854825 <https://reviews.llvm.org/D104827#2854825>, @uabelho wrote:

> Hi,
>
> We've noticed that this patch changes things so bcfiles created with the patch cannot be parsed with binaries built before it.
> E.g if I create foo.bc with a clang binary built from commit 8cd35ad854ab <https://reviews.llvm.org/rG8cd35ad854ab4458fd509447359066ea3578b494> (this patch) with:
>
>   clang -save-temps foo.c -S -g
>
> and then try to run opt built from aad87328fab <https://reviews.llvm.org/rGaad87328fabff9382bac0b452c83934515e6d0c8> (the commit before this patch) with
>
>   opt foo.bc -S > /dev/null
>
> it results in
>
>   opt: ../lib/Bitcode/Reader/MetadataLoader.cpp:366: (anonymous namespace)::(anonymous namespace)::PlaceholderQueue::~PlaceholderQueue(): Assertion `empty() && "PlaceholderQueue hasn't been flushed before being destroyed"' failed.
>   PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
>   Stack dump:
>   0.	Program arguments: build-all-builtins/bin/opt foo.bc -S
>    #0 0x0000000002a11623 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (build-all-builtins/bin/opt+0x2a11623)
>    #1 0x0000000002a0f2de llvm::sys::RunSignalHandlers() (build-all-builtins/bin/opt+0x2a0f2de)
>    #2 0x0000000002a119a6 SignalHandler(int) Signals.cpp:0:0
>    #3 0x00007f2c97079630 __restore_rt sigaction.c:0:0
>    #4 0x00007f2c947ac387 raise (/lib64/libc.so.6+0x36387)
>    #5 0x00007f2c947ada78 abort (/lib64/libc.so.6+0x37a78)
>    #6 0x00007f2c947a51a6 __assert_fail_base (/lib64/libc.so.6+0x2f1a6)
>    #7 0x00007f2c947a5252 (/lib64/libc.so.6+0x2f252)
>    #8 0x0000000003398a64 llvm::MetadataLoader::MetadataLoaderImpl::parseMetadata(bool) (build-all-builtins/bin/opt+0x3398a64)
>    #9 0x00000000033a19ac llvm::MetadataLoader::parseMetadata(bool) (build-all-builtins/bin/opt+0x33a19ac)
>   #10 0x00000000033730a8 (anonymous namespace)::BitcodeReader::parseFunctionBody(llvm::Function*) BitcodeReader.cpp:0:0
>   #11 0x0000000003370f7c (anonymous namespace)::BitcodeReader::materialize(llvm::GlobalValue*) BitcodeReader.cpp:0:0
>   #12 0x00000000033720aa (anonymous namespace)::BitcodeReader::materializeModule() BitcodeReader.cpp:0:0
>   #13 0x000000000221fc8a llvm::Module::materializeAll() (build-all-builtins/bin/opt+0x221fc8a)
>   #14 0x000000000336acb1 llvm::BitcodeModule::getModuleImpl(llvm::LLVMContext&, bool, bool, bool, llvm::function_ref<llvm::Optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (llvm::StringRef)>) (build-all-builtins/bin/opt+0x336acb1)
>   #15 0x000000000336ef60 llvm::parseBitcodeFile(llvm::MemoryBufferRef, llvm::LLVMContext&, llvm::function_ref<llvm::Optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (llvm::StringRef)>) (build-all-builtins/bin/opt+0x336ef60)
>   #16 0x00000000024521a0 llvm::parseIR(llvm::MemoryBufferRef, llvm::SMDiagnostic&, llvm::LLVMContext&, llvm::function_ref<llvm::Optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (llvm::StringRef)>) (build-all-builtins/bin/opt+0x24521a0)
>   #17 0x000000000245262e llvm::parseIRFile(llvm::StringRef, llvm::SMDiagnostic&, llvm::LLVMContext&, llvm::function_ref<llvm::Optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > (llvm::StringRef)>) (build-all-builtins/bin/opt+0x245262e)
>   #18 0x0000000000782acb main (build-all-builtins/bin/opt+0x782acb)
>   #19 0x00007f2c94798555 __libc_start_main (/lib64/libc.so.6+0x22555)
>   #20 0x000000000076f800 _start (build-all-builtins/bin/opt+0x76f800)
>   Abort
>
> I suppose this is not expected?
>
> F17715352: foo.bc <https://reviews.llvm.org/F17715352>

Thank you for letting me know, and for the reproducer! Curiously this is just on the `return error(...)` path in `upgradeDIExpression`, which I just didn't test (as I'm not sure how to in the current LLVM infrastructure). I assume this is because normally bitcode error returns occur after most of the bitcode file has already been read, so there are no pending placeholders, but I need to learn some more about the bitcode parser in general to be sure I understand the issue. My first thought is that we should just flush placeholders on an error, as we are about to just bail anyway.

In D104827#2856347 <https://reviews.llvm.org/D104827#2856347>, @JDevlieghere wrote:

> In D104827#2855970 <https://reviews.llvm.org/D104827#2855970>, @dexonsmith wrote:
>
>> That looks bad — best to revert while that's investigated.
>
> This also breaks `lang/cpp/member-and-local-vars-with-same-name/TestMembersAndLocalsWithSameName.py` in the LLDB test suite:
>
>   Assertion failed: ((FromValue || !(isa<LocalAsMetadata>(MD) || isa<DIArgList>(MD))) && "Unexpected function-local metadata outside of value argument"), function WriteAsOperandInternal, file AsmWriter.cpp, line 2519.
>
> Given that it's Friday, I'm going to go ahead and revert this to get our bot back to green.

Thank you for reverting, I was out Friday+Monday. I thought I was safe to move the assert that is triggering here up further in the function body to make it stronger, but evidently I overlooked some cases. I'll identify them and either fix them elsewhere or restore the assert (possibly with a comment describing the rationale). Thanks again!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104827



More information about the llvm-commits mailing list