search for: dicompileunit

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-de...

I'm looking at cases of disagreement between assertions in the backend and what the Verifier checks for (for http://reviews.llvm.org/D16083). One of these seems to be the question of whether a DISuprogram may exist without a DICompileUnit. Currently the Verifier doesn't care, but there are a few assertions to this extent in the backend. Possible options are: 1) A DISubprogram may exist without a DICompileUnit (what would we have to change in the backend?) 2) A DISubprogram's scope may be null, but only if there's a DICo...

...:) !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",...

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...

...u, Oct 1, 2009 at 8:34 PM, Talin <viridia at gmail.com> wrote: > Here is a patch that does just that. This does not work. I'm getting llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp: In member function ‘llvm::DIType clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::QualType, llvm::DICompileUnit)’: /Users/yash/clean/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:225: error: call of overloaded ‘CreateDerivedType(unsigned int&, llvm::DICompileUnit&, const char [1], llvm::DICompileUnit, int, int, int, int, int, llvm::DIType&)’ is ambiguous llvm/include/llvm/Analysis/DebugInfo.h:530:...

Hello, One of my Julia programs failed to execute with the following error, DICompileUnit not listed in llvm.dbg.cu !11 = distinct !DICompileUnit(language: DW_LANG_C89, file: !3, producer: "julia", isOptimized: true, runtimeVersion: 0,emissionKind: FullDebug, enums : !12) This was generated by verifyModule(*GPUModule,&(llvm::errs())From whithin PPCGCodeGeneration.cpp in P...

...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", dire...

...as anyone's radar (it's not something I'll be pushing on myself in the near future, but just wanted to see if the idea was already out there, etc): Why are there DIGlobalVariableExpressions that are both attached as !dbg metadata on llvm::GlobalVariables, and in the globals() list of a DICompileUnit? I would've thought, ideally, a DIGlobalVariableExpression would be mutually exclusively in one place or the other - the only ones in the globals() list of a DICompileUnit would be the constant values, that have no place elsewhere. When the storage for a global is optimized away, it'd be po...

That's because instructions have a location associated with them, not a compile unit. -eric On Thu, Oct 4, 2012 at 12:46 PM, George Baah <georgebaah at gmail.com> wrote: > I used DILocation instead of DICompileUnit and it works. Hmmm, interesting. > > George > > On Thu, Oct 4, 2012 at 1:33 AM, George Baah <georgebaah at gmail.com> wrote: >> >> Here is the code. I am running on llvm 3.1 on Lion (Mac 10.7.4) >> >> string getFileDirectory(const Instruction &I){ >&...

...iridia at gmail.com> wrote: > > Here is a patch that does just that. > > This does not work. I'm getting > > llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp: In member function > ‘llvm::DIType > clang::CodeGen::CGDebugInfo::CreateQualifiedType(clang::QualType, > llvm::DICompileUnit)’: > /Users/yash/clean/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:225: > error: call of overloaded ‘CreateDerivedType(unsigned int&, > llvm::DICompileUnit&, const char [1], llvm::DICompileUnit, int, int, > int, int, int, llvm::DIType&)’ is ambiguous > llvm/include/llvm/...

Here is the code. I am running on llvm 3.1 on Lion (Mac 10.7.4) *string getFileDirectory*(*const* Instruction &I){ MDNode *MD = I.getMetadata("dbg"); DICompileUnit compileUnit(MD); return compileUnit.getDirectory().str(); } George On Wed, Oct 3, 2012 at 12:40 PM, Eric Christopher <echristo at gmail.com>wrote: > Without knowing the code that you've written and the IR that you're > running on I'm > not sure what I can do to help...

...as under the mistaken impression that the DISubprogram's scope would have to be the compile unit, but it seems we also currently allow it to be a DIFile (or any other kind of scope). In that case, I suppose the behavior that the backend expects is that every DISubprogram is referenced from some DICompileUnit contained in llvm.dbg.cu. I'll implement a Verifier pass to that extent. Two things I remember: 1. There's difference between subprogram definitions and subprogram declarations. Declarations seem to just be part of the type hierarchy. 2. Subprogram definitions need to be referenced from t...

You should probably think of the DIFooBar constructors like reinterpret-casts, not "go find the thing I actually want" functions. If you hand DICompileUnit() a node that is not a compile-unit metadata node, it's not going to tell you that you goofed. If you _did_ have a CU metadata node, then DICompileUnit's getDirectory() would work just fine. But you don't. --paulr ________________________________ From: llvmdev-bounces at cs.uiu...

All, I'm seeing duplication of DICompileUnits in a pass that worked in 3.8. I assume I'm doing something wrong. Would someone be willing to point me in the right direction? The below minimized pass reproduces my issue in 4.0 with the following error: DICompileUnit not listed in llvm.dbg.cu !1707 = distinct !DICompileUnit(language: DW_LA...

Thank you. What I need to do to address this? Open an issue on bugs.llvm.org? I'm not sure what the fix needs to be in the cloner. On Thu, Jun 8, 2017 at 4:19 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > There have in the past been bugs in the cloner involving duplicate > DICompileUnits (see e.g. https://reviews.llvm.org/D29240), this one may > need a similar fix. > > Peter > > On Thu, Jun 8, 2017 at 3:07 PM, Matthew O'Connor via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> All, >> >> I'm seeing duplication of DICompile...

...Christopher <echristo at gmail.com> wrote: > That's because instructions have a location associated with them, not > a compile unit. > > -eric > > On Thu, Oct 4, 2012 at 12:46 PM, George Baah <georgebaah at gmail.com> wrote: > > I used DILocation instead of DICompileUnit and it works. Hmmm, > interesting. > > > > George > > > > On Thu, Oct 4, 2012 at 1:33 AM, George Baah <georgebaah at gmail.com> > wrote: > >> > >> Here is the code. I am running on llvm 3.1 on Lion (Mac 10.7.4) > >> > >> string...

...ble -> GlobalVariable edge, which should hopefully clear the way for removing the llvm.dbg.cu named metadata node. > > Not to spoil all the fun, but I’m not sure if this will bring us much closer to removing the llvm.dbg.cu node. The reason the llvm.dbg.cu node exits is so we can find all DICompileUnits, because the DICompileUnit holds debug info that is not referenced by any IR. This includes things like DIImportedEntity (think C++ “using”), enums, and macros. I understand the fact that DICompileUnit holds debug information that are useful and not referenced directly from the IR. What I wonder...

...t 07:34 PM, David Blaikie via llvm-dev wrote: > On Sat, Mar 11, 2017 at 3:10 AM SANJAY SRIVALLABH SINGAPURAM via llvm-dev > < > llvm-dev at lists.llvm.org> wrote: > > > Hello, > > > > One of my Julia programs failed to execute with the following error, > > DICompileUnit not listed in llvm.dbg.cu > > !11 = distinct !DICompileUnit(language: DW_LANG_C89, file: !3, producer: > > "julia", isOptimized: true, runtimeVersion: 0,emissionKind: FullDebug, > > enums: !12) > > > > This was generated by verifyModule(*GPUModule,&(llvm:...

I used DILocation instead of DICompileUnit and it works. Hmmm, interesting. George On Thu, Oct 4, 2012 at 1:33 AM, George Baah <georgebaah at gmail.com> wrote: > Here is the code. I am running on llvm 3.1 on Lion (Mac 10.7.4) > > *string getFileDirectory*(*const* Instruction &I){ > > MDNode *MD = I.getMetadata(...

...rk. Now all I need is for the methods of DIFactory to take a > Constant* instead of uint64. ok. Feel free to add /// CreateBasicType - Create a basic type like int, float, etc. DIBasicType CreateBasicType(DIDescriptor Context, const std::string &Name, DICompileUnit CompileUnit, unsigned LineNumber, uint64_t SizeInBits, uint64_t AlignInBits, uint64_t OffsetInBits, unsigned Flags, unsigned Encoding); variants that take Constant*, for example, /// CreateBasicTyp...