linux-mips
[Top] [All Lists]

Re: Relocation problem with MIPS kernel modules

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: Relocation problem with MIPS kernel modules
From: David VomLehn <dvomlehn@cisco.com>
Date: Mon, 3 Aug 2009 19:18:01 -0700
Authentication-results: sj-dkim-3; header.From=dvomlehn@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Cc: David Daney <ddaney@caviumnetworks.com>, GCC Help Mailing List <gcc-help@gcc.gnu.org>, Linux MIPS Mailing List <linux-mips@linux-mips.org>
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; l=1809; t=1249352281; x=1250216281; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dvomlehn@cisco.com; z=From:=20David=20VomLehn=20<dvomlehn@cisco.com> |Subject:=20Re=3A=20Relocation=20problem=20with=20MIPS=20ke rnel=20modules |Sender:=20; bh=6w5qH6tFpo6FIo1bh7rrjStGktrnabyq0Oxoq+uewF4=; b=Vs1hvEHV0B9aS+StId072B4RpRhqGEC+R6Fvsx2X8Qlfuh4pss0c21q77Z Tpjo6bl3izhBaHbW+8JJWTfY+A2l2bblgOq9xzzNsdZXWCUqRTreHV60Fc+C 6A4INnBgQY;
In-reply-to: <20090803235536.GB22543@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20090730184923.GA27030@cuplxvomd02.corp.sa.net> <20090803092030.GB30431@linux-mips.org> <4A773B85.6010004@caviumnetworks.com> <20090803201521.GA24691@cuplxvomd02.corp.sa.net> <20090803235536.GB22543@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.18 (2008-05-17)
On Tue, Aug 04, 2009 at 12:55:36AM +0100, Ralf Baechle wrote:
> On Mon, Aug 03, 2009 at 01:15:21PM -0700, David VomLehn wrote:
> 
> > > Actually I think it is the opposite:
> > >
> > > RELOCATION RECORDS FOR [.text]:
> > > OFFSET   TYPE              VALUE
> > > 00000000 R_MIPS_HI16       .bss+0x00000004
> > > 00000008 R_MIPS_LO16       .bss+0x00000004
> > > 00000014 R_MIPS_LO16       .bss+0x00000004
> > >
> > > We load the hi16 value into a register and then use multiple lo16  
> > > offsets for the follow loads and stores to the same location.  On a  
> > > read-modify-write we only want to load the base address one time.
> > 
> > This particular case is covered by the old MIPS Processor psABI:
> > 
> >     R_MIPS_LO16 entries without an R_MIPS_HI16 entry immediately preceding
> >     are orphaned and the previously defined R_MIPS_HI16 is used for
> >     computing the addend.
> > 
> > The code in module.c looks like it implements the extension to which Ralf
> > refers.
> 
> Which is useful for for branch delay slot scheduling like:
> 
>       ...
>       j       1f
>       lui     a0, %hi16(hello)
>       ...
>       j       1f
>       lui     a0, %hi16(hello)
>       ...
> 1:    jal     printf
>       addiu   a0, %lo16(hello)
> 
> hello:        .asciz  "hello, hola\n"
> 
> 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.

>   Ralf

David VomLehn

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