In MSVC, DebugBreak() or __debugbreak cause a debugger to break. On x86 it is equivalent to writing \"_asm int 3\", on x64 it is something different. When compiling with gcc
This looks like an appropriate compat library https://github.com/scottt/debugbreak
This seems to be a very good, portable solution to this question: https://github.com/scottt/debugbreak
The header provided in the repository cited (debugbreak.h) encapsulates MSVC's
__debugbreak,
and
__asm__ volatile("int $0x03");
on i386 and x86_64, and on ARM it implements
__asm__ volatile(".inst 0xe7f001f0");
as well as documenting some workarounds for problems noted in the header for single-stepping past the breakpoint in GDB plus a Python script for extending GDB on those platforms where stepi or cont get stuck. The script adds debugbreak-step and debugbreak-continue to GDB.
A method that is portable to most POSIX systems is:
raise(SIGTRAP);
If you consider assert(x)
portable enough, assert(false)
seems to be the obvious portable solution to your problem.
If you are trying to debug a crash-related condition, good old fashioned abort() will give you a call stack on most platforms. Downside is that you can't continue from the current PC, which you probably don't want to do anyway.
http://www.cplusplus.com/reference/cstdlib/abort/
#define __debugbreak() \
do \
{ static bool b; \
while (!b) \
sleep(1); \
b = false; \
} while (false)
When the process is sleeping, you can attach a debugger to the process, change the variable b to break the loop and do your thing. This code might not work in an optimized build!