thr3ads.net - llvm dev - [llvm-dev] LLC crash while handling DEBUG info [Jun 2020]

If this information is useful, please help other people find it:
Share via:

Mahesha S via llvm-dev

2020-Jun-01 04:10 UTC

[llvm-dev] LLC crash while handling DEBUG info

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>

David Blaikie via llvm-dev

2020-Jun-01 04:16 UTC

head link

[llvm-dev] LLC crash while handling DEBUG info

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

Mahesha S via llvm-dev

2020-Jun-01 04:34 UTC

head link

[llvm-dev] LLC crash while handling DEBUG info

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>

llvm dev - Jun 2020 - LLC crash while handling DEBUG info

[llvm-dev] LLC crash while handling DEBUG info

[llvm-dev] LLC crash while handling DEBUG info

[llvm-dev] LLC crash while handling DEBUG info