[Dwarf-Discuss] Using DWARF for C++ runtime reflection

[Roman Popov]

>
> It is certainly an interesting use case.  I haven't see this done before,
> but since DWARF gives descriptions of classes, it seems reasonable.

I've found some attempts in this direction on github. So certainly I'm not
the first one.  My application is hardware modeling, I make something
similar to Chisel (https://chisel.eecs.berkeley.edu/) but in C++, instead
of Scala.


> The AT_name is the declared name of the type in the source, not the name
> of an underlying type.  For example, if your source is ...


Yes, I forgot about aliases. But since DWARF allows to go from alias to
underlying type, it's not an issue for my application.

Yes, assuming that the compiler generates a valid source type.  In some
> cases, particularly with template classes, this may not be the case.


 So DWARF does not give any guarantees and it's up to compiler vendor to
decide about DW_AT_name?


2018-03-06 11:08 GMT-08:00 Michael Eager <eager at eagercon.com>:

> On 03/06/2018 10:37 AM, Roman Popov wrote:
>
>> Hi everyone,
>> I'm working on a dynamic analysis tool that needs runtime reflection in
>> C++. Since C++ has no standardized runtime reflection, I'm using DWARF as a
>> source of reflection metadata.
>>
>> Is it a legitimate use-case from DWARF standard point of view?
>>
>
> It is certainly an interesting use case.  I haven't see this done
> before, but since DWARF gives descriptions of classes, it seems
> reasonable.
>
> It has been working great for me until I've upgraded to latest g++ and
>> clang compilers. Those compilers produce ambiguous names for some template
>> instantiations, so my tools no longer work. So I start to wonder: whether
>> it me misusing DWARF, or it is compilers that are buggy.
>>
>> In particular, what is the DWARF answer for these questions:
>>
>> 1.  Does DWARF guarantees that:
>>
>>       typeid(T1) == typeid(T2)    ==> DW_AT_name(T1)  == DW_AT_name(T2)
>>       typeid(T1) != typeid(T2)     ==> DW_AT_name(T1)  != DW_AT_name(T2)
>>
>> i.e. Is DW_AT_name an unique identifier for type?
>>
>
> The AT_name is the declared name of the type in the source, not the name
> of an underlying type.  For example, if your source is
>
>   typedef int int_name_1;
>   typedef int int_name_2;
>
>   int_name_1 name_1;
>   int_name_2 name_2;
>
> The (edited) DWARF for this
>
>  <1d>: (DW_TAG_typedef)
>     <1e>   DW_AT_name        : int_name_1
>     <24>   DW_AT_type        : <0x28>
>  <28>: (DW_TAG_base_type)
>     <2b>   DW_AT_name        : int
>  <2f>: (DW_TAG_typedef)
>     <30>   DW_AT_name        : int_name_2
>     <36>   DW_AT_type        : <0x28>
>  <3a>: (DW_TAG_variable)
>     <3b>   DW_AT_name        : name_1
>     <41>   DW_AT_type        : <0x1d>
>  <4f>: (DW_TAG_variable)
>     <50>   DW_AT_name        : name_2
>     <56>   DW_AT_type        : <0x2f>
>
> typeid(name_1) == typeid(name_2) == "int" which is different from
> AT_name(name_1) or AT_name(name_2).
>
>
> 2.  Does DWARF guarantees that DW_AT_name(T)  is a valid source language
>> name?
>>
>
> Yes, assuming that the compiler generates a valid source type.  In some
> cases, particularly with template classes, this may not be the case.
>
> i.e. If I copy string from DW_AT_name to source code, and compile it with
>> the same compiler that produced DWARF, will it produce the same type?
>>
>>      T   var1;
>>      DW_AT_name(T)   var2;
>>
>>    typeid(var1)  ==  typeid (var2) ?
>>
>
> I expect that it would.
>
> --
> Michael Eager    eager at eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20180306/22d4f6ab/attachment-0001.html>