Re: ARM kernel module supported reloc types

[Andrew Doran <ad%netbsd.org@localhost>]

On Mon, Dec 29, 2008 at 09:47:47PM +0000, Julio M. Merino Vidal wrote:

> On Fri, Dec 19, 2008 at 01:44:32AM -0500, Rafal Boni wrote:
> > On Thu, Dec 18, 2008 at 09:35:02PM -0800, Matt Thomas wrote:
> > > Yes.  PC24 is not appropriate in dynamic shared library loading but  
> > > since kernel modules are simple .o files, it is appropriate.
> > 
> > Ok, so the next hole I fall into is symbols being too far for the PC24
> > reloc to resolve (printf in the example modules), and a crash related
> > to the auto-loading of the compat module.
> > 
> > The second one I haven't dug into very much (it gave me a reason to give
> > up for the night), but the first is interesting -- in the old LKM frame-
> > work, the lkmtramp.awk scripts generated trampoline code for all targets
> > of PC24 relocs... do we have an equivalent for the new modules?  Where is
> > this supposed to happen in the new world order?
> 
> Alright... so I have also been fighting this for the past two days and
> just now I find this thread.  Great, it'd have saved me some time!
> 
> So far I have also implemented support for R_ARM_PC24 and found the same
> problems as you: the target addresses do not fit into the 24 bits.  As a
> workaround, you can build the modules with -mlong-calls; at least that is
> working for my test module (src/tests/modules/k_helper).  But the
> trampolines are a solution and not a workaround as this.

This is slow, a better way to fix the "reach" problem is described here:

http://mail-index.netbsd.org/port-arm/2008/12/19/msg000587.html

> What I find now is that the data is not handled properly (or at least that
> seems to be the case).  For example, the module load fails because it
> raises an error during initialization, and the kernel tries to print the
> module's name but fails (empty string).  Similarly, the module load problems
> seem to be related due to missing data too.

There is probably a bug in arm's kobj_reloc().

Thanks,
Andrew