Guardian Procedure Calls Reference Manual

the called Guardian procedure, because it might have written over the return address that was
stored in the local stack.
Which Guardian procedures actually switch stack might change from RVU to RVU and will differ
by processor type.
C Syntax for a Guardian Procedure Call
C syntax is presented in this manual in addition to TAL syntax. Where necessary, considerations
for C programmers are also presented. For further information on calling Guardian procedures
from a C program, see the C/C++ Programmer's Guide.
Figure 3 shows an example of C syntax. As in TAL syntax, square brackets ([ ]) indicate optional
parameters. Detailed descriptions of parameters are not included with the C syntax; such descriptions
accompany the TAL syntax.
Figure 3 Sample C Syntax for a Procedure Call
Because TAL does not have a string terminator like C, it often requires that you supply both a string
and its length (not counting the null-byte terminator) in two parameters, or that you supply a string
buffer with the maximum string length along with a third parameter for returning the actual string
length. See String Output Variables (page 35).
When calling TAL procedures that use strings in this manner from a C program, you must also pass
the complete set of parameters for handling the string. The TAL convention of pairing certain string
parameters together, joined by colons, is not supported in C; parameters are always separated
by commas.
How to find the (writable) global data in an TNS/E native process
The global, writable data in a native TNS/E process can be found in up to four distinct sections
per loadfile
2
: data, data1, sdata, sdata1, sbss, and bss. The first two are for initialized data and
the last two are for uninitialized data (which is always set to zero by NSK). Some (or even all) of
them could be zero length. They may not be contiguous.
The base addresses and lengths of each section can be determined from linker-defined reserved
symbols.
The simplest way to get this information is by coding a small C function that accesses the symbols
and returns the addresses and lengths. That function can be compiled in C and the resulting object
file linked into an otherwise completely pTAL program, without requiring the use of additional
runtime support (no CRTL and CRE DLLs are required). Note that to report about the program, the
function must be linked into the program loadfile; if it were in a separate DLL it would report about
the instance data sections of that DLL, since these special symbols are local to the each loadfile.
2. Normally programs that use passive checkpointing (that is, use the file system CHECKPOINT functions) consist of a
single loadfile: the program file with no DLLs. If there is a DLL (perhaps a UL), a similar function with another name can
be linked into it to report the DLL’s instance data segments.
36 Introduction to Guardian Procedure Calls