Hi Steve,
"Matt D. Robinson" wrote:
>
> 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 :)
Thanks! :]
> >
> > 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?
Generally speaking, we're trying to have as little architecture specific
code as possible. At one time, the kl_kernelstack() function was in
an arch specific file, but I moved it (I didn't realize that there was
a conflict with the PPC). What I have done now is to move the guts of
the kl_kernelstack() call to a function called _kernelstack(), which
is located in the libklib/arch/<your_arch>/kl_kern.c file. You can pick
this change up from the LKCD source repository on SourceForge. If you
run across any other situations similar to this, you can put the arch
specific code there as well. BTW, we really should get you set up as one
of the LKCD developers, so that you can add your own changes (especially
the PPC stuff) to the LKCD project. Do you already have a SourceForge
login?
Thanks,
Tom
|