At 11/9/2010 04:23 PM, Binyamin Dissen wrote:
Why does TEST cancel breakpoints on BRC instructions?
Any ideas why this weird restriction exists?
z/XDC does not have this restriction.
At 11/9/2010 05:45 PM, Rick Fochtman wrote:
I seriously doubt if TEST has been updated in "donkey's years". I've
noticed other restrictions.
z/XDC continues to be actively developed. Example: When IBM GA'd the
z/Enterprise this past September (which has over 100 new machine
instructions), we released to beta test our support for those new
instructions only 3 days later.
At 11/9/2010 05:52 PM, Starr, Alan wrote:
I'm reasonably sure that TEST / TESTAUTH establish a breakpoint by
actually replacing your code at that address with X'0A3D' (i.e. SVC 61).
Almost correct. The breakpoint SVC is 97, not 61. SVC 61 is used in
deferred breakpoint support. When TEST is running (TCBTCP=1),
Contents Supervisor issues SVC 61 (after it places a load
module/program object into user storage) so that deferred
breakpoints, if any, can be set.
At 11/9/2010 05:52 PM, Starr, Alan wrote:
This [the breakpoint SVC] is the fundamental reason why there are
some instructions which may not be breakpointed (e.g. EX or the target of EX).
z/XDC does not have either of these restrictions. We fully support
breakpoints both on an EX (and EXRL) or on their targets or on both
the EX/EXRL and their targets simultaneously.
Support for doing this is simplified because we use 1-byte wide X'00'
"opcodes" for our breakpoints, not 2-byte wide SVCs. Imagine what
happens when an EX target is replaced by an SVC 97. When the EX is
issued, the SVC number can be changed from 97 to a large number of
other values. Thus, a random SVC would be issued, not SVC 97. And so,
not only would TEST not receive control, but random wonderment would
also ensue.
Now imagine the same scenario but in XDC's case where only one byte
is changed (to X'00'), not two bytes. Then when the EX is issued, an
0C1 occurs, not a random SVC. Thus, XDC will always receive control
and will recognize and process the 0C1 as a breakpoint, just like normal.
At 11/9/2010 07:47 PM, Brian Kennelly wrote:
The offset in a BRC is relative to the instruction, whether it is
executed directly or by EX, so you cannot easily execute it out of
line without recalculating the offset or simulating execution. It
is easier to restore the instruction and execute inline.
Bingo!
In any case, z/XDC does not have this problem because all
breakpointed instructions are run by actually running them in place
in their true execution environments (not EX'ing them from the
debugger's environment). Accordingly, z/XDC has had mechanisms from
day one [back in 1980!] for restoring ATs once execution has moved past them.
This design permits z/XDC to support placing breakpoints on EVERY
machine instruction that z/Systems supports! regardless of how it
affects the execution flow or environment. (Well... every instruction
that I know about. And... uh... not on SIE. Sorry).
But even for unpublished instructions, z/XDC breakpoints will work as
they should just so long as those instructions don't branch.
Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Marketing WEB PAGE: http://www.xdc.com
736 Fox Hollow Road VOICE: 540-456-8536
Afton, VA 22920 FAX: 540-456-6658
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
