[Top] [All Lists]

Relocation problem with MIPS kernel modules

To: GCC Help Mailing List <>, Linux MIPS Mailing List <>
Subject: Relocation problem with MIPS kernel modules
From: David VomLehn <>
Date: Thu, 30 Jul 2009 11:49:23 -0700
Authentication-results: sj-dkim-4;; dkim=pass ( sig from verified; );
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; l=1428; t=1248979763; x=1249843763; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20David=20VomLehn=20<> |Subject:=20Relocation=20problem=20with=20MIPS=20kernel=20m odules |Sender:=20; bh=9f9x8kTKD4KD64RXA6AOtYHCBinkvCl44V99sMUwwhk=; b=IYxd54zu/pgLHeI5wP1XBokW/omvbhpWoAFYVYzx5xx8emV95M2GSeIGqE IckQS4haJvNOTXpEwSUQtMJrTfmSbwm8Fis3Nmpnc920o1tBjpuaaVp0/34M dvd+a85xRo;
Original-recipient: rfc822;
User-agent: Mutt/1.5.18 (2008-05-17)
I have a MIPS loadable kernel module that, when I try to insmod it, causes the
kernel to emit the message:

        module xyz: dangerous relocation

This message appears in three different places in arch/mips/kernel/module.c,
but this one is coming from apply_r_mips_lo16_rel(). The module code at
the location at which the error message is generated appears to be pretty
        lw v0,28564(s1)
with the expected relocation type of R_MIPS_LO16. The relocation before it
is R_MIPS_HI16, as expected, but for a different symbol. Before *that*
is another R_MIPS_HI16 relocation entry for yet a third symbol.

According to the MIPS ABI, for what it's worth, "Each relocation type of
R_MIPS_HI16 must have an associated R_MIPS_LO16 entry immediately following
it in the list of relocations." So, what's actually getting generated by
gcc and linker differs from the closest thing we have to an ABI of record for
MIPS processors.

What the kernel actually does differs from my interpretation of the MIPS ABI
in several particulars, which it has to do to relocate what it is actually
getting, but since I get the "dangerous relocation" error for a module that
appears to me to be valid, it may need to be fixed/enhanced.

So, who the heck knows what gcc and the linker are really generating and can
anyone suggest an algorithm for handling R_MIPS_HI16/R_MIPS_LO16 relocation
entries correctly?
David VomLehn

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