[Bug gdb/31194] Stepping on "int3" instruction fails assertion.

["peter0x44 at disroot dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=31194

--- Comment #7 from Peter0x44 <peter0x44 at disroot dot org> ---
> I'm not really sure how int3 is supposed to be handled
Perhaps it would be beneficial to state what my preferences would be.
On Windows it is common to use it as a "continuable assertion", the Microsoft
compiler has the intrinsic __debugbreak() to generate it, along with clang
__builtin_debugtrap(). I expect it to break pointing to the line containing the
assertion, if defined in a macro likeso:
#define assert(e) do { if (!e) __asm__("int3") } while (0)

After which "continue" or "step" would behave "as expected"
Maybe there's some cases I haven't considered where this could be problematic,
or the issue actually lies with the gcc/clang generated debug info. To be
clear, the assertion fails in the same way even if you build the executable
using the clang __builtin_debugtrap() intrinsic.

There is a workaround for my case - you can use __builtin_trap, which compiles
to "ud2", and then use `j +1` to skip the ud2 when debugging. However, gcc
treats code following __builtin_trap() as dead, so it's not always possible to
step past the assertion.

Related info that made me think about assert macros more generally:
https://nullprogram.com/blog/2022/06/26/

Some of this is off topic but I figure more info can't hurt.

-- 
You are receiving this mail because:
You are on the CC list for the bug.