Constructor names in the symbol table

Constructor names in the symbol table

[Jim Blandy]

Hey you C++ guys (and anyone else who's interested):

I've noticed that constructors get entered into the full symbol table
under their unprefixed name.  That is, the following code:

    struct S
    {
      int x;
      S(int);
    };


    S::S (int _x)
    {
      x = _x * 2;
    }


    int
    main ()
    {
      S s(3);
    }

as compiled by GCC 3.4 produces a LOC_TYPEDEF entry for S, and then
two LOC_BLOCK symbols for the in-charge and not-in-charge
constructors, whose names are S.

When I do something like set a breakpoint on S::S(int), I don't get a
match from the full symbol table; instead, I get a match on the
demangled names in the minimal symbol table.

Is this the way it's supposed to work?  I would have expected
something in dwarf2read to have consulted processing_current_prefix
and produced a qualified name for the full symbol.

Re: Constructor names in the symbol table

[Daniel Jacobowitz]

On Fri, Sep 17, 2004 at 03:03:50PM -0500, Jim Blandy wrote:
> When I do something like set a breakpoint on S::S(int), I don't get a
> match from the full symbol table; instead, I get a match on the
> demangled names in the minimal symbol table.
> 
> Is this the way it's supposed to work?  I would have expected
> something in dwarf2read to have consulted processing_current_prefix
> and produced a qualified name for the full symbol.

I don't remember the details, but I believe this is part of the mess
caused by normally using mangled names.  But since the constructor is
abstract, it doesn't have a mangled name.

Probably producing a fully qualified name, when we don't have a linkage
name, would work.

-- 
Daniel Jacobowitz

Re: Constructor names in the symbol table

[David Carlton]

On Fri, 17 Sep 2004 18:55:50 -0400, Daniel Jacobowitz <drow@false.org> said:
> On Fri, Sep 17, 2004 at 03:03:50PM -0500, Jim Blandy wrote:

>> When I do something like set a breakpoint on S::S(int), I don't get
>> a match from the full symbol table; instead, I get a match on the
>> demangled names in the minimal symbol table.

>> Is this the way it's supposed to work?  I would have expected
>> something in dwarf2read to have consulted processing_current_prefix
>> and produced a qualified name for the full symbol.

> I don't remember the details, but I believe this is part of the mess
> caused by normally using mangled names.  But since the constructor
> is abstract, it doesn't have a mangled name.

> Probably producing a fully qualified name, when we don't have a
> linkage name, would work.

I tend to agree.

David Carlton
david.carlton@sun.com