Oppolzer - Informatik / Blog


Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie

PL1-L - Ermitteln der Rufer-Kette

Subject:

Re: Who Called Me

From:

Bernd Oppolzer <bernd.oppolzer@T-ONLINE.DE>

Reply-To:

PL1 (language) discussions <PL1-L@LISTSERV.DARTMOUTH.EDU>

Date:

2014.07.31 20:09:22


The long and hard way goes like this:

call a little ASSEMBLER function that returns the actual register contents to
you, especially the content of register 13.  This way you get the address of
your own save area, and in the second word you will find the address of the
previous save area, and so on (until it is zero, which marks the beginning of
the stack).

In every save area, you find the contents of the registers saved on entry to the
function or procedure on that nesting level.  Most interesting are the registers
14, 15 and 1, stored at offsets 12, 16 and 24. r15 contains the address of the
entry point to the new function, and r14 contains the return address just after
the call instruction in the old function, and r1 contains the address of a list
of parameters or parameter addresses (depending on the language).

Using the entry point address in r15, you find at epa + 12 an offset which
points to a structure called PPA (IIRC), which contains the name of the function
or procedure (for most new compilers).  For some old compilers, there are
different rules.  If you have ASSEMBLER programs in your call chain (which are
not LE compliant), there may be even different rules.

We were able to write some programs, which write diagnostic information after
every program error (although we have different kinds of programs in our call
chain, even not LE compliant VERY OLD ASSEMBLER programs).  The diagnostic
programs are started by means of an LE exit, which gets control after any LE
exception.  They first print a readable representation of the call stack, with
function names etc., even for the not LE compliant ASSEMBLER programs etc.; then
they show the parameters and working areas of the programs at every call level.
The areas are marked with the appropriate headers, for example

PARAMETERS FOR LEVEL 35 FUNCTION xxx

WORKING STORAGE FOR LEVEL 35 FUNCTION xxx

If you are interested to know more about this, feel free to contact me offline.

Kind regards

Bernd




Am 31.07.2014 07:00, schrieb F.W.:
> Just in case anybody still wants to know:  you can use CEETBCK and CEEYEPAF to
> retrieve information about the call stack and the modules on that stack.

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie