[PATCH] Support for R_SPARC_OLO10 relocations

Jakub Jelinek jj@sunsite.ms.mff.cuni.cz
Thu Jul 8 23:34:00 GMT 1999


On Thu, Jul 08, 1999 at 09:20:46PM -0400, Ian Lance Taylor wrote:
>    Date: Mon, 5 Jul 1999 17:47:29 +0200
>    From: Jakub Jelinek <jj@sunsite.ms.mff.cuni.cz>
> 
>    This patch adds support for R_SPARC_OLO10 relocation.
>    It is in fact a compound relocation equal to R_SPARC_LO10 and R_SPARC_13
>    with no symbol applied on top of it, so I have modelled the support from
>    elf64-mips.c which already supports compound relocations.
> 
> Are you copying some existing ABI?  I ask because this implementation
> seems overly complex.  There is already a place to store the addend:
> the instruction itself.  I don't see any reason to store an additional
> addend in the Rela structure.  The range of possible values would seem
> to be limited by the nature of the relocation.

Yes, R_SPARC_OLO10 is part of the SYSV ABI sparc64 supplement.
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.
> 
> This patch seems to have several parts which are unrelated to
> R_SPARC_OLO10 support, such as the readelf.c and the sparc-dis.c
> patches.  Please submit unrelated patches separately.  That will speed
> the process of checking them in.  Thanks.

I'll cvs update to what is in CVS now and post separate patches.
> 
>    --- ./include/elf/sparc.h.jj	Tue Jun 29 10:51:49 1999
>    +++ ./include/elf/sparc.h	Mon Jul  5 14:44:35 1999
>    @@ -138,9 +138,9 @@ END_RELOC_NUMBERS
> 
>     /* Relocation macros.  */
> 
>    -#define ELF64_R_TYPE_DATA(info)		(((bfd_vma) (info) << 32) >> 40)
>    +#define ELF64_R_TYPE_DATA(info)		(((bfd_signed_vma) (info) << 32) >> 40)
> 
> This bit of the patch appears to assume that a right shift of a signed
> value does an arithmetic shift.  However, C does not guarantee this:
> the result of a right shift of a signed negative value is
> implementation defined.

That's just a cosmetic thing. For actual linking it really does not matter,
because bfd will shift the value back and mask again into 24 bits, so it
will only appear in objdump/readelf output.

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jj@sunsite.mff.cuni.cz | http://sunsite.mff.cuni.cz
Administrator of SunSITE Czech Republic, MFF, Charles University
___________________________________________________________________
UltraLinux  |  http://ultra.linux.cz/  |  http://ultra.penguin.cz/
Linux version 2.2.10 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________


More information about the Binutils mailing list