> From: Havard.Eidnes@runit.sintef.no
>
> > It is possible to debug kernel crash dumps w/ gdb, though it can't
> > backtrace over trap frames properly (gdb doesn't understand them).
>
> Is there hope of this being fixed eventually, or are the trap frames
> processor-variant-specific (which would make this more difficult, I
> assume)?

Quite some time ago, I kludged the kernel trap entry stabs in locore.s by
hand to give frame sizes and register offsets to gdb, as if they were
procedure calls. This did, sometimes, enable gdb(1) to step over trap frames
and continue. It may have seen some bit rot since then. It's not the ultimate
right way, because, duhh, trap frames don't really look like procedure
calls.

There is a correct solution, but it involves fixing the alpha-specific
stack unwinder in gdb(1). There are two problems with that: one is that
alpha frames are really hard to follow, so the problem is difficult, and
the other -- really a facet of the first problem -- is that the gdb code
that presently deals with alpha stack frames is large and complex. It isn't
something easy to work on.

If someone presently beating their head against a wall and being flogged
would like a possibly less painful project, I will be happy to describe
the needed changes to gdb in private email. (Contact ross@netbsd.org :-)

Now, the ddb(4) traceback that Jason and I did is quite nice. It will step
over all the trap frames, identify the system calls .. it does everything
except give you the locals and registers per frame. However, it does this
by cheating .. it just compares each address against the trap vectors, all
of which it naturally knows about. Therefore this isn't really the right
way to fix gdb.

	ross