ソースコードが利用可能であってもgdbは機能しません。

ソースコードが利用可能であっても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利用可能なソースがないと思われるようです。

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 を使用する際の問題を回避できます。以前は、ルーチンに関するデバッグ情報がある場合は、サブルーチンへのステップごとに実行が行われていました。

おすすめ記事