On Feb 19, 2009, at 14:43, David Cole wrote:
The reverse case, though, is problematic: When you EX the
immediately following instruction, z/XDC's tracing process can get
stuck. Years ago, though, I had one customer who actually liked
this "defect". When he learned of this, he immediately started
using such code sequences as "gatekeepers" to try to keep an XDC
user out of code that he wanted to keep "secret". (Or at least make
tracing it exceedingly inconvenient.)
At 2/19/2009 05:04 PM, Paul Gilmartin wrote:
Oops? Breakpoint code overlays the EX target? A suitably enhanced
z/XDC should be able to handle this.
Hi Paul, In all cases *except* the "EX *+4" case, XDC does handle
things correctly. In particular, XDC is perfectly fine with setting a
breakpoint either on the EX or on its target or on both! (In the
"both" case, XDC will receive control first for the breakpoint on the
EX, then second for the breakpoint on the target, before allowing the
code to move on [.org].)
But I'll readily agree if you say it's worth neither the execution
overhead nor the coding resource.
Coding a solution for the "EX *+4" case was not, as they say,
"commercially feasible". (Coding solutions for the other cases was,
in my youthful exuberance, fun!)
Dave Cole REPLY TO: dbc...@colesoft.com
ColeSoft Partners WEB PAGE: http://www.colesoft.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