Steve James wrote:
> > 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
> 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?
I'd assume the second answer, but I'll let Tom answer
definitively since that's his ball of wax.
> If you can't get ahold of the PPC ".h" files for the
> thread structure, etc., let me know and I'll mail 'em