From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Jelinek To: Ian Lance Taylor Cc: binutils@sourceware.cygnus.com, davem@redhat.com Subject: Re: [PATCH] Support for R_SPARC_OLO10 relocations Date: Thu, 08 Jul 1999 23:34:00 -0000 Message-id: <19990709083424.B1736@mff.cuni.cz> References: <19990705174729.B1736@mff.cuni.cz> <19990709012046.6401.qmail@daffy.airs.com> X-SW-Source: 1999-q3/msg00099.html 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 > > 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) ___________________________________________________________________