This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Reloc question


Richard Sandiford <rsandifo@cygnus.com> writes:

> Is it better to have a reloc refer to the operand that needs fixing up, or
> to the instruction that contains it?  I'd expected the former, based on
> ports like the i386 and m68hc11.  But it seemed to be generally accepted
> on the cgen list that this was not a good thing in general.  If, for
> example, you have a 2-word instruction with an absolute address in the
> second word, you shouldn't use a standard 32-bit reloc on that operand,
> but instead have a reloc such as BFD_RELOC_2ND_32_BITS_OF_64_BIT_VALUE, or
> similar.

Most ABIs define a minimal set of relocations, and they define them as
simply as possible.  That leads to fewer moving parts, and fewer
things for independent implementors to get wrong.  Also, most linkers
don't do any significant link time optimization anyhow.

But there is no requirement either way.  Clearly the more information
the linker has about the relocation, the more flexibility it has in
performing link time optimizations.  You just have to pick your
priorities.

If you ever expect an independent implementation, and you want to use
many different relocation types, you need to be sure that you define
each of them very precisely, and that you implement your definitions
correctly.

XCOFF is an example of a standard with a vast number of relocation
types which were incompletely defined.  It was impossible to implement
the GNU XCOFF linker from the spec.  It has been very difficult to
keep the GNU linker in synch with updated AIX releases--and indeed,
this has not been done with recent releases.  IBM presumably has no
real interest in supporting independent implementations, so they do
not see this as a drawback.

Ian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]