Coded halts (i.e. placing a halt- or breakpoint message into the code),
have the disadvantage of being treated by the system like any other code changes.
They add entries to the change lists (both internal and in the changes file),
they mark the code as being changed and finally, they have to be removed eventually and not
been forgotten when an application is finally deployed or a class is checked into the
source code repository (although the source code manager checks for such leftover halts and
gives a warning).
ST/X provides two additional mechanisms for breakpointing,
which do not suffer from the above disadvantages:
- Method Breakpoints (Wrapped Methods)
- Statement (Line-) Breakpoints
Method Breakpoints
These are implemented by creating a wrapping method,
which enters the debugger and then calls the original method.
The original method is not recompiled, modified or touched.
Therefore, method breakpoints can be set on any method,
even those which contain primitive C code,
or for which no source code is available.
The debugger hides the context of the wrapper method in the walkback
and skips over any wrapper code
when single stepping. This makes those wrappers
almost completely transparent (there may be some exceptional
situations, where a wrapper is still visible in the walkback).
On entry into a wrapper, only the context's arguments are shown
(no method locals have been allocated yet).
A single step will bring you into the original
method, and the full context is shown.
Statement Breakpoints
These are created by the compiler
by compiling breakpoint calls into the generated byte code.
This instrumented recompilation is done whenever a statement breakpoint
is placed from either a system browser or the debugger
(click into the left gutter area, left of the line number).
Thus, a new method is actually created and installed in the class's method dictionary.
However, the class is not marked as being modified and no change list entries are created.
Due to this recompilation, the debugger is not able to place statement breakpoints
into an already active method's code, unless that method is already such a breakpointed method
(because a brand new method would be created,
which is only executed on the next call to the method,
but does not affect the currently active frame's execution).
Also, statement breakpoints cannot be placed in primitive C code.
Notice:
There are some places in the system which do not (yet) know about this
and therefore do not handle those breakpoints transparently.
Especially some browser windows still think that the original method (which was
shown initially) is now unbound (not connected to any class) and may malfunction.
These issues are being addressed and should be fixed by the time you read this.
Continue in
"Misc other Issues"...
![[stx logo]](../../../icons/stx.gif)
Copyright © 1995 Claus Gittinger Development & Consulting, all rights reserved
<cg at exept.de>
Doc $Revision: 1.7 $ $Date: 2021/03/13 18:24:53 $