0

Logically, I would assume that there has to be. If im correct, I'm also assuming that its separate from the global symbol table, and that its created by the compiler when a function call is reached and deleted when the compiler reaches the end of the called function. I would also assume that within the symbol table, the variable locations would be stored as relative offsets from the stack base pointer. And just out of curiosity and with reference to all symbol tables, is the explicit length of a variable stored in the symbol table entry, or is the variable type stored (from which a length could be extrapolated), or perhaps both?

KeatonB
  • 213
  • 2
  • 10
  • 3
    Those are all implementation details of particular compilers, so there is not one simple answer. – rici Jun 07 '19 at 16:04
  • You have many questions, perhaps you should refine. – Frank C. Jun 08 '19 at 08:32
  • I think a better question might be whether such a symbol table can be passed to debuggers. One of my further-off goals in my debugger. – ecm Jul 24 '19 at 18:12
  • @ecm the same answer applies, how debbugers interact with a symbol table (s) vary from a debugger to another debugger – umlcat Aug 03 '19 at 18:50
  • 1
    1. All variables are in a symbol table. 2. It's not necessarily separate. 3. Yes the offsets are stored. 4. Depends on the compiler, but it it was mine I would just store the type and not repeat the length information. – user207421 Aug 03 '19 at 21:57

1 Answers1

1

Although, each item compiler, may work different from another, including debugger and symbol table operation, one possible solution, it's to use the AST tree as a hierarchical symbol table.

Each tree node stores a symbol, in some cases, such as a function, stores subordinates symbols as local parameters, and local variables.

Each tree node, may store additional information for each symbol, like the source code file, where it was declared, line and row number, text of the variable or constant, and the current memory location.

Many debbugers work more like an interpreter, even if you are crafting a compiler.

umlcat
  • 4,091
  • 3
  • 19
  • 29