Compiling a program turns a human-readable source file (set x = 3) into assembly language (load 3 into register) and finally into machine language (101010101...).
This is a companion discussion topic for the original entry at http://betterexplained.com/articles/debuggers-and-symbol-tables/
> If you wish to debug a binary program you did
> not compile yourself, you must get the symbol
> tables from the author.
Not if you’re one of those “talented souls” who “can read and decipher raw computer instructions”
Its a very useful site…but hope it keeps updating
you seem to imply that retail builds don’t have associated symbols at all. (pardon the windows jargon) But whether you build debug or release in Visual studio, you will see that a separate .pdb file is created which contains symbols.
Thanks for the info. Yep, symbols may or may not be included depending on the build system. On UNIX, the symbols aren’t there unless you explicitly specify it.
Sometimes we need indeed to include symbol-info into our “Retail” release, in order to further debug it. In some systems, this info is stored externally and, thus, costs nothing to the final executable.
Developers choose a “debug” version of a program having more run-time checks in it, a “retail” one being faster and optimized. One has to explicitly deny the production of symbol info at either release version. But why bother so, if the symbol tables are located to an external file?!
thanks for providing the comlete information about symbol table