Bernd Oppolzer wrote:
At a site where I was working some years ago we had a site specific
debugging tool which inserted break points into test objects (= load
modules) by changing certain instruction's opcodes to hex zero, then
catching the resulting 0C1 interrupts and this way tracking the
execution of certain branches of the test object (of course, the
debugger had to restore the correct opcodes after the 0C1 and resume
execution ... at the next break point, the hex zero was inserted
again and so on ...)
[snip]
I proposed to use TRAP instead.
FWIW, the current maintenance level of z/XDC allows setting
breakpoints either via X'00' "opcodes" or via TRAP2 instructions. I
wrote some articles about it at www.xdc.com.
Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS: dbc...@colesoft.com
Home page: www.colesoft.com
LinkedIn: www.xdc.com
Facebook: www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware
Tools: z/XDC for Assembler debugging
c/XDC for C debugging
At 6/20/2018 05:11 PM, Bernd Oppolzer wrote:
Am 19.06.2018 um 22:18 schrieb Farley, Peter x23353:
The recent discussion about the ability (or not) of setting R14
values in dbx at a break point while debugging brought me back to
an old and (for me) somewhat sore subject.
The z/Architecture hardware designers graced us with TRAP and TRAP4
and then with compare-and-trap instructions in the hardware.
z/OS has yet to provide ordinary application-mode programmers (or
for that matter compiler and debugger writers) with the tools to
use these hardware features. Because updates to the DUCT are
needed to properly utilize the TRAP features, only supervisor-state
code (and therefore only APF-authorized code) can use these
facilities in current z/OS versions, leaving ordinary application
programmers with no way to use any of these hardware features..
When will z/OS provide application programmers (and others) the
tools to utilize TRAP and friends?
Inquiring minds would love to know.
Peter
At a site where I was working some years ago we had a
site specific debugging tool which inserted break points into
test objects (= load modules) by changing certain instruction's opcodes
to hex zero, then catching the resulting 0C1 interrupts and this way
tracking the execution of certain branches of the test object (of course,
the debugger had to restore the correct opcodes after the 0C1 and resume
execution ... at the next break point, the hex zero was inserted
again and so on ...)
This worked, but because recovery from the 0C1 had to be executed for every
breakpoint, it was slow ... and there were many breakpoints ... at
every IF and
every LOOP.
I proposed to use TRAP instead. The problem was indeed the update of the DUCT,
which had to be done by privileged code. To do this, one of our
friendly system
programmers installed a site specific SVC for us, which allowed us
to do just this ...
modify the DUCT. Using this SVC, is was no problem to insert the breakpoints
as TRAP instructions instead of hex zeroes (two bytes to modify
instead of one)
and to control the debugger using a TRAP handler instead of recovery
from a 0C1 abend.
BTW: when first testing this, we used another SVC which was present
on our systems
at this time, allowing an arbitrary user program to write into
protected storage. At one
point during testing, some of our programmers used this incorrectly
and wrote into
address zero, which caused the whole system to halt :-)
This convinced our systems people
a) that this SVC had to be removed and
b) it would be much better to give us a facility to ONLY update the DUCT
Kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Dave Cole
ColeSoft Marketing
414 Third Street, NE
Charlottesville, VA 22902
EADDRESS: <mailto:dbc...@colesoft.com>dbc...@colesoft.com
Home page: www.colesoft.com
LinkedIn: www.xdc.com
Facebook: www.facebook.com/colesoftware
YouTube: www.youtube.com/user/colesoftware
Tools: <http://www.colesoft.com/zxdc/>z/XDC for Assembler debugging
<http://www.colesoft.com/c/>c<http://www.colesoft.com/c/>/XDC
for C debugging
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
