Tim Kelly <hockey@dialectronics.com> writes:

> There really needs to be better bookkeeping on this, not because there is
> something wrong with the current implementation but because on every single
> reported panic that I've seen on macppc that included registers it was from
> the frame ddb expects. Since in many, many cases the problem is not
> repeatable by others on the list, all we have to go by is what ddb gives
> us. With MCHK exceptions in particular, of which at least one list reader
> gets at a random occasion all too often, it is next to impossible to
> accurate isolate the problem without the correct register values and unless
> the user knows to dump the previous stack frame, anyone trying to help is
> SOL.

There are two things that would be useful:

1. Make trap() dump register state if it's about to panic.

2. Make the ddb backtrace dump trapframe register state when it
   traverses a trap. This would be useful both in panic situations and
   otherwise.

At least some other architectures do this; neither is very hard. A
common function could probably be used for both (though there might be
some trickiness around the ddb *pr indirection).

At a higher level, an issue here is that the code was not particularly
designed with the goal of being accessable or debuggable by
non-experts - usually, debug and panic messages are written by the
author of the code to be useful to them, and perhaps secondairly to be
useful for other people to report back.

        - Nathan