Visual studio not showing symbol table?

Question

I have this source code:

#include <iostream>
int snsn = 344;
int main()
{
    int anothername = 29;
    std::cout << &snsn << "\n";
    system("pause");
}

And after linking the final image file, I run dumpbin /SYMBOLS source.exe on the file, but this it the output:

Dump of file source.exe

File Type: EXECUTABLE IMAGE

  Summary

        1000 .00cfg
        1000 .data
        1000 .idata
        3000 .rdata
        1000 .reloc
        1000 .rsrc
        7000 .text
       10000 .textbss

Why doesn't it show any symbols?

/symbols dumps COFF symbols, the kind that appear in .obj and .lib files. The linker uses them. — Hans Passant, Jun 06 '18 at 13:09
@HansPassant Yea, I actually managed to show some symbols using the /SYMBOLS option with the object file, however, can you tell me why it only shows global symbols like `snsn` and not local ones such as `anothername`? If so, could you also tell me how I can show the local ones? — That Guy, Jun 06 '18 at 13:34
The linker is just not involved with local variables, they are stored on the stack frame in a location that the compiler picks. Global variables like snsn need to be merged with other globals from other source files so their address may change. — Hans Passant, Jun 06 '18 at 13:37
@HansPassant Oh, but isn't it sort of like a must for there to be "local" symbol tables for each function in order for the compiler to do type checking etc.? In that case, why can't you output information about this "local" symbol table? — That Guy, Jun 06 '18 at 14:35
The debugger is interested in that detail, it uses the PDB file. https://blogs.msdn.microsoft.com/vcblog/2016/02/08/whats-inside-a-pdb-file/ — Hans Passant, Jun 06 '18 at 14:45
@HansPassant Perfect. But wait whut, does that mean that when in release mode, type checking in local scopes are not performed? :// I mean, if it did, such local symbols and their associated information should still be stored at compile-time... I must be confusing something, because that does not seem to make sense - all I have read implies that the compiler always performs type checking (for statically typed languages)... — That Guy, Jun 06 '18 at 14:52
@asd all type checking is done at compile time. The only type checks done at run time are `dynamic_casts`. — Alan Birtles, Jun 06 '18 at 15:38
@AlanBirtles, Yes, that is also what I have learnt, but then why would then say that "The debugger is interested in that detail" as if when compiling in release mode, the compiler is not interested in all these "local" symbol tables? If type checking always is done at compile-time for statically typed languages, as I have learnt, then no matter whether the compiler is in debug or release mode, it should store these "local" symbol tables, right? And if so, isn't Hans' statement wrong? Or am I just confusing things? — That Guy, Jun 06 '18 at 15:48
@asd the debugger needs to know the type and stack address of the variables in order to be able to display the variable value to the user. The executable itself doesn't know anything about the type of local variables, the executable is just a list of instructions. — Alan Birtles, Jun 06 '18 at 16:06
https://godbolt.org/ will show you the code generated by your executable, note there are no variable names or types — Alan Birtles, Jun 06 '18 at 16:08
@AlanBirtles Hmm yea, but I might have worded myself wrongly - in every compilation types are matches against each other, so no matter if you are debugging or not, you will compile your code in which case symbol information is used - so how can it only be the debugger and not the compiler itself that "is interested in this detail"(the "local" symbol tables) as Hans said? Thus shouldn't you just be able to output the same information that the compiler uses (i.e. all the symbol tables)? That was my final question :) Thanks for it all. — That Guy, Jun 06 '18 at 16:55
yes the compiler will generate a list of local variables used in each function but it wont store that anywhere and it is thrown away once the compilation is complete. — Alan Birtles, Jun 06 '18 at 17:20

score 0 · Accepted Answer · answered Jun 06 '18 at 11:59

0

Executables on Windows don't generally export symbols.

dumpbin /EXPORTS <file>

can be used on a lib file or dll to view the exported symbols.

To view the symbols used by an executable use:

dumpbin /IMPORTS source.exe

Even if executables did export symbols then your example would probably only export main. Local variables like anothername will never be exported.

/SYMBOLS shows the COFF symbol table which is only present in debug image files: https://msdn.microsoft.com/en-us/library/b842y285.aspx

answered Jun 06 '18 at 11:59

Alan Birtles

32,622
4
31
60

So how can I get local symbol tables? Is that not possible then? Like if the object file only contains global names. And thank you! :)) – That Guy Jun 06 '18 at 12:15
What do you mean by "local symbol tables"? – Alan Birtles Jun 06 '18 at 12:50
For example, the symbol table for the main function containing the symbol `anothername` – That Guy Jun 06 '18 at 12:59
There is no such symbol table. The only place `anothername` might exist is in the debug information stored in the pdb file. See https://stackoverflow.com/questions/2040132/reading-a-pdb-file for viewing pdb files. – Alan Birtles Jun 06 '18 at 14:31
Thanks. I'll check it out :) – That Guy Jun 06 '18 at 14:35

Visual studio not showing symbol table?

1 Answers1