ATTACH EXTR=exit and saving registers (save _all_ registers?)

[Thomas David Rivers]

When you specify the EXTR= parameter on an ATTACH, you
are indicating the offset of an exit to asynchoronously receive
control when the sub-task ends.

This exit is invoked as many are, in that a 72-byte save area
is addressed by R13 for saving/restoring the registers.

The documentation even goes on to say:

"The exit routine is responsible for saving and restoring
registers".

In the 'MVS Programming: Assembler Services Guide" in the
section on linkage, called "Saving the calling program's registers"
it says that saving registers involves saving R2 through R13
"Unless otherwise defined by the individual interface".

Has the one sentence in the EXTR description 'otherwise defined'
that R14,R15,R0 and R1 also need to be saved; or is it referring
tot he normal saving which would not preserve those? It seems
a little ambiguous to me.

That is - in the case for an EXTR exit - do we need to also save/restore
R14,R15,R0 and R1 - or are those "safe" to trash? I'd like to use
them to trampoline into a different environment if possible without
having to do a "save-area dance".

- Thanks -
- Dave Rivers -

[Binyamin Dissen]

As I believe that it gets control via SYNCH(X), you really do not need to save
or restore any registers. Just exit by branching to the address that was
contained in R14 when entered.

It would be a bit of an integrity exposure for the task termination routine to
trust your registers.

On Tue, 29 Aug 2017 06:02:12 -0400 Thomas David Rivers <***@DIGNUS.COM>
wrote:

:>When you specify the EXTR= parameter on an ATTACH, you
:>are indicating the offset of an exit to asynchoronously receive
:>control when the sub-task ends.
:>
:>This exit is invoked as many are, in that a 72-byte save area
:>is addressed by R13 for saving/restoring the registers.
:>
:>The documentation even goes on to say:
:>
:> "The exit routine is responsible for saving and restoring
:> registers".
:>
:>In the 'MVS Programming: Assembler Services Guide" in the
:>section on linkage, called "Saving the calling program's registers"
:>it says that saving registers involves saving R2 through R13
:>"Unless otherwise defined by the individual interface".
:>
:>Has the one sentence in the EXTR description 'otherwise defined'
:>that R14,R15,R0 and R1 also need to be saved; or is it referring
:>tot he normal saving which would not preserve those? It seems
:>a little ambiguous to me.
:>
:>That is - in the case for an EXTR exit - do we need to also save/restore
:>R14,R15,R0 and R1 - or are those "safe" to trash? I'd like to use
:>them to trampoline into a different environment if possible without
:>having to do a "save-area dance".
:>
:> - Thanks -
:> - Dave Rivers -

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

[Steve Smith]

You'll have to spell it as ETXR, and if by "offset" you mean offset
from 0, then sure.

You can do what you want with the registers. The ETXR runs under an
IRB on the mother task, so I'm not sure why any of them need to be
saved.

Beyond that, I've no idea what you're planning on doing, but ETXRs
aren't normally suitable for doing much.


sas

On Tue, Aug 29, 2017 at 9:02 AM, Binyamin Dissen

Post by Binyamin Dissen
As I believe that it gets control via SYNCH(X), you really do not need to save
or restore any registers. Just exit by branching to the address that was
contained in R14 when entered.
It would be a bit of an integrity exposure for the task termination routine to
trust your registers.
:>When you specify the EXTR= parameter on an ATTACH, you
:>are indicating the offset of an exit to asynchoronously receive
:>control when the sub-task ends.
:>
:>This exit is invoked as many are, in that a 72-byte save area
:>is addressed by R13 for saving/restoring the registers.
:>
:>
:> "The exit routine is responsible for saving and restoring
:> registers".
:>
:>In the 'MVS Programming: Assembler Services Guide" in the
:>section on linkage, called "Saving the calling program's registers"
:>it says that saving registers involves saving R2 through R13
:>"Unless otherwise defined by the individual interface".
:>
:>Has the one sentence in the EXTR description 'otherwise defined'
:>that R14,R15,R0 and R1 also need to be saved; or is it referring
:>tot he normal saving which would not preserve those? It seems
:>a little ambiguous to me.
:>
:>That is - in the case for an EXTR exit - do we need to also save/restore
:>R14,R15,R0 and R1 - or are those "safe" to trash? I'd like to use
:>them to trampoline into a different environment if possible without
:>having to do a "save-area dance".
:>
:> - Thanks -
:> - Dave Rivers -
--
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

[Thomas David Rivers]

Post by Steve Smith
You'll have to spell it as ETXR, and if by "offset" you mean offset
from 0, then sure.
You can do what you want with the registers. The ETXR runs under an
IRB on the mother task, so I'm not sure why any of them need to be
saved.
Beyond that, I've no idea what you're planning on doing, but ETXRs
aren't normally suitable for doing much.
sas

Hmm - then why is the doc so clear that the ETXR (spelled right :-) )
needs to save/restore the regs?

Is the doc wrong?

Regarding the use of it - I just want a notification that the subtask
ended early (perhaps because of an abend.)

- Dave R. -

[Steve Smith]

The doc isn't "wrong", it's just a bit overstated. It's a good idea
to follow normal linkage conventions (well normal from 1970) and
they're encouraging that. This is an ancient facility, and for all I
know it may have been a more vital requirement in the past.

Also, I have no insider's knowledge of how the system works (like
Mulder & Relson). It's conceivable that things could change to where
you'll fail somehow if you don't preserve the registers.

I would (and do) just follow normal saving and restoring conventions
in an ETXR. It certainly won't hurt.


sas

Post by Thomas David Rivers

Post by Steve Smith
You'll have to spell it as ETXR, and if by "offset" you mean offset
from 0, then sure.
You can do what you want with the registers. The ETXR runs under an
IRB on the mother task, so I'm not sure why any of them need to be
saved.
Beyond that, I've no idea what you're planning on doing, but ETXRs
aren't normally suitable for doing much.
sas

Hmm - then why is the doc so clear that the ETXR (spelled right :-) )
needs to save/restore the regs?
Is the doc wrong?
Regarding the use of it - I just want a notification that the subtask
ended early (perhaps because of an abend.)
- Dave R. -
--
Get your mainframe programming tools at http://www.dignus.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,

[Thomas David Rivers]

Post by Steve Smith
The doc isn't "wrong", it's just a bit overstated. It's a good idea
to follow normal linkage conventions (well normal from 1970) and
they're encouraging that. This is an ancient facility, and for all I
know it may have been a more vital requirement in the past.
Also, I have no insider's knowledge of how the system works (like
Mulder & Relson). It's conceivable that things could change to where
you'll fail somehow if you don't preserve the registers.
I would (and do) just follow normal saving and restoring conventions
in an ETXR. It certainly won't hurt.
sas

Hence my question... the "normal saving" from the Assembler
Services doc says that R14, R15, R0 and R1 don't need to be preserved,
*unless* documented otherwise.

The ATTACH doc says that the called function is responsible
for "saving and restoring the registers."

Does that mean "all" the registers - or the "normal" ones; is that
sentence documentation that all the registers need to be saved/restored;
or that the system doesn't care about saving R14, R15, R0 and R1
and only R2-R13 needs to be saved/restored?

The doc seems ambiguous to me; which leads me down this path
of doing funky save-area machinations to ensure that all registers
are saved - not just the "normal" ones.

- Dave Rivers-

[Ed Jaffe]

Post by Steve Smith
Beyond that, I've no idea what you're planning on doing, but ETXRs
aren't normally suitable for doing much.

I was astonished to learn recently that ETXR routines are entered in
problem state even if the ATTACHX is issued by a supervisor state
caller. Talk about inconvenient!
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

[Tom Marchant]

Post by Thomas David Rivers
The doc seems ambiguous to me; which leads me down this path
of doing funky save-area machinations to ensure that all registers
are saved - not just the "normal" ones.

STM 14,12,12(13)
hardly constitutes "doing funky save-area machinations".

Saving your caller's registers is a good practice, if for no other reason than to aid in debugging.
Diagnosing "clever" code that avoids the calling conventions is a PITA.

[Webster, Chris]

Using BAKR on entry frees up the provided save area for other uses.

...chris.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tom Marchant
Sent: August-29-17 1:29 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH EXTR=exit and saving registers (save _all_ registers?)

The doc seems ambiguous to me; which leads me down this path of doing
funky save-area machinations to ensure that all registers are saved -
not just the "normal" ones.

STM 14,12,12(13)
hardly constitutes "doing funky save-area machinations".

Saving your caller's registers is a good practice, if for no other reason than to aid in debugging.
Diagnosing "clever" code that avoids the calling conventions is a PITA.

--
Tom Marchant

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

[Thomas David Rivers]

Post by Webster, Chris
Using BAKR on entry frees up the provided save area for other uses.
...chris.

Oh! That's a great idea!

- Dave R. -

[Thomas David Rivers]

Post by Tom Marchant

Post by Thomas David Rivers
The doc seems ambiguous to me; which leads me down this path
of doing funky save-area machinations to ensure that all registers
are saved - not just the "normal" ones.

STM 14,12,12(13)
hardly constitutes "doing funky save-area machinations".
Saving your caller's registers is a good practice, if for no other reason than to aid in debugging.
Diagnosing "clever" code that avoids the calling conventions is a PITA.

Oh yes! I *totally* agree - the problem is a little involved... I'm
branching to
some code that wants a save area, but I'm not in position to allocate one.
So - I can't save the incoming registers in the OS-provided area just to
have
the branched-to routine overwrite that... the restore would then not restore
the proper registers.

It's a twisty maze of save-area stuff to be sure...

(It's a "thunk" between two stacks... - these things happen...)

If I didn't have to save/restore R15 and R1, then I could totally get away
with something very close to standard linkage... that's my basic
question/hope.

- Dave Rivers -