シンボル・ファイルの読み込み中に、
GDBはときどき問題にぶつかることがあります。
例えば、
認識できないシンボル・タイプを見つけたり、
コンパイラの出力に既知の問題を発見することがあります。
デフォルトでは、
このようなエラーがあったことを、
GDBはユーザに知らせません。
なぜなら、
このようなエラーは比較的よく見られるものであり、
コンパイラのデバッグをしているような人々だけが関心を持つようなものだからです。
もし、
正しく構築されていないシンボル・テーブルに関する情報を見ることに関心があれば、
set complaints
コマンドを使用することで、
何回問題が発生しようと個々のタイプの問題について1回だけメッセージを出力するよう指示することができますし、
また、
何回問題発生したかを見るためにより多くのメッセージを表示するよう指示することもできます
(see Optional warnings and messages)。
現在のバージョンで表示されるメッセージとその意味を以下に記します。
inner block not inside outer block in
symbolGDBは、
内側のブロックが外側のブロックと同一のスコープを持つものとして扱うことで、
この問題を回避します。
外側のブロックが関数でない場合には、エラー・メッセージの
symbolの部分が`(don't know)
'のように表示されることがあります。
block at
address out of order
GDBはこの問題を回避することはせず、
読み込もうとしているソース・ファイルのシンボルを見つけるのに支障が出ます
(set verbose on
を指定することで、
どのソース・ファイルが関係しているかを知ることができます。
See Optional warnings and messages)。
bad block start address patched
GDBは、
シンボルのスコープとなるブロックが1つ前のソース行から始まるものとして扱うことによって、
この問題を回避します。
bad string table offset in symbol
nGDBは、
このシンボルがfoo
という名前を持つものとみなすことによって、
この問題を回避します。
この結果、
多くのシンボルがfoo
という名前を持つことになってしまうと、
他の問題が発生する可能性があります。
unknown symbol type 0x
nn0x
nnは理解できなかったシンボルの型を16進数で表わしたものです。
GDBは、
このようなシンボル情報を無視することによって、
このエラーを回避します。
通常、
プログラムのデバッグを行うことは可能になりますが、
ある特定のシンボルにアクセスすることができなくなります。
このような問題にぶつかり、
それをデバッグしたいのであれば、
gdb
自身を使ってgdb
をデバッグすることができます。
この場合、
シンボルcomplain
にブレイクポイントを設定し、
関数read_dbx_symtab
まで実行してから、
*bufp
によってシンボルを参照します。
stub type has NULL name
const/volatile indicator missing (ok if using g++ v1.x), got...
info mismatch between compiler and debugger