Re: Books on Debuggers

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>
>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]


I don't think so. I think that it is because the people who developed
the hardware and the people who developed the debuggers talked more
directly, and were often part of the same team. Nowadays, we get the
following situation:


The hardware has debugging features that the hardware team use, but
do not document as they are version-specific, so the operating system
team cannot use them.


The operating system has debugging features that the operating system
team use, but do not document as they are version-specific, so the
run-time system team cannot use them.


The run-time system has debugging features that the run-time system
team use, but do not document as they are version-specific, so the
application developers cannot use them.


The end result is that the documented facilities are totally inadequate
for writing a debugger, and it has to be hacked up using a mixture of
relying on undocumented facilities and support from the application
being debugged. This is why a real error (e.g. overwriting) so often
causes the debugger to crash, and more often than not has it throw up
in its hands in horror and say "Yer whaa?"


You also get the effect that some forms of application debugging need
root privilege and even kernel modification. This is just plain crazy.
There is absolutely NO reason why a bulletproof, fully functional
debugger should not be written using only documented interfaces. But,
if those interfaces are not there, it can't be done.


Note that the above diatribe applies, mutis mutandis, to exception and
interrupt handling, resource control and hardware and software emulation.
The primitives needed for these are very similar.


There is the second aspect that modern IT development is driven almost
entirely by marketing, and it is MUCH easier to write a debugger that
is good enough for demonstrations and locating the cleanest sort of
value errors than to write one that handles real errors - let alone
one that can be used to track down code generation and run-time system
bugs. Of course, in a secure language with a bug-free compiler, ALL
errors are clean value errors - but let's stay in touch with reality.


Regards,
Nick Maclaren.

Return to the comp.compilers page.
Search the comp.compilers archives again.