From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5437 invoked by alias); 9 Feb 2005 17:09:43 -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 5379 invoked from network); 9 Feb 2005 17:09:35 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 9 Feb 2005 17:09:35 -0000 Received: (qmail 29784 invoked from network); 9 Feb 2005 17:09:35 -0000 Received: from localhost (HELO ?10.1.1.4?) (julian@127.0.0.1) by mail.codesourcery.com with SMTP; 9 Feb 2005 17:09:35 -0000 Message-ID: <420A43C8.5090008@codesourcery.com> Date: Wed, 09 Feb 2005 19:02:00 -0000 From: Julian Brown User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) MIME-Version: 1.0 To: Ian Lance Taylor CC: binutils@sources.redhat.com Subject: Re: [PATCH] Indicate dependency on personality routines for ARM EHABI References: <420A38B6.3010609@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00171.txt.bz2 Ian Lance Taylor wrote: > Julian Brown writes: > > >> /* These relocs are only used within the ARM assembler. They are not >> (at present) written to any object files. */ >>+ BFD_RELOC_ARM_NONE, > > > Why not just use BFD_RELOC_NONE here? > > In general you should only create a target specific BFD_RELOC enum > constant for relocations which only arise on a particular target. For > example, note that there is no BFD_ARM_RELOC_32. Perhaps it should be, and I tried it with that initially. The reason it isn't is because elsewhere in tc-arm.c:md_apply_fix3 BFD_RELOC_NONE seems to be used as an error indicator:- case BFD_RELOC_NONE: default: as_bad_where (fixP->fx_file, fixP->fx_line, _("bad relocation fixup type (%d)"), fixP->fx_r_type); ...which was being triggered when that relocation type was requested with fix_new(), I think. Is there another way around that? Cheers, Julian -- Julian Brown CodeSourcery, LLC