From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27349 invoked by alias); 18 Nov 2003 17:20:14 -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 27329 invoked from network); 18 Nov 2003 17:20:13 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 18 Nov 2003 17:20:13 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 5B7832B8F; Tue, 18 Nov 2003 12:20:10 -0500 (EST) Message-ID: <3FBA54CA.3080900@redhat.com> Date: Tue, 18 Nov 2003 17:20: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: <200311181645.hAIGjI406889@pc960.cambridge.arm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00379.txt.bz2 > So GDB and objdump both need this information? How does objdump handle >> all this? >> >> - should there be a BFD method that lets GDB better identify a user >> visibile [minimal] symbol (gdb's elf reader currently contains what can >> only be described as heuristics). >> >> - should there be a BFD method that, given an address and symbol table, >> indicates the relevant ISA/ABI? >> >> - or even just have BFD export name->addr and addr->name methods? >> >> Andrew >> > > > The real question should be "what does gdb/objdump need to know?". I > think the answer to this is that it needs to know what is at a particular > address in an image. In other words, it needs to be asking "what type of > object is at address X?" How that information is stored in the image is > not of particular interest outside of the BFD. In particular, it > shouldn't matter whether the information is stored in mapping symbols or > some other section in the object file. > > 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. 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 .... Andrew