From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23608 invoked by alias); 1 Apr 2003 00:31:18 -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 23600 invoked from network); 1 Apr 2003 00:31:15 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 1 Apr 2003 00:31:15 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 229D82B23; Mon, 31 Mar 2003 19:31:12 -0500 (EST) Message-ID: <3E88DDD0.2090603@redhat.com> Date: Tue, 01 Apr 2003 00:31: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: Adam Fedor Cc: David Carlton , GDB Patches , Daniel Jacobowitz Subject: Re: [RFA] Compile objc-lang.c, objc-exp.tab.c [1/5] References: <99FCC0F2-63CE-11D7-9F75-000A277AC1A4@doc.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00000.txt.bz2 > > On Monday, March 31, 2003, at 03:53 PM, David Carlton wrote: > > On Sun, 30 Mar 2003 19:23:08 -0700, Adam Fedor said: > > Here's my crack at doing [language-specific demangling]. > >> This patch bothers me: it doesn't handle Java cleanly, and I'm not >> sure about the 'options' argument to language_demangle. It seems to >> me that, at the very least, there should be a java_demangle function >> defined that takes the options passed in, applies '| DMGL_JAVA' to it, >> and calls cplus_demangle. > Sure. That makes sense. > >> But I also wanted to double-check: does 'options' really make sense >> for all language types? If I'm reading the patch correctly, it looks >> like Objective C just throws it away. If that's the case, then I >> don't think that 'options' should be part of the language vector: if >> C++ needs it for internal purposes, then C++ could have its own more >> flexible demangler with that option (which Java could also use), but >> the version in the language vector should be more restricted. > > > Then I should go back to the case where if we know the language is cplus or java, then call cplus_demangle(/java_demangle), otherwise use language_demangle? Either that, or add a FIXME comment explaining why the options shouldn't be there. The problem with trying to eliminate the parameter is that it also means eliminating it from things like fprintf_symbol_filtered(). While likely a good idea, it is getting beyond the scope of this immediate patch. >> Also, I'm not convinced that it's best for the unknown language >> demangler to always return NULL. Probably Adam's patch isn't too bad >> in that regard: it will change the behavior of 'maint demangle', but >> we can work around that if it's important, and it won't change the >> behavior of fprintf_symbol_filtered; those are the only places where >> Adam's patch actually calls language_demangler. But, given that we >> don't always reliably know the current language (and could conceivably >> figure that out via demangling, modulo Java/C++ confusion), I'm not >> convinced that returning NULL is the right thing. (Or that it isn't >> the right thing.) Hmm, good catch. Any reason for the unknown language demangler to not just do c++ demangling? Andrew