From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32702 invoked by alias); 18 Nov 2003 17:29: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 32649 invoked from network); 18 Nov 2003 17:29:34 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sources.redhat.com with SMTP; 18 Nov 2003 17:29:34 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id hAIHTRbo014283; Tue, 18 Nov 2003 17:29:27 GMT Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id hAIHTQN14174; Tue, 18 Nov 2003 17:29:26 GMT Message-Id: <200311181729.hAIHTQN14174@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Andrew Cagney cc: Richard.Earnshaw@arm.com, Nick Clifton , gdb-patches@sources.redhat.com, binutils@sources.redhat.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly In-reply-to: Your message of "Tue, 18 Nov 2003 12:20:10 EST." <3FBA54CA.3080900@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Nov 2003 17:29:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-11/txt/msg00380.txt.bz2 > > So I think the bfd needs to export a bfd_map_address_to_type() interface > > that hides all the details of the representation behind it. What's less > > clear is what types need to be returned, for ARM we really need to return > > something like BFD_OBJECT_DATA, BFD_OBJECT_ARM or BFD_OBJECT_THUMB, but it > > would vary from processor to processor. > > 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. > That's why I mention the third one. Throw the whole problem back at BFD > :-) Why does GDB even need a minimal symbol table anyway .... > 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. R.