☰

ソースが利用可能であるにもかかわらず、gdb は関数にステップインしません

tag-icon • tag-icon debugging gdb clang
ソースが利用可能であるにもかかわらず、gdb は関数にステップインしません

以下を含めてコンパイルされた共有ライブラリがあります-g -O0:

void MyClass::whatever()
{
  ...
  doSomething(myImage, myPoints);
  ...
}

bool MyClass::doSomething(const Image& image, std::vector<cv::Vec2f>& points) const
{ 
  const int32_t foo = 1;
  const float   bar = 0.1f;
  ...
}

whatever()現在、をステップ実行していますsが、 にステップインするのではなくdoSomething()、 をステップスルーします。これはソースの可用性の問題ではありません。(1) は同じファイルにあり、(2) にブレークポイントを設定してdoSomething()、問題なくソースをステップ実行できるためです。しかし、 はs利用可能なソースがないと考えているようです。

とするとset step-mode on、次のような出力が得られる。

0xb5d51148 in myClass::doSomething (this=0xb25e4, image=..., 
points=std::vector of length -91315, capacity 372871920 = {...})
from /path/to/myclass.so

利用できるソースがない場合に取得するのと同じです。初期化が数回行われた後、nソースが表示されます。そのため、関数の先頭に置かれたパラメーター (タイプ、リリース ビルド) に何らかの魔法fooがある可能性があります。これを見て、「変だ、この関数の後を続けよう」と考え、関数のほとんどに実際に利用できるソースがあることに気付かない可能性はありますか?inlineopencvgdb

(問題になるかどうかはわかりませんが、Ubuntu を搭載した ARM ボックスで LLVM/clang 3.5 を使用してコンパイルされています)

答え1

これはおそらくgccの最適化とそれに続く行番号表によって作成されたドワーフ マップ

プログラムの実行可能コードと、そのアドレスに対応するソース行を含むメモリアドレス

（8ページ）

最も簡単な解決策は、ステップ関数に到達すると

からGDB ユーザーマニュアル（65ページ）

ステップ

制御が別のソース行に到達するまでプログラムの実行を継続し、その後停止して制御を gdb に戻します。

....

step コマンドは、ソース ラインの最初の命令でのみ停止します。これにより、switch ステートメントや for ループなどで発生する可能性のある複数の停止を防止します。step は、行内でデバッグ情報を持つ関数が呼び出されると停止を続けます。つまり、step は、行内で呼び出されるすべての関数内をステップ実行します。

また、step コマンドは、関数の行番号情報がある場合にのみ関数に入ります。それ以外の場合は、next コマンドのように動作します。これにより、MIPS マシンで cc -gl を使用するときに問題が回避されます。以前は、ルーチンに関するデバッグ情報がある場合、step はサブルーチンに入りました。

関連情報