search for: didescriptor

...ow to generated basic debug info. I got that far... ;) I could prepare a how-to when I'm finished, if that interests you. > It is encapsulating how debug info is encoded. Earlier it was using > GlobalVariable, now it uses MDNode. The idea is that debug info user > will only rely on DIDescriptor class hierarchy to manipulate debug > info. The classes in this hierarchy are light weight enough to pass > around as objects. The problem with that is that you can't do: DIDescriptor file = factory->CreateFile(...); You have to get the type of file to be DIFile. When creating a Su...

...t; I got that far... ;) > > I could prepare a how-to when I'm finished, if that interests you. sure > >> It is encapsulating how debug info is encoded. Earlier it was using >> GlobalVariable, now it uses MDNode. The idea is that debug info user >> will only rely on DIDescriptor class hierarchy to manipulate debug >> info. The classes in this hierarchy are light weight enough to pass >> around as objects. > > The problem with that is that you can't do: > > DIDescriptor file = factory->CreateFile(...); > > You have to get the type of fil...

...ill be > DITrivialType). > If you have opinions against it, please let me know, We haven't bothered using typed arrays in DebugInfo yet (as you say, we just have DIArray) so I have two thoughts 1) why does this one case need fixing/changing? Is it because we have things that aren't DIDescriptors inside the DIArray? (the strings that refer to types). Given how loosely typed DIDescriptor is (it doesn't check that it's a valid DIDescriptor) I assume this doesn't actually cause a problem, though it's certainly not nice. So we could just leave it as-is, pass DIArray's eleme...

...info. > > It seems similar enough to IRBuilder but working with objects (rather > than pointers) and that's raising some issues. It is encapsulating how debug info is encoded. Earlier it was using GlobalVariable, now it uses MDNode. The idea is that debug info user will only rely on DIDescriptor class hierarchy to manipulate debug info. The classes in this hierarchy are light weight enough to pass around as objects. It is on my wish list to enhance IRBuilder to cover functionality supported by DIFactory. If you're interested then patches are welcome in that direction! > Also, am I...

...gt;> >> We haven't bothered using typed arrays in DebugInfo yet (as you say, >> >> we just have DIArray) so I have two thoughts >> >> >> >> 1) why does this one case need fixing/changing? Is it because we have >> >> things that aren't DIDescriptors inside the DIArray? (the strings that >> >> refer to types). Given how loosely typed DIDescriptor is (it doesn't >> >> check that it's a valid DIDescriptor) I assume this doesn't actually >> >> cause a problem, though it's certainly not nice. So...

...ns against it, please let me know, >> >> We haven't bothered using typed arrays in DebugInfo yet (as you say, >> we just have DIArray) so I have two thoughts >> >> 1) why does this one case need fixing/changing? Is it because we have >> things that aren't DIDescriptors inside the DIArray? (the strings that >> refer to types). Given how loosely typed DIDescriptor is (it doesn't >> check that it's a valid DIDescriptor) I assume this doesn't actually >> cause a problem, though it's certainly not nice. So we could just >> leav...

Hi All, Is there any documentation on how to use DIFactory to generate basic debug info? It seems similar enough to IRBuilder but working with objects (rather than pointers) and that's raising some issues. Also, am I supposed to run the ModuleDebugInfoPrinterPass manually, or it gets printed automatically when I WriteBitcodeToFile? -- cheers, --renato http://systemcall.org/ Reclaim

...f, and getOffsetOf what >> you're looking for? >> > That will work. 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, uns...

...‘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: note: candidates are: llvm::DIDerivedType llvm::DIFactory::CreateDerivedType(unsigned int, llvm::DIDescriptor, llvm::StringRef, llvm::DICompileUnit, unsigned int, uint64_t, uint64_t, uint64_t, unsigned int, llvm::DIType) llvm/include/llvm/Analysis/DebugInfo.h:540: note: llvm::DIDerivedType llvm::DIFactory::CreateDerivedType(unsigned int, llvm::DIDescriptor, const std::string&, llvm::DICompileUnit, unsi...

> On 2015-Jan-19, at 12:38, Frédéric Riss <friss at apple.com> wrote: > > >> On Jan 19, 2015, at 12:04 PM, Christian Schafmeister <chris.schaf at verizon.net> wrote: >> >> >> I forgot to mention this in my initial email. >> >> The build of LLVM that I was using was commit a0d5d7aed8e177cea381b3d054d80c212ece9f2c >> The date on the

I'm getting close to executing the transition to the new debug info hierarchy. For reference, I've attached two WIP patches (which would be squashed before commit) and the WIP upgrade script I'm using. - transition-code.patch: Change the `DIDescriptor` hierarchy to lightweight wrappers around the subclasses of `DebugNode` (instead of rather heavier wrappers around `MDTuple`), and update `DIBuilder` to generate the right things. - transition-testcases.patch: Upgrade of testcases, entirely generated from the upgrade scr...

...<<"DN@"<<Dir; // mapping } // // Print out name if it exists........Code compiles well but i get following linking problem :(llvm[2]: Linking Debug+Asserts executable llvm-as/home/rangi/llvm/build/Debug+Asserts/lib/libLLVMCore.a(AsmWriter.o): In function `llvm::DIDescriptor::getUnsignedField(unsigned int) const':/home/rangi/llvm/include/llvm/Analysis/DebugInfo.h:70: undefined reference to `llvm::DIDescriptor::getUInt64Field(unsigned int) const'/home/rangi/llvm/build/Debug+Asserts/lib/libLLVMCore.a(AsmWriter.o): In function `DIScope':/home/rangi/llvm/includ...

...you're looking for? > >> > > That will work. 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, >...

...ed the template. I don't think I can use DICompileUnit, since (I'm guessing) only one of those are allowed per module. (Side note: I've never understood the relationship between DICompileUnit and DIFile. I'm guessing, however, that DICompileUnit acts like a container for all of the DIDescriptors within a module - that is, even if the DIDescriptor is referring to an external symbol, the compile unit for that descriptor is the module *containing* the reference, not the module of the *target* of the reference. DIFile, on the other hand, is I think the target. If this is not the case, then wh...

...ed int&, > llvm::DICompileUnit&, const char [1], llvm::DICompileUnit, int, int, > int, int, int, llvm::DIType&)’ is ambiguous > llvm/include/llvm/Analysis/DebugInfo.h:530: note: candidates are: > llvm::DIDerivedType llvm::DIFactory::CreateDerivedType(unsigned int, > llvm::DIDescriptor, llvm::StringRef, llvm::DICompileUnit, unsigned > int, uint64_t, uint64_t, uint64_t, unsigned int, llvm::DIType) > llvm/include/llvm/Analysis/DebugInfo.h:540: note: > llvm::DIDerivedType llvm::DIFactory::CreateDerivedType(unsigned int, > llvm::DIDescriptor, const std::string&, llvm:...

We still have access to types via MDNodes directly and the assertion that assumes all accesses to DITypes are accessing the resolved DIType will fire i.e assert(Ty == resolve(Ty.getRef())) One example is the access to DIType via DIArray in SubroutineType. If all elements in the type array are DITypes we can create a DITypeArray and use that for SubroutineType's type array instead. But we

...evelopment/externals-clasp/llvm36/lib/IR/Value.cpp, line 345. It’s happening when DIBuilder::finalize is being called at the end of a source file compilation. Here’s the most illuminating debugging information I could pull out of a frame: (lldb) frame #6: 0x0000000103a67c3e clasp_boehm_d`llvm::DIDescriptor::replaceAllUsesWith(this=0x00007fff5fb9e288, D=0x000000010985b330) + 254 at DebugInfo.cpp:399 396 MDNode *Node = const_cast<MDNode *>(DbgNode); 397 const MDNode *DN = D; 398 const Value *V = cast_or_null<Value>(DN); -> 399 Node->replaceAllUsesWith(const_cast&l...

...e of DIFile and DICompileUnit. Both of these are DIScopes, but it's not clear to me whether the symbols within a module should be the children of one or the other. Many of the DIFactory parameters take an explicit DIFile, so those cases are clear - but many of the other context params only have DIDescriptor as their type, so there's not a lot of guidance as to which is the right type of DIDescriptor to use. > > -- > cheers, > --renato > > http://systemcall.org/ > > Reclaim your digital rights, eliminate DRM, learn more at > http://www.defectivebydesign.org/what_is_drm &...

Talin, If there is a magic wand, I would be interested to know! DIDescriptor.Verify() is not suitable for you needs. It checks structure of encoded debug info after optimizer has modified the IR. Its main goal is inform Dwarf writer, at the end of code gen, which IR construct it should ignore. If you want to test code gen you have to link compiled code and run it regularly...

On Fri, Feb 18, 2011 at 1:52 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 18 February 2011 21:34, Talin <viridia at gmail.com> wrote: > > Sorry, I meant DIBuilder. > > DIBuilder is the new DIFactory. I've been playing with it this week > and it's much easier and straightforward to use. I'm still having > problems to create arrays, though.