[llvm-dev] LLC crash while handling DEBUG info
Mahesha S via llvm-dev
llvm-dev at lists.llvm.org
Sun May 31 21:10:31 PDT 2020
Let's forget about my malformed IR if it is adding additional confusion
here. I mentioned it here to ease the conversation, but if it is causing
confusion rather than making the discussion flow easier, then we better
ignore it.
The whole triggering point for this email initiative is - one of the
applications is crashing with the stack trace that I mentioned earlier. The
crash is during the pass -
llvm::LiveDebugVariables::runOnMachineFunction(). And, it is because, the
function in question is `optimized` case, and hence `unit` is `null', and
we are accessing this `null` pointer at the point of crashing.
Naturally, I want to understand the root of this issue. So, many questions
are raised within my mind.
(1) Is it because, debug metadata info is wrongly generated by setting
`optimized` instead of `definition`, and hence `unit` is missing?
(2) Is it because, we are running
lvm::LiveDebugVariables::runOnMachineFunction() without checking if the
`definition` is set or not?
(3) Is it because, we are not treating 'optimized` as 'definition` and
hence not setting 'unit`?
(4) and many more.
However, I do not have detailed knowledge in this area. So, I need to
understand certain basics here. First, I would ask:
(1) What is the scenario (testcase) for the 'optimized' case?
(2) Should we run the pass llvm::LiveDebugVariables::runOnMachineFunction()
for the case where 'optimized' is set OR we should not?
On Mon, Jun 1, 2020 at 12:25 AM David Blaikie <dblaikie at gmail.com> wrote:
> On Sun, May 31, 2020 at 11:00 AM Mahesha S <mahesha.comp at gmail.com> wrote:
> >
> > I am bit confused - `unit` must be present for definitions, and
> `optimized ` is also a `definition`,
>
> Optimized doesn't make much sense/use for a non-definition, as far as
> I understand it - but it's probably a fairly benign that the verifier
> doesn't diagnose "optimized specified on a non-definition". The
> verifier could be tightened to verify that constraint - and then your
> IR would fail verification, you could add the definition flag and be
> back with working IR that doesn't crash in LLVM's backend, I think?
>
> It's more "optimized was specified where it's meaningless - we don't
> do anything with that flag on a non-definition". The verifier could
> diagnose that to avoid producers being confused by why it's being
> ignored - but it's probably not super important to do so.
>
> > 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
>
--
Thanks,
Mahesha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200601/e7aa4c59/attachment.html>
More information about the llvm-dev
mailing list