On Tue, May 24, 2011 at 02:43:54PM +0100, Tixy wrote:
Hi Dave
I've managed to reproduce a relocation error when loading a module built for Thumb. The runtime error message is:
section 4 reloc 247 sym '': relocation 30 out of range (0xbf9710c6 -> 0xbf96c000)
Relocation 30 is R_ARM_THM_JUMP24, and looking at apply_relocate() in arch/arm/kernel/module.c it looks like the error is caused by 'offset' being even here ...
/* only Thumb addresses allowed (no interworking) */ if (!(offset & 1) || offset <= (s32)0xff000000 || offset >= (s32)0x01000000) { pr_err("%s: section %u reloc %u sym '%s': relocation %u out of range (%#lx -> %#x)\n", module->name, relindex, i, symname, ELF32_R_TYPE(rel->r_info), loc, sym->st_value); return -ENOEXEC; }
I seem to remember you posting some similar issue to a mailing list recently, or is my memory faulty?
I have some labels declared in inline assembler, and after adding
.type name_of_label, %function
the relocation error goes away, presumably because the label is now thumbified by having bit 0 set.
It's hard to judge whether that's right or wrong without the example, but most probably the module loader is doing the right thing, and the fix you suggest is probably also correct.
However, usually relocations wouldn't be generated against symbols in inline assmbler since most things can be fixed up locally; so I wonder if you're doing something "interesting" which needs special attention ... ?
Under particular circumstances when using valid inline assembler, the compiler may cause the emission of relocations which cause the module loader to barf in a similar way to what you saw, but I don't know if this is what is biting you. This is relatively rare though, affecting the use of some low-level macro from <asm/uaccess.h> in loadable modules.
See
ARM: Thumb-2: Relax relocation requirements for non-function symbols http://article.gmane.org/gmane.linux.ports.arm.kernel/116054/
This might be what you were remembering. I'll follow up and repost this, but I plan to wait for the merge window to close first, since it's not top priority.
Cheers ---Dave