From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-19443-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 10723 invoked by alias); 17 Sep 2004 20:05:11 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 10695 invoked from network); 17 Sep 2004 20:05:09 -0000
Received: from unknown (HELO mx1.redhat.com) (66.187.233.31)
  by sourceware.org with SMTP; 17 Sep 2004 20:05:09 -0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8HK54lb031443
	for <gdb@sources.redhat.com>; Fri, 17 Sep 2004 16:05:04 -0400
Received: from zenia.home.redhat.com (sebastian-int.corp.redhat.com [172.16.52.221])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8HK4rr04871;
	Fri, 17 Sep 2004 16:04:53 -0400
To: Daniel Jacobowitz <drow@false.org>, david.carlton@sun.com
Cc: gdb@sources.redhat.com
Subject: Constructor names in the symbol table
From: Jim Blandy <jimb@redhat.com>
Date: Fri, 17 Sep 2004 20:05:00 -0000
Message-ID: <vt2u0twoe6x.fsf@zenia.home>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2004-09/txt/msg00149.txt.bz2


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.