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: ian at zembu dot com
- Subject: Re: Ok to change so a target can define RELOC_..._BITS_...?
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Date: Mon, 6 Mar 2000 20:46:18 +0100
- CC: hans-peter dot nilsson at axis dot com, binutils at sourceware dot cygnus dot com
> Date: 6 Mar 2000 13:22:16 -0500
> From: Ian Lance Taylor <ian@zembu.com>
> ... And why don't the existing
> macros work?
Sorry, I didn't answer this one. The reason is that the relocs
have a kind-of-but-not-exactly big-endian bit-layout, for
reasons that became historical and a compatiblility issue before
it could be harmonized with BFD:
#define RELOC_EXT_BITS_EXTERN_LITTLE 0x80
#define RELOC_EXT_BITS_TYPE_LITTLE 3
#define RELOC_EXT_BITS_TYPE_SH_LITTLE 0
> Mind you, I don't know what CRIS is.
A 32-bit embedded CPU core. For those interested, there's
related info at <URL:http://developer.axis.com/>.
> (By the way, as you probably know, EXT means ``extended,'' not
> ``external.'')
Yeah, thinko; the offset is external to the actual code where
the reloc is applied.
> I'm surprised that you can use aout_link_input_section_ext as is if
> you have to change the macro definitions.
I guess the code was engineered to be generic enough; it seemed
it was just an oversight that include/aout/aout64.h
unconditionally defined the layout macros.
brgds, H-P