From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5729 invoked by alias); 18 Nov 2003 16:45:30 -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 5625 invoked from network); 18 Nov 2003 16:45:28 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sources.redhat.com with SMTP; 18 Nov 2003 16:45:28 -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 hAIGjIbo010299; Tue, 18 Nov 2003 16:45:18 GMT Received: from pc960.cambridge.arm.com (rearnsha@localhost) by pc960.cambridge.arm.com (8.11.6/8.9.3) with ESMTP id hAIGjI406889; Tue, 18 Nov 2003 16:45:18 GMT Message-Id: <200311181645.hAIGjI406889@pc960.cambridge.arm.com> X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha owned process doing -bs To: Andrew Cagney cc: Nick Clifton , gdb-patches@sources.redhat.com, binutils@sources.redhat.com, Richard.Earnshaw@arm.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 11:14:57 EST." <3FBA4581.1080904@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Nov 2003 16:45:00 -0000 From: Richard Earnshaw X-SW-Source: 2003-11/txt/msg00378.txt.bz2 > Nick, > > > I have recently committed a patch to the arm-elf port of GAS which > > causes it to generate special mapping symbols as required by the ARM > > ELF spec. Unfortunately this now means that when GDB shows a > > disassembly it can select one of the mapping symbols instead of the > > proper function name symbol. > > (GDB has minimal (=== asymbol), partial and full symbols. IN the below > "symbol" refers to the minimal symbol.) > > Hmm, what information do those mapping symbols provide? Dig dig (from > tc-arm.c) ... > > 4.4.7 Mapping and tagging symbols > > A section of an ARM ELF file can contain a mixture of ARM code, > Thumb code, and data. There are inline transitions between code > and data at literal pool boundaries. There can also be inline > transitions between ARM code and Thumb code, for example in > ARM-Thumb inter-working veneers. Linkers, machine-level > debuggers, profiling tools, and disassembly tools need to map > images accurately. For example, setting an ARM breakpoint on a > Thumb location, or in a literal pool, can crash the program > being debugged, ruining the debugging session. > > ARM ELF entities are mapped (see section 4.4.7.1 below) and > tagged (see section 4.4.7.2 below) using local symbols (with > binding STB_LOCAL). To assist consumers, mapping and tagging > symbols should be collated first in the symbol table, before > other symbols with binding STB_LOCAL. > > To allow properly collated mapping and tagging symbols to be > skipped by consumers that have no interest in them, the first > such symbol should have the name $m and its st_value field equal > to the total number of mapping and tagging symbols (including > the $m) in the symbol table. > > 4.4.7.1 Mapping symbols > > $a Labels the first byte of a sequence of ARM instructions. > Its type is STT_FUNC. > > $d Labels the first byte of a sequence of data items. > Its type is STT_OBJECT. > > $t Labels the first byte of a sequence of Thumb instructions. > Its type is STT_FUNC. > > This list of mapping symbols may be extended in the future. > > Section-relative mapping symbols > > Mapping symbols defined in a section define a sequence of > half-open address intervals that cover the address range of the > section. Each interval starts at the address defined by a > mapping symbol, and continues up to, but not including, the > address defined by the next (in address order) mapping symbol or > the end of the section. A corollary is that there must be a > mapping symbol defined at the beginning of each section. > Consumers can ignore the size of a section-relative mapping > symbol. Producers can set it to 0. > > Absolute mapping symbols > > Because of the need to crystallize a Thumb address with the > Thumb-bit set, absolute symbol of type STT_FUNC (symbols of type > STT_FUNC defined in section SHN_ABS) need to be mapped with $a > or $t. > > The extent of a mapping symbol defined in SHN_ABS is [st_value, > st_value + st_size), or [st_value, st_value + 1) if st_size = 0, > where [x, y) denotes the half-open address range from x, > inclusive, to y, exclusive. > > In the absence of a mapping symbol, a consumer can interpret a > function symbol with an odd value as the Thumb code address > obtained by clearing the least significant bit of the > value. This interpretation is deprecated, and it may not work in > the future. > > Note - the Tagging symbols ($b, $f, $p $m) have been dropped from > the EABI (which is still under development), so they are not > implemented here. */ > > 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. R.