search for: difactori

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

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

Hi All, DIFactory interface, part of DebugInfo.h, is used to emit LLVM IR constructs to encode debugging information. We are replacing this interface with new simple interface, DIBuilder. Here is one example that demonstrates differences between two interfaces. To create debug information entries to encode volatile type one would use following call in a language front end,

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

On Thu, Feb 24, 2011 at 1:29 PM, Devang Patel <dpatel at apple.com> wrote: > Hi All, > DIFactory interface, part of DebugInfo.h, is used to emit LLVM IR constructs > to encode debugging information. We are replacing this interface with new > simple interface, DIBuilder. > Here is one example that demonstrates differences between two interfaces. To > create debug information

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.

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 DebugInfoBuilder had "offsetOf" and "alignOf" methods, similar to the "sizeOf"

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

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

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

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

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

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.

On Feb 18, 2011, at 8:31 PM, Talin wrote: > 2) There's no means to set TheCU other than creating a new compile unit. This means that you have to generate all of the debug info for your module with a single DIBuilder instance, since there's no way to use a pre-existing compile unit. TheCU is an internal debug info information that FE should not care about. DIBuilder is meant to use for

On 21 February 2011 18:17, Devang Patel <dpatel at apple.com> wrote: > TheCU is an internal debug info information that FE should not care about. DIBuilder is meant to use for one translation unit by FE. If all the internal debug info information is exposed to FE then you'll get DIFactory. I agree, DIBuilder should not expose its internal structure. This is why, on a C-only world,

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