__builtin_trap() cannot be used as a breakpointing mechanism because the optimizer removes all subsequent code: #include <stdio.h> int main() { __builtin_trap(); printf("hello world\n"); return 0; } Then main: ud2 I propose, as a feature, either to provide a new command line option to control whether the code is optimized out or preserved, or to a add a new builtin function.
What you want is __builtin_breakpoint (if that existed). Trap is considered as noreturn just like abort/exit.
https://github.com/scottt/debugbreak
(In reply to Andrew Pinski from comment #1) > What you want is __builtin_breakpoint (if that existed). Trap is considered > as noreturn just like abort/exit. OK. That was my second suggested alternative. BTW I didn't see __builtin_trap documented as noreturn in the documentation.
(In reply to Daniel Gutson from comment #3) > OK. That was my second suggested alternative. > BTW I didn't see __builtin_trap documented as noreturn in the documentation. Depends on the reading of __builtin_trap documentation. My reading says it does not return. "This function causes the program to exit abnormally. GCC implements this function by using a target-dependent mechanism (such as intentionally executing an illegal instruction) or by calling abort." Since the documentation talks about calling abort, I would assume __built_trap should be treated almost the same as calling abort.
(In reply to Andrew Pinski from comment #4) > (In reply to Daniel Gutson from comment #3) > > OK. That was my second suggested alternative. > > BTW I didn't see __builtin_trap documented as noreturn in the documentation. > > Depends on the reading of __builtin_trap documentation. > My reading says it does not return. > > "This function causes the program to exit abnormally. GCC implements this > function by using a target-dependent mechanism (such as intentionally > executing an illegal instruction) or by calling abort." > > Since the documentation talks about calling abort, I would assume > __built_trap should be treated almost the same as calling abort. OK. I'll leave this issue as a feature request for __builtin_break(). Maybe the component should be changed to something more appropriate?
Compare with e.g. the G_BREAKPOINT macro within GNOME's GLib library, which has accumulated a collection of platform-specific logic for C/C++ code that wants to inject a breakpoint: http://git.gnome.org/browse/glib/tree/glib/gbacktrace.h (LGPLv2+ licensed) I had a go at adding something similar to CPython: https://bugs.python.org/issue9635 (albeit for fewer platforms) It seems useful to have this in either the compiler or in GNU libc.
I frequently use raise(SIGSTOP) ... (or x86 specific you can do asm ("int 3"); or whatever that break thing was... Note I think that a compiler-only-side implementation might not be possible on all targets given it might be dependent on OS and debugger preferences as well?
(In reply to Richard Biener from comment #7) > I frequently use raise(SIGSTOP) ... (or x86 specific you can do asm ("int > 3"); > or whatever that break thing was... > > Note I think that a compiler-only-side implementation might not be possible > on all targets given it might be dependent on OS and debugger preferences > as well? It is an interesting observation. I'll drop a question in the DWARF mailing list. In any case it could be a -ggdb extension? (a table of predefined breakpoints) Pedro?
How is this different from raise(SIGTRAP);?
*** Bug 99299 has been marked as a duplicate of this bug. ***
(In reply to Richard Biener from comment #7) > I frequently use raise(SIGSTOP) ... (or x86 specific you can do asm ("int > 3"); > or whatever that break thing was... > > Note I think that a compiler-only-side implementation might not be possible > on all targets given it might be dependent on OS and debugger preferences > as well? Generating a trap instruction is not. How that then will be handled by something else is that something else's concern, yes :-)
(In reply to H. Peter Anvin from comment #9) > How is this different from raise(SIGTRAP);? It does an architecture-specific trap instruction, not a SIGTRAP signal. The former is useful even if you do not have an OS (or *are* the OS), for example.