I wonder if there's only one symbol table that stores all the information about a source file, or there're multiple symbol tables that are stacked upon each other, and only fetched when current scope is related to the table.
For example say I have two methods
int foo(int a){
int b;
bar(b);
...
}
double bar (int a){
int b;
...
}
here the a, and b in two don't have the same scope, so if symbol table is stacked, the symbol table associated with foo is fetched first when executing foo. However when executing bar, the symbol table of bar is stacked upon foo's so that the current symbol table contains the information for bar's a and b.
if the symbol table is centralized, foo's info and bar's info both reside in one symbol table, but there may be entries that specify a,b in foo belongs to scope of foo, and a,b in bar belongs to bar. There're no other symbol table to refer to
Above is my assumption of symbol table. please tell me which one is the real case, and fill it with possibly more details.
Thanks
You need a mapping of identifiers to type/meaning, per scope instance found in the source code, as defined by the language. Some people would call a single such a single mapping a "symbol table" but I think that is an abuse of the term; I prefer the term "symbol space" for such individual scope maps. For me, the set of scope mappings is the symbol table.
The idea of symbol spaces/tables is independent of how and when your compiler creates such symbol spaces/tables.
For classic Pascal-like like languages, scopes happen to nest in a way that matches the program nesting syntax ("lexical scoping"). For such languages, it is possible to create the symbol spaces in a stack-like way, processing the program from top to bottom (lowest line number to largest line number). As each new scope boundary is encountered, a new symbol space is pushed onto the stack. Identifier lookup occurs by searching the current symbol space (the one on top of the stack), and if the identifier is not found, searching symbol spaces further down the stack. As a scope is exited, that symbol space can be deleted (e.g., popped). This scheme works only if the compiler processes the program in single pass. Sometime you want to retain all the symbol spaces to allow complex processing of the program in multiple passes; in this case, you can create the symbol spaces as encountered, but you can't delete them.
Many languages have scoping rules that don't fit the stack-of-symbol spaces at all. An obvious example are namespaces, which are really just symbol spaces accessible from widely separated parts of the program.
I build a fair number of language-processing tools that require symbol tables using a tool infrastructure (see bio for details about the tool). Mostly I don't use a stack-style of symbol spaces, and the tool infrastructure makes it straightforward to create (and delete if necessary) symbol spaces, and provide linkages between one symbol space and another. One of those links is a special lexical-scope link, enabling the infrastructure to record that one symbol space is lexically embedded in another. A standard lookup scheme then searches "the current" scope, and if it does not find a matching symbol, follows the lexical-scope link to continue the search.
The scheme is actually a bit more clever; each symbol space has an associated sequence of parent symbol-space links; the standard lexical search visits the parents (recursively) when a symbol is not found in the current scope. With only one parent link, this is the same as lexical scoping. With multiple parent links, it nicely handles multiple inheritance. Namespaces are handled by using a "well-known" top-level symbol space, that contains symbols for top-level namespaces, etc. You can see what this looks like for C++ in this SO answer: https://stackoverflow.com/a/32012786/120163
A custom action ("procedural attachment") is called before the lexical scoping links are visited; this allows the action to decide to visit arbitrary other symbol spaces first. In particular, this makes it possible for a symbol space search for Java to fetch source/class files from the file system, extract their symbols, and then continue the search as appropriate.