From ripopov@gmail.com  Tue Mar  6 18:37:22 2018
From: ripopov@gmail.com (Roman Popov)
Date: Tue, 6 Mar 2018 10:37:22 -0800
Subject: [Dwarf-Discuss] Using DWARF for C++ runtime reflection
Message-ID: <CAATAM3FmeQDy+p6OQ-_KgBkFUff-BUCNZ+_yfdnhUJweopo9pw@mail.gmail.com>

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 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?


2.  Does DWARF guarantees that DW_AT_name(T)  is a valid source language
name?
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) ?

Thanks,
Roman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20180306/58dacdce/attachment.html>


From eager@eagercon.com  Tue Mar  6 19:08:21 2018
From: eager@eagercon.com (Michael Eager)
Date: Tue, 6 Mar 2018 11:08:21 -0800
Subject: [Dwarf-Discuss] Using DWARF for C++ runtime reflection
In-Reply-To: <CAATAM3FmeQDy+p6OQ-_KgBkFUff-BUCNZ+_yfdnhUJweopo9pw@mail.gmail.com>
References: <CAATAM3FmeQDy+p6OQ-_KgBkFUff-BUCNZ+_yfdnhUJweopo9pw@mail.gmail.com>
Message-ID: <a2b14dab-c336-7606-59af-69f63696ccb5@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


From ripopov@gmail.com  Tue Mar  6 19:20:58 2018
From: ripopov@gmail.com (Roman Popov)
Date: Tue, 6 Mar 2018 11:20:58 -0800
Subject: [Dwarf-Discuss] Using DWARF for C++ runtime reflection
In-Reply-To: <a2b14dab-c336-7606-59af-69f63696ccb5@eagercon.com>
References: <CAATAM3FmeQDy+p6OQ-_KgBkFUff-BUCNZ+_yfdnhUJweopo9pw@mail.gmail.com>
 <a2b14dab-c336-7606-59af-69f63696ccb5@eagercon.com>
Message-ID: <CAATAM3HhYY9O=68R=J23mMWiefaWxuPDNAQkDGsQ7GMf_fM0YA@mail.gmail.com>

>
> 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>


From dblaikie@gmail.com  Tue Mar  6 19:24:02 2018
From: dblaikie@gmail.com (David Blaikie)
Date: Tue, 06 Mar 2018 19:24:02 +0000
Subject: [Dwarf-Discuss] Using DWARF for C++ runtime reflection
In-Reply-To: <CAATAM3HhYY9O=68R=J23mMWiefaWxuPDNAQkDGsQ7GMf_fM0YA@mail.gmail.com>
References: <CAATAM3FmeQDy+p6OQ-_KgBkFUff-BUCNZ+_yfdnhUJweopo9pw@mail.gmail.com>
 <a2b14dab-c336-7606-59af-69f63696ccb5@eagercon.com>
 <CAATAM3HhYY9O=68R=J23mMWiefaWxuPDNAQkDGsQ7GMf_fM0YA@mail.gmail.com>
Message-ID: <CAENS6EvsgwFqrwq0Nyu8FA9=n5aPP3c_ww235Gz0JKOV0sm6hQ@mail.gmail.com>

On Tue, Mar 6, 2018 at 11:21 AM Roman Popov <ripopov at 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 <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
>>
>
> _______________________________________________
> 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/20180306/defdbe30/attachment.html>


From eager@eagercon.com  Tue Mar  6 19:55:07 2018
From: eager@eagercon.com (Michael Eager)
Date: Tue, 6 Mar 2018 11:55:07 -0800
Subject: [Dwarf-Discuss] Using DWARF for C++ runtime reflection
In-Reply-To: <CAENS6EvsgwFqrwq0Nyu8FA9=n5aPP3c_ww235Gz0JKOV0sm6hQ@mail.gmail.com>
References: <CAATAM3FmeQDy+p6OQ-_KgBkFUff-BUCNZ+_yfdnhUJweopo9pw@mail.gmail.com>
 <a2b14dab-c336-7606-59af-69f63696ccb5@eagercon.com>
 <CAATAM3HhYY9O=68R=J23mMWiefaWxuPDNAQkDGsQ7GMf_fM0YA@mail.gmail.com>
 <CAENS6EvsgwFqrwq0Nyu8FA9=n5aPP3c_ww235Gz0JKOV0sm6hQ@mail.gmail.com>
Message-ID: <45285beb-dd7c-6782-e39c-ba332c6e3a46@eagercon.com>

>         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


From jasonnyberg@gmail.com  Wed Mar  7 09:04:39 2018
From: jasonnyberg@gmail.com (Jason Nyberg)
Date: Wed, 07 Mar 2018 09:04:39 +0000
Subject: [Dwarf-Discuss] Using DWARF for C++ runtime reflection
In-Reply-To: <45285beb-dd7c-6782-e39c-ba332c6e3a46@eagercon.com>
References: <CAATAM3FmeQDy+p6OQ-_KgBkFUff-BUCNZ+_yfdnhUJweopo9pw@mail.gmail.com>
 <a2b14dab-c336-7606-59af-69f63696ccb5@eagercon.com>
 <CAATAM3HhYY9O=68R=J23mMWiefaWxuPDNAQkDGsQ7GMf_fM0YA@mail.gmail.com>
 <CAENS6EvsgwFqrwq0Nyu8FA9=n5aPP3c_ww235Gz0JKOV0sm6hQ@mail.gmail.com>
 <45285beb-dd7c-6782-e39c-ba332c6e3a46@eagercon.com>
Message-ID: <CAAGEaS1GCdN1XT2zLShf8ZbD6mTC7tD9eV4=1-Gx1Y9pFT34zQ@mail.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
> _______________________________________________
> 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/4dd2cd9d/attachment.html>


From ripopov@gmail.com  Wed Mar  7 18:07:13 2018
From: ripopov@gmail.com (Roman Popov)
Date: Wed, 7 Mar 2018 10:07:13 -0800
Subject: [Dwarf-Discuss] Using DWARF for C++ runtime reflection
In-Reply-To: <CAAGEaS1GCdN1XT2zLShf8ZbD6mTC7tD9eV4=1-Gx1Y9pFT34zQ@mail.gmail.com>
References: <CAATAM3FmeQDy+p6OQ-_KgBkFUff-BUCNZ+_yfdnhUJweopo9pw@mail.gmail.com>
 <a2b14dab-c336-7606-59af-69f63696ccb5@eagercon.com>
 <CAATAM3HhYY9O=68R=J23mMWiefaWxuPDNAQkDGsQ7GMf_fM0YA@mail.gmail.com>
 <CAENS6EvsgwFqrwq0Nyu8FA9=n5aPP3c_ww235Gz0JKOV0sm6hQ@mail.gmail.com>
 <45285beb-dd7c-6782-e39c-ba332c6e3a46@eagercon.com>
 <CAAGEaS1GCdN1XT2zLShf8ZbD6mTC7tD9eV4=1-Gx1Y9pFT34zQ@mail.gmail.com>
Message-ID: <CAATAM3GdCn17t0-zuBV6GJ9mH7D35gvM3d++EY0WRUfkmUG0Xg@mail.gmail.com>

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>


