From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3477 invoked by alias); 20 Apr 2006 14:38:43 -0000 Received: (qmail 3468 invoked by uid 22791); 20 Apr 2006 14:38:43 -0000 X-Spam-Check-By: sourceware.org Received: from mail.artimi.com (HELO mail.artimi.com) (217.40.213.68) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Apr 2006 14:38:37 +0000 Received: from mail.artimi.com ([192.168.1.3]) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 15:38:28 +0100 Received: from rainbow ([192.168.1.165]) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 15:38:28 +0100 From: "Dave Korn" To: "'Amarnath'" , Subject: RE: Query in MIPS HI and LO relocations Date: Thu, 20 Apr 2006 16:00:00 -0000 Message-ID: <019301c66488$16965a80$a501a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000201c66486$d17663b0$ad00a8c0@amarnath> 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/msg00284.txt.bz2 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....