[Top] [All Lists]

Re: Relocation problem with MIPS kernel modules

To: David VomLehn <>
Subject: Re: Relocation problem with MIPS kernel modules
From: "Maciej W. Rozycki" <>
Date: Fri, 7 Aug 2009 16:29:26 +0100 (BST)
Cc: Ralf Baechle <>, David Daney <>, GCC Help Mailing List <>, Linux MIPS Mailing List <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <>
User-agent: Alpine 2.00 (LFD 1167 2008-08-23)
On Mon, 3 Aug 2009, David VomLehn wrote:

> > The next and logical extension would be to permit multiple R_MIPS_LO16
> > records following a sequence of one or more R_MIPS_HI16 relocs as long as
> > all relate to the same symbol - which would be simple to support in the
> > kernel.
> This is what the orphaned R_MIPS_LO16 entries mentioned in the psABI quote
> are all about. The existing relocation code handles this in most cases, but
> could be juiced up a bit to do the check to verify the symbols match between
> the current R_MIPS_LO16 entry and the last R_MIPS_HI16 entry.

 Note there is no need to implement Ralf's suggestion -- if multiple HI16 
and LO16 relocations referring to the same symbol and addend are scattered 
throughout an object module, then the tools should combine them into pairs 
appropriately -- it does not matter exactly which ones of each are paired.  
Now once this has been done, a number of orphaned HI16 or LO16 relocations 
may remain, but there will only ever be one kind of these left and they 
can be attached to any of the pairs previously created.  My understanding 
is this is exactly what BFD does (modulo any possible bugs of course, as 


<Prev in Thread] Current Thread [Next in Thread>