Peter Relson wrote:
This is because the SVC 144 routine uses register 14 to exit
That is unlikely to be relevant. Registers used by an SVC routine do not
necessarily have any effect on the registers of the SVC issure.
Peter Relson
z/OS Core Technology Design
Yeah - that's what I thought - which is why I was confused
by the statement in the doc... it seems to say, to my reading,
that while other register values can be changed (by a ptrace
call to effect the change) during the SVC 144 routine, R14
cannot be changed, because SVC 144 uses it (and thus, restores
it to the previous value.) In this situation, we absolutely
want to alter the state of the program that invoked the SVC.
That is, a debugger, during the processing of the break-pt
using ptrace facilities, can change the register values that
will be in-place when the target program resumes execution; all
except, that is, R14. (t can, for example, even change the
PSWA (well - the low 4 bytes anyway), but not R14.
The restriction seems a little awkward, I suppose. And, I was wondering
why the SVC 144 would use R14 for the return (via some branch?) instead
of something that would allow R14 to be changed... especially since this
is an OS-level interface. Surely some other mechanism could be used
for resuming the program that didn't involve relying on R14 (like
a RESUME-PROGRAM or LOADPSW, etc..)
But - I have to admit to complete ignorance (something I may have known
at one time and now long forgotten) about how an SVC is obliged to
return.
Just curious about how/why the restriction pop'd up...
And, if SVCs architecturally have this restriction, then perhaps an SVC
isn't the best way for PTRACE to do its break-pts?
- Dave R. -
--
[email protected] Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
