This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Ok to change so a target can define RELOC_..._BITS_...?
- To: hans-peter dot nilsson at axis dot com
- Subject: Re: Ok to change so a target can define RELOC_..._BITS_...?
- From: Ian Lance Taylor <ian at zembu dot com>
- Date: 6 Mar 2000 13:22:16 -0500
- CC: binutils at sourceware dot cygnus dot com
- References: <200003061640.RAA07161@ignucius.axis.se>
Date: Mon, 6 Mar 2000 17:40:50 +0100
From: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
The file include/aout/aout64.h defines a bunch of reloc-layout
macros, RELOC_x_BITS_y_... like RELOC_EXT_BITS_TYPE_LITTLE,
including STD and BIG equivalents.
The to-be-submitted CRIS port (a little-endian target) uses
external relocs, but unfortunately needs definitions of these
macros that do not match the default.
I have to ask why a new port is using a.out. The a.out object file
format has been obsolete for many years. And why don't the existing
macros work? Mind you, I don't know what CRIS is.
(By the way, as you probably know, EXT means ``extended,'' not
``external.'')
I'd like to submit a patch to include/aout/aout64.h that
conditionalizes these macro settings, so a target can define
them before including e.g. aout32.h. It seems all users are
static functions, so a multi-target BFD should not break.
It's OK with me to add #ifndef/#endif around these macro definitions.
The a.out support is generally a mess, but it's not worth cleaning up
because a.out is obsolete anyhow.
Anyway, before I cook up patches, I'd like to make sure there's
consensus that this is the right way to generalize the target
reloc-layout. There might be related issues; I'm trying to
separate what I can.
I'm surprised that you can use aout_link_input_section_ext as is if
you have to change the macro definitions.
Ian