similar to: [LLVMdev] DebugFactory

On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com> wrote: > On Tue, Sep 22, 2009 at 12:14 AM, Talin <viridia at gmail.com> wrote: >> So, one feature of the late, lamented DebugInfoBuilder that I am missing >> quite badly, and which is not available in the current DIFactory, is the >> ability to specify structure offsets abstractly. The

On Tue, Sep 22, 2009 at 12:14 AM, Talin <viridia at gmail.com> wrote: > So, one feature of the late, lamented DebugInfoBuilder that I am missing > quite badly, and which is not available in the current DIFactory, is the > ability to specify structure offsets abstractly. The DebugFactory > requires that you pass in structure offset information as ints, whereas >

On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com>wrote: > On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com> > wrote: > > On Tue, Sep 22, 2009 at 12:14 AM, Talin <viridia at gmail.com> wrote: > >> So, one feature of the late, lamented DebugInfoBuilder that I am missing > >> quite badly, and which is not

On Tue, Sep 22, 2009 at 4:49 PM, Talin <viridia at gmail.com> wrote: > > > On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com> > wrote: >> >> On Tue, Sep 22, 2009 at 9:21 AM, Devang Patel <devang.patel at gmail.com> >> wrote: >> > On Tue, Sep 22, 2009 at 12:14 AM, Talin <viridia 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: >>> >>> // Calculate the size of the specified LLVM type. >>> Constant * DebugInfoBuilder::getSize(const Type * type) { >>>    Constant * one =

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 = ConstantInt::get(Type::Int32Ty, 1); >> return ConstantExpr::getPtrToInt( >>

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 = ConstantInt::get(Type::Int32Ty, 1); > return ConstantExpr::getPtrToInt( > ConstantExpr::getGetElementPtr( > ConstantPointerNull::get(PointerType::getUnqual(type)), >

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

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:

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

The old patch works, it's just that when you pass "0, 0, 0" for size, align and offset the compiler can't decide which method to call since "0" can be either a pointer or an integer. I can produce a new patch if you like, but I'm having trouble thinking of good names for the new methods. Alternatively, I suppose we could re-arrange the order of the parameters

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 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. As far as I remember (from the 2010 meeting), the idea was to replace and deprecate DIFactory. I'm not saying we

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

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.

Looking at DebugInfo.h, there are a couple of minor features that DebugInfoBuilder that I would miss: 1) The ability to pass in an LLVM type and have it figure out the size, alignment, etc. without having to explicitly pass those values in as parameters to the builder call. 2) The ability for the size & alignment to be specified as Constants rather than as int64 so that the "gep

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 Jan 7, 2009, at 1:48 PM, Talin wrote: > Fine by me :) Is it ok to remove DebugInfoBuilder now? I don't think that anything in the tree is using it, what do you think Talin? -Chris > > > On Wed, Jan 7, 2009 at 1:35 PM, Chris Lattner <clattner at apple.com> > wrote: > > On Jan 7, 2009, at 3:22 AM, Patrick Boettcher wrote: > > > Hi list, > >

DebugInfo.h is very light weight interface that allows one to manipulate llvm values that holds debugging information directly. On Jan 7, 2009, at 3:22 PM, Talin wrote: > Looking at DebugInfo.h, there are a couple of minor features that > DebugInfoBuilder that I would miss: > > 1) The ability to pass in an LLVM type and have it figure out the > size, alignment, etc. without