From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9740 invoked by alias); 18 Nov 2003 17:41:35 -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 9726 invoked from network); 18 Nov 2003 17:41:34 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 18 Nov 2003 17:41:34 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8CA172B8F; Tue, 18 Nov 2003 12:41:31 -0500 (EST) Message-ID: <3FBA59CB.3040508@redhat.com> Date: Tue, 18 Nov 2003 17:41:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard.Earnshaw@arm.com Cc: Nick Clifton , gdb-patches@sources.redhat.com, binutils@sources.redhat.com Subject: Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly References: <200311181729.hAIHTQN14174@pc960.cambridge.arm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00381.txt.bz2 >> It's at this point, things get weird. >> >> BFD hands GDB a raw symbol table (ignoring coff m'kay) and then GDB >> implements the search algorithm. To implement a addr->attrib method, >> BFD's going to need a mechanism for searching GDB's symbol table and/or >> get at the underlying bfd symbol table. >> > > > But it still gets the symbol table via a bfd method, most likely > bfd_slurp_symbol_table. On normal elf32 systems this is > elf_slurp_symbol_table, but it doesn't have to be. The comment in that > file reads: > > /* Read each raw ELF symbol, converting from external ELF form to > internal ELF form, and then using the information to create a > canonical bfd symbol table entry. > > Note that we allocate the initial bfd canonical symbol buffer > based on a one-to-one mapping of the ELF symbols to canonical > symbols. We actually use all the ELF symbols, so there will be no > space left over at the end. When we have all the symbols, we > build the caller's pointer vector. */ > Note that the caller ends up using the pointer vector to iterate over the > symbols. What I'm suggesting is that on ARM, we replace > elf_slurp_symbol_table with armelf_slurp_symbol_table, which does the same > thing, but leaves the mapping symbols out of the caller's pointer vector. > Any function using that routine will now see only real symbols; the > mapping symbols have vanished entirely. GDB still needs to hang onto the entire underling table so that the addr->type method has access to the information that it needs. Stripping that stuff out of the "pointer vector" would force GDB to slurp the table twice. (BFD doesn't keep an internal pointer to this table around). > Yep, that's another option. GDB seems to be doing far too much mid-level > symbol manipulation at present, which certainly suggests that the > abstraction is wrong somewhere. Andrew