From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14452 invoked by alias); 3 Apr 2004 12:04:05 -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 14441 invoked from network); 3 Apr 2004 12:04:03 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 3 Apr 2004 12:04:03 -0000 Received: from localhost (localhost [127.0.0.1]) by nile.gnat.com (Postfix) with ESMTP id 4F524F28F7; Sat, 3 Apr 2004 07:04:03 -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 26294-01-6; Sat, 3 Apr 2004 07:04:03 -0500 (EST) Received: by nile.gnat.com (Postfix, from userid 1345) id 0A9C4F2ADF; Sat, 3 Apr 2004 07:04:03 -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 02 Apr 2004 17:26:11 -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> <20040402092958.9443FF2F3E@nile.gnat.com> Message-Id: <20040403120403.0A9C4F2ADF@nile.gnat.com> Date: Sat, 03 Apr 2004 12:04:00 -0000 X-Virus-Scanned: by amavisd-new at nile.gnat.com X-SW-Source: 2004-04/txt/msg00092.txt.bz2 > I meant lazily demangling the names. I was wondering if the > demangling could be done at minsym reading time, or psymtab->symtab > conversion time, as the other languages do, when there is an I'd really be very reluctant to do this; it vitiates the entire point of this "search name" strategy, which was to avoid the storage requirements of demangled names. We adopted that strategy quite a few years ago, due in part to the fact that ACT had customers with LOTS of symbols and this was a way to save a good deal of symbol space. (Side comment: Indeed, until I started to make changes for the public tree, the ACT version of GDB never even cached demangled names at all, but instead demangled on the fly into a static area. One of you (Daniel or David) objected that this was dangerous, and that we should make permanent copies of demangled names, which is what gave rise to this whole caching problem. Oddly enough, we had never enountered difficulties as a result of the short lifetimes of our demangled symbols: it was just a contingent property of GDB that such persistance wasn't needed. Nevertheless, I had to agree that it is better not to rely on a property that is not guaranteed.) 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). Paul Hilfinger