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,
CreateDerivedType(DW_TAG_volatile_type, Context, StringRef(), File,
0 /*line no*/, type_size_in_bits, type_align_in_bits,
0 /* offset */, 0 /* flags */, OriginalType);
using DIFactory interface. Now, DIBuilder allows you to do the same using
following call.
createQualifiedType(DW_TAG_volatile_type, OriginalType);
DIBuilder interface was introduced in Nov/Dec last year. Now, clang has fully
adopted this new interface. So we are going to remove DIFactory from llvm
sources soon. Our plan is to move DIFactory interface in dragonegg (and
llvm-gcc) for now until the front-ends adopt DIBuilder.
If you have any concerns about this plan, please speak up now.
-
Devang
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110224/7ef6c76d/attachment.html>
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 to encode volatile type one would use > following call in a language front end, > CreateDerivedType(DW_TAG_volatile_type, Context, StringRef(), File, > 0 /*line no*/, type_size_in_bits, > type_align_in_bits, > 0 /* offset */, 0 /* flags */, OriginalType); > using DIFactory interface. Now, DIBuilder allows you to do the same using > following call. > createQualifiedType(DW_TAG_volatile_type, OriginalType); > DIBuilder interface was introduced in Nov/Dec last year. Now, clang has > fully adopted this new interface. So we are going to remove DIFactory from > llvm sources soon. Our plan is to move DIFactory interface in dragonegg (and > llvm-gcc) for now until the front-ends adopt DIBuilder. > If you have any concerns about this plan, please speak up now.Assuming it has no impact on the actual dwarf tags, smaller code is better! -jason> - > Devang > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
On Feb 24, 2011, at 1:34 PM, Jason Kim wrote:> 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 to encode volatile type one would use >> following call in a language front end, >> CreateDerivedType(DW_TAG_volatile_type, Context, StringRef(), File, >> 0 /*line no*/, type_size_in_bits, >> type_align_in_bits, >> 0 /* offset */, 0 /* flags */, OriginalType); >> using DIFactory interface. Now, DIBuilder allows you to do the same using >> following call. >> createQualifiedType(DW_TAG_volatile_type, OriginalType); >> DIBuilder interface was introduced in Nov/Dec last year. Now, clang has >> fully adopted this new interface. So we are going to remove DIFactory from >> llvm sources soon. Our plan is to move DIFactory interface in dragonegg (and >> llvm-gcc) for now until the front-ends adopt DIBuilder. >> If you have any concerns about this plan, please speak up now. > > Assuming it has no impact on the actual dwarf tags,yup, that's true.> smaller code is better! > -jason > > >> - >> Devang >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >>
On 24/02/11 22:34, Jason Kim wrote:> 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 to encode volatile type one would use >> following call in a language front end, >> CreateDerivedType(DW_TAG_volatile_type, Context, StringRef(), File, >> 0 /*line no*/, type_size_in_bits, >> type_align_in_bits, >> 0 /* offset */, 0 /* flags */, OriginalType); >> using DIFactory interface. Now, DIBuilder allows you to do the same using >> following call. >> createQualifiedType(DW_TAG_volatile_type, OriginalType); >> DIBuilder interface was introduced in Nov/Dec last year. Now, clang has >> fully adopted this new interface. So we are going to remove DIFactory from >> llvm sources soon. Our plan is to move DIFactory interface in dragonegg (and >> llvm-gcc) for now until the front-ends adopt DIBuilder. >> If you have any concerns about this plan, please speak up now. > > Assuming it has no impact on the actual dwarf tags, smaller code is better! > -jasonIt does make me wonder how you are supposed to represent types which cannot be properly represented by LLVM types, for example structs with fields at variable offsets from the start and/or of variable size; or structs with fields that may or may not be present depending on the value of other fields. Such types occur in Ada for example. Ciao, Duncan.
On 24 February 2011 21:34, Jason Kim <jasonwkim at google.com> wrote:> On Thu, Feb 24, 2011 at 1:29 PM, Devang Patel <dpatel at apple.com> wrote:It simplified a bit type construction but the overall code did not reduce that much. It's still very similar to the previous style but had a few differences in the IR output. We had LIT tests that checked the IR and Dwarf and GDB execution and they failed in all levels more or less around December. This week I had time to finally refactor it and everything went back to normal (with lots of changes in the IR/Dwarf checks). To be honest, debugging metadata in IR is not trivial. You need to understand what's being built and how it gets used later, and for that you have to dig deep in the code, a problem that normal IR doesn't have. Not to mention the lack of validation on the parameters, metadata accepts anything you put in and the MDNode* behave almost like void*. But I have to say that the new DIBuilder is much closer to the metadata generated than the previous DIFactory, so maybe that'll get there in time... Great work Devang! It's really getting a lot nicer to build debug information. cheers, --renato