|[6 earlier articles]|
|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-05)|
|Re: How do debuggers work? firstname.lastname@example.org (1991-12-06)|
|Re: How do debuggers work? email@example.com (1991-12-09)|
|Re: How do debuggers work? firstname.lastname@example.org (1991-12-15)|
|Re: How do debuggers work? tedg@apollo.HP.COM (1991-12-19)|
|From:||tedg@apollo.HP.COM (Ted Grzesik)|
|Organization:||Hewlett-Packard Company, Chelmsford, MA|
|Date:||Thu, 19 Dec 1991 22:19:30 GMT|
The Wang VS microcode provided some really nice features for the debugger.
All breakpoints were stored in a table that the microcode compared against
the executing PC. Thus the debugger didn't have to modify the code, or
anything nasty like that. The only drawback was that there were a limited
number of breakpoints (although most people never hit the limit).
Once very nice feature was the memory modification trap. Much like
breakpoints, there was a way to tell the microcode to trap on the
modification of a 4-byte quantity at a give address. To trap on
modification of aggregates, the debugger simply created a series of
"modtraps" in 4-byte increments.
One could also trap inside or outside a range of code, which was very
helpful for procedures with multiple entry points.
Also, the debugger could be invoked on a running program. This allowed
you to debug a problem that occured after a long run.
It was quite a shock for me when I started working on Unix debuggers after
having such nice kernel/microcode support.
Ted Grzesik Massachusetts Language Lab Hewlett-Packard Company
email@example.com Chelmsford, MA (508) 256-6600 x5959
[No question, watchpoints can be very handy, particularly on a machine with
hardware support for them. (Take that, RISC-lovers.) -John]
Return to the
Search the comp.compilers archives again.