* Query in MIPS HI and LO relocations @ 2006-04-20 14:50 Amarnath 2006-04-20 15:24 ` Thiemo Seufer ` (2 more replies) 0 siblings, 3 replies; 5+ messages in thread From: Amarnath @ 2006-04-20 14:50 UTC (permalink / raw) To: binutils 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Query in MIPS HI and LO relocations 2006-04-20 14:50 Query in MIPS HI and LO relocations Amarnath @ 2006-04-20 15:24 ` Thiemo Seufer 2006-04-20 15:36 ` Eric Christopher 2006-04-20 16:00 ` Dave Korn 2 siblings, 0 replies; 5+ messages in thread From: Thiemo Seufer @ 2006-04-20 15:24 UTC (permalink / raw) To: Amarnath; +Cc: binutils 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. The ELF ABI specifies this requirement. The GNU toolchain supports somewhat relaxed rules which allow some optimisations. > 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. Well, you can change it to anything you like, but it likely won't be compatible any more. :-) I recommend you stick with the model the GNU toolchain implements. Thiemo ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Query in MIPS HI and LO relocations 2006-04-20 14:50 Query in MIPS HI and LO relocations Amarnath 2006-04-20 15:24 ` Thiemo Seufer @ 2006-04-20 15:36 ` Eric Christopher 2006-04-20 16:00 ` Dave Korn 2 siblings, 0 replies; 5+ messages in thread From: Eric Christopher @ 2006-04-20 15:36 UTC (permalink / raw) To: Amarnath; +Cc: binutils On Apr 20, 2006, at 7:29 AM, 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. You're free to do whatever you want. I'd look at some of the comments in elfxx-mips.c for guidance, e.g. /* The combined value is the sum of the HI16 addend, left-shifted by sixteen bits, and the LO16 addend, sign extended. (Usually, the code does a `lui' of the HI16 value, and then an `addiu' of the LO16 value.) Scan ahead to find a matching LO16 relocation. According to the MIPS ELF ABI, the R_MIPS_LO16 relocation must be immediately following. However, for the IRIX6 ABI, the next relocation may be a composed relocation consisting of several relocations for the same address. In that case, the R_MIPS_LO16 relocation may occur as one of these. We permit a similar extension in general, as that is useful for GCC. */ -eric ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Query in MIPS HI and LO relocations 2006-04-20 14:50 Query in MIPS HI and LO relocations Amarnath 2006-04-20 15:24 ` Thiemo Seufer 2006-04-20 15:36 ` Eric Christopher @ 2006-04-20 16:00 ` Dave Korn 2006-04-21 10:06 ` Amarnath 2 siblings, 1 reply; 5+ messages in thread From: Dave Korn @ 2006-04-20 16:00 UTC (permalink / raw) To: 'Amarnath', binutils 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.... ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: Query in MIPS HI and LO relocations 2006-04-20 16:00 ` Dave Korn @ 2006-04-21 10:06 ` Amarnath 0 siblings, 0 replies; 5+ messages in thread From: Amarnath @ 2006-04-21 10:06 UTC (permalink / raw) To: 'Dave Korn', 'Thiemo Seufer', 'Eric Christopher' Cc: 'Binutils At Redhat' 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.... ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-04-21 6:55 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-04-20 14:50 Query in MIPS HI and LO relocations Amarnath 2006-04-20 15:24 ` Thiemo Seufer 2006-04-20 15:36 ` Eric Christopher 2006-04-20 16:00 ` Dave Korn 2006-04-21 10:06 ` Amarnath
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).