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

[Ron 603-884-2088]

Drow wrote:
>>                                                         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?
>
>Sort of.  The problem I think that James is talking about is that "int
>foo(int)" and "int foo(long)" are different functions.  For a debugger
>to perform a call "foo(var)", it needs to know the difference between
>int and long to see which one var is (or is closer to, for overload
>resolution).
>
>Doing this based on the names of base type DIEs is pretty ugly.

I don't understand the "sort of". If the user enters the command

    debugger> call foo(var)

the debugger will look up foo and find two candidates, one with a
parameter whose DW_AT_type refers to the DIE for long and another
with a parameter whose DW_AT_type refers to the DIE for int. It
will also look up var, and find an object DIE whose DW_AT_type
refers to the DIE for, say, int.

At this point there is no issue! The type for var and the type
for foo(int) are represented by the same DIE. Overloading
resolution is done. (You know a priori that the other function
can't "match" because the language rules don't allow such an
inherent ambiguity. (Or does it?)

It seems like

    debugger> call foo(1)

is actually more of a challenge because 1 can be of type int or
of type long, or perhaps implicitly converted to type long if
there is no visible function foo with a parameter of type int, or
some such. Which is to say that the debugger needs to have a lot
of builtin knowledge of C++ semantics in any case, so one routine
that computes the predicate is_same_cxx_type(char*,char*) is
perhaps messy but probably no worse than many other language-specific
idiosyncrasies that abound...

I am not trying to trivialize this problem, but I am trying to
understand precisely what the problem is.

Assuming that we are really violently agreeing, it seems to me
that Cownie's suggested solution is very C/C++ specific and does
not extent at all well to other languages and/or other classes of
types that might have a similar equivalence problem.

Perhaps an alternative solution might be a DW_AT_equivalent
attribute that allows one type to refer to another that
semantically should be treated as "the same type" in the current
language. A debugger then need only start with two type DIEs and
follow two possible chains of DW_AT_equivalent attributes until
they end on the same DIE (same type) or not (not same type). No
names involved at all. Indeed, a compiler might even keep the
chains all of maximum length one and/or use an unnamed
"canonical" representative DIE to keep life simple/efficient
for the debugger.

Ron Brender