Devang Patel
2010-Sep-30 17:13 UTC
[LLVMdev] Associating types directly with debug metadata?
On Sep 30, 2010, at 1:30 AM, Pekka Nikander wrote:>>>> Would the right starting point be to simply add an MDNode pointer to the Type class? That should be then convertible to a DIType? >>> >>> We want to avoid any Type class modification. Instead you can use pair in named metadata to match metadata with type. >>> >>> !11 = metadata !{i32 524307, metadata !1, metadata !"T", metadata !1, i32 2, i64 32, i64 32, i64 0, i32 0, null, metadata !12, i32 0, null} ; [ DW_TAG_structure_type ] >>> >>> !21 = metadata !{ metadata !11, %struct.T %z} >>> >>> !llvm.my_special_type_info = !{!21} >> >> Ok, that approach should work. Though we want to associate the type, not some variable with the type, i.e. something like >> >> !21 = metadata !{ %struct.T, metadata !11 } >> >> But I don't know if that would be valid syntax... > > I thought about that more, and I think the "right" way would be to have a syntax like > > !21 = metadata !{ type %struct.T, metadata !11 } > > or perhaps > > !21 = metadata !{ typeval %struct.T, metadata !11 } > > to avoid the problem with the keyword 'type'. > > But to be able to do that, should apparently be possible to represent types as first class values. That in turn would apparently require a new Type::TypeID? > > Would that be worth doing? Apparently we can fake with our need, and use a null pointer instead. Technically, that would be wrong, but would work with the current code without any modifications: > > !21 = metadata !{ %struct.T *null, metadata !11 }I would recommend this approach. - Devang> > Any opinions? (I guess I'll just try the number of changes needed for a 'typeval' and report back.) > > --Pekka >
Pekka Nikander
2010-Sep-30 17:28 UTC
[LLVMdev] Associating types directly with debug metadata?
>>>> We want to avoid any Type class modification. Instead you can use pair in named metadata to match metadata with type. >>>> >> >> I thought about that more, and I think the "right" way would be to have a syntax like >> >> !21 = metadata !{ type %struct.T, metadata !11 } >> >> or perhaps >> >> !21 = metadata !{ typeval %struct.T, metadata !11 } >> >> to avoid the problem with the keyword 'type'. >> >> Would that be worth doing? Apparently we can fake with our need, and use a null pointer instead. Technically, that would be wrong, but would work with the current code without any modifications: >> >> !21 = metadata !{ %struct.T *null, metadata !11 } > > I would recommend this approach.But that would have a hacky feeling :-) Anyway, I already implemented an early patch for making Types representable as Values. For that I created a new class, TypeValue, which represents a type as a value. An early patch for that enclosed. Works when reading or writing textual representations; no BC representation yet. And no test case yet. This works well enough for our purposes; I don't have any incentive to go further unless someone else needs a similar kind of functionality. --Pekka -------------- next part -------------- A non-text attachment was scrubbed... Name: TypeValue.diff Type: application/octet-stream Size: 11238 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100930/eead66b4/attachment.obj>
Pekka Nikander
2010-Oct-05 07:59 UTC
[LLVMdev] Associating types directly with debug metadata?
>>> I thought about that more, and I think the "right" way would be to have a syntax like >>> >>> !21 = metadata !{ typeval %struct.T, metadata !11 } >>> >>> to avoid the problem with the keyword 'type'. >>> > > Anyway, I already implemented an early patch for making Types representable as Values. For that I created a new class, TypeValue, which represents a type as a value. An early patch for that enclosed. Works when reading or writing textual representations; no BC representation yet. And no test case yet.Here is another version of the patch. This one includes also a small patch to llvm-gcc so that it generates the type metadata for structures and classes. This one also generates and parses correctly the metadata for .ll files. No .bc support yet. The biggest problem with this version is that it breaks when the compiler/linker performs type reductions, and I don't understand why. --Pekka -------------- next part -------------- A non-text attachment was scrubbed... Name: TypeValue.diff Type: application/octet-stream Size: 16812 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101005/93446e93/attachment.obj>
Alexander Herz
2010-Oct-06 12:37 UTC
[LLVMdev] Associating types directly with debug metadata?
I'd really be interested in getting full support for this. We're doing abstract interpretation on c++ code (lowered to c code via llvm). I restrained from adding a direct mapping from type to type name because it appears to be somewhat involved (having to change the IT etc) but it would be very helpful for us to have this. Alex P.S.: To Devang : I'll submit the other patch for debug info asap..I just didn't have the time yet.. On 09/30/2010 07:28 PM, Pekka Nikander wrote:>>>>> We want to avoid any Type class modification. Instead you can use pair in named metadata to match metadata with type. >>>>> >>>>> >>> I thought about that more, and I think the "right" way would be to have a syntax like >>> >>> !21 = metadata !{ type %struct.T, metadata !11 } >>> >>> or perhaps >>> >>> !21 = metadata !{ typeval %struct.T, metadata !11 } >>> >>> to avoid the problem with the keyword 'type'. >>> >>> Would that be worth doing? Apparently we can fake with our need, and use a null pointer instead. Technically, that would be wrong, but would work with the current code without any modifications: >>> >>> !21 = metadata !{ %struct.T *null, metadata !11 } >>> >> I would recommend this approach. >> > But that would have a hacky feeling :-) > > Anyway, I already implemented an early patch for making Types representable as Values. For that I created a new class, TypeValue, which represents a type as a value. An early patch for that enclosed. Works when reading or writing textual representations; no BC representation yet. And no test case yet. > > This works well enough for our purposes; I don't have any incentive to go further unless someone else needs a similar kind of functionality. > > --Pekka > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101006/4ab3d349/attachment.html>
Possibly Parallel Threads
- [LLVMdev] Associating types directly with debug metadata?
- [LLVMdev] Associating types directly with debug metadata?
- [LLVMdev] Associating types directly with debug metadata?
- [LLVMdev] Associating types directly with debug metadata?
- [LLVMdev] Associating types directly with debug metadata?