From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18630 invoked by alias); 12 Apr 2004 08:22:58 -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 18593 invoked from network); 12 Apr 2004 08:22:55 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 12 Apr 2004 08:22:55 -0000 Received: from localhost (localhost [127.0.0.1]) by nile.gnat.com (Postfix) with ESMTP id 03D32F2E7A; Mon, 12 Apr 2004 04:22:54 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07640-01-4; Mon, 12 Apr 2004 04:22:54 -0400 (EDT) Received: by nile.gnat.com (Postfix, from userid 1345) id 97735F2E7C; Mon, 12 Apr 2004 04:22:54 -0400 (EDT) From: Paul Hilfinger To: drow@false.org Cc: jimb@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <20040409215112.GB851@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 9 Apr 2004 17:51:12 -0400) 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> Message-Id: <20040412082254.97735F2E7C@nile.gnat.com> Date: Mon, 12 Apr 2004 08:22:00 -0000 X-Virus-Scanned: by amavisd-new at nile.gnat.com X-SW-Source: 2004-04/txt/msg00251.txt.bz2 > 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. Paul Hilfinger ACT, Inc.