Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
To: drow@mvista.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfc/cp] method stub assertions
Date: Tue, 06 Jan 2004 00:12:00 -0000	[thread overview]
Message-ID: <20040106001215.5CD314B35A@berman.michael-chastain.com> (raw)

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
anyways!

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.

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

Michael C


             reply	other threads:[~2004-01-06  0:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-06  0:12 Michael Elizabeth Chastain [this message]
2004-01-06  2:51 ` Daniel Jacobowitz
  -- strict thread matches above, loose matches on Subject: below --
2004-01-06 18:24 Michael Elizabeth Chastain
2004-01-06 19:02 ` Daniel Jacobowitz
2004-01-06  4:28 Michael Elizabeth Chastain
2004-01-06  4:43 ` Daniel Jacobowitz
2004-01-06 17:05 ` Daniel Jacobowitz
2004-01-06 18:41   ` David Carlton
2004-01-06 19:05     ` Daniel Jacobowitz
2004-01-05 20:51 Michael Elizabeth Chastain
2004-01-05 11:50 [rfc/cp] take 2: method stubs asserts Michael Elizabeth Chastain
2004-01-05  0:50 ` [rfc/cp] method stub assertions Michael Elizabeth Chastain
2004-01-05  1:56   ` Daniel Jacobowitz
2004-01-05 19:23   ` Daniel Jacobowitz
2004-01-05  2:32 Michael Elizabeth Chastain
2004-01-05  2:33 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040106001215.5CD314B35A@berman.michael-chastain.com \
    --to=mec.gnu@mindspring.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox