---

B.15 Debugging ¶

Debugging Lisp code is much easier with a fully functional Lisp. However, it is quite possible that a change made in the system can cause a bug to happen while running the cold core file. If this happens, it is best to use adb to track down the problem. Unfortunately, the core file (i.e., the remains of a process normally created by Unix when a process dies) generated by such a bug will be of no use. To get some useful information, follow these steps:

1. Look at the file /usr/lisp/lisp.map and find the entry points for the miscop routines error0, error1, and error2. These entry points are used to invoke the Lisp error system from the miscops. Write down the numbers beside these names. They are the addresses (in hex) of where the miscops are located when the cold core file is loaded into memory.
2. Run adb on the lisp file, i.e.:

   adb lisp
   

3. Set a breakpoint at the lispstart entry point:

   lispstart:b
   

4. Start the lisp program running, telling it to use ilisp.core (I’m assuming you’re in /usr/lisp):

   :r -c ilisp.core
   

5. After a while, you will hit the lispstart breakpoint. The core file has been mapped into memory, but control is still in the C startup code. At this point, you should enter breakpoints for all the error entry points described above.
6. Continue running the program by typing :c. Shortly after this, the C lisp program will give up control to Lisp proper. Lisp will start doing its initialization and will probably hit one of the error break points. At that point you can look around at the state and try and discover what has gone wrong. Note that the two files rg and st are useful at this point. Also, you should look at the document Internal Design of Common Lisp on the IBM RT PC by David B. McDonald, Scott E. Fahlman, and Skef Wholey so that you know the internal data structures.