Re: ARM kernel module supported reloc types

["Julio M. Merino Vidal" <jmmv%NetBSD.org@localhost>]

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.

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.

Cheers,

-- 
Julio M. Merino Vidal <jmmv%NetBSD.org@localhost>