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
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 hav
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 gua
On Tue, Mar 6, 2018 at 11:21 AM Roman Popov 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
>
> 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
simil
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 v
