From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2147 invoked by alias); 23 Aug 2002 19:26:06 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2135 invoked from network); 23 Aug 2002 19:26:05 -0000 Received: from unknown (HELO tetsuo.nj.caldera.com) (63.124.204.226) by sources.redhat.com with SMTP; 23 Aug 2002 19:26:05 -0000 Received: from caldera.com (localhost.localdomain [127.0.0.1]) by tetsuo.nj.caldera.com (8.11.6/8.11.6) with ESMTP id g7NJbrC26753; Fri, 23 Aug 2002 15:37:54 -0400 Message-ID: <3D668F10.C739D3F5@caldera.com> Date: Fri, 23 Aug 2002 12:26:00 -0000 From: Petr Sorfa Organization: Caldera X-Accept-Language: en MIME-Version: 1.0 To: dberlin@dberlin.org CC: David Carlton , gdb , jlw@caldera.com Subject: Re: adding namespace support to GDB References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00302.txt.bz2 Hi Daniel, Well, let me or John Wolfe submit a patch with the imported declaration support next week. It will at least be some kind of comparison. Petr > > In article <3D6677D3.6E84743C@caldera.com>, Petr Sorfa > > writes: > > > > > Well to help things along I will be submitting a DWARF patch that > > > will supported imported declarations which are essential for FORTRAN > > > modules and C++ namespaces. > > > > Great, I look forward to reading it. > > > > > This is essential for the "using" commands in either language (of > > > course the compiler needs to generate the correct DWARF > > > ;o)). > > > > Yes, well, there is always that. > > This is easy, i've had patches to do it forever, that are already > approved. > I'm just waiting for gdb to get around to namespace support before > committing them, because it turns out we don't want to add a -gdwarf-3 > switch. > > Certainly it seems like a solution > > for C++ will initially have to get recreate namespace info from > > DW_AT_MIPS_linkage_name, and there's no way that we'll be able to > > allow users to use symbol names as if all the appropriate using > > directives were in effect, since that information simply isn't in the > > debug information that GCC is currently producing. (Though that's not > > the end of the world: we should be able to do name lookup using C++'s > > name resolution rules based on the enclosing function and its > > arguments, presumably.) > > > > David Carlton > > carlton@math.stanford.edu > > > >