From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21876 invoked by alias); 2 Apr 2004 09:30:04 -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 21780 invoked from network); 2 Apr 2004 09:29:59 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 2 Apr 2004 09:29:59 -0000 Received: from localhost (localhost [127.0.0.1]) by nile.gnat.com (Postfix) with ESMTP id D6119F2F52; Fri, 2 Apr 2004 04:29:58 -0500 (EST) 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 08364-01-6; Fri, 2 Apr 2004 04:29:58 -0500 (EST) Received: by nile.gnat.com (Postfix, from userid 1345) id 9443FF2F3E; Fri, 2 Apr 2004 04:29:58 -0500 (EST) From: Paul Hilfinger To: jimb@redhat.com Cc: drow@false.org, gdb-patches@sources.redhat.com In-reply-to: (message from Jim Blandy on 01 Apr 2004 10:20:07 -0500) Subject: Re: [RFA] Introduce notion of "search name" References: <20040303191550.7307DF2DB8@nile.gnat.com> <20040305035955.GH5320@nevyn.them.org> <20040305103925.A4815F2EE4@nile.gnat.com> <20040331221249.GA6811@nevyn.them.org> <20040401150022.GA30729@nevyn.them.org> Message-Id: <20040402092958.9443FF2F3E@nile.gnat.com> Date: Fri, 02 Apr 2004 09:30:00 -0000 X-Virus-Scanned: by amavisd-new at nile.gnat.com X-SW-Source: 2004-04/txt/msg00053.txt.bz2 > I have to say, I think our allocation rules are hairy enough already. > If there is some better solution on the horizon for lazy demangling's > allocation, I am relucantant to put in complex and slow mechanisms, > even temporarily. It's a step backwards, justified by work that isn't > even scheduled. > > Paul, how critical is this to the intent of your change? I haven't > reviewed it. Sorry, I'm not sure what that pesky pronoun "this" refers to here. The complex allocation is the one that goes symbol->bfd section->bfd->objfile. It is not critical at all; I use it only on the general principle that we try to allocate names things on obstacks. I have a simple fallback that just uses a hash table on malloced symbols on the theory that the set of demangled names does not generally change over a GDB session (unless, of course, you are in the habit of running 'file' on many different executables in one session or completely rewriting your program before reloading it into GDB), so that one would gain little storage saving from using an obstack anyway. Using just that fallback (at least until we come up with a better way of getting to an appropriate obstack) would simplify my code. Paul