www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why are breakpoints caught by the runtime?

reply "Trass3r" <un known.com> writes:
void main()
{
	asm { int 3; }
}

object.Error: Breakpoint
----------------
0x00402013 in _Dmain at bptest.d(6)
0x00402314 in void rt.dmain2._d_run_main(int, char**, extern (C) 
int function(char[][])*).runAll().void __lambda1()
0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern (C) 
int function(char[][])*).runAll()
0x00402200 in _d_run_main


Is there any good reason to catch that?
I really want the debugger to fire up.
Jun 15 2014
next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote:
 void main()
 {
 	asm { int 3; }
 }

 object.Error: Breakpoint
 ----------------
 0x00402013 in _Dmain at bptest.d(6)
 0x00402314 in void rt.dmain2._d_run_main(int, char**, extern 
 (C) int function(char[][])*).runAll().void __lambda1()
 0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern 
 (C) int function(char[][])*).runAll()
 0x00402200 in _d_run_main


 Is there any good reason to catch that?
 I really want the debugger to fire up.

Which OS and compiler version is that? The breakpoint is correctly triggered here on openSUSE 13.1 x86_64 / DMD 2.066 git: # ./bptest Trace/breakpoint trap # gdb ./bptest ... (gdb) run Program received signal SIGTRAP, Trace/breakpoint trap. 0x000000000041b7b5 in D main () (gdb)
Jun 15 2014
prev sibling next sibling parent "Trass3r" <un known.com> writes:
Win7 x64
Jun 15 2014
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Sunday, 15 June 2014 at 15:23:29 UTC, Marc Sch├╝tz wrote:
 On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote:
 void main()
 {
 	asm { int 3; }
 }

 object.Error: Breakpoint
 ----------------
 0x00402013 in _Dmain at bptest.d(6)
 0x00402314 in void rt.dmain2._d_run_main(int, char**, extern 
 (C) int function(char[][])*).runAll().void __lambda1()
 0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern 
 (C) int function(char[][])*).runAll()
 0x00402200 in _d_run_main


 Is there any good reason to catch that?
 I really want the debugger to fire up.

Which OS and compiler version is that? The breakpoint is correctly triggered here on openSUSE 13.1 x86_64 / DMD 2.066 git: # ./bptest Trace/breakpoint trap # gdb ./bptest ... (gdb) run Program received signal SIGTRAP, Trace/breakpoint trap. 0x000000000041b7b5 in D main () (gdb)

Obviously he is using windows and compiler version is irrelevant - it is windows runtime issue.
Jun 15 2014
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Sunday, 15 June 2014 at 14:50:30 UTC, Trass3r wrote:
 void main()
 {
 	asm { int 3; }
 }

 object.Error: Breakpoint
 ----------------
 0x00402013 in _Dmain at bptest.d(6)
 0x00402314 in void rt.dmain2._d_run_main(int, char**, extern 
 (C) int function(char[][])*).runAll().void __lambda1()
 0x004022E7 in void rt.dmain2._d_run_main(int, char**, extern 
 (C) int function(char[][])*).runAll()
 0x00402200 in _d_run_main


 Is there any good reason to catch that?
 I really want the debugger to fire up.

It is default windows runtime behavior and unless it provides some interface to adjust it, you can not fix it (except patching and rebuilding runtime, of course). Or, perhaps, you can bypass runtime behavior by using windows api directly to adjust the behavior to your needs. By the way, judging by that runtime catches windows exceptions and rethrows them as errors (object.Error: Breakpoint), you are not encouraged to catch them.
Jun 15 2014
prev sibling next sibling parent "Trass3r" <un known.com> writes:
 It is default windows runtime behavior

Yeah but couldn't/shouldn't it let breakpoints through?
Jun 15 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Trass3r"  wrote in message news:sgcekbmbxefmnghzsaaf forum.dlang.org...

 Is there any good reason to catch that?
 I really want the debugger to fire up.

I know, I hate this. You can disable it by changing rt_trapExceptions in dmain2.d in druntime to false and rebuilding druntime, which is horrible but what I usually do. Unfortunately it is read before Dmain and the module constructors are run so it's tricky to clear on startup.
Jun 15 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Trass3r"  wrote in message news:lonuiouwqmquoyrjhbcv forum.dlang.org...

 So you can't even do something like
 extern extern (C) __gshared bool rt_trapExceptions;
 void main()
 {
 rt_trapExceptions = false;
 asm { int 3; }
 }

No, because rt_trapExceptions is checked before main is called, something like this: int tryMain() { void runMainAndStuff() { runModuleConstructors(); main(); } if (rt_trapExceptions) { try { runMainAndStuff(); } catch { ... } } else runMainAndStuff(); } It might be possible to _replace_ the variable using some linker magic but I haven't managed to do that successfully.
Jun 17 2014
prev sibling parent "Trass3r" <un known.com> writes:
On Monday, 16 June 2014 at 01:23:28 UTC, Daniel Murphy wrote:
 "Trass3r"  wrote
 Is there any good reason to catch that?
 I really want the debugger to fire up.

I know, I hate this. You can disable it by changing rt_trapExceptions in dmain2.d in druntime to false and rebuilding druntime, which is horrible but what I usually do. Unfortunately it is read before Dmain and the module constructors are run so it's tricky to clear on startup.

So you can't even do something like extern extern (C) __gshared bool rt_trapExceptions; void main() { rt_trapExceptions = false; asm { int 3; } } Strangely enough now my original example triggers the debugger. Not a clue what changed.
Jun 17 2014