While reading a symbol file, the debugger occasionally encounters problems, such as symbol types it does not recognize, or known bugs in compiler output. By default, the debugger does not notify you of such problems, since they are relatively common and primarily of interest to people debugging compilers. If you are interested in seeing information about ill-constructed symbol tables, you can either ask the debugger to print only one message about each such type of problem, no matter how many times the problem occurs; or you can ask the debugger to print more messages, to see how many times the problems occur, with the set complaints command (see Section 20.6.).
The messages currently printed, and their meanings, include:
The symbol information shows where symbol scopes begin and end (such as at the start of a function or a block of statements). This error indicates that an inner scope block is not fully contained in its outer scope blocks.
The debugger circumvents the problem by treating the inner block as if it had the same scope as the outer block. In the error message, symbol may be shown as “(don't know)” if the outer block is not a function.
The symbol information for symbol scope blocks should occur in order of increasing addresses. This error indicates that it does not do so.
The debugger does not circumvent this problem, and has trouble locating symbols in the source file whose symbols it is reading. (You can often determine which source file is affected by specifying set verbose on. See Section 20.6.)
The symbol information for a symbol scope block has a start address smaller than the address of the preceding source line. This is known to occur in the SunOS 4.1.1 (and earlier) C compiler.
The debugger circumvents the problem by treating the symbol scope block as starting on the previous source line.
Symbol number n contains a pointer into the string table which is larger than the size of the string table.
The debugger circumvents the problem by considering the symbol to have the name foo, which may cause other problems if many symbols end up with this name.
The symbol information contains new data types that the debugger does not yet know how to read. 0xnn is the symbol type of the misunderstood information, in hexadecimal.
The debugger could not find the full definition for a struct or class.
The symbol information for a C++ member function is missing some information that recent versions of the compiler should have output for it.
The debugger could not parse a type specification output by the compiler.