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 > GlobalVariable, now it uses MDNode. The idea is that debug info user > will only rely on DIDescriptor class hierarchy to manipulate debug > info. The classes in this hierarchy are light weight enough to pass > around as objects.The problem with that is that you can't do: DIDescriptor file = factory->CreateFile(...); You have to get the type of file to be DIFile. When creating a Subprogram, you can't pass a DIFile object, but only a DIDescriptor, so you have to: DIDescriptor* desc = &file; factory->CreateSubprogram(*desc, ...); Also, because they're not pointers, you can't use cast, as you would when passing arguments to IRBuilder. I understand that the objects are lightweight, thus the ability to pass them as objects, but some casting could be allowed, especially to DIDescriptor (copy ctor? new and assignment operators?).> Debug info is encoded in llvm IR as MDNodes. And all MDNodes from a > Module, just like any other llvm values, are automatically emitted > when the Module is written to a bitcode file.Weird, I wasn't getting the metadata before I started forcing ModuleDebugInfoPrinterPass via PassManager. Could be other changes I did, too, will check. -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
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 finished, if that interests you.sure> >> It is encapsulating how debug info is encoded. Earlier it was using >> GlobalVariable, now it uses MDNode. The idea is that debug info user >> will only rely on DIDescriptor class hierarchy to manipulate debug >> info. The classes in this hierarchy are light weight enough to pass >> around as objects. > > The problem with that is that you can't do: > > DIDescriptor file = factory->CreateFile(...); > > You have to get the type of file to be DIFile. > > When creating a Subprogram, you can't pass a DIFile object, but only a > DIDescriptor, so you have to: > > DIDescriptor* desc = &file; > factory->CreateSubprogram(*desc, ...); > > Also, because they're not pointers, you can't use cast, as you would > when passing arguments to IRBuilder. > > I understand that the objects are lightweight, thus the ability to > pass them as objects, but some casting could be allowed, especially to > DIDescriptor (copy ctor? new and assignment operators?).If it helps then go ahead add them.>> Debug info is encoded in llvm IR as MDNodes. And all MDNodes from a >> Module, just like any other llvm values, are automatically emitted >> when the Module is written to a bitcode file. > > Weird, I wasn't getting the metadata before I started forcing > ModuleDebugInfoPrinterPass via PassManager. Could be other changes I > did, too, will check.Make sure at least one regular llvm value is using these MDNodes. MDNodes are like Constants, if nobody is using them then they disappear magically. - Devang
On 14 July 2010 22:21, Devang Patel <devang.patel at gmail.com> wrote:>> I understand that the objects are lightweight, thus the ability to >> pass them as objects, but some casting could be allowed, especially to >> DIDescriptor (copy ctor? new and assignment operators?). > > If it helps then go ahead add them.Hi Devang, I've managed to make it work, so I can pass all sorts of DI* objects when a DIDescriptor is required, but now I also have to do the other way round and cast them back to DI*. This is getting a bit too ugly... Is there any strong reason to re-invent polymorphism here? The fact that the objects are light is not a reason, just an enabling fact. And they might grow bigger in the future, so there must be a strong underlying reason not to use pointers as IRBuilder does... But I can't figure it out... ;) -- cheers, --renato http://systemcall.org/ Reclaim your digital rights, eliminate DRM, learn more at http://www.defectivebydesign.org/what_is_drm
On 14 July 2010 22:21, Devang Patel <devang.patel at gmail.com> wrote:>> I understand that the objects are lightweight, thus the ability to >> pass them as objects, but some casting could be allowed, especially to >> DIDescriptor (copy ctor? new and assignment operators?). > > If it helps then go ahead add them.Hi Devang, I've sent the patch to llvm-commits, can you check if it's ok? cheers, --renato