In ELF (Etymology ELF=Extended  load  Format)  SDB  information  is
highly  structured  and  placed  in a separate area (.debug) from symbol
table information.   The debug area has many cross links with itself and
other  areas  so  that  variables are owned by subroutines,   members by
structures etc.  It is not possible for the compiler to construct .debug
without  help from the Ecode modules so it seems best for PUT to provide
an interface for the front ends

     On the plus side ELF SDB information is very general and  can  cope
with  records,structures  and  enumeration  types  etc  via  user define
typing.   There are also a selection of  fundamental  types.    Location
information  is  also  extremely  general  via  a do-it-yourself reverse
polish calculation kit that is  able  to  cope  with  exceeding  complex
calculations.

     The following routine is suggest as the  interface  for  variables.
Further  routines  to  add  arrays,structures  etc as user types will be
added later.   In general PUT will assume all SDB  information  provided
between  calls  of  EPROC  and  EPROCEND  are for variables owned by the
current procedure.   Globals are assumed for SDB information  preceeding
the  first call of EPROC or after the last EPROCEND .   However on Sparc
the code modules hold all code back to the EPROCEND and then pass it  to
put  so  SDB  data  following an EPROCEND is taken as being owned by the
preceeding procedure. PUT when working in SDB mode makes all the entries
for the source file,  line number table and procedures without involving
the compiler. The following routine is used to pass SDB data to PUT

%externalroutinespec PSDBENTRY(%integer tag,%string(*)%name name,%integer %c
     type1,type2,bytes,%record(locf)%name location info)

Where:
tag is the SDB tag field of which the following aresupported
5 := formal parameter defn
7 := Global variable defn
11 := Lexical block (with declaration to follow)
12 :=Local variable
13 := Member of previously noted structure
19 := Structure

   Tag characterises what is being defined

name is the variable name (null for Lexical blocks)

Type1 has just two values
5 for fundamental type
7 for user defined type (eg array,structure or enumeration type)

Type2 depend on type 1
       For user types it is the key returned from the type defn
       For fundamental type it is as follows

2:=signed char
3:=unsigned char
5=signed short
6=unsigned short
8=signed integer
9=unsigned integer
11=signed long(64 bit integer)
12=unsigned long
14=float(32 bit real)
15=dbl float(64 bit real)
16=quad float(128 bit real where supported)
11=complex
12=double complex
13=set

Bytes is normally the item size in bytes

Location defines how to find the varaible as in nextsection

When defining lexical blocks type1 is either 1(start block) or -1(end block)
in the case bytes it offset from start of code on the block start(or end)

Location Information


   This is provided via record :-
        %recordformat Locf(%integer dis,offset,area,dref,offset2)

    This defines a variable in an epc area and with a known offset.
       dref =0 for a normal variable, =1 for a pointer, =2 for a pointer
       to a pointer. Offset2 is applied to the pointer after derefencing
       for dref>0.

Dis discrimates as follows

Dis=0    The variables is at a constant addresss Offset. Primarily this
         is for members of a structure but can also cope with items at
         a known virtual address

Dis=1    The variable is in register offset (dref=0) of pointed at by
         Register offset (dref=1).

Dis=2    The variable is in area and offset. This covers common areas
         as well as stack frames and globals.