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 reply "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:


     Trace/breakpoint trap

     ...
     (gdb) run
     Program received signal SIGTRAP, Trace/breakpoint trap.
     0x000000000041b7b5 in D main ()
     (gdb)
Jun 15 2014
next sibling parent "Trass3r" <un known.com> writes:
Win7 x64
Jun 15 2014
prev 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:


     Trace/breakpoint trap

     ...
     (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 reply "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
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 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 reply "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
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