similar to: [LLVMdev] DIFactory

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

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

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

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 export debug symbols in definitions, not declarations. I may be doing wrong, though, for multi-file compilation (haven't tested

On Sun, Sep 5, 2010 at 1:02 PM, Renato Golin <rengolin at systemcall.org>wrote: > On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > > I've carefully studied the source code of CGDebugInfo in clang as a > working > > example. One puzzlement is that there's a discrepancy between what the > > "source level debugging with LLVM" docs

If llvm compiler mis compiles a code then it is unlikely to be a bug in IRBuilder. Most likely it could be a bug in FE's use of IRBuilder or codegen/optimization bug. In either case IRBuilder won't save you. Same is true for DIFactory. It is a utility to construct MDNodes. It does not strictly enforce semantic correctness of debug info. (In fact, it is on my list somewhere to absorb

Here are some issues that I am unclear about. What would be great is if the answers could be incorporated into the comments and documentation for DIFactory and DebugInfo.h: 1) What types of DIScope are valid arguments for DebugLoc::get()? The method takes an MDNode* argument, so looking at the function signature is no help. For example, DIFile is a subtype of DIScope, however looking at

On 5 September 2010 19:32, Talin <viridia at gmail.com> wrote: > I've carefully studied the source code of CGDebugInfo in clang as a working > example. One puzzlement is that there's a discrepancy between what the > "source level debugging with LLVM" docs say and what clang does: According > to the docs, DW_TAG_formal_parameter is used to specify a formal

I hate to be a nag, but after several days of working on this I am still utterly stumped. Let me recap the situation as it currently stands: I'm trying to write code that generates DWARF debugging information for my compiler using DIFactory and friends. Unfortunately the information I am generating appears to be invalid, but I can't figure out the cause. Based on the advice in the

On 7 September 2010 16:49, Devang Patel <dpatel at apple.com> wrote: > Your recent changes mentioned below would change correctness of debug info, > but it would unlikely to impact structure of DWARF generated. And somehow, > this structure is invalid in your case. I was hoping for a quick-fix on the assumptions of DwarfDebug about Subprograms' MDNodes, but it might be

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.

BTW, the reason I stopped responding to this thread is not because I solved the problem, but because I simply gave up and decided to work on other things for a while since I was making no progress. Having finished those other things (the stack crawler, for one), I'm hoping that time and a fresh start will yield better results. Unfortunately after about a day spent reviewing old llvm-dev

On Sun, Oct 10, 2010 at 9:54 AM, Talin <viridia at gmail.com> wrote: > BTW, the reason I stopped responding to this thread is not because I solved > the problem, but because I simply gave up and decided to work on other > things for a while since I was making no progress. Having finished those > other things (the stack crawler, for one), I'm hoping that time and a fresh >

On Sep 7, 2010, at 9:11 AM, Renato Golin wrote: > On 7 September 2010 16:49, Devang Patel <dpatel at apple.com> wrote: >> Your recent changes mentioned below would change correctness of debug info, >> but it would unlikely to impact structure of DWARF generated. And somehow, >> this structure is invalid in your case. > > I was hoping for a quick-fix on the

Seems the last use of DIFactory in LLVM/Clang is in: clang/lib/CodeGen/CGDebugInfo.cpp to get the enums llvm::DIFactory::OpDeref and llvm::DIFactory::OpPlus. Shouldn't this be moved to DIBuilder and remove the dependency completely? -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm

I didn't know DIFactory existed until you mentioned it just now. And if folks are adding brand new classes to LLVM, can we not follow the naming conventions in the developer guidelines? On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at systemcall.org>wrote: > Seems the last use of DIFactory in LLVM/Clang is in: > > clang/lib/CodeGen/CGDebugInfo.cpp to get the enums

Hi Devang, >> It does make me wonder how you are supposed to represent types which cannot >> be properly represented by LLVM types, for example structs with fields at >> variable offsets from the start and/or of variable size; or structs with >> fields that may or may not be present depending on the value of other fields. >> Such types occur in Ada for example. >

Sorry, I meant DIBuilder. On Fri, Feb 18, 2011 at 1:32 PM, Talin <viridia at gmail.com> wrote: > I didn't know DIFactory existed until you mentioned it just now. > > And if folks are adding brand new classes to LLVM, can we not follow the > naming conventions in the developer guidelines? > > On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at

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: