我的理解是，插入软件断点涉及用软件中断指令替换要执行的代码中的下一条指令，这将导致 CPU 在到达该指令时停止。
硬件断点涉及将要执行的断点之后的下一条指令的地址放入寄存器中，当地址匹配时，通过使用硬件比较器，这会导致 CPU 停止（如果我是，请纠正我错了）。
我感到困惑的是，例如，当使用硬件调试器通过 JTAG 调试板时，我们是否只使用硬件断点？或者 JTAG 也可以使用软件断点吗？
GDB 是否只与软件断点一起使用，还是可以与 JTAG 一起使用？对不起，如果问题有点宽泛。
【问题讨论】：
标签： debugging embedded interrupt breakpoints jtag
"如果我错了请纠正我"
断点是在指令上设置的，而不是在它之后——断点发生在之前指令被执行，而不是在之后——否则在跳转时设置断点，调用否则分支指令会失败。
"我们是否只在使用硬件调试器通过 JTAG 调试板时才使用硬件断点？"
JTAG 是用于片上调试的简单通信接口（例如用于其他用途，例如在线存储器和 FPGA 编程和边界扫描）。
虽然它可能因 ARM Cortex-M 上的架构而异，但您可以从目标代码访问片上调试寄存器并设置硬件断点。 Yoiu 还可以使用 BKPT 指令在您的代码中放置软件断点（而不是您建议的 SWI）。
或者 JTAG 也可以使用软件断点吗？
正如我所说，JTAG 只是片上调试的通信接口，但是通过片上调试，您可以直接设置任何 RAM 内容，因此 JTAG 连接在开发主机上运行的调试器软件可以临时修改RAM中的代码以设置软件断点（通过将目标指令替换为BKPT，然后当断点被击中时，恢复到原始指令以便可以执行. 软件断点对于从 ROM 运行的代码来说并不是那么简单，尽管一些调试器支持无限的 ROM 断点（需要付费）——此类硬件的制造商不一定会公开他们用来执行此操作的方法。
在 JTAG 和片上调试在 evebnlow-end 器件上广泛使用之前，使用了在线仿真和 ROM 仿真器等技术。这些通常是昂贵且复杂的解决方案。
GDB 是否只与软件断点一起使用，还是可以与 JTAG 一起使用？
可以通过多种方式使用 GDB。它需要一个“调试存根”——一个将调试器软件映射到可用硬件的软件层——其性质取决于所使用的调试接口和目标设备。例如，当使用 UART 或以太网端口时，存根实际上是在目标本身上运行的代码（例如 Linux 的 gdbserver）。在这种情况下，它不太可靠，因为软件错误可能会阻止调试端口驱动程序实际运行，尤其是在缺乏 MMU 保护的目标中。更简单的 JTAG 设备通过在开发主机上运行的存根与 GDB 接口，例如常用的 OpenOCD 软件。更昂贵的 JTAG 调试硬件可能会在 JTAG 硬件本身上运行存根——例如 Abatron 的 bdi2000。无论哪种方式，调试存根都将能够根据目标功能使用硬件和软件断点。
【讨论】：
在本文的上下文中，让我们就断点的统一定义达成一致。这里讨论的断点是我们希望处理器停止的程序位置，以便我们可以进行某种调试。可能还有其他类型的断点，例如由数据访问触发的断点，但在本文中，我们将只讨论程序断点，即应用程序代码中每次遇到该代码时我们希望暂停的位置。
硬件断点和软件断点有什么区别？那么，显而易见的答案是“硬件断点在硬件中实现”和“软件断点在软件中实现”。但这究竟意味着什么，它的后果是什么？为什么我会选择一个而不是另一个？
硬件断点实际上是由集成到设备中的特殊逻辑实现的。您可以将硬件断点视为一组连接到程序地址总线的可编程比较器。这些比较器使用特定的地址值进行编程。当代码正在执行时，并且程序地址总线上的地址中的所有位都与编程到比较器中的位相匹配，硬件断点逻辑会向 CPU 生成一个信号以停止。 使用硬件断点的好处是它可以在任何类型的内存中使用。在讨论了软件断点之后，这可能更有意义。当我们讨论软件断点时，我们会发现它们只能在易失性内存中使用。无论正在执行的代码是在 RAM 还是 ROM 中，都可以使用硬件断点，因为对于硬件断点逻辑，没有区别。它只是匹配 PAB 上的一个地址，并在找到一个地址时停止 CPU。 HWBP 的缺点是，因为它们是在硬件中实现的，所以可用的数量有限。可用的 HWBP 数量因架构而异，但在大多数情况下只有 2-8 个可用。确定设备有多少的最简单方法是在 CCS 中连接到它并继续设置 HWBP，直到您收到没有可用设备的错误消息。
如前所述，软件断点是在软件中实现的。但是这是怎么做到的呢？实际上有两种不同的实现。 一些设备在其操作码定义中保留了一个指定的位来指示软件断点。例如，在 C6000 系列的一种架构中，所有指令的长度均为 32 位，并且保留第 28 位以指示软件断点，因此该指令集中的所有指令都将第 28 位设为零。在这种情况下，当在 CCS 中设置软件断点时，它实际上会修改该位置处指令的操作码并将第 28 位设置为 1。然后，仿真逻辑会监控程序操作码是否只要第 28 位为 1，并且发生这种情况时停止 CPU。请注意，这是少数情况。大多数架构不这样做。原因是它限制了指令集的灵活性。此外，它不适用于具有可变长度指令的架构，因此它也限制了代码密度。 更流行的实现软件断点的方法也复杂得多。在这种情况下，有一个指定的断点操作码。通常，操作码是 8 位。每当设置断点时，该位置处指令的前 8 位将被删除并替换为该 8 位断点操作码。然后将指令的原始 8 位存储在断点表中。每当遇到断点时，CPU 就会停止，CCS 将断点操作码替换为指令的原始 8 位。当重新开始执行时，CCS 必须做一些诡计，因为实际 CPU 流水线中的指令是不正确的。它仍然有断点操作码。因此 CCS 刷新 CPU 流水线，然后将其中待处理的指令重新获取到它们的原始状态，下一个要执行的函数是设置断点的函数。同时，CCS 用断点操作码重新加载该位置的指令，以便下次遇到该代码时，它将再次停止。 SWBP 的优点是数量不受限制，因此您可以将它们放在任意数量的地方。缺点是不能将它们放在ROM/FLASH等非易失性存储器中，因为CCS无法将操作码写入该位置。
http://processors.wiki.ti.com/index.php/How_Do_Breakpoints_Work
【讨论】：