From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1773 invoked by alias); 28 Feb 2007 06:01:43 -0000 Received: (qmail 1764 invoked by uid 22791); 28 Feb 2007 06:01:43 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 28 Feb 2007 06:01:37 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 3F86D48D1CC for ; Wed, 28 Feb 2007 01:01:35 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24422-01 for ; Wed, 28 Feb 2007 01:01:35 -0500 (EST) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 9E91448D1C6 for ; Wed, 28 Feb 2007 01:01:34 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id 5191FE7972; Tue, 27 Feb 2007 22:01:40 -0800 (PST) Date: Wed, 28 Feb 2007 06:01:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFA/stabs] 't' type declaration is equivalent to 'Tt' for Ada Message-ID: <20070228060140.GC13140@adacore.com> References: <20070209225249.GK3372@adacore.com> <20070227165404.GC31729@caradoc.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070227165404.GC31729@caradoc.them.org> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00369.txt.bz2 > > When we have a 't', the debugger builds a VAR_DOMAIN symbol. When we > > have a 'T', the debugger also builds a STRUCT_DOMAIN symbol. In Ada, > > there is no equivalent of the distinction between typedef and non-typedef. > > So as a result, I modified the stabsreader such that, for Ada, a 't' > > symbol would be treated as if it was defined with 'Tt'. > > I guess this is OK. It seems silly to rely on STRUCT_DOMAIN, but I > don't want to make intrusive changes to this code now - a drawback of > everything moving away from stabs is that it becomes harder to test. I must say I agree on all counts. We still have a handful of gcc-34 debuggers that still do a decent job with stabs, so we can help with the testing for a little longer. But I personally hope to be through with stabs within a year or two.... In the meantime, checked in. Thanks! -- Joel