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 <jasonnyb...@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 <ea...@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 ea...@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@lists.dwarfstd.org >> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org >> >
_______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
