ptrace + SVC 144 + R14 + dbx setting register values

[Thomas David Rivers]

The doc on the BPX1PTR (ptrace) facility indicates that
an SVC 144 should be used to set a break-point, but it
very carefully then goes on to say this:

Any modification that is made to register 14 with a PT_WRITE_GPR
request is lost. This is because the SVC 144 routine uses register 14
to exit.

which is a little surprising - because there might be really good
reasons to want to change register 14 at a break-point.

I tried to change $r14 in dbx at a break-pt and sure enough, couldn't do it.

Then I tried setting $r0 to something - and that didn't work either...
(using the dbx command:
set $r0=5
for example - which got no complaints but also didn't perform the task.)
I didn't find anything in the dbx documentation that says "oh - you can't
set $r<n> (general register) values."

So - this has led me to ask a question - can you set register values in dbx
when you reach a break point? Or - is this a bug? Or - more likely - am
I not
doing something right?

And - why would register 14 be so carefully carved-out? Seems like the
SVC 144
could "return" without requiring R14, perhaps via some LOADPSW or similar
approach within the bowels of the OS...

Thoughts ??

- Thanks -
- Dave R. -

[Paul Gilmartin]

Post by Thomas David Rivers
And - why would register 14 be so carefully carved-out? Seems like the
SVC 144
could "return" without requiring R14, perhaps via some LOADPSW or similar
approach within the bowels of the OS...

How about just B address(0,0) instruction constructed in temp storage instead of BR.
(And gotta set AMODE and program mask, etc.)

Hmmm. Can one rely on content of program mask (especially ILC) aftr a
breakpoint?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Seymour J Metz]

Normally, when a type 2, 3 or 4 SVC exit, the exit routine restores registers R2 through R14 from the RB. SVC 144 must be doing something weird.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Thomas David Rivers <***@DIGNUS.COM>
Sent: Thursday, May 31, 2018 5:05 PM
To: IBM-***@listserv.ua.edu
Subject: ptrace + SVC 144 + R14 + dbx setting register values

The doc on the BPX1PTR (ptrace) facility indicates that
an SVC 144 should be used to set a break-point, but it
very carefully then goes on to say this:

Any modification that is made to register 14 with a PT_WRITE_GPR
request is lost. This is because the SVC 144 routine uses register 14
to exit.

which is a little surprising - because there might be really good
reasons to want to change register 14 at a break-point.

I tried to change $r14 in dbx at a break-pt and sure enough, couldn't do it.

Then I tried setting $r0 to something - and that didn't work either...
(using the dbx command:
set $r0=5
for example - which got no complaints but also didn't perform the task.)
I didn't find anything in the dbx documentation that says "oh - you can't
set $r<n> (general register) values."

So - this has led me to ask a question - can you set register values in dbx
when you reach a break point? Or - is this a bug? Or - more likely - am
I not
doing something right?

And - why would register 14 be so carefully carved-out? Seems like the
SVC 144
could "return" without requiring R14, perhaps via some LOADPSW or similar
approach within the bowels of the OS...

Thoughts ??

- Thanks -
- Dave R. -




--
***@dignus.com Work: [phone]
Get your mainframe programming tools at http://secure-web.cisco.com/1CzGrAdWjXouncBLAMgEAPueYDApT9-f1uEuoLulXmy2splM8ZKR8OXMkqkQrbMigAXnOsCOp3rgUSrvuvWAzwY3msOgGPIHPtBFEkbXpMlWO1AneA1yUEcsP4qRLy1-W4Wy6PbMonzzeARd4hGq0NjENaiirlHgNWMxBz4dQqjDLgEi0bzml7283sIqZGZF20myW4ZlHsch57QERuTtnqqJgD-nCjuckYRlfEfEEtuK6YwCuOd8jNPHgAn8yn9H-6ct8Do2EsjSKabvOZ0m5jW_sW_loQQ-bNZsqZA709VyHKOc671p7RGJiiKlFHyx9ZxhAzTsW0I5oupDRvhNZlYdrDH7jYQhQHPH2xMc4VNJ48f0gP4W7tHFXm6c6Z37V/http%3A%2F%2Fwww.dignus.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Peter Relson]

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


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Thomas David Rivers]

Post by Peter Relson

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. -

[Paul Gilmartin]

Post by Thomas David Rivers
And, if SVCs architecturally have this restriction, then perhaps an SVC
isn't the best way for PTRACE to do its break-pts?

How does PER work? I believe it's nondisruptive. And I believe VM gives the
end user control over PER.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Seymour J Metz]

PER uses program interrupts, not an SVC.

That said, calling an SVC does not normally alter R14; the SVC would have to do something unusual.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@listserv.ua.edu>
Sent: Sunday, June 3, 2018 9:58 PM
To: IBM-***@listserv.ua.edu
Subject: Re: ptrace + SVC 144 + R14 + dbx setting register values

Post by Thomas David Rivers
And, if SVCs architecturally have this restriction, then perhaps an SVC
isn't the best way for PTRACE to do its break-pts?

How does PER work? I believe it's nondisruptive. And I believe VM gives the
end user control over PER.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Tony Harminc]

Post by Seymour J Metz
PER uses program interrupts, not an SVC.

To say PER "uses" program interrupts is of course true, but sounds
slightly odd. PER interrupts are a specific subclass of program
interrupts that can occur concurrently with "normal" ones; it's very
different from debuggers that insert an invalid opcode in order to
produce a program interrupt.

Post by Seymour J Metz
That said, calling an SVC does not normally alter R14; the SVC would have to do something unusual.

Post by Paul Gilmartin
How does PER work? I believe it's nondisruptive. And I believe VM gives the
end user control over PER.

Yes. VM does. And because virtualization is so cool, you can have
virtual PER events taking place within z/OS while "real" PER events
within z/OS (or of course other guests) are being handled by z/VM. All
for some values of "virtual" and "real". And z/OS could surely have
something like VM/s PER-using commands, but it has chosen to give
ownership of PER to SLIP, which makes for a very poor debugger. A
privileged program could easily enough set up PER on its own, but
catching and handling any resulting interrupts without seriously
annoying SLIP would be the trick. Is there an interface to SLIP to
tell it that someone else is using PER too, I wonder.

Is anyone here old enough to remember DSS (the MVS Dynamic Support
System), which was a system level debugger that predates SLIP? *It*
used to own PER, but I believe it was removed in MVS 3.6 or so. There
are one or two remnants of it in current control blocks.

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Seymour J Metz]

By the pricking of my thumbs
SU7 this way comes.

IBM killed DSS twice; the second time it stayed dead.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Tony Harminc <***@HARMINC.NET>
Sent: Tuesday, June 19, 2018 1:02 PM
To: IBM-***@listserv.ua.edu
Subject: Re: ptrace + SVC 144 + R14 + dbx setting register values

Post by Seymour J Metz
PER uses program interrupts, not an SVC.

To say PER "uses" program interrupts is of course true, but sounds
slightly odd. PER interrupts are a specific subclass of program
interrupts that can occur concurrently with "normal" ones; it's very
different from debuggers that insert an invalid opcode in order to
produce a program interrupt.

Post by Seymour J Metz
That said, calling an SVC does not normally alter R14; the SVC would have to do something unusual.

Post by Paul Gilmartin
How does PER work? I believe it's nondisruptive. And I believe VM gives the
end user control over PER.

Yes. VM does. And because virtualization is so cool, you can have
virtual PER events taking place within z/OS while "real" PER events
within z/OS (or of course other guests) are being handled by z/VM. All
for some values of "virtual" and "real". And z/OS could surely have
something like VM/s PER-using commands, but it has chosen to give
ownership of PER to SLIP, which makes for a very poor debugger. A
privileged program could easily enough set up PER on its own, but
catching and handling any resulting interrupts without seriously
annoying SLIP would be the trick. Is there an interface to SLIP to
tell it that someone else is using PER too, I wonder.

Is anyone here old enough to remember DSS (the MVS Dynamic Support
System), which was a system level debugger that predates SLIP? *It*
used to own PER, but I believe it was removed in MVS 3.6 or so. There
are one or two remnants of it in current control blocks.

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Peter Relson]

Post by Thomas David Rivers
if SVCs architecturally have this restriction

SVCs do not architecturally have this restriction.

Given what I know in general (not specific to USS), I would not make the
assumption that "...because the SVC 144 routine uses register 14 to exit"
is true.
It might be true that a modification to register 14 is lost, but this is
not the reason. Conceivably the designer/coder of that routine that it was
true, but that doesn't make it true.

I'll see if I can track down someone who knows.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Thomas David Rivers]

Post by Peter Relson

Post by Thomas David Rivers
if SVCs architecturally have this restriction

SVCs do not architecturally have this restriction.
Given what I know in general (not specific to USS), I would not make the
assumption that "...because the SVC 144 routine uses register 14 to exit"
is true.
It might be true that a modification to register 14 is lost, but this is
not the reason. Conceivably the designer/coder of that routine that it was
true, but that doesn't make it true.
I'll see if I can track down someone who knows.
Peter Relson
z/OS Core Technology Design
-

Thanks Peter!

That quote is from the IBM doc... (the section on BPX1PTR in the Callable
services descriptions.) So.. ?

- Thanks so very much for following up! -
- Dave Rivers -

[Thomas David Rivers]

Post by Peter Relson

Post by Thomas David Rivers
if SVCs architecturally have this restriction

SVCs do not architecturally have this restriction.
Given what I know in general (not specific to USS), I would not make the
assumption that "...because the SVC 144 routine uses register 14 to exit"
is true.
It might be true that a modification to register 14 is lost, but this is
not the reason. Conceivably the designer/coder of that routine that it was
true, but that doesn't make it true.
I'll see if I can track down someone who knows.
Peter Relson
z/OS Core Technology Design

Hi Peter!

Did your search bear any fruit?

- Thanks -
- Dave Rivers -

[Paul Gilmartin]

Post by Seymour J Metz
PER uses program interrupts, not an SVC.
That said, calling an SVC does not normally alter R14; the SVC would have to do something unusual.

Does either PER or SVC preserve the program mask (CC, ILC, ...)?
If so, that's the one dbx ought to use.

Saving these things can be important if you break just before an IPM instruction.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

[Thomas David Rivers]

Post by Paul Gilmartin

Post by Seymour J Metz
PER uses program interrupts, not an SVC.
That said, calling an SVC does not normally alter R14; the SVC would have to do something unusual.

Does either PER or SVC preserve the program mask (CC, ILC, ...)?
If so, that's the one dbx ought to use.
Saving these things can be important if you break just before an IPM instruction.
-- gil

It's not the saving of the registers/PSW state that is at question, it's the
changing of it.

Imagine you're debugging a program and hit a break-pt, and would like to
change a register/PSWA before continuing... that's what we're talking
about here.

IBM provides the facilities to do this for all the registers _except_ R14.

- Dave R. -

[Rob Schramm]

Dave,

IBM is telling you that R14 is not important! How dare you question the
coding gods that we must all provide supplication to?

Just kidding. Sorry.. LOL

It seems a bit arbitrary that you would have to what .... make sure the
trace table went far enough back to see what R14 was? Or worse.. have to
take a stand-alone dump?

Maybe a slip trap for all modifications of R14!!! That the ticket to
absurd-ville.

Rob Schramm

Post by Seymour J Metz

Post by Paul Gilmartin

Post by Seymour J Metz
PER uses program interrupts, not an SVC.
That said, calling an SVC does not normally alter R14; the SVC would

have to do something unusual.

Post by Paul Gilmartin
Does either PER or SVC preserve the program mask (CC, ILC, ...)?
If so, that's the one dbx ought to use.
Saving these things can be important if you break just before an IPM

instruction.

Post by Paul Gilmartin
-- gil

It's not the saving of the registers/PSW state that is at question, it's the
changing of it.
Imagine you're debugging a program and hit a break-pt, and would like to
change a register/PSWA before continuing... that's what we're talking
about here.
IBM provides the facilities to do this for all the registers _except_ R14.
- Dave R. -
--
Get your mainframe programming tools at http://www.dignus.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

[Seymour J Metz]

PER definitely preserves the entire PSW. Unless the SVC routine tinkers with RBOPSW, I would expect Exit to restore the original value.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@listserv.ua.edu>
Sent: Monday, June 4, 2018 1:18 PM
To: IBM-***@listserv.ua.edu
Subject: Re: ptrace + SVC 144 + R14 + dbx setting register values

Post by Seymour J Metz
PER uses program interrupts, not an SVC.
That said, calling an SVC does not normally alter R14; the SVC would have to do something unusual.

Does either PER or SVC preserve the program mask (CC, ILC, ...)?
If so, that's the one dbx ought to use.

Saving these things can be important if you break just before an IPM instruction.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN