|[5 earlier articles]|
|Re: How do debuggers work? email@example.com (1991-12-04)|
|Re: How do debuggers work? firstname.lastname@example.org (1991-12-05)|
|Re: How do debuggers work? email@example.com (1991-12-05)|
|Re: How do debuggers work? firstname.lastname@example.org (1991-12-05)|
|Re: How do debuggers work? email@example.com (1991-12-06)|
|Re: How do debuggers work? firstname.lastname@example.org (1991-12-09)|
|Re: How do debuggers work? email@example.com (1991-12-15)|
|Re: How do debuggers work? tedg@apollo.HP.COM (1991-12-19)|
|Date:||Sun, 15 Dec 91 13:54:08 -0500|
| Does anyone have any pointers to interesting other OS debug kernel functions?
| Are there other ways of defining an OS debugging interface? I remember
| a Modula system where the debugger ran as a coroutine (PROCESS)
| along with the program.
In the same vein, on the Data General MV/Eclipse, the debugger interface
was linked into the program image, and the breakpoint instruction called
through a local vector in low memory. All high level debugging was done
through the normal IPC mechanisms of AOS/VS, via this stub code. The user
level assembly language debugger in the OS had a system call gate, and the
high level stub would call that gate if the breakpoint was not one of the
ones inserted by the high level debugger.
In the later days, the SWAT (tm) debugger took advantage of this to
provide watchpoints. The compilers were modified to emit NOP's in front
of each statement when /DEBUG was used, with an option to disable this.
When in watchpoint mode, the debugger would change all of the NOP's in
either the entire program or just the function to the breakpoint
instruction, and downline load code into the debug agent in the process
address space, which would check for the variable(s) being modified, and
if it wasn't, would return to the next instruction in the user program.
This was substantially faster than the normal sequence of doing an IPC to
the debugger for each statement. I've often times wished that the UNIX
debuggers did something similar. The UNIX debugger people looked down at
their noses at this, so I often times debugged the UNIX compiler on
AOS/VS, because it was much faster to find where something got modified.
Another trick that the debugger people did, was provide a user callable
function, which when called would start a debugger, if none was already
started, and if a debugger was running, wake it up. This allowed
debugging of long running production programs without advance
notification, in case something bad happened in the middle of the run.
Since debugger <-> debuggee communication just used IPC's and did not need
special priv's to attach or a parent/child relationship, this was fairly
Michael Meissner email: firstname.lastname@example.org phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
[High performance watchpoints are great things. I added them to gdb a while
ago, using the hardware debug registers on the 386. -John]
Return to the
Search the comp.compilers archives again.