Symbol table


In computer science, a symbol table is a data structure used by a language translator such as a compiler or interpreter, where each identifier in a program's source code is associated with information relating to its declaration or appearance in the source. In other words, the entries of a symbol table store the information related to the entry's corresponding symbol.

Background

A symbol table may only exist in memory during the translation process, or it may be embedded in the output of the translation, such as in an ABI object file for later use. For example, it might be used during an interactive debugging session, or as a resource for formatting a diagnostic report during or after execution of a program.

Description

The minimum information contained in a symbol table used by a translator includes the symbol's name, its relocatability attributes, and its location or address. For relocatable symbols, some relocation information must be stored. Symbol tables for high-level programming languages store the symbol's type: string, integer, floating-point, etc., its size, and its dimensions and its bounds. Not all of this information is included in the output file, but may be provided for use in debugging. In many cases, the symbol's cross-reference information is stored with or linked to the symbol table. Most compilers print some or all of this information in symbol table and cross-reference listings at the end of translation.

Implementation

Numerous data structures are available for implementing tables. Trees, linear lists and self-organizing lists can all be used to implement a symbol table. The symbol table is accessed by most phases of a compiler, beginning with lexical analysis, and continuing through optimization.
A compiler may use one large symbol table for all symbols or use separated, hierarchical symbol tables for different scopes. For example, in a scoped language such as Algol or PL/I a symbol "p" can be declared separately in several procedures, perhaps with different attributes. The scope of each declaration is the section of the program in which references to "p" resolve to that declaration. Each declaration represents a unique identifier "p". The symbol table must have some means of differentiating references to the different "p"s.
A common data structure used to implement symbol tables is the hash table. The time for searching in hash tables is independent of the number of elements stored in the table, so it is efficient for a large number of elements. It also simplifies the classification of literals in tabular format.
As the lexical analyser spends a great proportion of its time looking up the symbol table, this activity has a crucial effect on the overall speed of the compiler. A symbol table must be organised in such a way that entries can be found as quickly as possible. Hash tables are usually used to organise a symbol table, where the keyword or identifier is 'hashed' to produce an array subscript. Collisions are inevitable in a hash table, and a common way of handling them is to store the synonym in the next available free space in the table.

Applications

An object file will contain a symbol table of the identifiers it contains that are externally visible. During the linking of different object files, a linker will identify and resolve these symbol references. Usually all undefined external symbols will be searched for in one or more object libraries. If a module is found that defines that symbol it is linked with together with the first object file, and any undefined external identifiers are added to the list of identifiers to be looked up. This process continues until all external references have been resolved. It is an error if one or more remains unresolved at the end of the process.
While reverse engineering an executable, many tools refer to the symbol table to check what addresses have been assigned to global variables and known functions. If the symbol table has been stripped or cleaned out before being converted into an executable, tools will find it harder to determine addresses or understand anything about the program.

Example

Consider the following program written in C:

// Declare an external function
extern double bar;
// Define a public function
double foo

A C compiler that parses this code will contain at least the following symbol table entries:
Symbol nameTypeScope
barfunction, doubleextern
xdoublefunction parameter
foofunction, doubleglobal
countintfunction parameter
sumdoubleblock local
iintfor-loop statement

In addition, the symbol table will also contain entries generated by the compiler for intermediate expression values, statement labels, and so forth.

Example: SysV ABI

AddressTypeName
00000020aT_BIT
00000040aF_BIT
00000080aI_BIT
20000004tirqvec
20000008tfiqvec
2000000ctInitReset
20000018T_main
20000024tEnd
20000030TAT91F_US3_CfgPIO_useB
2000005ctAT91F_PIO_CfgPeriph
200000b0Tmain
20000120TAT91F_DBGU_Printk
20000190tAT91F_US_TxReady
200001c0tAT91F_US_PutChar
200001f8TAT91F_SpuriousHandler
20000214TAT91F_DataAbort
20000230TAT91F_FetchAbort
2000024cTAT91F_Undef
20000268TAT91F_UndefHandler
20000284TAT91F_LowLevelInit
200002e0tAT91F_DBGU_CfgPIO
2000030ctAT91F_PIO_CfgPeriph
20000360tAT91F_US_Configure
200003dctAT91F_US_SetBaudrate
2000041ctAT91F_US_Baudrate
200004ectAT91F_US_SetTimeguard
2000051ctAT91F_PDC_Open
2000059ctAT91F_PDC_DisableRx
200005c8tAT91F_PDC_DisableTx
200005f4tAT91F_PDC_SetNextTx
20000638tAT91F_PDC_SetNextRx
2000067ctAT91F_PDC_SetTx
200006c0tAT91F_PDC_SetRx
20000704tAT91F_PDC_EnableRx
20000730tAT91F_PDC_EnableTx
2000075ctAT91F_US_EnableTx
20000788T__aeabi_uidiv
20000788T__udivsi3
20000884T__aeabi_uidivmod
2000089cT__aeabi_idiv0
2000089cT__aeabi_ldiv0
2000089cT__div0
200009a0D_data
200009a0A_etext
200009a0Dholaamigosh
200009a4A__bss_end__
200009a4A__bss_start
200009a4A__bss_start__
200009a4A_edata
200009a4A_end

An example of a symbol table can be found in the SysV Application Binary Interface specification, which mandates how symbols are to be laid out in a binary file, so that different compilers, linkers and loaders can all consistently find and work with the symbols in a compiled object.
The SysV ABI is implemented in the GNU binutils' nm utility. This format uses a sorted memory address field, a "symbol type" field, and a symbol identifier.
The symbol types in the SysV ABI indicate the nature of each entry in the symbol table. Each symbol type is represented by a single character. For example, symbol table entries representing initialized data are denoted by the character "d" and symbol table entries for functions have the symbol type "t". Additionally, the capitalization of the symbol type indicates the type of linkage: lower-case letters indicate the symbol is local and upper-case indicates external linkage.

Example: the Python symbol table

The Python programming language includes extensive support for creating and manipulating symbol tables. Properties that can be queried include whether a given symbol is a free variable or a bound variable, whether it is block scope or global scope, whether it is imported, and what namespace it belongs to.

Example: Dynamic symbol tables

Some programming languages allow the symbol table to be manipulated at run-time, so that symbols can be added at any time. Racket is an example of such a language.
Both the LISP and the Scheme programming languages allow arbitrary, generic properties to be associated with each symbol.
The Prolog programming language is essentially a symbol-table manipulation language; symbols are called atoms, and the relationships between symbols can be reasoned over. Similarly, OpenCog provides a dynamic symbol table, called the atomspace, which is used for knowledge representation.