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

[Roman Popov]

I think the type "T" found in the Dwarf info would have to have come from
> the same compile unit that the "normally declared" type "T" came from, i.e.
> your "DW_AT_name(...)" function would have to guarantee that. There's
> nothing stopping the same type name from being used in different ways in
> different source files, as long as they don't collide in the same compile
> unit.


Yes, I understand this.  Currently I merge all source files into one
compilation unit to enforce unique naming. In C++ to Hardware community
it's a common method.

Another hack I'm doing is replacing built-in new operators, with equivalent
variadic templates :   my_new<my_type> (args...).   This allows me to save
a mangled type name for each allocation. I use it to support dynamic
allocation of HW modules.  For STL collections I do the same thing as GDB
Python pretty printers.



2018-03-07 1:04 GMT-08:00 Jason Nyberg <jasonnyberg at gmail.com>:

> Roman, For your given example:
>
>   T   var1;
>     DW_AT_name(T)   var2;
>
>   typeid(var1)  ==  typeid (var2) ?
>
> I think the type "T" found in the Dwarf info would have to have come from
> the same compile unit that the "normally declared" type "T" came from, i.e.
> your "DW_AT_name(...)" function would have to guarantee that. There's
> nothing stopping the same type name from being used in different ways in
> different source files, as long as they don't collide in the same compile
> unit.
>
> Your project sounds very interesting to me because I've *also* been using
> Dwarf for reflection; in my case I combine (all in C) a minimalistic
> language, Dwarf comprehension, and libffi such that shared libraries become
> "native" extensions to my simple language just by importing them.
> Eventually I'll hoist the whole thing up into C++ too...
>
> On Tue, Mar 6, 2018 at 2:55 PM Michael Eager <eager at eagercon.com> wrote:
>
>> >         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?
>> >
>> >
>> > DWARF doesn't give guarantees, just suggestions. Practically speaking
>> > there's certainly benefit to compilers ensuring they produce a
>> > consistent name across different translation units - and potentially
>> > even a consistent name across compilers (so that code built with
>> > different compilers and then debugged can behave consistently/well). (or
>> > consistent enough for a debugger to cope with it - but I think as Daniel
>> > pointed out, having the debugger have to decompose the name and do
>> > various type equivalences is painful - which might lean one towards
>> > trying to produce more consistent names across GCC and Clang - the few
>> > cases I know of (enums, for example) could probably be improved just for
>> > the compiler self-consistency aspect and incidentally improve the cross
>> > compiler consistency anyway)
>>
>> Exactly.  In many areas, the DWARF Standard is permissive.  There are
>> specific constraints which are mentioned, but the producer is given a
>> lot of latitude whether to generate complete or incomplete, good or poor
>> DWARF.  DWARF guarantees the organization and structure of the data.
>>
>> There is a comment about names on the DWARF Wiki under Best Practices:
>> http://wiki.dwarfstd.org/index.php?title=Best_Practices
>>
>>
>> --
>> Michael Eager    eager at eagercon.com
>> 1960 Park Blvd., Palo Alto, CA 94306
>> <https://maps.google.com/?q=1960+Park+Blvd.,+Palo+Alto,+CA+94306&entry=gmail&source=g>
>> _______________________________________________
>> Dwarf-Discuss mailing list
>> Dwarf-Discuss at lists.dwarfstd.org
>> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20180307/5f937b31/attachment.html>