Re: [rfc/cp] method stub assertions

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Jan 05, 2004 at 07:12:15PM -0500, Michael Chastain wrote:
> Hi Daniel,
> 
> > Right now we assume that methods have a TYPE_DOMAIN_TYPE.  This patch
> > pushes more knowledge of limited debug readers out into the rest of
> > GDB.  I'd rather go the other direction - set a domain type.
> 
> I'm going to push back on this and argue that a C++ method should
> not need to have a domain type.
> 
> A pointer-to-member needs to have a domain type because it's
> explicitly associated with a domain:
> 
>   int (A::*PMF)(int);
> 
> The debug information for "PMF" says that it's in class A,
> and that becomes the domain type.  It's all good.
> 
> But an ordinary member does not need to have a domain:
> 
>   class A
>   {
>     static int foo (int);
>   };
> 
>   class B
>   {
>     static int bar (int);
>   };
> 
>   static int bletch (int);
> 
> Here, the types of "foo", bar", and "bletch" are exactly the same.
> Adding a "domain A" to the first and "domain B" to the second
> makes them not the same, and will cause me a big problem.

Those are static methods.  Don't confuse them with normal methods! 
They're basically just functions that live in a class.  I don't know
whether or not offhand they need to have a domain type.  Probably right
now they do, but I'd be amenable to changing that.

> In HP debug format, the DNTT records for A::foo, B::bar, and bletch can
> be the same record.  hp-read.c has a 1-1 map from DNTT records to gdb
> types.  This is the dntt_type_vector in 'struct hpread_symfile_info'.
> 
> When the HP reader sees a DNTT type, it autovivifies dntt_type_vector
> and uses the dntt_type_vector[hp_type.dnttp.index] for the gdb type.
> So the same DNTT type always maps to the same gdb type,
> and all three functions can share a type entry.
> 
> But different DNTT type will need to have different gdb types because
> they have different domain types.  That means I have to mess with a lot
> of code that translates DNTT types: (1) pass in context information that
> is not part of the DNTT record to begin with, and (2) change the
> dntt-to-gdbtype mapping array to index off of [domain type, index]
> instead of just [index].
> 
> All of this for a field which is not used in expression evaluation
> anyways!

Do
  class A { int bar (int); }
and
  class B { int baz (int); }

have the same DNTT type?  If they do, then aCC is so hideously busted
that I don't know what to do.

Wait a sec... this doesn't make sense... if the domain type is only
needed for non-static members we could just get it from the first
argument.... something is wrong here.

> c_type_print_varspec_prefix does contain this code:
> 
>   case TYPE_CODE_METHOD:
>       if (passed_a_ptr)
> 	fprintf_filtered (stream, "(");
>       c_type_print_varspec_prefix (TYPE_TARGET_TYPE (type), stream, show, 0, 0);
>       if (passed_a_ptr)
> 	{
> 	  fprintf_filtered (stream, " ");
> 	  c_type_print_base (TYPE_DOMAIN_TYPE (type), stream, 0, passed_a_ptr);
> 	  fprintf_filtered (stream, "::");
> 	}
>       break;
> 
> However, I don't think it's actually possible to have a C++ type which
> is a pointer to a TYPE_CODE_METHOD.  If the C++ type is "pointer to
> function returning int", it can point to a non-method function or to a
> static method function.  If the C++ type is "pointer to class method
> returning int", then that is a pointer-to-member, and a
> 
> pointer-to-member is already required to have a class type
> along with the method signature.

I believe you can create a pointer to TYPE_CODE_METHOD in GDB even
though it is not meaningful C++; just take the thing's address.  I
could be mistaken about that however.

> How about it, can you re-think your requirement that each method
> type has a domain type?

Do static methods have TYPE_CODE_METHOD, and should they?  That's the
question.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer