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