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
On 24 Jan 2003 16:51:42 -0800,
Roland Dreier <[email protected]> wrote:
>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.
On 24 Jan 2003, Roland Dreier wrote:
> 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
On Fri, 24 Jan 2003 22:06:58 -0600 (CST),
Kai Germaschewski <[email protected]> wrote:
>On 24 Jan 2003, Roland Dreier wrote:
>
>> 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