From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26835 invoked by alias); 17 Feb 2004 15:57:41 -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 26827 invoked from network); 17 Feb 2004 15:57:40 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 17 Feb 2004 15:57:40 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 580022B92; Tue, 17 Feb 2004 10:57:39 -0500 (EST) Message-ID: <403239F3.70003@gnu.org> Date: Tue, 17 Feb 2004 15:57:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: [rfa] Add SYMBOL_SET_LINKAGE_NAME References: <20040216212406.GC17141@nevyn.them.org> <16433.15049.172030.577544@localhost.redhat.com> <20040216225743.GA1714@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00469.txt.bz2 > 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. Andrew