[patch] migrating DragonEgg to DIBuilder

[David Blaikie]

On Sat, Feb 23, 2013 at 9:33 AM, Duncan Sands <baldrick at free.fr> wrote:

> Hi David,
>
>
>      Your patch still applies, and now the only failure is the objc member
>> problem
>>     I mentioned before.
>>
>>
>> Looking at this, it seems like there's no change in behavior - the test
>> appears
>> to have been accidentally passing because the IR dumper wasn't printing
>> out the
>> annotated debug info comments next to the metadata (I guess the IR
>> printer lost
>> support for annotating the old debug info format somewhere along the way)
>>
>> Attached are the old (ToT) & new (with my patch applied) IR for this test
>> case -
>> perhaps I'm missing something about what the test case is meant to test,
>> etc.
>>
>
> it's hard for me to comment since I have no idea what this metadata means,


Ah, sorry - forget that I've actually built up some context here in the
last few months...


> and
> why dragonegg is now outputting so much more than clang and the old
> dragonegg.
>

I'm not sure what you mean by "so much more" - between the two attached .ll
files, the new file has only one more metadata value than the old. Fair
question as to what that is, though... it's just the function list from the
compile_unit.

So the old debug info schema used to have several named metadata nodes,
each one containing a list of the top level components of the debug info
that needed to be maintained (not sure how much you know about LLVM
metadata: unnamed metadata is not explicitly preserved, it's only
preserved/accessible by reference from a named metadata node - so the debug
info nodes are ethire  referenced from IR (things like debug info for
variables are referenced from the llvm.dbg.declare intrinsic calls) or from
the named metadata (so there's a list of functions, a list of global
variables, a list of types, etc - because there's no point in the IR that
we could refer to the debug info for those constructs so we used named
metadata and lists)). You can see one of those lists in old.ll attached
previously, "llvm.dbg.sp".

In the new schema, we have one named metadata node "llvm.dbg.cu" (CU:
Compile Unit which is the DWARF term for what C++ calls a Translation Unit)
which lists all the Compile Units (we could have multiple CUs in a single
bitcode file due to bitcode linking for LTO) and each Compile Unit metadata
has its own lists of functions/globals/types.

So the extra metadata entry is just that difference in representation. In
the old schema there's one 'subprogram' (function) in the llvm.dbg.sp list,
in the new one there's one compile unit in the 'llvm.dbg.cu' list and it
has a reference to another metadata list (!2) containing one entry (!3)
that is the subprogram.


> For example I don't know what you mean by "annotated debug info comments".
>

The IR printer is aware of the debug info metadata so it prints extra
human-readable comments after the metadata value itself. EG:

!0 = metadata !{i32 786449, i32 0, i32 16, metadata
!"2010-02-23-DbgInheritance.m", metadata
!"/usr/local/google/home/blaikie/dev/dragonegg/src/test/validator/objc",
metadata !"4.7.2", i1 true, i1 false, metadata !"", i32 0, metadata !1,
metadata !1, metadata !2, metadata !1} ; [ DW_TAG_compile_unit ]
[/usr/local/google/home/blaikie/dev/dragonegg/src/test/validator/objc/2010-02-23-DbgInheritance.m]
[DW_LANG_ObjC]

Everything after the ';' is  just the comment explaining what the metadata
means - that it's a DW_TAG_compile_unit description and that this compile
unit was Objective C and which file it was for, etc.

We're just not printing out those helpful comments for old debug info for
whatever reason.

It looks like the test case in question was using the absence of those
comments as a metric for the correctness of the output (unfortunate that we
dropped the comments then) - my change seems to have merely caused the
comments to come back again (I assume they were there at some point in the
past when this test case was originall written, then probably lost (I
assume because the version info moved on & the comment printing stuff
didn't stay backwards compatible with the old debug info formats), then the
test regressed at some point without failing the test)

Does this make any sense? If not I'll be on IRC in a few minutes & perhaps
we can chat about it there if you're around (or at some other time soon)

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130223/35ae9970/attachment.html>