[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ARM kernel module supported reloc types
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:
> 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().
Main Index |
Thread Index |