From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Received: (qmail 19422 invoked from network); 9 Apr 2004 22:40:24 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 9 Apr 2004 22:40:24 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1BC3u4-0000HU-9J; Fri, 09 Apr 2004 17:51:12 -0400 Date: Fri, 09 Apr 2004 22:40:00 -0000 From: Daniel Jacobowitz To: Paul Hilfinger , Jim Blandy Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Introduce notion of "search name" Message-ID: <20040409215112.GB851@nevyn.them.org> Mail-Followup-To: Paul Hilfinger , Jim Blandy , gdb-patches@sources.redhat.com References: <20040402092958.9443FF2F3E@nile.gnat.com> <20040403120403.0A9C4F2ADF@nile.gnat.com> <20040303191550.7307DF2DB8@nile.gnat.com> <20040305035955.GH5320@nevyn.them.org> <20040305103925.A4815F2EE4@nile.gnat.com> <20040331221249.GA6811@nevyn.them.org> <20040402082955.CCEF3F2F2A@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040402082955.CCEF3F2F2A@nile.gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-04/txt/msg00226.txt.bz2 On Tue, Apr 06, 2004 at 09:35:16AM -0500, Jim Blandy wrote: > > Paul Hilfinger writes: > > Do you really object to our simply making permanent copies of these > > names as needed? (I'm perfectly happy to ditch the kludgy > > objfile-finding hack.) You can't expect to save any space by > > reclaiming these demangled names space when you reload the symbol > > file, because (as I argued before) the set of demangled names > > generally doesn't change much in such cases, and we are "interning" > > the demangled symbols, so that multiple computations of the same > > demangled symbol don't increase space. This particular choice of name > > storage is confined to the Ada module (the symbol table module doesn't > > apply free to names stored in symbols, partial symbols, or minimal > > symbols, so it doesn't care if one them has a longer than necessary > > lifetime). > > I tend to think it's not ideal, but okay. Daniel, you were unhappy > with this; did you have suggestions? I'm unhappy with it, partly because not having a lifetime for these things make it harder to identify memory leaks (of which we already have quite enough, thank you). But there are two options: - decide that lazily demangling is useful, and arrange to pass an objfile to every call to SYMBOL_DEMANGLED_NAME. This also affects, at least, SYMBOL_NATURAL_NAME and SYMBOL_PRINT_NAME. I think it wouldn't be hard, just messy. - decide that being picky about the storage lifetime doesn't matter, and Paul's approximation is good enough. I'm happier with the global hash table than I am with kludging around searching for an objfile, certainly. What do you think of the options? On Fri, Apr 02, 2004 at 03:29:55AM -0500, Paul Hilfinger wrote: > > What you did not explain is how [SYMBOL_DEMANGLED_SEARCH_NAME] > > is supposed to be different from SYMBOL_SEARCH_NAME. > > Well, the direct answer is that for Ada, > SYMBOL_DEMANGLED_SEARCH_NAME (sym) == NULL > whereas > SYMBOL_SEARCH_NAME (sym) == the "linkage name" of the symbol > Perhaps, now that you bring it up, it might be clearer simply to make > this a predicate: > SYMBOL_SEARCHED_BY_DEMANGLED_NAME (sym) > or something like that? I don't think that either of those divisions is general enough to be useful. Why should the search name have to be the linkage name or the demangled name? For C++ there are two potential 'search names' - the name without DMGL_PARAMS, or just the basename. Neither of these is the linkage or natural name. > > The existing ada_demangle never fails. How does that interact with > > what you said above? Hopefully not by tagging all minsyms as Ada! > > Ah, I have been putting off syncing the ada-* files with ours (they > aren't compiled at the moment, and I feel no need to clutter the > public file system with unused versions. However, perhaps it's time to > check in the current versions, which are considerably different from the > snapshot that's currently there. In short: you are quite right, and the > current Ada demangler returns NULL for non-Ada-mangled symbols. Perhaps it's time to do this again. I'm not sure how to handle it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer