stfe(3)stfe(3)NAMEstfe - routines that provide a high-level interface to basic functions
needed to access and add to the symbol table
SYNOPSIS
#include <syms.h>
long st_filebegin(
char *filename,
long lang,
long merge,
long glevel ); long st_endallfiles(
void ); long st_fileend(
long idn ); long st_blockbegin(
long iss,
long value,
long sc ); long st_textblock(
void ); long st_blockend(
long size ); long st_procend(
long idn ); long st_procbegin(
long idn ); char *st_str_idn(
long idn ); char *st_sym_idn(
long idn,
long *value,
long *sc,
long *st,
long *index ); long st_abs_ifd_index(
long ifd,
long index ); long st_fglobal_idn(
long idn ); pSYMR st_psym_idn_offset(
long idn,
long offset ); long st_pdadd_idn(
long idn );
DESCRIPTION
The stfe routines provide a high-level interface to the symbol table
based on common needs of the compiler front-ends. Should be called
upon encountering each cpp directive in the front end. It calls
st_fileadd() to add symbols and will find the appropriate open file or
start a new file. It takes a filename, language constant (see sym‐
const.h), a merge flag (0 or 1), and the -g level constant (see sym‐
const.h). It returns a dense number pointing to the file symbol to be
used in line number directives. Requires the dense number from the
corresponding st_filebegin() call for the file in question. It then
generates an end symbol and patches the references so that the index
field of the begin file points to that of one beyond the end file. The
end file points to the begin file. Is called at the end of execution
to close off all files that have not been ended by previous calls to
st_filebegin(). CPP directives might not reflect the return to the
original source file; therefore, this routine can possibly close many
files. Supports both language blocks (for example, C's left curly
brace blocks), beginning of structures, and unions. If the storage
class is scText, it is the former; if it is scInfo, it is one of the
latter. The iss (index into string space) specifies the name of the
structure/etc, if any.
If the storage class is scText, we must check the result of
st_blockbegin(). It returns a dense number for outer blocks and
a zero for nested blocks. The nonzero block number should be
used in the BGNB ucode. Users of languages without nested blocks
that provide variable declarations can ignore the rest of this
paragraph. Nested blocks are two-staged: one stage happens when
we detect the language block and the other stage happens when we
know the block has content. If the block has content (for exam‐
ple, local variables), the front-end must call st_textblock() to
get a nonzero dense number for the block's BGNB ucode. If the
block has no content and st_textblock() is not called, the
block's st_blockbegin() and st_blockend() do not produce block
and end symbols.
If the storage class is scInfo, st_blockbegin() creates a begin
block symbol in the symbol table and returns a dense number ref‐
erencing it. The dense number is necessary to build the auxil‐
iary required to reference the structure/etc. It goes in the aux
after the TIR along with a file index. This dense number is
also noted in a stack of blocks used by st_blockend().
The st_blockbegin() routine should not be called for language
blocks when the front-end is not producing debugging symbols.
Requires that blocks occur in a nested fashion. It retrieves the
dense number for the most recently started block and creates a
corresponding end symbol. As in st_fileend(), both the begin and
end symbol index fields point at the other end's symbol. If the
symbol ends a structure/etc., as determined by the storage class
of the begin symbol, the size parameter is assigned to the begin
symbol's value field. It is usually the size of the structure or
max value of an enum. We only know it at this point. The dense
number of the end symbol is returned so that the ucode ENDB can
use it. If it is an ignored text block, the dense number is zero
and no ENDB should be generated.
In general, defined external procedures or functions appear in
the symbols table and the externals table. The external table
definition must occur first through the use of a st_extadd().
After that definition, st_procbegin() can be called with a dense
number referring to the external symbol for that procedure. It
checks to be sure we have a defined procedure (by checking the
storage class). It adds a procedure symbol to the symbol table.
The external's index should point at its auxiliary data type
information (or if debugging is off, indexNil). This index is
copied into the regular symbol's index field or a copy of its
type is generated (if the external is in a different file than
the regular symbol). Next, we put the index to symbol in the
external's index field. The external's dense number is used as a
block number in ucodes referencing it and is used to add a pro‐
cedure when in the st_pdadd_idn(). Creates an end symbol and
fixes the indices as in st_blockend() and st_fileend(), except
that the end procedure reference is kept in the begin proce‐
dure's aux rather than in the index field (because the begin
procedure has a type as well as an end reference). This must be
called with the dense number of the procedure's external symbol
as an argument and returns the dense number of the end symbol to
be used in the END ucode. Returns the string associated with
symbol or external referenced by the dense number argument. If
the symbol was anonymous (for example, there was no symbol), a
(char *), -1 is returned. Returns the same result as
st_str_idn(), except that the rest of the fields of the symbol
specified by the idn are returned in the arguments. Returns a 1
if the symbol associated with the specified idn is non-static;
otherwise, a 0 is returned. Returns the absolute offset for a
dense number. If the symbol is global, the global's index is
returned. If the symbol occurred in a file, the sum of all sym‐
bols in files occurring before that file and the symbol's index
within the file is returned. Adds an entry to the procedure ta‐
ble for the st_proc entry generated by st_procbegin(). This
should be called when the front-end generates code for the pro‐
cedure in question.
SEE ALSOstcu(3), stfd(3)stfe(3)
