From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20902 invoked by alias); 6 Apr 2002 15:58:03 -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 20893 invoked from network); 6 Apr 2002 15:58:02 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 6 Apr 2002 15:58:02 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g36FvJm26487; Sat, 6 Apr 2002 10:57:19 -0500 Date: Sat, 06 Apr 2002 07:58:00 -0000 From: Daniel Berlin To: Andrew Cagney cc: Jim Blandy , , Benjamin Kosnik Subject: Re: C++ nested classes, namespaces, structs, and compound statements In-Reply-To: <3CAF06B6.8030809@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg00083.txt.bz2 On Sat, 6 Apr 2002, Andrew Cagney wrote: > > At the moment, GDB doesn't handle C++ namespaces or nested classes > > very well. I have a general idea of how we could address these > > limitations, which I'd like to put up for shredding M-DEL discussion. > > > > Let me admit up front that I don't really know C++, so I may be saying > > stupid things. Please set me straight if you notice something. > > > > In C, structs are essentially lists of member names, types, and > > locations (offsets from the structure's base address): > > > > struct S { int x; char y; struct T t; } > > > > (Unions are just the same, except that the offsets are all zero. That > > relationship carries through the entire discussion here, so I'm not > > going to talk about unions any more.) > > > > If you think about it just right (or just wrong), this is really very > > similar to the set of local variables associated with a compound > > statement: > > I'm very interested in hearing about what ACT did for Ada. As far as I > know Ada, with its packages et.al. has a very similar problem and, > potentially, working code. The last time I scanned the Ada changes (a few days ago), they hadn't handled this problem at all. Probably because gcc doesn't produce module/packages/etc debug info for Ada. --Dan > > Andrew >