Skip to contentSkip to conversation

modutils: using kallsyms when cross-compiling kernel

DISCUSSION Roland Dreier 3 participants 4 messages Jan 25, 2003

lore
Share & tools
lore
#0 lore raw

Hi, I'm trying to run kallsyms on x86 while cross-compiling a kernel for PowerPC. I'd like to use the kksymoops patch for 2.4, and the build process tries to call kallsyms. I had no problem building a version of kallsyms (from modutils 2.4.22) that runs on x86 and is targeted to PPC.

However, kallsyms seems to have endianness problems. Specifically, when it runs on my kernel, the test of MATCH_MACHINE(f->header.e_machine) in obj_load.c fails because EM_PPC is 0x14, but f->header.e_machine has 0x1400 in it.

Looking further in the code it looks like none of ELF handling stuff takes endianness into account. For example, e_type is also byte-swapped from what kallsyms is looking for.

Is my diagnosis correct? Is there any easy way for me to fix this (at least enough so that I can build a PPC kernel on x86 with kkallsyms support), or is the only solution to bite the bullet and fix the modutils ELF code to be endianness clean?

Thanks,
Roland

#1 lore raw
Quoted 8 lines · Roland Dreier

Looking further in the code it looks like none of ELF handling stuff takes endianness into account. For example, e_type is also byte-swapped from what kallsyms is looking for.

Is my diagnosis correct? Is there any easy way for me to fix this (at least enough so that I can build a PPC kernel on x86 with kkallsyms support), or is the only solution to bite the bullet and fix the modutils ELF code to be endianness clean?

You are correct. modutils was never designed to run on one system and handle modules created for another. To make it endian safe, all structures that are read or written from/to disk need a swab routine to be called after reading and before writing that structure. You also have to consider word size differences, e.g. ix86 -> ia64 uses different word sizes. Not a trivial task.

Google for kallsyms_i386_ia64.c. That is a hacked version of kallsyms that runs on i386 and handles ia64 modules. Different word size, same endianess. It is a starting point to hack a version for i386 -> ppc.

#2 lore raw
In reply to Roland Dreier
Quoted 4 lines · Roland Dreier

Is my diagnosis correct? Is there any easy way for me to fix this (at least enough so that I can build a PPC kernel on x86 with kkallsyms support), or is the only solution to bite the bullet and fix the modutils ELF code to be endianness clean?

You could of course also backport the current 2.5 kallsyms code. This has, though originally based on kallsyms, been completely rewritten and not much to do with the original patch anymore (and different objectives).

It generates the information as a .S file and uses the cross-assembler to generate the object code, so it does not have any of the above issues.

--Kai

#3 lore raw
Quoted 10 lines · Kai Germaschewski
Quoted 4 lines · Roland Dreier

Is my diagnosis correct? Is there any easy way for me to fix this (at least enough so that I can build a PPC kernel on x86 with kkallsyms support), or is the only solution to bite the bullet and fix the modutils ELF code to be endianness clean?

You could of course also backport the current 2.5 kallsyms code. This has, though originally based on kallsyms, been completely rewritten and not much to do with the original patch anymore (and different objectives).

The 2.5 kallsyms code is incomplete. It is missing all the section data which is required by kernel debuggers and profilers.
http://kerneltrap.org/node.php?id=500