|Books on Debuggers firstname.lastname@example.org (2004-04-28)|
|Re: Books on Debuggers email@example.com (2004-04-29)|
|Re: Books on Debuggers firstname.lastname@example.org (Paul F. Dietz) (2004-04-29)|
|Re: Books on Debuggers email@example.com (Joe) (2004-04-29)|
|Re: Books on Debuggers firstname.lastname@example.org (glen herrmannsfeldt) (2004-05-02)|
|Re: Books on Debuggers email@example.com (2004-05-02)|
|Re: Books on Debuggers firstname.lastname@example.org (2004-05-08)|
|Re: Books on Debuggers email@example.com (Tim Bauer) (2004-05-08)|
|Re: Books on Debuggers firstname.lastname@example.org (2004-05-16)|
|From:||glen herrmannsfeldt <email@example.com>|
|Date:||2 May 2004 21:51:56 -0400|
|Posted-Date:||02 May 2004 21:51:56 EDT|
Nick Maclaren wrote:
> Mohd Hanafiah Abdullah <firstname.lastname@example.org> wrote:
>>Could anyone please recommend any good books on how to write a debugger?
>>[I've never seen one. -John]
> That is one reason that few modern debuggers approach the usability
> of the best 1960s and 1970s ones.
Questions about debuggers still remind me of the PER facility IBM
built into S/370, and still in the current z/Architecture.
PER allows a program (or OS or debugger) take control on:
1) Execution of a branch instruction with the target in
a specified address range.
2) Fetching an instruction from a designated address range.
3) Alteration of storage in a designated address range.
I don't know of any other architecture, before or since, that provides
this service to the debugger. While the system may run slower when
PER is on, it should be much faster than software simulation of such
features. Is it because programs were harder to debug in the 60's and
70's that such facility was designed?
[The x86 also has address stops. -John]
Return to the
Search the comp.compilers archives again.