On Mon, Jun 3, 2024 at 9:06 AM Peter0x44 <peter0...@disroot.org> wrote:
>
> 3 Jun 2024 4:14:28 pm Jonathan Wakely <jwak...@redhat.com>:
>
> > On Mon, 3 Jun 2024 at 14:36, Peter0x44 wrote:
> >>> +void
> >>> +std::breakpoint() noexcept
> >>> +{
> >>> +#if _GLIBCXX_HAVE_DEBUGAPI_H && defined(_WIN32) &&
> >>> !defined(__CYGWIN__)
> >>> + DebugBreak();
> >>> +#elif __has_builtin(__builtin_debugtrap)
> >>> + __builtin_debugtrap(); // Clang
> >>> +#elif defined(__i386__) || defined(__x86_64__)
> >>> + __asm__ volatile ("int3");
> >> Worth noting, currently gcc has some bugs around its handling of int3,
> >
> > s/gcc/gdb/ ?
> Yes, my bad
> >
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=31194
> >> int3;nop seems to work around it okay. __builtin_debugtrap() of clang
> >> does run into the same issues.
> >
> > It seemed to work OK for me, maybe because there's no code after it?
> I suspect it won't matter for the tests, the assertion failure is only if
> you step after hitting the int3. I just figured I'd mention it as a heads
> up. It would affect users writing code.
Note there is a request for adding __builtin_break to GCC;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84595 .
(and one for __builtin_debugtrap;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299 ).
When __builtin_break is added, I think we should use that here if it
is available (as a higher priority than __builtin_debugtrap).
Thanks,
Andrew
> >
> > void breakpoint() {
> > __asm__ volatile ("int3);
> > }
