Mahesha S via llvm-dev
2020-May-31 09:53 UTC
[llvm-dev] LLC crash while handling DEBUG info
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200531/a114065e/attachment-0001.html>
David Blaikie via llvm-dev
2020-May-31 16:43 UTC
[llvm-dev] LLC crash while handling DEBUG info
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
Mahesha S via llvm-dev
2020-May-31 17:59 UTC
[llvm-dev] LLC crash while handling DEBUG info
I am bit confused - `unit` must be present for definitions, and `optimized ` is also a `definition`, so, `unit` must be present for `optimized ` too. Am I right? Mahesha On Sun, May 31, 2020 at 10:14 PM David Blaikie <dblaikie at gmail.com> wrote:> 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 >-- Thanks, Mahesha -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200531/dea44eed/attachment.html>
Seemingly Similar Threads
- LLC crash while handling DEBUG info
- LLC crash while handling DEBUG info
- LLC crash while handling DEBUG info
- [LLVM][DISubprogram][LL format updation query] Question regarding moving DISubprogram DIFlags to DISPFlag.
- [LLVM][DISubprogram][LL format updation query] Question regarding moving DISubprogram DIFlags to DISPFlag.