From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30876 invoked by alias); 7 Mar 2003 16:18:15 -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 30866 invoked from network); 7 Mar 2003 16:18:14 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 7 Mar 2003 16:18:14 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7153D2A9C; Fri, 7 Mar 2003 11:18:10 -0500 (EST) Message-ID: <3E68C642.30009@redhat.com> Date: Fri, 07 Mar 2003 16:18:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hilfinger@otisco.mckusick.com Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Ada-related patches, part I References: <200303040737.XAA17188@otisco.McKusick.COM> <3E64CCA7.50201@redhat.com> <200303050827.AAA25601@otisco.McKusick.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00161.txt.bz2 > Andrew, > > >> You don't appear to have a personal assignment for GDB on file. >> Assuming this is being done as an employee of Act, can you please use >> your act e-mail address in your ChangLogs. > > > Sure, if that will simplify things. For the record, however, > otisco.mckusick.com is the property of Ada Core Technologies. > > >> > * defs.h (enum language): Add language_ada. > >> >> This is ok. >> >> However, this change shouldn't be necessary. The language code should >> be sufficiently modula as to not need this. Can you/act at least >> investigate what would be needed to finish this? > > > Umm. But I notice quite a few tests scattered around the current > sources having the form ``if (suchandsuch == language_cplus...).'' In > particular, there are uses in such routines as symbol_natural_name > that are going to have to be extended for Ada. Perhaps, then, I am a > bit unclear what you intend here. (insert std disclaimer `ignoring c++ ...') > Are you simply saying that if I find a place in common (i.e., non ada- > *) files that requires different treatment for Ada than for another > language, I should introduce a new entry into the language_defn > structure to handle it object-orientedly rather than performing > specific ``... == language_ada'' tests? I'm certainly all for that. Yes. Before adding another case to a switch, see of the code can be pushed into the language vector. > Yes, I considered doing that, just as someone (you, as I recall) previously > asked for OP_ADA_ATTRIBUTE. However, these operators make sense > generically; it's just that only Ada uses them at the moment. > How's about if I change the comments instead to remove all > traces of Ada (see below)? Your choice. Which ever. The re-worded version is much better. >> (mind you, again, this shouldn't be needed. Instead these operators >> should be objects that language specific modules can just add). > > > I think I agree again, and normally would have done just this as a matter > of course, except that parse.c is not set up to be extensible in this > way. The functions prefixify_subexp and length_of_subexp both need to > know about these opcodes, as things now stand. Of course, if you are > asking me to reorganize parse.c and to revise expression.h so as to > make the operator set open-ended, just say the word. Wow! is there duplication or what. Would adding a new operator `generic' that, in the expression array, added: OP_GENERIC (better name?) (operator *) op ... op->length(exp) elements ... work? Something similar for the expression evaluator. What about op_print? I guess operator ends up containing similar information. Andrew