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

Reply via email to