From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Lance Taylor <ian@zembu.com>
To: jj@sunsite.ms.mff.cuni.cz
Cc: binutils@sourceware.cygnus.com, davem@redhat.com
Subject: Re: [PATCH] Support for R_SPARC_OLO10 relocations
Date: Fri, 09 Jul 1999 09:52:00 -0000
Message-id: <19990709154144.7682.qmail@daffy.airs.com>
References: <19990705174729.B1736@mff.cuni.cz> <19990709012046.6401.qmail@daffy.airs.com> <19990709083424.B1736@mff.cuni.cz>
X-SW-Source: 1999-q3/msg00107.html

   Date: Fri, 9 Jul 1999 08:34:24 +0200
   From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>

   Yes, R_SPARC_OLO10 is part of the SYSV ABI sparc64 supplement.

OK.

   And it has a reason to have two addends: it is used for instructions which
   have signed 13bit field for the immediate, but the standard way of
   constructing addresses is sethi into some register, which sets upper 22 bits
   and then the second instruction fills in just 10 bits in the 13bit
   immediate. So, one usually does
	   sethi %hi(ab-24), %g1
	   ld [%g1 + %lo(ab-24)], %g2
   which means 3 bits in the second instruction's immediate are always 0.
   So the R_SPARC_OLO10 makes me use those 3 bits, so that the sethi can be
   shared among multiple instructions. The relocation is computed as
   (((SYMBOL + ADDEND) & 0x3ff) + SECONDARYADDEND) & 0x1fff. The secondary
   addend really does not behave like the normal addend in there, because bfd
   should not change it ever, no matter how is symbol moved.

My point was that the second addend could simply have been stored in
the object file itself.  The second addend can only be 13 bits, and
there are 13 bits available in the object file.  There was no need to
store it in the Rela structure.

However, since there is an existing ABI which acts differently, there
is no point.

Ian