以下を含むコンパイル済み共有ライブラリがあります-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
利用可能なソースがないと思われるようです。
I の場合、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
。したがって、inline
関数の先頭に配置されたパラメータ(タイプ、リリースバージョン)には魔法がある可能性があります。これを見て「奇妙なことですね。この関数の次に進みます」と思い、ほとんどの関数に実際に利用可能なソースコードがあることを知らないのはopencv
可能ですか?gdb
(重要な場合は、UbuntuがインストールされているARMシステムでLLVM / clang 3.5を使用してコンパイルされました)
答え1
これはgccの最適化とそれに続く問題である可能性が高いです。行番号テーブル作成者小人 その地図
プログラム実行コードのメモリアドレスと、このアドレスに対応するソースコード行を含みます。
(8ページ)
最も簡単な解決策は、次を使用することです。ステッピー関数に達すると
~からGDBユーザーマニュアル(65ページ)
ステップ
制御が別のソースコード行に達するまでプログラムを実行し続け、プログラムを停止して制御をgdbに返します。
....
ステップコマンドは、ソースコード行の最初のコマンドでのみ停止します。これにより、スイッチステートメント、forループなどで発生する可能性があるマルチストップを防ぎます。デバッグ情報を含む関数がインラインで呼び出されると、ステップは停止し続けます。つまり、ステップはその行内で呼び出されるすべての関数に入ります。
また、ステップコマンドは、行番号情報がある場合にのみ関数を入力します。それ以外の場合は、次のコマンドのように動作します。これにより、MIPS システムで cc -gl を使用する際の問題を回避できます。以前は、ルーチンに関するデバッグ情報がある場合は、サブルーチンへのステップごとに実行が行われていました。