From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11865 invoked by alias); 21 Feb 2003 17:19:42 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11849 invoked from network); 21 Feb 2003 17:19:41 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by 172.16.49.205 with SMTP; 21 Feb 2003 17:19:41 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 66EAFD34B6; Fri, 21 Feb 2003 09:19:41 -0800 (PST) Date: Fri, 21 Feb 2003 17:19:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Cc: Jim Blandy Subject: Re: [drow@mvista.com: Re: RFA: LOC_COMPUTED support] Message-ID: <20030221171941.GB910@gnat.com> References: <20030213211157.GA13537@nevyn.them.org> <20030221152420.GA32260@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030221152420.GA32260@nevyn.them.org> User-Agent: Mutt/1.4i X-SW-Source: 2003-02/txt/msg00525.txt.bz2 > > I think I found some switches that still need LOC_COMPUTED{,_ARG} cases: > > - ada-lang.c (ada_resolve_subexp, symtab_for_sym, > > ada_add_block_symbols, fill_in_ada_prototype) > > OK, what's up with that? The code bits in ada_resolve_subexp all > appear to be commented out. Is this code going away? Just from the top of my head, since I haven't directly been involved with the process of getting this file in: I think they are commented out until we can add the different pieces that would make them compilable and/or activatable. They will for sure be re-examined when we activate this code. > symtab_for_sym is pretty hokey too. All the Ada code reads like > someone wanted to keep changes local to ada-lang.c when they were > addressing general symtab weaknesses. I hope it can all go away > someday. The amount of duplication is pretty scary, too. I don't know the history of this code, Paul Hilfinger will probably know more, but I agree that getting rid of this code one day would be a tremendous improvement. Thanks for taking care of ada-lang.c in the interim. If any problem arises with the maintenance of these file, please let me and Paul know, we'll jump in to help. -- Joel