This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc/cp] method stub assertions

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.

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

c_type_print_varspec_prefix does contain this code:

      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, "::");

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.

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

Michael C

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]