[Dwarf-discuss] C++ standard integral types and overload resolution

[Ron 603-884-2088]

Jim Cownie wrote:
>The Problem
>-----------
>Consider C++ integer types, on a machine in which sizeof(int) ==
>sizeof(long) (say a normal 32 bit machine). (The same problem also
>occurs on most 64 bit machines where sizeof (long) == sizeof (long
>long)). 
>
>If the debugger is to support calling overloaded C++ functions it must
>be able to distinguish calls to these functions :-
>
>   void foo (int);
>and 
>   void foo (long);
>
>However when types are passed through DWARF to the debugger the only
>difference between the fundamental types is their name, since the bit
>representation in store of int and long is identical, e.g.
>
> <1><46e>: Abbrev Number: 4 (DW_TAG_base_type)
>     DW_AT_name        : int	
>     DW_AT_byte_size   : 4	
>     DW_AT_encoding    : 5	(signed)
>
>and 
>
> <1><455>: Abbrev Number: 2 (DW_TAG_base_type)
>     DW_AT_name        : long int	
>     DW_AT_byte_size   : 4
>     DW_AT_encoding    : 5	(signed)

All that is exactly what I expect.

>The problem here is not with the functions (from outside DWARF we can
>get the fuction's signature from its mangled name), but with variable
>declarations where all we have is the type given in the DWARF.

I don't understand why there is a problem here. "the type given in
the DWARF" comes from a DW_AT_type attribute to refers to one of
the DIEs illustrated above (for example). There is no ambiguity about
the name of the type, although I don't think the name is even needed
generally.

>The problem is that 
>
>  1) The debugger has to rely on the name of the type generated by the
>     compiler, which is unpleasant, especially for types like
>     "unsigned long long int", for which I think there are twelve
>     possible valid names.

Why do you say "rely on the name"? DW_AT_type attributes refer to
dies, not names.

>  2) If the compiler elides typedefs, so that for
>       typedef long foo;
>     it emits a base type with the name foo there is no way in which the
>     debugger can determine whether foo is really an int or a long
>     (because there is no name to use).

Yes, well this is a different problem, easily fixed by correcting
the compiler to stop eliding the typedef definitions. But even if
it doesn't, then all DW_AT_type attributes that should refer to
the typedef DIE for foo will instead point to the type DIE for
long and the debugger should be in the same position as discussed
above.

>Suggested Solution
>------------------
>
>We add another attribute which can be used on DW_TAG_base_type DIE which
>allows the compiler explicitly to specify the C++ language type being
>represented.
>
>Something like
>
>  DW_AT_cplus_true_type  <constant>
>
>where <constant> has one of the values
>
>  DW_true_type_short,
>  DW_true_type_int,
>  DW_true_type_long,
>  DW_true_type_long_long,
>
>  DW_true_type_float,
>  DW_true_type_double,
>  DW_true_type_long_double,
>  DW_true_type_long_long_double

Don't you need unsigned variants for all of these too?

I'm still not understanding the problem. Is the issue that C/C++
say, for example, that 'int' and 'signed int' are the *same type*
but that 'int' and 'long' are not the same type even if they
have the identical representation (on some systems)? So the
problem is making it easier for the debugger to compare two type
dies and discover whether they are the same type or not?

Which is totally orthogonal to any typedef issues, I think?

>This would also allow for some space saving, since if the compiler emits
>the DW_AT_cplus_true_type it need not emit the name string (as the
>debugger can construct it from the true type).

>The same issue may apply to other languages which permit overloaded
>functions ?

>(Note that in DWARF-1 there were explicit enumerations for C types, but
>those no longer appear in DWARF 3 anywhere).

Perhaps some "old timer" can recall/reconstruct why the DWARF V1 model
was abandoned...

Ron