The VxWorks Symbol Table

Since VxWorks performs load-time linking, it must maintain a symbol table. A "symbol" in this context is a named value. The name is something for humans to use, and the value usually represents the location of an object, not the object itself. In VxWorks, global functions and global variables go into the symbol table. Functions are always loaded from a compiled object file, while variables are either loaded from an object file or created by the shell. When the VxWorks shell prints the "value" of a command, the last thing it prints is the name of the symbol from the symbol table whose value lies closest to the command's value. For example, if the symbol "mySymbol" has the value 0x220, and the command you just ran returned the value 0x225, it would show:


	value = 549 = 0x225 = mySymbol + 0x5

to let you know that the value 0x225 just happens to be 5 away from "mySymbol". This is sometimes useful in debugging.

OK, Why Do I Care About the Symbol Table?

Since VxWorks is single-user, everyone using a given target must pay very close attention to the symbol table. This is because of name collisions. If two software packages implement global functions, or even global variables, with the same names, the consequences could be disastrous. The symbol table always tracks the most recent version of a symbol. This means you can override ANY symbol. Everything which was loaded BEFORE the new definition of a symbol is fine, because it has already been linked with the old version. But everything loaded AFTER the new definition will be linked with the new symbol. This is useful for patching, but may be fatal in other cases. This problem can be avoided by choosing a unique "name" for your package, and then using this name in all of your function names and global variable names.