How does gdb interpret `main` when no debug symbols loaded?

<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /root/ctest/printf...(no debugging symbols found)...done.
(gdb) disas main
Dump of assembler code for function main:
0x0000000000400498 <m开发者_JAVA技巧ain+0>:    push   %rbp
0x0000000000400499 <main+1>:    mov    %rsp,%rbp
0x000000000040049c <main+4>:    sub    $0x10,%rsp

How does gdb interpret main when no debug symbols loaded?

GDB doesn't "interpret" main.

If your question is "how does GDB know where main is", the answer is: "because its address is in the symbol table" (see output from nm /root/ctest/printf). On UNIX (unlike Windows) one doesn't need debug symbols to have function and global variable names in the executable (or shared library) -- they are kept by default (to make debugging easier). If you wanted to hide your main, you could run strip printf to remove it (and all other symbols) from the executable.

For your second question, main isn't mangled because it has extern "C" linkage. It must have that linkage so it can be called from assembly (it is called by the C runtime startup, usually crt1.o).

main isn't a debug symbol, so it isn't stripped. It has external linkage, so it is preserved unless an explicit strip or link command removes it. It isn't mangled because on most platforms, there is no name mangling in the C ABI (except maybe for appending an underscore or similar).

The linker and other tools are able to determine what symbols are debug symbols and which are extern, or private, etc, because they are marked differently in the symbol table. For example, on Mac OS X, we might see something like this:

                 U _constantFromAnotherModule
0000000000000018 T _externFunction
0000000000000410 s _privateInt
0000000000000000 t _staticFunction

The different letters in the middle column, before the symbol names, indicate different types of linkage, and they are treated differently by the tools.

Even if the symbols are mangled, tools often know how to undo the mangling, so a debugger should be able to find a function name in a symbol table even if it has been mangled, so long as it was built by tools compatible with the debugger. Beyond that, main( ) in C++ has C linkage, and follows the platform's C ABI, so it is typically not mangled.