Verilog pliインターフェイス経由で呼び出される.soファイルで定義された関数にブレークポイントを設定する方法

Question

私は、pltルーチンの呼び出しでrtlシミュレーション中にセグメント化エラーをデバッグする必要があるtestbench環境で作業しています。このpliルーチンは、ファイル（routines.so）に定義されています。これは、デザインとテストベンチ環境のvcsコンパイル後に生成されたシミュレーション実行ファイルにリンクされています。シミュレータ実行ファイルの名前はsimvです。 C sideで中断したい機能がbadfunction()であるとします。これはVerilog側で$badfunction()と呼ばれています。デバッグをサポートしてroutines.soをコンパイルしました。

シミュレーションを実行しているvcs simvシミュレータ実行ファイルにgdbが添付されています。routines.soが読み込まれ、シンボルが読み込まれています。私はinfo sharedを実行してこれをチェックします。

今私はこのinfo address badfunctionのようなシンボルbadfunctionを探します。私はこのようなメッセージを受け取ります。 Symbol "badfunction" is at 0x156bea0 in a file compiled without debugging これは、私には、badfunctionにブレークポイントを置くと、正しい場所に私を得ることができないと思っています。だからbadfunctionはinfo symbol 0x156bea0を参照しています。これは私にメッセージbadfunction in section .text of /home/simulations/rtl/build/simvを与えます。したがって、badfunctionをsimvに記載しています。

ブレークポイントを正しい場所に配置するには、シミュレーションが失敗のポイントに達するまでに約10時間かかります。ブレークポイントをbadfunctionのroutines.soに配置するにはどうすればよいですか？ 関数名badfunctionはマングルされていません。 routines.soを逆アセンブルしてシンボルを見ることができます。 routines.soで関数を探すようにgdbに指示するにはどうすればよいですか？

Answer 1

gdb 7.4からは、break functionに応答して、gdbはすべての一致する関数にブレークポイントを設定します。だから、break badfunctionあなたがしたいことをする必要があります。

しかし、デバッグしたい場所に到達するまでに10時間かかるため、適切なことが起こっていることを確認するために、最初にできることがいくつかあります。

まず、.soにdebuginfoがあることを確認します。これを行う最も信頼性の高い方法は、ロードされる.so（つまり、どこかにインストールされている場合、開発コピーではなくインストールされたコピーをチェックする）を直接調べることです。objdumpまたはreadelfを使用します。私は通常、ちょうどreadelf -wi whatever.soをやります。もしそれがたくさんのものをダンプすれば、あなたはdebuginfoを持っています。

次に、ブレークポイントが正しく設定されていることを確認することができます。 .soのは、実行ファイルにリンクされている場合、これは簡単です。この時点で

$ gdb whatever 
(gdb) break badfunction 
(gdb) start 

、すべての共有ライブラリにリンクされ、ロードされているでしょうし、あなたがこれを行うことができます。

(gdb) info break 

...そして結果として得られた健全性のためのブレークポイントを調べてください。あなたが上に述べたことに基づいて、badfunctionには2つの場所が設定されているはずです。

.soが結果として得られる実行可能ファイルにリンクされていない（実際にはわかりませんが）場合は、もう少し複雑です。 1つのアプローチは、catch load、次にcontinueを実行して、目的のライブラリがロードされ、ブレークポイントがgdbで再解決されるまで実行します。上記のように調べてください。