public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@redhat.com>
To: gdb@sources.redhat.com
Subject: representing C++ constructors in GDB's symbol tables
Date: Fri, 17 Sep 2004 22:46:00 -0000	[thread overview]
Message-ID: <vt2pt4ko6p7.fsf@zenia.home> (raw)


There are currently several problems I see in the way we represent C++
constructors in GDB's symbol table.

First, for a class named "X", we put three (or possibly four) entries
in VAR_DOMAIN all named "X": the typedef, and two (or possibly three)
constructors.  This makes it (cough) difficult to look up the one you
need.

It occured to me that perhaps constructors should not be in the
VAR_DOMAIN.  You can't use them by name in expressions: you have to
say "new X(...)", never "X(...)".  You can't call them directly.  You
can't take their addresses: "&X::X(int)" is not valid C++.  The only
reason they really have names at all is to let you define them outside
the class.

Creating a new CONSTRUCTORS_DOMAIN would give you something reasonable
to pass when handling a "new" expression.  And there's nothing wrong
with adding a C++-specific domain; domains were created to distinguish
the different roles identifiers might play in a particular language:
witness STRUCT_DOMAIN vs VAR_DOMAIN for C.

Then there's the question of duplicate copies of the constructors
themselves.  The code at the moment wants to distinguish them by their
physical (linker) names, but I gather one of the main thrusts of David
and Daniel's work was to move away from the internal use of mangled
names for this kind of thing.  Domains are the wrong tool there; the
presence of multiple constructor copies is an ABI-specific thing.
I don't have an answer to that that sounds good yet. 

             reply	other threads:[~2004-09-17 22:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-17 22:46 Jim Blandy [this message]
2004-09-18  0:14 ` Daniel Jacobowitz
2004-09-18  0:18 ` David Carlton
2004-09-18  2:29   ` Michael Chastain
2004-09-20 16:36     ` David Carlton

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=vt2pt4ko6p7.fsf@zenia.home \
    --to=jimb@redhat.com \
    --cc=gdb@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).