On Tue, Mar 6, 2018 at 11:21 AM Roman Popov <ripo...@gmail.com> wrote:
> 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? > 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) > > > 2018-03-06 11:08 GMT-08:00 Michael Eager <ea...@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 ea...@eagercon.com >> 1960 Park Blvd., Palo Alto, CA 94306 >> > > _______________________________________________ > 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
