<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Thanks for the clarification. Yes, <span style="font-family:Arial,Helvetica,sans-serif">DISubprogram</span><span style="font-family:Arial,Helvetica,sans-serif"> is </span><span style="font-family:Arial,Helvetica,sans-serif">referenced from an llvm::Function definition's "getSubprogram" at the point of crash. Then, it must be an issue with the debug info generation.</span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 1, 2020 at 9:46 AM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think "optimized" is a red herring here - it's just a minor flag<br>
that's used to add an extra attribute to a DW_TAG_subprogram DIE, if<br>
it's present - so far as I know.<br>
<br>
It's not "optimized instead of definition" - if the DISubprogram is<br>
referenced from an llvm::Function definition's "getSubprogram", then<br>
it should have a non-null unit. If it doesn't have a unit - that's I<br>
think the source of the problem. A DISubprogram attached to an<br>
llvm::Function definition's getSubprogram should be a definition and<br>
should have a non-null unit.<br>
<br>
On Sun, May 31, 2020 at 9:10 PM Mahesha S <<a href="mailto:mahesha.comp@gmail.com" target="_blank">mahesha.comp@gmail.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Naturally, I want to understand the root of this issue. So, many questions are raised within my mind.<br>
><br>
> (1) Is it because, debug metadata info is wrongly generated by setting `optimized` instead of `definition`, and hence `unit` is missing?<br>
> (2) Is it because, we are running lvm::LiveDebugVariables::runOnMachineFunction() without checking if the `definition` is set or not?<br>
> (3) Is it because, we are not treating 'optimized` as 'definition` and hence not setting 'unit`?<br>
> (4) and many more.<br>
><br>
> However, I do not have detailed knowledge in this area. So, I need to understand certain basics here. First, I would ask:<br>
><br>
> (1) What is the scenario (testcase) for the 'optimized' case?<br>
> (2) Should we run the pass llvm::LiveDebugVariables::runOnMachineFunction() for the case where 'optimized' is set OR we should not?<br>
><br>
><br>
> On Mon, Jun 1, 2020 at 12:25 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>><br>
>> On Sun, May 31, 2020 at 11:00 AM Mahesha S <<a href="mailto:mahesha.comp@gmail.com" target="_blank">mahesha.comp@gmail.com</a>> wrote:<br>
>> ><br>
>> > I am bit confused - `unit` must be present for definitions, and `optimized ` is also a `definition`,<br>
>><br>
>> Optimized doesn't make much sense/use for a non-definition, as far as<br>
>> I understand it - but it's probably a fairly benign that the verifier<br>
>> doesn't diagnose "optimized specified on a non-definition". The<br>
>> verifier could be tightened to verify that constraint - and then your<br>
>> IR would fail verification, you could add the definition flag and be<br>
>> back with working IR that doesn't crash in LLVM's backend, I think?<br>
>><br>
>> It's more "optimized was specified where it's meaningless - we don't<br>
>> do anything with that flag on a non-definition". The verifier could<br>
>> diagnose that to avoid producers being confused by why it's being<br>
>> ignored - but it's probably not super important to do so.<br>
>><br>
>> > so, `unit` must be present for `optimized ` too. Am I right?<br>
>> ><br>
>> > Mahesha<br>
>> ><br>
>> > On Sun, May 31, 2020 at 10:14 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>> >><br>
>> >> definition and optimized are orthogonal (a function could be both, or<br>
>> >> neither) - one says this DISubprogram describes a function definition<br>
>> >> (rather than a declaration) and the other says this function has been<br>
>> >> compiled (so I suppose it must be a definition - though we may not<br>
>> >> rely on/verify that/need that to be true at the moment).<br>
>> >><br>
>> >> Sounds like you're saying the verifier does check the constraint<br>
>> >> you're interested in (ie: you only hit the assert in<br>
>> >> lib/CodeGen/LexicalScopes if the code is in violation of the<br>
>> >> verifier?) - and the verification check sounds correct/reasonable to<br>
>> >> me. (declarations are owned by the unit - whereas definitions are<br>
>> >> intentionally owned by the llvm::Function and refer to the unit they<br>
>> >> are within so they can be implicitly dropped if the Function is<br>
>> >> dropped - so, yes, the unit must be present for definitions and must<br>
>> >> not be present for non-definitions).<br>
>> >><br>
>> >> On Sun, May 31, 2020 at 2:53 AM Mahesha S <<a href="mailto:mahesha.comp@gmail.com" target="_blank">mahesha.comp@gmail.com</a>> wrote:<br>
>> >> ><br>
>> >> > Hi David<br>
>> >> ><br>
>> >> > If you look at line <a href="https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Verifier.cpp#L1160" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Verifier.cpp#L1160</a> 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 <a href="https://github.com/llvm/llvm-project/blob/master/llvm/lib/CodeGen/LexicalScopes.cpp#L53" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/master/llvm/lib/CodeGen/LexicalScopes.cpp#L53</a><br>
>> >> ><br>
>> >> > Thanks,<br>
>> >> > Mahesha<br>
>> >> ><br>
>> >> > On Sun, May 31, 2020 at 11:26 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
>> >> >><br>
>> >> >> In theory the LLVM IR verifier (llvm/lib/IR/Verifier.cpp) should catch<br>
>> >> >> this sort of thing. Maybe it isn't running in llc? It probably should<br>
>> >> >> be. It's also likely not exhaustive to completely arbitrary changes to<br>
>> >> >> the debug info IR - but could be improved if there are particular<br>
>> >> >> things folks come across/want to sure it up against.<br>
>> >> >><br>
>> >> >> On Sat, May 30, 2020 at 10:27 PM Mahesha S via llvm-dev<br>
>> >> >> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>> >> >> ><br>
>> >> >> > Hi-<br>
>> >> >> ><br>
>> >> >> > Here is the simple C++ function:<br>
>> >> >> ><br>
>> >> >> > -----------<br>
>> >> >> > void foo() {<br>
>> >> >> > }<br>
>> >> >> > -----------<br>
>> >> >> ><br>
>> >> >> > Let's say, above function is compiled to generate LLVM IR with -g flag<br>
>> >> >> > using the command line `clang++ -g -O0 -S -emit-llvm foo.cpp`, we get<br>
>> >> >> > below IR<br>
>> >> >> ><br>
>> >> >> > -----------<br>
>> >> >> > ; ModuleID = 'foo.cpp'<br>
>> >> >> > source_filename = "foo.cpp"<br>
>> >> >> > target datalayout =<br>
>> >> >> > "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"<br>
>> >> >> > target triple = "x86_64-unknown-linux-gnu"<br>
>> >> >> ><br>
>> >> >> > ; Function Attrs: noinline nounwind optnone uwtable<br>
>> >> >> > define dso_local void @_Z3foov() #0 !dbg !7 {<br>
>> >> >> > ret void, !dbg !10<br>
>> >> >> > }<br>
>> >> >> ><br>
>> >> >> > attributes #0 = { noinline nounwind optnone uwtable<br>
>> >> >> > "correctly-rounded-divide-sqrt-fp-math"="false"<br>
>> >> >> > "disable-tail-calls"="false" "frame-pointer"="all"<br>
>> >> >> > "less-precise-fpmad"="false" "min-legal-vector-width"="0"<br>
>> >> >> > "no-infs-fp-math"="false" "no-jump-tables"="false"<br>
>> >> >> > "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false"<br>
>> >> >> > "no-trapping-math"="false" "stack-protector-buffer-size"="8"<br>
>> >> >> > "target-cpu"="x86-64"<br>
>> >> >> > "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87"<br>
>> >> >> > "unsafe-fp-math"="false" "use-soft-float"="false" }<br>
>> >> >> ><br>
>> >> >> > !<a href="http://llvm.dbg.cu" rel="noreferrer" target="_blank">llvm.dbg.cu</a> = !{!0}<br>
>> >> >> > !llvm.module.flags = !{!3, !4, !5}<br>
>> >> >> > !llvm.ident = !{!6}<br>
>> >> >> ><br>
>> >> >> > !0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file:<br>
>> >> >> > !1, producer: "clang version 11.0.0<br>
>> >> >> > (<a href="https://github.com/llvm/llvm-project" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project</a><br>
>> >> >> > 9e0b52e2e68412a9a2add18697f4246e5e5ee5e3)", isOptimized: false,<br>
>> >> >> > runtimeVersion: 0, emissionKind: FullDebug, enums: !2,<br>
>> >> >> > splitDebugInlining: false, nameTableKind: None)<br>
>> >> >> > !1 = !DIFile(filename: "foo.cpp", directory:<br>
>> >> >> > "/home/mahesha/ROCm/issues/hipclang/other/crash/foo")<br>
>> >> >> > !2 = !{}<br>
>> >> >> > !3 = !{i32 7, !"Dwarf Version", i32 4}<br>
>> >> >> > !4 = !{i32 2, !"Debug Info Version", i32 3}<br>
>> >> >> > !5 = !{i32 1, !"wchar_size", i32 4}<br>
>> >> >> > !6 = !{!"clang version 11.0.0 (<a href="https://github.com/llvm/llvm-project" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project</a><br>
>> >> >> > 9e0b52e2e68412a9a2add18697f4246e5e5ee5e3)"}<br>
>> >> >> > !7 = distinct !DISubprogram(name: "foo", linkageName: "_Z3foov",<br>
>> >> >> > scope: !1, file: !1, line: 1, type: !8, scopeLine: 1, flags:<br>
>> >> >> > DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0,<br>
>> >> >> > retainedNodes: !2)<br>
>> >> >> > !8 = !DISubroutineType(types: !9)<br>
>> >> >> > !9 = !{null}<br>
>> >> >> > !10 = !DILocation(line: 2, column: 1, scope: !7)<br>
>> >> >> > -----------<br>
>> >> >> ><br>
>> >> >> > Now, let's say, in the above IR file, I intentionally make debug info<br>
>> >> >> > metadata, a kind of invalid, by removing the field 'unit` and by<br>
>> >> >> > changing the field `spFlags` from `DISPFlagDefinition` to<br>
>> >> >> > `DISPFlagOptimized` within metadata info !7 as shown below.<br>
>> >> >> ><br>
>> >> >> > -----------<br>
>> >> >> > ; ModuleID = 'foo.cpp'<br>
>> >> >> > source_filename = "foo.cpp"<br>
>> >> >> > target datalayout =<br>
>> >> >> > "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"<br>
>> >> >> > target triple = "x86_64-unknown-linux-gnu"<br>
>> >> >> ><br>
>> >> >> > ; Function Attrs: noinline nounwind optnone uwtable<br>
>> >> >> > define dso_local void @_Z3foov() #0 !dbg !7 {<br>
>> >> >> > ret void<br>
>> >> >> > }<br>
>> >> >> ><br>
>> >> >> > attributes #0 = { noinline nounwind optnone uwtable<br>
>> >> >> > "correctly-rounded-divide-sqrt-fp-math"="false"<br>
>> >> >> > "disable-tail-calls"="false" "frame-pointer"="all"<br>
>> >> >> > "less-precise-fpmad"="false" "min-legal-vector-width"="0"<br>
>> >> >> > "no-infs-fp-math"="false" "no-jump-tables"="false"<br>
>> >> >> > "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false"<br>
>> >> >> > "no-trapping-math"="false" "stack-protector-buffer-size"="8"<br>
>> >> >> > "target-cpu"="x86-64"<br>
>> >> >> > "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87"<br>
>> >> >> > "unsafe-fp-math"="false" "use-soft-float"="false" }<br>
>> >> >> ><br>
>> >> >> > !<a href="http://llvm.dbg.cu" rel="noreferrer" target="_blank">llvm.dbg.cu</a> = !{!0}<br>
>> >> >> > !llvm.module.flags = !{!3, !4, !5}<br>
>> >> >> > !llvm.ident = !{!6}<br>
>> >> >> ><br>
>> >> >> > !0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file:<br>
>> >> >> > !1, producer: "clang version 11.0.0<br>
>> >> >> > (<a href="https://github.com/llvm/llvm-project" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project</a><br>
>> >> >> > 9e0b52e2e68412a9a2add18697f4246e5e5ee5e3)", isOptimized: false,<br>
>> >> >> > runtimeVersion: 0, emissionKind: FullDebug, enums: !2,<br>
>> >> >> > splitDebugInlining: false, nameTableKind: None)<br>
>> >> >> > !1 = !DIFile(filename: "foo.cpp", directory:<br>
>> >> >> > "/home/mahesha/ROCm/issues/hipclang/other/crash/foo")<br>
>> >> >> > !2 = !{}<br>
>> >> >> > !3 = !{i32 7, !"Dwarf Version", i32 4}<br>
>> >> >> > !4 = !{i32 2, !"Debug Info Version", i32 3}<br>
>> >> >> > !5 = !{i32 1, !"wchar_size", i32 4}<br>
>> >> >> > !6 = !{!"clang version 11.0.0 (<a href="https://github.com/llvm/llvm-project" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project</a><br>
>> >> >> > 9e0b52e2e68412a9a2add18697f4246e5e5ee5e3)"}<br>
>> >> >> > !7 = distinct !DISubprogram(name: "foo", linkageName: "_Z3foov",<br>
>> >> >> > scope: !1, file: !1, line: 1, type: !8, scopeLine: 1, flags:<br>
>> >> >> > DIFlagPrototyped, spFlags: DISPFlagOptimized, retainedNodes: !2)<br>
>> >> >> > !8 = !DISubroutineType(types: !9)<br>
>> >> >> > !9 = !{null}<br>
>> >> >> > !10 = !DILocation(line: 2, column: 1, scope: !7)<br>
>> >> >> > -----------<br>
>> >> >> ><br>
>> >> >> > Now, if I compile the above modified IR file using LLC, then LLC<br>
>> >> >> > crashes as below. The crash point is<br>
>> >> >> > <a href="https://github.com/llvm/llvm-project/blob/master/llvm/lib/CodeGen/LexicalScopes.cpp#L53" rel="noreferrer" target="_blank">https://github.com/llvm/llvm-project/blob/master/llvm/lib/CodeGen/LexicalScopes.cpp#L53</a>.<br>
>> >> >> > Reason for crash is `NULL` pointer access. `DISubprogram::getUnit()`<br>
>> >> >> > returns `NULL` pointer since there is no `unit` field in the related<br>
>> >> >> > metadata info.<br>
>> >> >> ><br>
>> >> >> > -----------<br>
>> >> >> > PLEASE submit a bug report to <a href="https://bugs.llvm.org/" rel="noreferrer" target="_blank">https://bugs.llvm.org/</a> and include the<br>
>> >> >> > crash backtrace.<br>
>> >> >> > Stack dump:<br>
>> >> >> > 0. Program arguments: /opt/rocm/llvm/bin/llc foo.ll<br>
>> >> >> > 1. Running pass 'Function Pass Manager' on module 'foo.ll'.<br>
>> >> >> > 2. Running pass 'Debug Variable Analysis' on function '@_Z3foov'<br>
>> >> >> > #0 0x0000556017a2aa8a llvm::sys::PrintStackTrace(llvm::raw_ostream&)<br>
>> >> >> > (/opt/rocm/llvm/bin/llc+0x1883a8a)<br>
>> >> >> > #1 0x0000556017a28854 llvm::sys::RunSignalHandlers()<br>
>> >> >> > (/opt/rocm/llvm/bin/llc+0x1881854)<br>
>> >> >> > #2 0x0000556017a289a3 SignalHandler(int) (/opt/rocm/llvm/bin/llc+0x18819a3)<br>
>> >> >> > #3 0x00007fdb38654890 __restore_rt<br>
>> >> >> > (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)<br>
>> >> >> > #4 0x0000556016f013ea<br>
>> >> >> > llvm::LexicalScopes::initialize(llvm::MachineFunction const&)<br>
>> >> >> > (/opt/rocm/llvm/bin/llc+0xd5a3ea)<br>
>> >> >> > #5 0x0000556016f224dd<br>
>> >> >> > llvm::LiveDebugVariables::runOnMachineFunction(llvm::MachineFunction&)<br>
>> >> >> > (/opt/rocm/llvm/bin/llc+0xd7b4dd)<br>
>> >> >> > #6 0x0000556016fcb2b0<br>
>> >> >> > llvm::MachineFunctionPass::runOnFunction(llvm::Function&)<br>
>> >> >> > (/opt/rocm/llvm/bin/llc+0xe242b0)<br>
>> >> >> > #7 0x0000556017375e8f<br>
>> >> >> > llvm::FPPassManager::runOnFunction(llvm::Function&)<br>
>> >> >> > (/opt/rocm/llvm/bin/llc+0x11cee8f)<br>
>> >> >> > #8 0x0000556017376581 llvm::FPPassManager::runOnModule(llvm::Module&)<br>
>> >> >> > (/opt/rocm/llvm/bin/llc+0x11cf581)<br>
>> >> >> > #9 0x0000556017376981<br>
>> >> >> > llvm::legacy::PassManagerImpl::run(llvm::Module&)<br>
>> >> >> > (/opt/rocm/llvm/bin/llc+0x11cf981)<br>
>> >> >> > #10 0x000055601662496a main (/opt/rocm/llvm/bin/llc+0x47d96a)<br>
>> >> >> > #11 0x00007fdb372e8b97 __libc_start_main<br>
>> >> >> > /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0<br>
>> >> >> > #12 0x000055601668f2ea _start (/opt/rocm/llvm/bin/llc+0x4e82ea)<br>
>> >> >> > -----------<br>
>> >> >> ><br>
>> >> >> > QUESTION IS: Is this expected behavior? OR should LLC throw an error<br>
>> >> >> > and abort compilation? OR at the crash point, we are suppose to test<br>
>> >> >> > `nullity` of `DISubprogram::getUnit()` before accessing it?<br>
>> >> >> ><br>
>> >> >> > --<br>
>> >> >> > Thanks,<br>
>> >> >> > Mahesha<br>
>> >> >> > _______________________________________________<br>
>> >> >> > LLVM Developers mailing list<br>
>> >> >> > <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> >> >> > <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > --<br>
>> >> > Thanks,<br>
>> >> > Mahesha<br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Thanks,<br>
>> > Mahesha<br>
><br>
><br>
><br>
> --<br>
> Thanks,<br>
> Mahesha<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><font face="trebuchet ms, sans-serif">Thanks,</font><div><font face="trebuchet ms, sans-serif">Mahesha</font></div></div></div></div>