ハードウェアブレークポイントとソフトウェアブレークポイントの違いは何ですか？
ハードウェアブレークポイントとソフトウェアブレークポイントの違いは何ですか？
ハードウェアブレークポイントはソフトウェアブレークポイントよりも高速であると言われていますか？
この記事では、長所と短所について適切に説明しています。 http://www.nynaeve.net/?p=8
ハードウェアブレークポイントは一部の機能が制限されており、アーキテクチャに大きく依存しているため、質問に直接答えるにはソフトウェアブレークポイントの方がより柔軟です。この記事に記載されている1つの例は、x86ハードウェアには4つのハードウェアブレークポイントの制限があることです。
ハードウェアブレークポイントは専用レジスタを備えており、ソフトウェアブレークポイントよりもオーバーヘッドが少ないため、高速です。
GDB internals を通過できます。HWおよびSWブレークポイントについて非常によく説明されています。
HWブレークポイントは、MCUからのサポートが必要なものです。 ARMコントローラには、PC（プログラムカウンタ）== sp register CPUが停止するたびに、アドレス空間を書き込むことができる特殊レジスタがあります。通常、これらの特殊レジスタに書き込むにはJtagが必要です。
SWブレークポイントは、GDBに実装されます。トラップ、不正な除算、または例外を引き起こすその他の命令を挿入し、それが発生するとgdbが例外を取得してプログラムを停止します。ユーザーが続行するように言うと、gdbは元の命令を復元し、シングルステップし、トラップを再挿入して続行します。
特に割り込みやメモリバスデバイスを扱う場合、SWデバッガよりもHWデバッガを使用することには多くの利点があります。 AFAIK割り込みは、ソフトウェアデバッガーではデバッグできません。
ハードウェアブレークポイントは実際にはコンパレータであり、現在のPCをコンパレータ内のアドレスと比較します（有効な場合）。ハードウェアブレークポイントは、ブレークポイントを設定する際の最適なソリューションです。通常、デバッグプローブを介して設定します（JTAG、SWDなどを使用）。ハードウェアブレークポイントの欠点：制限があります。 CPUには、限られた数のハードウェアブレークポイント（コンパレーター）しかありません。利用可能なハードウェアブレークポイントの数は、CPUによって異なります。 ARM 7/9コアには2、モダンARM 2から6までのデバイス（Cortex-M 0、3、4）、x86、通常4。
実際、ソフトウェアブレークポイントは、ブレークポイントを設定する命令をブレークポイント命令に置き換えることで設定されます。ブレークポイント命令はほとんどのCPUに存在し、通常は最短の命令と同じくらい短いため、x86では1バイトのみ（0xcc、INT 3）です。 Cortex-M CPUでは、命令は2または4バイトであるため、ブレークポイント命令は2バイトの命令です。
プログラムがRAM（PCなど）にある場合、ソフトウェアブレークポイントを簡単に設定できます。多くの組み込みシステムでは、プログラムがフラッシュメモリに配置されています。ほとんどのデバッグプローブは、プログラムがフラッシュメモリにある場合、ハードウェアブレークポイントのみをサポートしますが、一部（SEGGERのJ-Linkなど）はフラッシュの再プログラミングを許可します。ブレークポイント命令とasoを備えたメモリは、フラッシュ内にあるプログラムをデバッグするときでも、無制限の数の（ソフトウェア）ブレークポイントを許可します。
上記の回答に加えて、ソフトウェアブレークポイントはプログラム内の特定の命令を上書きして停止する場所を認識しますが、ハードウェアブレークポイントの数は実際にはプロセッサの一部であることに注意することも重要です。
Justin Seitzの本の中で Gray Hat Python ここで重要な違いは、命令を上書きすることでソフトウェアブレークポイントが実際に変化することであると指摘していますファイルの [〜＃〜] crc [〜＃〜] であるため、CRCを計算するマルウェアなどのあらゆる種類のプログラムは、ブレークポイントの設定に応じて動作を変更できます。一方、ハードウェアブレークポイントでは、デバッガーが特定のコードチャンクを停止してステップ実行することはあまり明確ではありません。
簡単に言えば、ハードウェアブレークポイントは専用レジスタを使用するため、数に制限があります。これらは、揮発性メモリと不揮発性メモリの両方に設定できます。
ソフトウェアブレークポイントは、RAMメモリ内の命令のオペコードをブレークポイント命令に置き換えることで設定されます。これらは、RAM memory（書かれている）と制限されていません。
この記事では、ブレークポイントに関する適切な説明を提供しています。
ありがとう、シヴァクマールV W
ウォッチポイントは、ハードウェア処理がmuchより速い場合です：
watch var
rwatch var
awatch var
GDB 7.7 x86-64でこれらのコマンドを入力すると、次のように表示されます。
Hardware watchpoint 2: var
X86のこのハードウェア機能については、以下で説明されています。 http://en.wikipedia.org/wiki/X86_debug_register
すべてのメモリアクセスを管理する既存のページング回路が原因である可能性があります。
「ソフトウェア」の代替手段は、 シングルステッププログラム で、これはvery低速です。
それを通常のブレークポイントと比較してください。少なくともソフトウェア実装が挿入し、int3命令を使用してプログラムを実行できるため、ブレークポイントに到達した場合にのみオーバーヘッドを支払うことができます。
Intel System Debuggerヘルプドキュメントからの引用：
ハードウェアとソフトウェアのブレークポイントデバッガーはハードウェアとソフトウェアの両方のブレークポイントを使用できますが、これらにはそれぞれ長所と短所があります。
ハードウェアブレークポイントは、Intel SDMで説明されているDRxアーキテクチャブレークポイントレジスタを使用して実装されます。リセット時に直接使用でき、不揮発性であり、フラッシュまたはその他の読み取り専用メモリで使用できるという利点があります。欠点は、それらが有限のリソースであるということです。 ソフトウェアブレークポイント必要な場所のオペコードを特別な命令で置き換えることにより実装されるため、システムメモリを変更する必要があります。これにより、リソースは無制限になりますが、メモリの依存関係により、モジュールをメモリにロードする前にインストールすることはできず、ターゲットソフトウェアがそのメモリを上書きすると無効になります。一般に、デバッガーで有効にする必要のあるデバッグ機能はリセット後に保持されず、SMMのエントリ/出口またはVMエントリ/出口などの他のアーキテクチャモードの移行後に影響を受ける可能性があります。具体例を次に示します。
CPUリセットは、リセットブレークを除くすべてのデバッグ機能をクリアします。これは、たとえば、リセット後にターゲットが1回停止するまで、ユーザー指定のブレークポイントが無効になることを意味します。この停止は、リセットブレークまたはユーザーが開始した停止が原因である可能性があることに注意してください。どちらの場合でも、デバッガーは必要なデバッグ機能を復元します。 SMM Entry/exitはブレークポイントを無効/再有効にします。つまり、SMRAMの外部で停止している間は、SMRAMでブレークポイントを指定できません。 SMRAM内でブレークする場合は、最初にSMMのエントリブレークで停止し、ブレークポイントを手動で適用する必要があります。または、SMMに入るときにブレークポイントを再度有効にするようにBIOSにパッチを適用することもできますが、これには生産コードで使用できないBIOSを変更する機能が必要です。