Relocation problem with MIPS kernel modules

[Marshall B. Rogers]

@David VomLehn:

This is four days overdue, but here's a big document on the 32-bit MIPS ABI:
http://math-atlas.sourceforge.net/devel/assembly/mipsabi32.pdf

I haven't read it all, but it seems to cover everything you would ever
need, including the relocation types.

Regards,
Marshall

On Mon, Aug 3, 2009 at 8:19 PM, David VomLehn <dvomlehn@cisco.com> wrote:
>
> On Mon, Aug 03, 2009 at 10:20:30AM +0100, Ralf Baechle wrote:
> > On Thu, Jul 30, 2009 at 11:49:23AM -0700, David VomLehn wrote:
> >
> > > To: GCC Help Mailing List <gcc-help@gcc.gnu.org>,
> > >     Linux MIPS Mailing List <linux-mips@linux-mips.org>
> > > Subject: Relocation problem with MIPS kernel modules
> > > Content-Type: text/plain; charset=us-ascii
> > >
> > > 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
> ...
> > > 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.
> >
> > The GNU tools as an extension over the MIPS ABI allows an arbitrary number of
> > R_MIPS_HI16 relocations to be followed by a R_MIPS_LO16 symbol.  All
> > relocations of this sequence must use the same symbol, of course.  This is
> > a very old extension; I think it predates the Linux/MIPS port.
>
> Perhaps a foolish question, but is this documented anywhere? I know there is a
> a document over at http://gcc.gnu.org/gcc-3.4/mips-abi.html addressing some
> other MIPS ABI changes, but I didn't see this one. Obviously, we could put
> documentation on the linux-mips Wiki, with pointers to other documents, but
> I'm not sure this is the right place. I'm also concerned there could be other
> ABI changes/extensions that need to be included.
>
> >   Ralf
>
> David