From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19070 invoked by alias); 16 Apr 2004 04:11:56 -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 19055 invoked from network); 16 Apr 2004 04:11:52 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 16 Apr 2004 04:11:52 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i3G4BpJW018272 for ; Fri, 16 Apr 2004 00:11:51 -0400 Received: from zenia.home.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i3G4Bnj28531; Fri, 16 Apr 2004 00:11:50 -0400 To: drow@false.org Cc: Paul Hilfinger , gdb-patches@sources.redhat.com Subject: Re: [RFA] Introduce notion of "search name" 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> <20040409215112.GB851@nevyn.them.org> <20040412082254.97735F2E7C@nile.gnat.com> From: Jim Blandy Date: Fri, 16 Apr 2004 04:11:00 -0000 In-Reply-To: <20040412082254.97735F2E7C@nile.gnat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-04/txt/msg00339.txt.bz2 Paul Hilfinger writes: > > 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? > > If leaking is your concern, how about this: I'll arrange our global > hash table for demangled names to store the strings themselves in a > a corresponding global obstack. That way, the total amount of memory devoted > to this particular set of demangled names is easy to monitor. > > There are a few opportunities, I suppose, to clear the whole thing, > such as when someone executes 'file' or 'symbol-file' (with no > arguments). Not sure if they're worth exploiting. > > > > 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. > > I don't think that's a problem. I'll take another stylistic pass over > the Ada sources and then just check in our current versions. Since > they aren't compiled (yet), they can't break anything, after all. Daniel, you've got higher standards on this issue than I do, but I'd like to see your standards prevail. If you and Paul can work out something, then I'll approve of it.