From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6091 invoked by alias); 29 Mar 2005 15:44:42 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 5914 invoked from network); 29 Mar 2005 15:44:10 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org with SMTP; 29 Mar 2005 15:44:10 -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 j2TFhr4G005970; Tue, 29 Mar 2005 16:43:53 +0100 (BST) Received: from pc960.cambridge.arm.com (localhost.localdomain [127.0.0.1]) by pc960.cambridge.arm.com (8.12.8/8.12.8) with ESMTP id j2TFi7IF012777; Tue, 29 Mar 2005 16:44:07 +0100 Received: (from rearnsha@localhost) by pc960.cambridge.arm.com (8.12.8/8.12.8/Submit) id j2TFi7uk012775; Tue, 29 Mar 2005 16:44:07 +0100 X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha set sender to rearnsha@gcc.gnu.org using -f Subject: Re: [PATCH] Fix type and alignment of ARM/Thumb EABI mapping symbols From: Richard Earnshaw To: Julian Brown Cc: binutils@sources.redhat.com In-Reply-To: <424716CD.5030909@codesourcery.com> References: <424716CD.5030909@codesourcery.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: GNU Message-Id: <1112111047.12337.7.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 Date: Tue, 29 Mar 2005 16:54:00 -0000 X-SW-Source: 2005-03/txt/msg00866.txt.bz2 On Sun, 2005-03-27 at 21:25, Julian Brown wrote: > Hi, > > This patch fixes two problems: the type of mapping symbols is made > STT_NOTYPE (from STT_FUNC or STT_OBJECT from ARM/Thumb or data > respectively), and the alignment is corrected to not have the low bit > set for Thumb mapping symbols, in accordance with the latest version of > the ARM AAELF spec. > > Unfortunately altering the symbol type to STT_NOTYPE for mapping symbols > affects the output of disassembly from objdump. $a and $t were > previously treated as functions. When objdump tried to find the closest > symbol for possibly-symbol-relative offsets previously, it found those > mapping symbols since compare_symbols places functions first in a sorted > version of the symbol table. They were then rejected by the > symbol_is_valid hook (arm_symbol_is_valid) from the disassemble_info > struct, and the section name was printed instead. > > When the type of mapping symbols is changed to STT_NOTYPE, they are no > longer placed first in the sorted symbol list, so another symbol is used > instead. This causes test regressions, e.g. a symbol-offset address > which was previously output as: > > bl 8224 <.text-0xc> > > was output instead as: > > bl 8224 <_start-0xc> > > In the interest of preserving existing behaviour, I have fixed this by > adding a new disassemble_info hook which allows the symbol table used > for disassembly to have a target-specific hook for altering each symbol > (or remove it) in the remove_useless_symbols function. This sets the > BSF_FUNCTION flag for mapping symbols, which makes things behave the way > they used to, and possibly provides useful functionality for other > platforms as well. > > It may be better to just change the expected test output instead. Thoughts? > I think the tests should be fixed. Other targets (those that don't have mapping symbols) would almost certainly output _start in the example above, so the existing behaviour should be considered undesirable at best and probably just buggy. That should allow you to simplify your patch so that you don't need to touch MI parts. R.