On Tue, Oct 20, 1998 at 06:39:21PM -0700, David S. Miller wrote:
> Relocating the code generated from this source later on will not be
> possible for ld. As knows this and dies ungracefully.
> Then why is this a supposed bug in Haifa? It looks to me there is a
> problem with how %hi relocs are assosciated with %lo ones in binutils.
It's not necessarily a bug in Haida itself but it gets visible when Haifa
is enabled. I haven't looked closely at the involved egcs code yet.
> The code you showed me looks perfectly legal.
For ECOFF and ELF, relocations against symbols are done in two parts, with
a hi16 relocation and a lo16 relocation. Each relocation has only 16 bits of
space to store an addend and a carry may have to be propagated between
the two. This means that in order for the linker to handle carries
correctly, it must be able to locate both the hi16 and the lo16 relocation.
Object files which don't contain any other information except the order in
the relocation table which could be used to find the hi16 / lo16 relocs which
The code I showed cannot be represented in a ELF or ECOFF object such that
the linker still knows which hi16 and which lo16 relocations are associated
with each other. Therefore it is not possible for the linker to correctly
do the hi16 relocations. Btw, all MIPS assemblers I know of will warn or
even error about that fragment.
The ABI is quite strict in that aspect, it wants one lo16 per hi16 for the
same symbol. Binutils relax that by allowing an arbitrary number of hi16
and one lo16 for the same symbol.