[patch] migrating DragonEgg to DIBuilder

Duncan Sands baldrick at free.fr
Tue Feb 19 12:25:34 PST 2013


Hi David,

On 18/02/13 09:23, 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.]

thanks so much for doing this!  The patch looks good, however it does cause some
test suite failures:

- dragonegg/test/validator/objc/2010-02-23-DbgInheritance.m
   This objc test fails because it doesn't want DW_TAG_member, but gets it:

!12 = metadata !{i32 786445, metadata !8, metadata !"", metadata !4, i32 8, i64 
0, i64 8, i64 0, i32 0, metadata !11} ; [ DW_TAG_member ] [line 8, size 0, align 
8, offset 0] [from P]

Do you have any thoughts on this?

- some Fortran testcases crash, but it's not your fault: it occurs with
pointers to arrays, due to hitting this:

   if (isa<ARRAY_TYPE>(type) && TYPE_STRING_FLAG(type) &&
       isa<INTEGER_TYPE>(TREE_TYPE(type))) {
     DEBUGASSERT(0 && "Don't support pascal strings");
     return DIType();
   }

Then the empty DIType is used by the pointer code to try and form a
derived type.  I'm not sure why this (ancient) debug code thinks there
is a problem with this kind of array, so I will try to fix it to handle
them properly.

Ciao, Duncan.



More information about the llvm-commits mailing list