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 we should do it now, just saying Clang should have no > more deps on the old DIFactory to avoid header pollution, since it's > only on one enum... ;) > > cheers, > --renato >A couple of other questions about DIBuilder: 1) I notice that there's no 'isMain' parameter to CreateCompileUnit. How do you specify the main module? 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. -- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110218/5f76dee6/attachment.html>
On 19 February 2011 04:31, Talin <viridia at gmail.com> wrote:> A couple of other questions about DIBuilder: > 1) I notice that there's no 'isMain' parameter to CreateCompileUnit. How do > you specify the main module? > 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.A few more concerns: By putting the copy ctor in private, I can't define a DIBuilder in a context and assign it later with a respective module (or re-assign it for that matter). To overcome this, I've created a pointer to a DIBuilder and only create it when I have the module information. I have to do this because the front-end is not in C++, so I can't use the ctor init trick on DIBuilder like clang does. But that seems to be getting in the way of the DIDescriptor "operator MDNode *" or whatever is converting a DIDescriptor into a Value* in the code below (CGDebugInfo.cpp): llvm::Value *Subscript = DBuilder.GetOrCreateSubrange(0, NumElems); since GetOrCreateSubrange() returns a DISubrange (not a pointer) both in DIFactory and DIBuilder. Any pointers? (pardon the pun) -- cheers, --renato
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 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 difficult. Can you change it to accept a list of DIDescriptors rather than Value*? I think for the metadata it doesn't make any difference and in the back-end you can always convert it. cheers, --renato