Tony Luck wrote:
The sorted ksymtab breaks ia64 (and possibly ppc64 and
parisc too).
Alex Chiang did the bisect to find this change as
the cause of the breakage. The problem is that ia64
expects that the first item in each ksymtab entry to be
a function pointer. The code in modpost that creates
.tmp_exports-asm.S doesn't know about types of exported
objects, so it uses __EXPORT_SYMBOL from linux/mod_export.h
for everything. This results in
PTR SYM(sym);
PTR SYM(__kstrtab_##sym);
which the preprocessor expands to entries like:
.long ____pagevec_lru_add
.long __kstrtab____pagevec_lru_add
which puts the address of the first instruction of the
function into the table, rather than the address of a
function pointer (which on ia64 is a two element data
object containing the code address and the global data
pointer).
The syntax you need for this* is:
.long @fptr(____pagevec_lru_add)
.long __kstrtab____pagevec_lru_add
Note that you must only use the @fptr(name) syntax for
function exports. Exported data items just need an address.
-Tony
* On ia64 ... powerpc and parisc might need something else.
Thanks! It doesn't sound too hard to retro-fit your suggestion.
Still, I can't help wondering if I've done this all wrong :-/. Perhaps
I should avoid the assembler. Instead, I could write a tool to sort the
ksymtab elf sections in-place (and mangle their relocations
accordingly). That should preserve any special handling for function
symbols without arch-specific special cases. It would also concentrate
all the magic in one tool - rather than it being scattered between the
modpost tool, mod_export.h, tmp_exports.S, and vmlinux.lds.h.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
