From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23721 invoked by alias); 17 Feb 2004 23:10:26 -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 23710 invoked from network); 17 Feb 2004 23:10:24 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 17 Feb 2004 23:10:24 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 4CB7C2B92; Tue, 17 Feb 2004 18:10:17 -0500 (EST) Message-ID: <40329F59.6070009@gnu.org> Date: Tue, 17 Feb 2004 23:10: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> <403239F3.70003@gnu.org> <20040217160126.GA29934@nevyn.them.org> <16434.26365.373673.881423@localhost.redhat.com> <20040217192919.GA31445@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg00487.txt.bz2 > > 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? I was refering to the interface, not the implementation. For instance: - how often it is called? - when it is called? - with what parameters it is called? - how time critical are the calls? And of course, how many existing interfaces can, as a consequence, be deprecated, obsoleted or deleted. The implementation is secondary. As PaulH noted, the initial implementation could even be based on the existing structure (just stripping off trailing parameter list). Elena wrote: > The symbol table is already a mess, with multiple redundant > interfaces. At the moment there isn't a clear picture of what various > bits of gdb need from the symbol table. How do we know the direction > we are going is improving things generally across the board? How can > we know that, if this is not the case, the impact is not too heavy on > other parts and we can live with the tradeoff? In the -file-list-exec-source-files discussion, notice that I'm trying to emphasize that things need to be a step removed from the symbol table - define the requirements according to the users needs, and not according to the existing symtab implementation. Andrew