[llvm-dev] LLC crash while handling DEBUG info

Sun May 31 09:43:49 PDT 2020

definition and optimized are orthogonal (a function could be both, or
neither) - one says this DISubprogram describes a function definition
(rather than a declaration) and the other says this function has been
compiled (so I suppose it must be a definition - though we may not
rely on/verify that/need that to be true at the moment).

Sounds like you're saying the verifier does check the constraint
you're interested in (ie: you only hit the assert in
lib/CodeGen/LexicalScopes if the code is in violation of the
verifier?) - and the verification check sounds correct/reasonable to
me. (declarations are owned by the unit - whereas definitions are
intentionally owned by the llvm::Function and refer to the unit they
are within so they can be implicitly dropped if the Function is
dropped - so, yes, the unit must be present for definitions and must
not be present for non-definitions).

On Sun, May 31, 2020 at 2:53 AM Mahesha S <mahesha.comp at gmail.com> wrote:
>
> Hi David
>
> If you look at line https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Verifier.cpp#L1160  there is IR verification which asserts that only in case of `spFlags = DISPFlagDefinition`, the compilation unit (`unit` field) should be present. Otherwise, it should *not* be present. In  the crash case, `spFlags = DISPFlagOptimized`. So, I guess, `unit` field should *not* be present, though I do not know the difference between ` DISPFlagDefinition` and ` DISPFlagOptimized`.  if that is expected, then we may need to check `nullity` of `DISubprogram::getUnit()` before accessing it at https://github.com/llvm/llvm-project/blob/master/llvm/lib/CodeGen/LexicalScopes.cpp#L53
>
> Thanks,
> Mahesha
>
> On Sun, May 31, 2020 at 11:26 AM David Blaikie <dblaikie at gmail.com> wrote:
>>
>> In theory the LLVM IR verifier (llvm/lib/IR/Verifier.cpp) should catch
>> this sort of thing. Maybe it isn't running in llc? It probably should
>> be. It's also likely not exhaustive to completely arbitrary changes to
>> the debug info IR - but could be improved if there are particular
>> things folks come across/want to sure it up against.
>>
>> On Sat, May 30, 2020 at 10:27 PM Mahesha S via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> >
>> > Hi-
>> >
>> > Here is the simple C++ function:
>> >
>> > -----------
>> > void foo() {
>> > }
>> > -----------
>> >
>> > Let's say, above function is compiled to generate LLVM IR with -g flag
>> > using the command line `clang++ -g -O0 -S -emit-llvm foo.cpp`, we get
>> > below IR
>> >
>> > -----------
>> > ; ModuleID = 'foo.cpp'
>> > source_filename = "foo.cpp"
>> > target datalayout =
>> > "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
>> > target triple = "x86_64-unknown-linux-gnu"
>> >
>> > ; Function Attrs: noinline nounwind optnone uwtable
>> > define dso_local void @_Z3foov() #0 !dbg !7 {
>> >   ret void, !dbg !10
>> > }
>> >
>> > attributes #0 = { noinline nounwind optnone uwtable
>> > "correctly-rounded-divide-sqrt-fp-math"="false"
>> > "disable-tail-calls"="false" "frame-pointer"="all"
>> > "less-precise-fpmad"="false" "min-legal-vector-width"="0"
>> > "no-infs-fp-math"="false" "no-jump-tables"="false"
>> > "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false"
>> > "no-trapping-math"="false" "stack-protector-buffer-size"="8"
>> > "target-cpu"="x86-64"
>> > "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87"
>> > "unsafe-fp-math"="false" "use-soft-float"="false" }
>> >
>> > !llvm.dbg.cu = !{!0}
>> > !llvm.module.flags = !{!3, !4, !5}
>> > !llvm.ident = !{!6}
>> >
>> > !0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file:
>> > !1, producer: "clang version 11.0.0
>> > (https://github.com/llvm/llvm-project
>> > 9e0b52e2e68412a9a2add18697f4246e5e5ee5e3)", isOptimized: false,
>> > runtimeVersion: 0, emissionKind: FullDebug, enums: !2,
>> > splitDebugInlining: false, nameTableKind: None)
>> > !1 = !DIFile(filename: "foo.cpp", directory:
>> > "/home/mahesha/ROCm/issues/hipclang/other/crash/foo")
>> > !2 = !{}
>> > !3 = !{i32 7, !"Dwarf Version", i32 4}
>> > !4 = !{i32 2, !"Debug Info Version", i32 3}
>> > !5 = !{i32 1, !"wchar_size", i32 4}
>> > !6 = !{!"clang version 11.0.0 (https://github.com/llvm/llvm-project
>> > 9e0b52e2e68412a9a2add18697f4246e5e5ee5e3)"}
>> > !7 = distinct !DISubprogram(name: "foo", linkageName: "_Z3foov",
>> > scope: !1, file: !1, line: 1, type: !8, scopeLine: 1, flags:
>> > DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0,
>> > retainedNodes: !2)
>> > !8 = !DISubroutineType(types: !9)
>> > !9 = !{null}
>> > !10 = !DILocation(line: 2, column: 1, scope: !7)
>> > -----------
>> >
>> > Now, let's say, in the above IR file, I intentionally make debug info
>> > metadata, a kind of invalid, by removing the field 'unit` and by
>> > changing the field `spFlags` from `DISPFlagDefinition` to
>> > `DISPFlagOptimized` within metadata info !7 as shown below.
>> >
>> > -----------
>> > ; ModuleID = 'foo.cpp'
>> > source_filename = "foo.cpp"
>> > target datalayout =
>> > "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
>> > target triple = "x86_64-unknown-linux-gnu"
>> >
>> > ; Function Attrs: noinline nounwind optnone uwtable
>> > define dso_local void @_Z3foov() #0 !dbg !7 {
>> >   ret void
>> > }
>> >
>> > attributes #0 = { noinline nounwind optnone uwtable
>> > "correctly-rounded-divide-sqrt-fp-math"="false"
>> > "disable-tail-calls"="false" "frame-pointer"="all"
>> > "less-precise-fpmad"="false" "min-legal-vector-width"="0"
>> > "no-infs-fp-math"="false" "no-jump-tables"="false"
>> > "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false"
>> > "no-trapping-math"="false" "stack-protector-buffer-size"="8"
>> > "target-cpu"="x86-64"
>> > "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87"
>> > "unsafe-fp-math"="false" "use-soft-float"="false" }
>> >
>> > !llvm.dbg.cu = !{!0}
>> > !llvm.module.flags = !{!3, !4, !5}
>> > !llvm.ident = !{!6}
>> >
>> > !0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file:
>> > !1, producer: "clang version 11.0.0
>> > (https://github.com/llvm/llvm-project
>> > 9e0b52e2e68412a9a2add18697f4246e5e5ee5e3)", isOptimized: false,
>> > runtimeVersion: 0, emissionKind: FullDebug, enums: !2,
>> > splitDebugInlining: false, nameTableKind: None)
>> > !1 = !DIFile(filename: "foo.cpp", directory:
>> > "/home/mahesha/ROCm/issues/hipclang/other/crash/foo")
>> > !2 = !{}
>> > !3 = !{i32 7, !"Dwarf Version", i32 4}
>> > !4 = !{i32 2, !"Debug Info Version", i32 3}
>> > !5 = !{i32 1, !"wchar_size", i32 4}
>> > !6 = !{!"clang version 11.0.0 (https://github.com/llvm/llvm-project
>> > 9e0b52e2e68412a9a2add18697f4246e5e5ee5e3)"}
>> > !7 = distinct !DISubprogram(name: "foo", linkageName: "_Z3foov",
>> > scope: !1, file: !1, line: 1, type: !8, scopeLine: 1, flags:
>> > DIFlagPrototyped, spFlags: DISPFlagOptimized, retainedNodes: !2)
>> > !8 = !DISubroutineType(types: !9)
>> > !9 = !{null}
>> > !10 = !DILocation(line: 2, column: 1, scope: !7)
>> > -----------
>> >
>> > Now, if I compile the above modified IR file using LLC, then LLC
>> > crashes as below. The crash point is
>> > https://github.com/llvm/llvm-project/blob/master/llvm/lib/CodeGen/LexicalScopes.cpp#L53.
>> > Reason for crash is `NULL` pointer access. `DISubprogram::getUnit()`
>> > returns `NULL` pointer since there is no `unit` field in the related
>> > metadata info.
>> >
>> > -----------
>> > PLEASE submit a bug report to https://bugs.llvm.org/ and include the
>> > crash backtrace.
>> > Stack dump:
>> > 0.      Program arguments: /opt/rocm/llvm/bin/llc foo.ll
>> > 1.      Running pass 'Function Pass Manager' on module 'foo.ll'.
>> > 2.      Running pass 'Debug Variable Analysis' on function '@_Z3foov'
>> >  #0 0x0000556017a2aa8a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
>> > (/opt/rocm/llvm/bin/llc+0x1883a8a)
>> >  #1 0x0000556017a28854 llvm::sys::RunSignalHandlers()
>> > (/opt/rocm/llvm/bin/llc+0x1881854)
>> >  #2 0x0000556017a289a3 SignalHandler(int) (/opt/rocm/llvm/bin/llc+0x18819a3)
>> >  #3 0x00007fdb38654890 __restore_rt
>> > (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
>> >  #4 0x0000556016f013ea
>> > llvm::LexicalScopes::initialize(llvm::MachineFunction const&)
>> > (/opt/rocm/llvm/bin/llc+0xd5a3ea)
>> >  #5 0x0000556016f224dd
>> > llvm::LiveDebugVariables::runOnMachineFunction(llvm::MachineFunction&)
>> > (/opt/rocm/llvm/bin/llc+0xd7b4dd)
>> >  #6 0x0000556016fcb2b0
>> > llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
>> > (/opt/rocm/llvm/bin/llc+0xe242b0)
>> >  #7 0x0000556017375e8f
>> > llvm::FPPassManager::runOnFunction(llvm::Function&)
>> > (/opt/rocm/llvm/bin/llc+0x11cee8f)
>> >  #8 0x0000556017376581 llvm::FPPassManager::runOnModule(llvm::Module&)
>> > (/opt/rocm/llvm/bin/llc+0x11cf581)
>> >  #9 0x0000556017376981
>> > llvm::legacy::PassManagerImpl::run(llvm::Module&)
>> > (/opt/rocm/llvm/bin/llc+0x11cf981)
>> > #10 0x000055601662496a main (/opt/rocm/llvm/bin/llc+0x47d96a)
>> > #11 0x00007fdb372e8b97 __libc_start_main
>> > /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0
>> > #12 0x000055601668f2ea _start (/opt/rocm/llvm/bin/llc+0x4e82ea)
>> > -----------
>> >
>> > QUESTION IS:  Is this expected behavior? OR should LLC throw an error
>> > and abort compilation? OR at the crash point, we are suppose to test
>> > `nullity` of `DISubprogram::getUnit()` before accessing it?
>> >
>> > --
>> > Thanks,
>> > Mahesha
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> Thanks,
> Mahesha