在 MSVC 中，DebugBreak() 或 __debugbreak 会导致调试器中断。在 x86 上它相当于写“_asm int 3”，在 x64 上它是不同的。使用 gcc（或任何其他标准编译器）编译时，我也想中断调试器。是否有独立于平台的功能或内在功能？我看到了XCode question，但它似乎不够便携。
旁注：我主要想用它来实现 ASSERT，我知道我可以为此使用 assert()，但我也想在代码中编写 DEBUG_BREAK 或其他东西。
【问题讨论】：
标签： c++ portability debugbreak
FWIW，这些解决方案均不适用于使用 NRF Connect SDK 的 nRF9160。这是一个 SEGGER Embedded Studio for ARM（北欧版）环境，使用 arm-none-eabi-gcc 编译器。
其他答案中提到的debug-trap.h、debugbreak.h和__builtin_trap()都导致“未定义的操作码”和硬故障（或调试监视器故障，但结果相同）并且没有有用的程序计数器、堆栈帧或其他可调试信息。
最后，这个替代方案确实奏效了。我是从其他一些神秘的北欧图书馆派生出来的，它被称为NRF_BREAKPOINT：
#if defined(__GNUC__)
__asm__("BKPT 0");
#else
__BKPT(0)
#endif
在构建时，会包含__GNUC__ 路径，因此只需要__asm__("BKPT 0")。
【讨论】：
我刚刚将a module 添加到portable-snippets（可移植代码的公共域sn-ps 集合）来执行此操作。它不是 100% 可移植的，但它应该非常健壮：
__builtin_debugtrap 用于某些版本的 clang（标识为 __has_builtin(__builtin_debugtrap)）__debugbreak
__breakpoint(42)
int3
.inst 0xde01
.inst 0xd4200000
.inst 0xe7f001f0
bpt
__builtin_trap
signal.h 和
defined(SIGTRAP)（即POSIX），raise(SIGTRAP)
raise(SIGABRT)
将来，portable-sn-ps 中的模块可能会扩展以包含其他逻辑，我可能会忘记更新此答案，因此您应该在那里查找更新。它是公共领域 (CC0)，所以请随意窃取代码。
【讨论】：
int3 以明确表示您需要特殊情况调试中断指令，一个字节 CC 而不是 CD 03 ，适用于罕见的情况（代码大小和 v8086 模式）。 (felixcloutier.com/x86/intn:into:int3:int1)。使用 NASM，它们实际上组装方式不同，GAS 将两者都优化为 int3。
__builtin_trap 通常编译为ud2 (x86) 或其他非法指令，而不是调试断点，并且也被视为 noreturn 即使使用调试器也无法继续。它不属于这个列表。例如在 C return x 语句之前使用它的简单函数中，在 ud2 之后没有 ret 指令。
int3。 FWIW，GCC 和 clang 也生成 int3（至少使用 -O3），这在这里真正重要，因为它是关于 C++ 而不是汇编。不过，听起来int3 更正确，所以没有理由不“修复”它:)
__debug_trap，我不确定这里真的有什么可以做的。在注释和链接代码中，它都处于回退区域的深处，只有在其他一切都失败时才调用并且它是一个非托管环境（在这种情况下 signal.h 将不可用）。 AFAICT 替代方案要么什么都没有，要么是编译时错误。如果您对其他可能的替代方案有建议，我当然会开放；我同意这是次优的（因此它是最后的手段）。
-O3 应该无关紧要，即使对于 clang 的内置汇编器也是如此。这就是将 C++ 转换为 asm 的优化级别。 Asm 到机器代码（包括来自asm("") 模板字符串的asm）对于gcc 来说是一个真正独立的过程，对于clang 来说在逻辑上是独立的。但是，是的，int3 是个好主意；这就是 0xCC 的反汇编方式，它更准确地表达了你想要的东西。
如果您认为assert(x) 足够便携，assert(false) 似乎是解决您问题的明显便携解决方案。
【讨论】：
assert 根本不是一个合适的解决方案，因为它通常不允许程序继续执行。
对于这个问题，这似乎是一个非常好的、可移植的解决方案： https://github.com/scottt/debugbreak
引用的存储库中提供的标头 (debugbreak.h) 封装了 MSVC 的
__debugbreak,
和
__asm__ volatile("int $0x03");
在 i386 和 x86_64 上，并在 ARM 上实现
__asm__ volatile(".inst 0xe7f001f0");
以及记录标题中指出的问题的一些解决方法，用于单步越过 GDB 中的断点，以及用于在 stepi 或 cont 的平台上扩展 GDB 的 Python 脚本em> 卡住了。该脚本将 debugbreak-step 和 debugbreak-continue 添加到 GDB。
【讨论】：
#define __debugbreak() \
do \
{ static bool b; \
while (!b) \
sleep(1); \
b = false; \
} while (false)
当进程处于休眠状态时，您可以将调试器附加到进程，更改变量 b 以中断循环并执行您的操作。此代码可能无法在优化的构建中运行！
【讨论】：
如果您尝试调试与崩溃相关的情况，老式的 abort() 将在大多数平台上为您提供调用堆栈。缺点是您无法从当前 PC 继续，您可能也不想这样做。
【讨论】：
这看起来像一个合适的兼容库https://github.com/scottt/debugbreak
【讨论】：
一种可移植到大多数 POSIX 系统的方法是：
raise(SIGTRAP);
【讨论】：
raise(SIGTRAP) 在 gcc/Linux 上非常适合我。 __builtin_trap() 引发了 SIGILL 信号。
SIGTRAP 是一个未声明的标识符。
#include <signal.h>了吗？
与其使用“正常”调试中断，不如使用以下方法之一，例如除以零：
int iCrash = 13 / 0;
或取消引用 NULL 指针：
BYTE bCrash = *(BYTE *)(NULL);
至少这在许多平台/架构上是可移植的。
在许多调试器中，您可以指定要对哪些异常执行什么操作，以便在遇到上述任一情况（如暂停执行，也就是“int 3”指令）并生成异常时采取相应措施。
【讨论】：
GCC 有一个名为 __builtin_trap 的内置函数，您可以看到 here，但是假设一旦达到此值，代码执行就会停止。
您应该确保__builtin_trap() 调用是有条件的，否则在它之后不会发出任何代码。
这篇文章由 5 分钟的测试推动，YMMV。
【讨论】：
__builtin_trap 通常编译为ud2 (x86) 或其他非法指令，而不是调试断点，并且也被视为 noreturn 即使使用调试器也无法继续。
如何定义一个基于 #ifdef 的条件宏，该宏可以扩展为基于当前架构或平台的不同结构。
类似：
#ifdef _MSC_VER
#define DEBUG_BREAK __debugbreak()
#else
...
#endif
这将由预处理器根据编译代码的平台扩展正确的调试器中断指令。这样您就可以在代码中始终使用DEBUG_BREAK。
【讨论】：