From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14756 invoked by alias); 10 Nov 2003 17:07:59 -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 14738 invoked from network); 10 Nov 2003 17:07:58 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 10 Nov 2003 17:07:58 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id D5302C6A0; Mon, 10 Nov 2003 09:07:57 -0800 (PST) To: Hilfinger@gnat.com Cc: gdb-patches@sources.redhat.com Subject: Re: Interactions of symbol-lookup with language References: <200311082255.hA8MtJK08216@otisco.McKusick.COM> From: David Carlton Date: Mon, 10 Nov 2003 17:07:00 -0000 In-Reply-To: <200311082255.hA8MtJK08216@otisco.McKusick.COM> (Paul N. Hilfinger's message of "Sat, 8 Nov 2003 14:55:19 -0800") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-11/txt/msg00193.txt.bz2 On Sat, 8 Nov 2003 14:55:19 -0800, "Paul N. Hilfinger" said: > In particular, in decode_line_1, there is a call to find_imps, an > Objective C function, which in turn calls lookup_symbol. When > decode_line_1 is called while in Ada mode, this latter lookup_symbol > acts like an Ada symbol lookup, which makes little sense given that > find_imps is concerned with Objective C code. We have encountered > cases where the result is anomalous. Ugh. I suppose it makes sense that the problem would arise in decode_line_1, though: by its nature, it often gets invoked to refer to functions in other files, which might be in other languages. > Our fix for the moment is simply to put a wrapper around decode_objc > to force the language to objc temporarily. We are a little > uncomfortable with submitting this kind of kludge publicly, and > would prefer something officially blessed. One possibility is to > have a variant of lookup_symbol that allows one to specify a > prevailing language for those cases where it matters. We have at > least one other place where we'd like to "look up a symbol as in C". That kludge wouldn't bother me too much if it were an isolated thing, but given that it's occurring more than once, I like your idea of adding a variant of lookup_symbol that specifies a language. My suggestions would be: * The comment before the new function should make it clear that the 'name' argument should be a demangled name. (Assuming, of course, that that fits all of the places where it's being used; if not, I'd like to hear about the exceptions.) It's okay for the implementation to call lookup_symbol (even though that function would then try to demangle it) - it's just that I've been trying to figure out which functions take demangled names and which functions take mangled names, and I don't want new functions to muddy the waters. * Don't add in all the arguments from lookup_symbol: just add in the ones you need. That function has too many arguments as it is, even though only certain combinations of arguments ever get used; I'd rather have new functions provide cleaner interfaces. (We can always add more arguments later if they're needed, after all.) David Carlton carlton@kealia.com