This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Relocation problem with MIPS kernel modules
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
usually).
Maciej