representing C++ constructors in GDB's symbol tables

representing C++ constructors in GDB's symbol tables

[Jim Blandy]

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. 

Re: representing C++ constructors in GDB's symbol tables

[Daniel Jacobowitz]

On Fri, Sep 17, 2004 at 05:45:40PM -0500, Jim Blandy wrote:
> 
> 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.

I prefer fixing the names of the constructors in the symbol table (or
un-flattening the symbol table); I think that would obsolete this.

> 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. 

We only need to have textual names that distinguish these things for
the user interface.  Internally, they can just be different pointers;
that means we have to keep track of them from the types rather than
storing names in the types and abusing lookup_symbol.

-- 
Daniel Jacobowitz

Re: representing C++ constructors in GDB's symbol tables

[David Carlton]

On Fri, 17 Sep 2004 17:45:40 -0500, Jim Blandy <jimb@redhat.com> said:

> It occured to me that perhaps constructors should not be in the
> VAR_DOMAIN.

This sounds plausible, though I'm not entirely convinced, but for what
it's worth this next claim of yours isn't really true:

> You can't use them by name in expressions: you have to say "new
> X(...)", never "X(...)".

You can use "X(...)" to create a temporary object of type X.  E.g. the
following program works fine.

  #include <iostream>

  class Printer {
    public:
      void print() const {
          std::cout << "print!\n";
      }
  };

  int main() {
      Printer().print();

      return 0;
  }

Having said that, a constructor really is a different beast from an
ordinary function call.  And I don't think that having GDB support

  (gdb) print Printer().print()

should be high on your list of priorities.

David Carlton
david.carlton@sun.com

Re: representing C++ constructors in GDB's symbol tables

[Michael Chastain]

David Carlton <david.carlton@sun.com> wrote:
> You can use "X(...)" to create a temporary object of type X.

Sure.  And of course:

  X my_x = X();

Also remember destructors.  A C++ program can explicitly call
a destructor.  Sigh.

> Having said that, a constructor really is a different beast from an
> ordinary function call.  And I don't think that having GDB support
>
>   (gdb) print Printer().print()
>
> should be high on your list of priorities.

Yeah.  I would be comfortable if gdb said "forget about it,
I don't call a ctor directly" (and the same for dtor).

Then in 2006 someone else can come along and fix that limitation,
watching out for the big trap that the ABI for constructors and
destructors can be *different* than for normal functions,
with hidden magic parameters.

Michael

Re: representing C++ constructors in GDB's symbol tables

[David Carlton]

On Fri, 17 Sep 2004 22:29:31 -0400, Michael Chastain <mec.gnu@mindspring.com> said:
> David Carlton <david.carlton@sun.com> wrote:

>> You can use "X(...)" to create a temporary object of type X.

> Sure.  And of course:

>   X my_x = X();

(But not "X my_x();", the C++ geek in me feels compelled to point
out. :-) )

David Carlton
david.carlton@sun.com