[llvm-dev] LLC crash while handling DEBUG info
Mahesha S via llvm-dev
llvm-dev at lists.llvm.org
Sun May 31 21:34:58 PDT 2020
Thanks for the clarification. Yes, DISubprogram is referenced from an
llvm::Function definition's "getSubprogram" at the point of crash. Then,
it must be an issue with the debug info generation.
On Mon, Jun 1, 2020 at 9:46 AM David Blaikie <dblaikie at gmail.com> wrote:
> I think "optimized" is a red herring here - it's just a minor flag
> that's used to add an extra attribute to a DW_TAG_subprogram DIE, if
> it's present - so far as I know.
>
> It's not "optimized instead of definition" - if the DISubprogram is
> referenced from an llvm::Function definition's "getSubprogram", then
> it should have a non-null unit. If it doesn't have a unit - that's I
> think the source of the problem. A DISubprogram attached to an
> llvm::Function definition's getSubprogram should be a definition and
> should have a non-null unit.
>
> On Sun, May 31, 2020 at 9:10 PM Mahesha S <mahesha.comp at gmail.com> wrote:
> >
> > 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
>
--
Thanks,
Mahesha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200601/2a1ccc6f/attachment-0001.html>
More information about the llvm-dev
mailing list