From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 330 invoked by alias); 18 Feb 2004 00:27:50 -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 321 invoked from network); 18 Feb 2004 00:27:47 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 18 Feb 2004 00:27:47 -0000 Received: by localhost.redhat.com (Postfix, from userid 469) id E77451A448A; Tue, 17 Feb 2004 19:23:29 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16434.45185.855584.104606@localhost.redhat.com> Date: Wed, 18 Feb 2004 00:27:00 -0000 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME In-Reply-To: <20040218002329.GA11115@nevyn.them.org> References: <20040216212406.GC17141@nevyn.them.org> <20040218002329.GA11115@nevyn.them.org> X-SW-Source: 2004-02/txt/msg00491.txt.bz2 Daniel Jacobowitz writes: > On Tue, Feb 17, 2004 at 09:23:47AM -0800, David Carlton wrote: > > On Mon, 16 Feb 2004 16:24:06 -0500, Daniel Jacobowitz said: > > > > > This patch adds a macro, SYMBOL_SET_LINKAGE_NAME, which is used to > > > set a symbol's name when the name should not be demangled. Used for > > > things like typedefs whose name comes from debug info. > > > > The idea is okay, but I don't like the name all that much. I once had > > a goal, which I've admittedly been lax about pursuing recently, that > > we would have a very clear distinction between linkage names (which > > really did mean names used by the linker) and natural names (i.e. the > > names in the source code), to the extent that, if we were to represent > > these by different types, then our code would almost compile. > > > > When we're talking about types, however, linkage names don't make much > > sense, only natural names. So, while it's true that your macro does > > set the field that, in the case of a symbol with both linkage and > > natural names, corresponds to the linkage name, that's really an > > implementation detail that should be shielded behind this macro. > > > > Having said that, I don't have any great suggestions for a better > > name. SYMBOL_SET_NATURAL_NAME? SYMBOL_SET_NATURAL_ONLY_NAME? Hmm. > > I don't want to call it SYMBOL_SET_NATURAL_NAME. It's not necessarily > the natural name. Other than that, I don't know. > > I'm just going to sit on this. The HP patches need to be revised > anyway, and people want me to draft a complete interface before doing > any cleanups. come on, that's not what I asked. > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer