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. >
Evgeny Leviant via llvm-dev
2018-Mar-21 17:36 UTC
[llvm-dev] lld/lto/win32 crash on DIE code
Yep, it's once again variable and it's type using different scopes. Is there any strong reason why you set scope for global DIDerivedType? ________________________________________ От: Carlo Kok <ck at remobjects.com> Отправлено: 21 марта 2018 г. 18:22 Кому: Evgeny Leviant; llvm-dev at lists.llvm.org Тема: Re: [llvm-dev] lld/lto/win32 crash on DIE code 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. >
I thought I had to do that. I'll try without scope. Thanks! Evgeny Leviant <eleviant at accesssoftek.com> schreef op 21 maart 2018 18:36:26 CET:>Yep, it's once again variable and it's type using different scopes. >Is there any strong reason why you set scope for global DIDerivedType? >________________________________________ >От: Carlo Kok <ck at remobjects.com> >Отправлено: 21 марта 2018 г. 18:22 >Кому: Evgeny Leviant; llvm-dev at lists.llvm.org >Тема: Re: [llvm-dev] lld/lto/win32 crash on DIE code > >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. >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180321/b23523bf/attachment.html>
Op 21-3-2018 om 18:36 schreef Evgeny Leviant:> Yep, it's once again variable and it's type using different scopes. > Is there any strong reason why you set scope for global DIDerivedType?So I removed them all and everything works now. I'm still curious why it didn't work but since everything compiles now, so I can move on. Thank you! -- Carlo Kok