[patch] migrating DragonEgg to DIBuilder

[David Blaikie]

Oh. Right you are.


On Mon, Feb 18, 2013 at 12:36 AM, Charles Davis <cdavis5x at gmail.com> wrote:

> ENOPATCH
>
> Chip
>
> On Feb 18, 2013, at 1:23 AM, David Blaikie wrote:
>
> > In the interests of centralizing the debug info metadata generation in
> one place (DIBuilder) the following patches (to DragonEgg, LLVM (to add a
> minor breaking API change), & Clang (to update for the breaking change) -
> any non-interesting API changes necessary have already been committed).
> >
> > I'll be the first to admit that this is a fairly mechanical
> transformation, simply replacing the raw metadata generation inside
> DragonEgg's DIFactory with a nested DIBuilder. With further consideration
> it would be quite easy to remove DIFactory entirely & use DIBuilder
> directly. This would most obviously tidy up the switches in
> DIFactory::CreateCompositeType and DIFactory::CreateDerivedType.
> >
> > Beyond that there's a couple of finer points:
> > 1) DIBuilder needed to be "finalized" - I chose to put that in
> DIFactory's dtor and add code to clean up the DIFactory at the appropriate
> point
> > 2) there's one case of raw MDNode creation for debug info metadata - see
> the comment in the DragonEgg patch starting "FIXME: Remove this
> conditional". If you remove it you can see the failure with a test case
> involving a pointer-to-member-variable typedef. (it seems the call to
> getOrCreateType at line 953 maybe needs to look through
> pointer-to-member-variable & create the type of the member being pointed to
> - that was a bit more involved that I was comfortable fixing, but fix
> welcome)
> >
> > [side note: currently DragonEgg seems to produce all record types as
> "struct" debug info, never using "class" debug info - I'm sure this would
> account for several failures in the GDB test suite & some minor usability
> confusion for users
> >
> > There is one test I'm still regressing (& a few that have improved with
> this patch) in the GDB 7.5 test suite: gdb.opt/inline-locals.exp, but I
> think that's just luck. It was mostly failing already, for slightly
> different reasons previously.]
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130218/e1c9418f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dibuilder-dragonegg.diff
Type: application/octet-stream
Size: 35006 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130218/e1c9418f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dibuilder-dragonegg-llvm.diff
Type: application/octet-stream
Size: 2814 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130218/e1c9418f/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dibuilder-dragonegg-clang.diff
Type: application/octet-stream
Size: 3692 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130218/e1c9418f/attachment-0002.obj>