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

[Chris Quenelle]

You could also:

1. fix the compiler to merge equivalent base types

    This has the possibly bad side effect that
    "unsigned foo" and "unsigned int bar" cannot
    be displayed in the debugger with the exact spelling
    of the type that was given in the source.  IMHO, no big loss.

2. assign the internal equivalent of DW_AT_cplus_true_type

    While reading dwarf, the debugger can do the string-compare
    heuristic (in a contained way, in one ugly spot in the debugger)
    and store the resulting enumeration internally in the debugger
    symbol table.


The fundamental problem seems to be this:

Compilers are not restricted from emitting multiple different dies
with different names that all reflect types which are "identical"
in the language standard.  This identity relationship is not recorded
in dwarf.

You could ask the compiler to choose one "distinguished" spelling,
and make other spelling point back to the original die
(sort of a base base-type).  The debugger then wouldn't need to know
what that spelling was, just that it needed to go back to the
"source" in order to do the type-comparison.

The other solutions proposed also seem workable:
   1. link identical types as siblings
   2. create an explicit enum with values for each C++ base type

If the debugger needs to know:

  "which base types correspond exactly to the C++
   official-standard-type of INT"

Then I think James' original proposal is probably best.  But
so far it doesn't seem that the debugger has to know that.
It only has to figure out equivalences between multiple types.

--chris




James Cownie wrote:
> Folks,
> 
> I'd like to propose a DWARF enhancement to overcome what I believe is a
> problem with the current standard.
> 
> 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)
> 
> 
> 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.
> 
> 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.
> 
>   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).
> 
> 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
> 
> 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).
>