4

過去に、Cortex M3 (STM32F2) の内部 SRAM にロードされた実行可能ファイルを問題なくデバッグしていました。最近、実行可能ファイルを Flash にロードしています (サイズの問題のため)。

それ以来、GDB でのデバッグは機能していません。私が理解しているように、実行可能ファイルがフラッシュにある場合、(ソフトウェア ブレークポイントではなく) ハードウェア ブレークポイントしか使用できず、6 つのハードウェア ブレークポイントがあります。ただし、ハードウェア ブレークポイントを 1 つだけ設定すると、GDB で次のエラー メッセージが表示されます。

(gdb) break main
Breakpoint 1 at 0x800019a: file src/main.c, line 88.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) Warning:
Cannot insert hardware breakpoint 1.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

何がうまくいかないのですか？ハードウェア ブレークポイントはバックグラウンドで実行されますか?

注: OpenOCD を使用して、JTAG 経由で実行可能ファイルをロードしました。

4

1 に答える 1

4

そのため、基本的に 2 つの方法 (および 1 つの非常に悪い方法) が、特定のデバッガーとプラットフォームの組み合わせでブレークポイントを実装できます。

  1. ハードウェア機能 (「ハードウェア ブレークポイント」) を使用して、プロセッサが特定のアドレスに到達したときにプロセッサをトラップさせます。これは通常、利用可能な場合でも、ほんの数個のブレークポイントに制限されています。

  2. 設定されているブレークポイントごとに、ブレークポイントの命令を何らかの種類の「トラップ」命令 (つまり、デバッガに割り込む命令) に置き換えます。ブレークポイントの 1 つにヒットしたら、元の命令をスワップして戻し、シングルステップを 1 回実行して実行します。

  3. プログラム全体をシングル ステップで実行します。これは恐ろしく遅いので、実際にはカウントされません。

デバッガーが方法 2 (「ソフトウェア ブレークポイント」) のみを使用しているように聞こえます。この方法の欠点は、プログラムが書き込み可能である必要があることです。また、フラッシュ メモリは一度に 1 命令ずつ書き込み可能ではないため、この手法は機能しません。

于 2012-07-04T01:44:45.107 に答える