search for: difactory

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 systemcall.org>wrote: > >> Seems the l...

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

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

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 should do it now, just saying...

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

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

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

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" trick, that would create the constants f...

..., 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 DebugFactory >> requires that you pass in structure offset information as ints, whereas >> DebugInfoBuilder had "offsetOf" and "alignOf" methods, similar to the >> "sizeOf" trick, t...

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 DIFactory into IRBuilder). BTW, DIFactory should be independent of a debugging format used by code generator. But until a target that implements for...

...for (ParameterList::const_iterator it = params.begin(); it != > > params.end(); ++it) { > > const ParameterDefn * param = *it; > > args.push_back(genDIParameterType(param->type())); > > } > > Don't do that. I know it looks right, but it's broken in DIFactory. > > > > DICompositeType fnType = dbgFactory_.CreateCompositeType( > > dwarf::DW_TAG_subroutine_type, > > dbgCompileUnit_, > > I use the file here, not the compile unit... But again, I could be wrong. > > Hope that puts you in the right direction. &...

...hen creating a function type > descriptor contains only the bare types, not types wrapped in a formal > parameter DIE. Hi Talin, Like in CGDebugInfo, you have to use the Subprogram type only for the return type. What gives you the parameters is passing the Function* as the last parameter on DIFactory.CreateSubprogram(). I suppose DIFactory was done tailored to C-like languages using Clang as the primary driver for changes. I'd not be surprised if you could do things that it didn't expect and then it'd generate images with bad Dwarf (enough to cause segfault in dwarfdump). I'd...

...e 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 anywhere. Reducing the test case is the best solution, but it might not be easy. Validating the MDNodes in DIFactory (or anywhere before DwarfDebug) would be a good step to ensure IR consistency and isolate problems. Unfortunately, it is the kind of thing that is not fundamental to get things working, so it always gets left behind... ;) -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, e...

...> 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 anywhere. > > Reducing the test case is the best solution, but it might not be easy. > > Validating the MDNodes in DIFactory (or anywhere before DwarfDebug) > would be a good step to ensure IR consistency and isolate problems. > Unfortunately, it is the kind of thing that is not fundamental to get > things working, so it always gets left behind... ;) > I understand your point and certainly acknowledge need...

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

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

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. > OK I switched all my stuff over to use DIBuilder, and you are right - the arrays don't work. Everything else does though. > &...

...ngle 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 one translation unit by FE. If all the internal debug info information is exposed to FE then you'll get DIFactory. - Devang

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, it's essential that you separate declaration from instantiation on DIBuilder. So far, it's been easy to do that with DIFactory (using a pointer to it), but DIBuilder's get-range makes it diff...

...evang 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 DebugFactory > >> requires that you pass in structure offset information as ints, whereas > >> DebugInfoBuilder had "offsetOf" and "alignOf" methods, similar to the > >> "s...