> And thanks for doing work on a PowerPC port. From an lcrash point of
> view, you can do a lot of work without actually having LKCD kernel
> functionality in place. As long as you have a "namelist" file you
> can start up lcrash on a live system. You need to make sure that
> you run the configure script in lkcdutils with the --topdir flag
> set to your kernel source tree (if it's not /usr/src/linux). You will
> then be able to do a 'make namelist' from within the libklib directory.
> Use the resulting namelist in the following manner:
>
> # lcrash /boot/System.map /dev/mem namelist
>
> You will then be able to work on the architecture specific stuff like
> stack traces for running tasks. Or, you may already be beyond this point.
Yes, my porting effort is well beyond that point. A great many
things are working. It is easy when you start with good code :)
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
working.
What is your philosophy about how to handle de-genericizing
things like this? For example, one approach would be to
move the entire kl_kernelstack function into one of the
architecture-dependent files. Or have kl_kernelstack
call an architecture-dependent function to actually
get the esp0/ksp. Or have kl_task.c include an
architecture specific ".h" which defines a macro, which,
in the case of the PPC, would transform the "esp0" references
to "ksp" references?
If you can't get ahold of the PPC ".h" files for the
thread structure, etc., let me know and I'll mail 'em
out.
thx/ Steve James
steve_james@xxxxxxxxxxxxxxx
> Take care,
>
> Tom
>
|