[LLVMdev] Associating types directly with debug metadata?

[Pekka Nikander]

>>>> If you need to name an LLVM type in your MDNode, just create an undef
>>>> value of that type.
>>> 
>>> I agree completely.
>> 
>> Ok, I will try using undefs...
> 
> As you proved by example, you could create a TypeValue and LLVM wouldn't collapse, but it goes against the grain of the design. If undef will work for you, please use it.

I finally had time to try the undef.  Generating the undefs in llvm-gcc is easy -- I guess it will be as easy in clang, too.  Here is some example output:

  !ahir.sema.types = !{!2079, !2080, !2081, .... }

  !2079 = metadata !{%struct.IPAddress undef, metadata !21}
  !2080 = metadata !{%"struct.String::memo_t" undef, metadata !89}
  !2081 = metadata !{%"struct.String::rep_t" undef, metadata !80}

That looks ok.

But when linking (and apparently with some optimisers), I have almost the same problem as before.  The information mostly disappears.  I should have several hundred undefs after linking -- but only some 25 of those get to the linked version.

The difference between using my TypeValue hack and your recommended usage of undef is that in the former case the typeval-containing metadata nodes still were there, but the type was null, while now with undefs the undef-containing metadata nodes disappear.  That is, with my previous version the !ahir.sema.types named metadata had hundreds of MDnodes pointed by it, but most of those MDnodes were wrong, containing a null instead of a typeval.  Now, with undefs, the !ahir.sema.types named metadata has only 25 MDnodes pointed by it, but the ones remaining are correct.

I have no idea what is going on, i.e. what earlier changed the types so that my TypeValues became invalid, and what is now apparently simply destroying the MDnodes.  

I'd be willing to fix this if I just knew where to start.

--Pekka
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: undef.patch
Type: application/octet-stream
Size: 2230 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101011/5f6d9f70/attachment.obj>