search for: didescriptors

On 14 July 2010 18:21, Devang Patel <devang.patel at gmail.com> wrote: > Use Create* methods to create basic debug info. There is not any > tutorial document explaining how 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 >

On Wed, Jul 14, 2010 at 1:04 PM, Renato Golin <rengolin at systemcall.org> wrote: > On 14 July 2010 18:21, Devang Patel <devang.patel at gmail.com> wrote: >> Use Create* methods to create basic debug info. There is not any >> tutorial document explaining how to generated basic debug info. > > I got that far... ;) > > I could prepare a how-to when I'm

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

On Wed, Jul 14, 2010 at 8:34 AM, Renato Golin <rengolin at systemcall.org> wrote: > Hi All, > > Is there any documentation on how to use DIFactory to generate basic debug info? Use Create* methods to create basic debug info. There is not any tutorial document explaining how to generated basic debug info. > > It seems similar enough to IRBuilder but working with objects

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

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

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

On Wed, Sep 23, 2009 at 2:27 PM, Talin <viridia at gmail.com> wrote: > On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: >> >> On Sep 22, 2009, at 4:49 PM, Talin wrote: >>> >>> // Calculate the size of the specified LLVM type. >>> Constant * DebugInfoBuilder::getSize(const Type * type) { >>>    Constant * one =

On Thu, 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:

> 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

Hi I am not a good programmer but for my project i have to use llvm to generate CFG for c programs where i have a mapping from IR instruction in CFG to their respective c instruction. After surfing a in source of llvm i did the following change in printInstruction() function in llvm/lib/VMCore/AsmWriter.cpp file. .....void AssemblyWriter::printInstruction(const Instruction &I) { if

Here is a patch that does just that. On Wed, Sep 23, 2009 at 3:38 PM, Devang Patel <devang.patel at gmail.com>wrote: > On Wed, Sep 23, 2009 at 2:27 PM, Talin <viridia at gmail.com> wrote: > > On Wed, Sep 23, 2009 at 1:51 PM, Dan Gohman <gohman at apple.com> wrote: > >> > >> On Sep 22, 2009, at 4:49 PM, Talin wrote: > >>> > >>>

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

OK so the problem is that the compiler sees '0' and can't decide whether its an integer or a null pointer of type Constant *. I guess the new functions will have to have slightly different names. On Wed, Oct 7, 2009 at 9:50 AM, Devang Patel <devang.patel at gmail.com> wrote: > On Thu, Oct 1, 2009 at 8:34 PM, Talin <viridia at gmail.com> wrote: > > Here is a patch

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

Hello, I wonder if someone would know what is going on below. All of a sudden I’m getting this assertion thrown: Assertion failed: (New->getType() == getType() && "replaceAllUses of value with new value of different type!"), function replaceAllUsesWith, file /Users/meister/Development/externals-clasp/llvm36/lib/IR/Value.cpp, line 345. It’s happening when

On Tue, Sep 7, 2010 at 1:56 AM, Renato Golin <rengolin at systemcall.org>wrote: > On 6 September 2010 01:05, Talin <viridia at gmail.com> wrote: > > DISubprogram CodeGenerator::genDISubprogram(const FunctionDefn * fn, > (...) > > false /* isDefinition */, > (...) > > Hi Talin, > > The only difference from what I'm doing is that I only

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. That's what

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.