llvm dev - Jun 2020 - 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>

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

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>