From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-37799-listarch-binutils=sources.redhat.com@sources.redhat.com>
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: <mailto:binutils-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/binutils/>
List-Post: <mailto:binutils@sources.redhat.com>
List-Help: <mailto:binutils-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
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 <julian@codesourcery.com>
User-Agent: Mozilla Thunderbird 0.9 (X11/20041124)
MIME-Version: 1.0
To: Ian Lance Taylor <ian@airs.com>
CC:  binutils@sources.redhat.com
Subject: Re: [PATCH] Indicate dependency on personality routines for ARM EHABI
References: <420A38B6.3010609@codesourcery.com> <m3hdkllmme.fsf@gossamer.airs.com>
In-Reply-To: <m3hdkllmme.fsf@gossamer.airs.com>
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 <julian@codesourcery.com> 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