Op 21-3-2018 om 10:28 schreef Evgeny Leviant:> It looks the problem lies in how your compiler generates debug info. LLVM doesn't > expect DIDerivedType scope to be an instance of DICompileUnit. Here is a quick fix: > > DIE *DwarfUnit::getOrCreateContextDIE(const DIScope *Context) { > - if (!Context || isa<DIFile>(Context)) > + if (!Context || isa<DIFile>(Context) || isa<DICompileUnit>(Context)) > > However, I suggest talking to someone with in-depth debug info experience, as the problem > itself seems to be not related to LTO.The problem seems to be related to that but it *does* support some DICompileUnits, just not this particular one, I stepped through this code and it gets a DICompileUnit often enough. Somehow during LTO/merging I get a type that has a different DICompileUnit than where the variable is defined, and it's not liking it.
Evgeny Leviant via llvm-dev
2018-Mar-21 10:58 UTC
[llvm-dev] lld/lto/win32 crash on DIE code
Ok, I've done a bit more investigation. I found the module which declares broken DIE (e54b3dc8c0536e29a65f8548b5ae7958-Global.o) and here is what I found there: !2 = !DIFile(filename: "island.windows.elements", ... ... !4 = distinct !DICompileUnit(language: DW_LANG_C99, file: !5, ... !5 = !DIFile(filename: "island.windows.elements-e54b3dc8c0536e29a65f8548b5ae7958-global", ... All subsequent DIEs reference file !2, except DICompileUnit (!4) which references file !5. This seems a bit strange for me. Can't this be a root cause of your problems? ________________________________________ От: Carlo Kok <ck at remobjects.com> Отправлено: 21 марта 2018 г. 12:31 Кому: Evgeny Leviant; llvm-dev at lists.llvm.org Тема: Re: [llvm-dev] lld/lto/win32 crash on DIE code Op 21-3-2018 om 10:28 schreef Evgeny Leviant:> It looks the problem lies in how your compiler generates debug info. LLVM doesn't > expect DIDerivedType scope to be an instance of DICompileUnit. Here is a quick fix: > > DIE *DwarfUnit::getOrCreateContextDIE(const DIScope *Context) { > - if (!Context || isa<DIFile>(Context)) > + if (!Context || isa<DIFile>(Context) || isa<DICompileUnit>(Context)) > > However, I suggest talking to someone with in-depth debug info experience, as the problem > itself seems to be not related to LTO.The problem seems to be related to that but it *does* support some DICompileUnits, just not this particular one, I stepped through this code and it gets a DICompileUnit often enough. Somehow during LTO/merging I get a type that has a different DICompileUnit than where the variable is defined, and it's not liking it.
Thanks!
Unfortunately this doesn't seem to cause it, because when I fix it to
match the other files (and pretty much how clang emits it:)
!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
!1 = !DIGlobalVariable(name: "IDispatch_UID", linkageName:
"f_t2b_RemObjects_d_Elements_d_System_d_____Global.IDispatchUID",
scope:
!2, file: !3, type: !622, isLocal: false, isDefinition: true)
!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer:
"RemObjects Island", isOptimized: true, runtimeVersion: 0,
emissionKind:
FullDebug, enums: !4, retainedTypes: !4, globals: !5, imports: !703)
!3 = !DIFile(filename:
"island.windows.elements-e54b3dc8c0536e29a65f8548b5ae7958-global",
directory:
"/__windows_drive__c/ci/b/elements/1301/source/islandrtl/source")
!4 = !{}
!5 = !{!0, !6, !620, !635, !637, !639, !660, !669, !671, !673, !675,
!680, !682, !684}
!6 = !DIGlobalVariableExpression(var: !7, expr: !DIExpression())
!7 = !DIGlobalVariable(name: "IDispatch_VMT", linkageName:
"f_t2b_RemObjects_d_Elements_d_System_d_____Global.IDispatchVMT",
scope:
!2, file: !3, type: !8, isLocal: false, isDefinition: true)
It still crashes. Same callstack.
Note that all these .o files individually compile file, it's only when I
let the linker lto-merge them things go wrong for me.
(updated https://www.dropbox.com/s/n3e2eystps9qvwx/repro.tar?dl=0 to
reflect above)
Op 21-3-2018 om 11:58 schreef Evgeny Leviant:> Ok, I've done a bit more investigation. I found the module which
declares broken DIE
> (e54b3dc8c0536e29a65f8548b5ae7958-Global.o) and here is what I found there:
>
> !2 = !DIFile(filename: "island.windows.elements", ...
> ...
> !4 = distinct !DICompileUnit(language: DW_LANG_C99, file: !5, ...
> !5 = !DIFile(filename:
"island.windows.elements-e54b3dc8c0536e29a65f8548b5ae7958-global", ...
>
> All subsequent DIEs reference file !2, except DICompileUnit (!4) which
references file !5. This seems a bit
> strange for me. Can't this be a root cause of your problems?
>
> ________________________________________
> От: Carlo Kok <ck at remobjects.com>
> Отправлено: 21 марта 2018 г. 12:31
> Кому: Evgeny Leviant; llvm-dev at lists.llvm.org
> Тема: Re: [llvm-dev] lld/lto/win32 crash on DIE code
>
> Op 21-3-2018 om 10:28 schreef Evgeny Leviant:
>> It looks the problem lies in how your compiler generates debug info.
LLVM doesn't
>> expect DIDerivedType scope to be an instance of DICompileUnit. Here is
a quick fix:
>>
>> DIE *DwarfUnit::getOrCreateContextDIE(const DIScope *Context) {
>> - if (!Context || isa<DIFile>(Context))
>> + if (!Context || isa<DIFile>(Context) ||
isa<DICompileUnit>(Context))
>>
>> However, I suggest talking to someone with in-depth debug info
experience, as the problem
>> itself seems to be not related to LTO.
>
> The problem seems to be related to that but it *does* support some
> DICompileUnits, just not this particular one, I stepped through this
> code and it gets a DICompileUnit often enough. Somehow during
> LTO/merging I get a type that has a different DICompileUnit than where
> the variable is defined, and it's not liking it.
>