STREAMS/UX for the HP 9000 Reference Manual

Debugging STREAMS/UX Modules and Drivers

Using adb

Obtaining Register Contents from Trap save_state or panic_save_state Areas

If the system core dump was produced by a panic or a trap, copies of all the

registers at the time of the trap or panic were saved in memory and are

available in the core dump. For a trap, the registers are saved on the stack, in

the order speciﬁed in the struct save_state, which is deﬁned in

/usr/include/machine/save_state.h. For a panic, the registers are saved in a

statically allocated memory location called panic_save_state, in the order

speciﬁed in the struct rpb, which is deﬁned in /usr/include/machine/rpb.h.

See the examples at the end of this chapter for details of how to access

registers in the trap save_state area. The mechanics of accessing

panic_save_state ﬁelds are similar, though the offsets into the save area are

different. For example, if you want to get r3 out of the panic_save_state

area, look at /usr/include/machine/rpb.h and note that the ﬁeld rp_gr3 is the

sixth word in struct rpb. Therefore, it can be found at panic_save_state + 5

words == panic_save_state + 0x14.

Not all registers in these save areas are guaranteed to be the same as at the

time of the panic or trap, because some registers must be used by the system

to execute the panic or trap path and save away the other registers. Registers

which may not be preserved are r1, r19 - r22, r31, arg0, arg1, arg2, and arg3.

Use your judgment with the contents of these registers in the save areas. If

they look odd, they may have been overwritten.

If your stack trace includes a call to trap(), it will also have a call to panic()

higher up (later in time) than the trap. In this case, it is safer to look in the

trap save_state structure on the stack than the panic_save_state area for

registers you are curious about, because the trap saved the registers closer in

time to when the problem which caused the system crash occurred.