On Tue, 16 Jan 2001 11:25:06 -0700 (MST),
Steve James <saj@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>However, we have a problem.
>libklib/kl_task.c:kl_kernelstack() is not architecture indepentdent.
>This is because the thread structure for the PPC is not the
>same as for the other three architectures. In particular,
>there is no member named "esp0". (They call that "ksp" on
>the PPC.) There could be similar problems in other libklib
>code that I will uncover as I get the stack backtrace stuff
FYI, I just went through a similar problem when porting kdb (kernel
debugger) v1.7 to IA64. The IA64 is particularly peculiar for several
* It has two stacks, the normal memory stack and a separate register
save engine stack.
* The first 8 parameters are passed in registers, any more parameters
are passed on the memory stack.
* It dumps process state in two separate structures on the memory
stack, one of which may not be present. You have to detect whether
the second structure is available.
* The only way to get an accurate stack backtrace is by using the
unwind information that gcc includes in the kernel and module
objects. The unwind code is interesting, as in "may you live in
interesting times", in any case it is completely IA64 specific.
* Data from the current function is allowed to use part of the
preceding stack frame. This is very, very confusing when marking out
kdb tries to abstract the stack information into a common struct
activation_record. But the IA64 showed how difficult that was to
generalise so for the moment, kdb v1.7 has a lot of hardwired code in
the IA64 arch directory. kdb v1.7 for IA64 is being reviewed by a
couple of other IA64 developers before general release, barring any
problems it will be released on Tuesday.