From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2320 invoked by alias); 21 Apr 2006 06:55:10 -0000 Received: (qmail 2312 invoked by uid 22791); 21 Apr 2006 06:55:09 -0000 X-Spam-Check-By: sourceware.org Received: from ac-202-238-16-ind.acmet.com (HELO alice.acmet.com) (61.16.238.202) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 21 Apr 2006 06:55:06 +0000 Received: from amarnath (localhost [127.0.0.1] (may be forged)) by alice.acmet.com (8.11.6/8.11.6) with ESMTP id k3L4hpZ05319; Fri, 21 Apr 2006 10:13:51 +0530 From: "Amarnath" To: "'Dave Korn'" , "'Thiemo Seufer'" , "'Eric Christopher'" Cc: "'Binutils At Redhat'" Subject: RE: Query in MIPS HI and LO relocations Date: Fri, 21 Apr 2006 10:06:00 -0000 Message-ID: <000001c664fe$2d99c200$ad00a8c0@amarnath> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <019301c66488$16965a80$a501a8c0@CAM.ARTIMI.COM> Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00300.txt.bz2 Since I am getting the compiled->assembled output emitted in the following pattern, linking process is failing to calculate the address correctly. Pattern ------- hi relocation - R_MIPS_HI16 sdaoff relocation - R_MIPS_GPREL16 sdaoff relocation - R_MIPS_GPREL16 lo relocation - R_MIPS_LO16 The insertion of two other relocation in between the HI and LO is causing the problem in calculating the correct address. When the two relocations (HI and LO) are following immediately, it is getting linked correctly. Thanks for all your valuable information. Regards, Amarnath M > -----Original Message----- > From: Dave Korn [mailto:dave.korn@artimi.com] > Sent: Thursday, April 20, 2006 8:08 PM > To: 'Amarnath'; binutils@sources.redhat.com > Subject: RE: Query in MIPS HI and LO relocations > > On 20 April 2006 15:29, Amarnath wrote: > > > Hi all, > > > > I am having a query in the MIPS ABI. As per the SYSTEM V ABI, > > R_MIPS_HI16 relocation should be immediately followed by its > > corresponding R_MIPS_LO16. > > > > I would like to know whether this is specific to SYSTEM V architecture > > alone / the linker specification can be changed as per our own > > architecture. > > > > Please help me in understanding this. > > It's in order to make life easier for the linker. Because MIPS is a > USE_REL > target, the reloc operands must be stored in the immediate operand field > in > each instruction itself. This means that there's only room for 16 bits of > the > actual reloc in each instruction and the full relocation computation can't > be > done without being able to link the two parts together and reassemble the > full > 32-bit reloc easily. > > See this extract from the bfd internals manual: > > -------------------------------snip------------------------------- > If the format should use Rel rather than Rela relocations, define USE_REL. > This is normally defined in chapter 4 of the processor specific > supplement. > > In the absence of a supplement, it's easier to work with Rela relocations. > Rela relocations will require more space in object files (but not in > executables, except when using dynamic linking). However, this is > outweighed > by the simplicity of addend handling when using Rela relocations. With Rel > relocations, the addend must be stored in the section contents, which > makes > relocateable links more complex. > > For example, consider C code like i = a[1000]; where a is a global array. > The > instructions which load the value of a[1000] will most likely use a > relocation > which refers to the symbol representing a, with an addend that gives the > offset from the start of a to element 1000. When using Rel relocations, > that > addend must be stored in the instructions themselves. If you are adding > support for a RISC chip which uses two or more instructions to load an > address, then the addend may not fit in a single instruction, and will > have to > be somehow split among the instructions. This makes linking awkward, > particularly when doing a relocateable link in which the addend may have > to be > updated. It can be done--the MIPS ELF support does it--but it should be > avoided when possible. > -------------------------------snip------------------------------- > > > See also the comments on 'struct mips_hi_fixup' and on function > mips_frob_file() in /src/gas/config/tc-mips.c for more. > > > cheers, > DaveK > -- > Can't think of a witty .sigline today....