From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14159 invoked by alias); 31 Oct 2003 17:36:29 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14147 invoked from network); 31 Oct 2003 17:36:26 -0000 Received: from unknown (HELO sunsite.ms.mff.cuni.cz) (195.113.19.66) by sources.redhat.com with SMTP; 31 Oct 2003 17:36:26 -0000 Received: from sunsite.ms.mff.cuni.cz (sunsite.mff.cuni.cz [127.0.0.1]) by sunsite.ms.mff.cuni.cz (8.12.8/8.12.8) with ESMTP id h9VFVv2c028474; Fri, 31 Oct 2003 16:31:57 +0100 Received: (from jakub@localhost) by sunsite.ms.mff.cuni.cz (8.12.8/8.12.8/Submit) id h9VFVv31028468; Fri, 31 Oct 2003 16:31:57 +0100 Date: Fri, 31 Oct 2003 17:36:00 -0000 From: Jakub Jelinek To: Andrew Cagney Cc: Daniel Jacobowitz , binutils@sources.redhat.com, gdb@sources.redhat.com Subject: Re: A gdb+bfd string pool? Message-ID: <20031031153157.GZ12344@sunsite.ms.mff.cuni.cz> Reply-To: Jakub Jelinek References: <3FA27C9B.1000702@redhat.com> <20031031151927.GA32700@nevyn.them.org> <3FA283A7.7080706@redhat.com> <20031031155102.GA1102@nevyn.them.org> <3FA29BDF.1000100@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA29BDF.1000100@redhat.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-10/txt/msg00350.txt.bz2 On Fri, Oct 31, 2003 at 12:29:03PM -0500, Andrew Cagney wrote: > > >>The interface or the implementation? The bcache interface is focused > >>and simple (something that can't be said for that hash table). The > >>hashtab could certainly be used in the implementation (as elf-strtab did). > > > > > >So does gdb/symtab.c. > > > > > >>Anyway, back to the question. Does a [global] common pool make sense > >>for BFD? > > > > > >Oh, you meant an _instance_, not a data structure. Sorry. > > More specifically, a single instance. Instead of having something like > a per-object file symbol bcache as was done with GDB, there would just > be a single global bcache (and it would never shrink). elf-strtab has a property which I'm not sure you really need in GDB, as it slow things down. It attempts to do suffix merging, ie. if you have p = "abcde" and q = "cde", r = "cde", s = "abcde" strings, then p = "abcde", q = p + 2, r = q, s = p. Storing strings in a hashtable is certainly cheaper for CPU time than this. Jakub