Bug 84595 - Add __builtin_break() built-in for a breakpointing mechanism
Summary: Add __builtin_break() built-in for a breakpointing mechanism
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 7.3.1
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-27 15:26 UTC by Daniel Gutson
Modified: 2018-05-11 18:37 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Gutson 2018-02-27 15:26:13 UTC
__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.
Comment 1 Andrew Pinski 2018-02-27 16:28:07 UTC
What you want is __builtin_breakpoint (if that existed).  Trap is considered as noreturn just like abort/exit.
Comment 2 Andrew Pinski 2018-02-27 16:30:53 UTC
https://github.com/scottt/debugbreak
Comment 3 Daniel Gutson 2018-02-27 16:33:36 UTC
(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.
Comment 4 Andrew Pinski 2018-02-27 16:39:08 UTC
(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.
Comment 5 Daniel Gutson 2018-02-27 16:42:57 UTC
(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?
Comment 6 David Malcolm 2018-02-27 20:39:50 UTC
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.
Comment 7 Richard Biener 2018-02-28 08:37:14 UTC
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?
Comment 8 Daniel Gutson 2018-02-28 11:35:09 UTC
(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?
Comment 9 H. Peter Anvin 2018-05-11 18:37:37 UTC
How is this different from raise(SIGTRAP);?