From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29348 invoked by alias); 8 Nov 2003 22:55:29 -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 29341 invoked from network); 8 Nov 2003 22:55:27 -0000 Received: from unknown (HELO otisco.McKusick.COM) (209.31.233.190) by sources.redhat.com with SMTP; 8 Nov 2003 22:55:27 -0000 Received: (from hilfingr@localhost) by otisco.McKusick.COM (8.11.6/8.11.6) id hA8MtJK08216; Sat, 8 Nov 2003 14:55:19 -0800 Date: Sat, 08 Nov 2003 22:55:00 -0000 Message-Id: <200311082255.hA8MtJK08216@otisco.McKusick.COM> From: "Paul N. Hilfinger" To: carlton@kealia.com CC: gdb-patches@sources.redhat.com Subject: Interactions of symbol-lookup with language Reply-to: Hilfinger@gnat.com X-SW-Source: 2003-11/txt/msg00156.txt.bz2 David, The symbol-lookup facilities are now organized to adapt themselves to the current language. We've encountered some problems with this. 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. 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". In any case, we'd welcome your (and other maintainers') comments. Paul Hilfinger ACT, Inc.