Re: [RFA] dwarf2_physname

[Michael Eager <eager@eagercon.com>]

Daniel Jacobowitz wrote:
> On Mon, Aug 31, 2009 at 04:19:02PM -0700, Keith Seitz wrote:
>> On 08/31/2009 03:55 PM, Michael Eager wrote:
>>
>>> Does this mean that (eventually) the DW_AT_MIPS_linkage_name attribute
>>> will not be needed by GDB?
>> That is exactly what it is intended to do. MIPS_linkage_name is not
>> needed in any case I've been able to invent on my
>> archer-keiths-expr-cumulative branch, and that branch has MUCH
>> tougher C++ tests than FSF gdb does.
> 
> I assume this patch is a distant descendant of the one I sent you a
> while back.  Is its goal to create a useful name for each symbol, or
> to match the one produced by some other source - probably the
> demangler?  What sort of template cases have you looked at?

I'd be concerned about trying to embed name mangling into gdb.
Not all compilers (or versions) use the same scheme.

> As you know, I spent several some time trying to do without
> DW_AT_MIPS_linkage_name.  My main goals were cleanliness and
> compatibility with a non-GCC compiler (ARM RealView).  I came across a
> lot of cases where the output from neither GCC nor any other compiler
> I could get my hands on made sense without a linkage name in the debug
> info - and I couldn't find a way to get sensible representation in
> DWARF, either.
> 
> Here's one case I remember having trouble with.
> 
> template<char *S> int f()
> {
>   return S[0];
> }
> 
> char Foo[3];
> char Bar[3];
> 
> int main()
> {
>   return f<Foo>() + f<Bar>();
> }
> 
> 0000000000000000 W int f<&Bar>()
> 0000000000000000 W int f<&Foo>()
> 
>  <1><31>: Abbrev Number: 2 (DW_TAG_subprogram)
>     <32>   DW_AT_external    : 1
>     <33>   DW_AT_name        : (indirect string, offset: 0x47): f<((char*)(& Foo))>
>     <37>   DW_AT_decl_file   : 1
>     <38>   DW_AT_decl_line   : 1
>     <39>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x1f): _Z1fIXadL_Z3FooEEEiv
>     <3d>   DW_AT_type        : <0x55>
>     <41>   DW_AT_low_pc      : 0x0
>     <49>   DW_AT_high_pc     : 0x10
>     <51>   DW_AT_frame_base  : 0x0      (location list)
> 
> You have to represent the name "Foo" in the debug info - the address
> isn't enough, there could be other symbols apparently at the same
> address.  The name this older GCC emits is not useful.  Most other
> compilers just punted.  While hopefully Dodji has made HEAD GCC do
> something sensible now, we have to handle all those field compilers :-)

I think that this is a problem with how the template instantiation is
described.

 From DWARF 3, Sec. 3.3.7:

   1. Each formal parameterized type declaration appearing in the template
      definition is represented by a debugging information entry with the tag
      DW_TAG_template_type_parameter. Each such entry has a DW_AT_name attribute,
      whose value is a null-terminated string containing the name of the formal
      type parameter as it appears in the source program. The template type
      parameter entry also has a DW_AT_type attribute describing the actual
      type by which the formal is replaced for this instantiation. All template
      type parameter entries should appear before the entries describing the
      instantiated formal parameters to the function.

I think that there should be something like
    DW_TAG_template_value_parameter
      DW_AT_name : Foo
      DW_AT_type : <int *>
as a child of  of f<Foo>.

(I'm pretty rusty on how template functions are described, and, unfortunately,
the DWARF Standard doesn't have any examples.)

My feeling is that in this case, DW_AT_MIPS_linkage_name compensates
for the compiler not generating more complete DWARF.  If it did generate
DW_TAG_template_value_parameter, there would be no need for DW_AT_MIPS_linkage_name.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077