From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29717 invoked by alias); 17 Feb 2004 16:01:29 -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 29709 invoked from network); 17 Feb 2004 16:01:28 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 17 Feb 2004 16:01:28 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1At7f4-0007o4-L7; Tue, 17 Feb 2004 11:01:26 -0500 Date: Tue, 17 Feb 2004 16:01:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME Message-ID: <20040217160126.GA29934@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Elena Zannoni , gdb-patches@sources.redhat.com References: <20040216212406.GC17141@nevyn.them.org> <16433.15049.172030.577544@localhost.redhat.com> <20040216225743.GA1714@nevyn.them.org> <403239F3.70003@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403239F3.70003@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00470.txt.bz2 On Tue, Feb 17, 2004 at 10:57:39AM -0500, Andrew Cagney wrote: > >On Mon, Feb 16, 2004 at 04:48:57PM -0500, Elena Zannoni wrote: > > > >>Daniel Jacobowitz writes: > >> > After this patch and my others from today there are no direct > >> > assignments to the symbol name. In addition to the cleanup value, I'm > >> > testing an approach which would change the storage of symbol names, > >> > which prompted me to do this. > >> > >>can you elaborate on where you are going? > > > > > >Sure. I'm not sure if it's actually going to end up this way, since > >I'm thinking it wasn't a great idea and it has some truly gross bits I > >haven't figured out what to do with yet - it was just a hack job last > >weekend. But here's what my current tree does. > > > >The C++ demangled name pointer in lang_specific is removed. The name > >pointer becomes a union, and a flag bit (there's about a byte's worth > >of empty space in general_symbol_info) is added. They look like this: > > Er, why not start by defining a relevant interface and then work > inwards? That way potential clients, such as paulh, can determine if it > is sufficient for their needs. The first implementation doesn't even > need to be fast, just correct. Once we've hard data on the interfaces > run-time behavioral characteristics we can consider symtab internal changes. Because the cleaner interface is not my goal - it's a side goal to my actual aims, which are improved GDB startup time and memory usage. An implementation which is not fast is a step backwards. I don't understand how you can propose to measure "hard data" on "run-time behavioral characteristics" without implementing the symtab internal changes - what am I missing? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer