digitalmars.D.debugger - [ddbg] trap to debugger?
- Vladimir Panteleev (19/19) Jul 08 2007 It comes often that during programming, I'd like to add a breakpoint at ...
- Jascha Wetzel (10/12) Jul 08 2007 yep, atm, ddbg ignores all breakpoints that it didn't set itself.
- Vladimir Panteleev (6/9) Jul 08 2007 Hehe, maybe I was just tired and annoyed of my bugs :)
- BCS (8/26) Jul 08 2007 if ddbg takes a "start up commands file" of some sort then you could add...
It comes often that during programming, I'd like to add a breakpoint at = source level. Since I don't use an IDE, having to specify breakpoints in= file:line format every time I run Ddbg (the line numbers change, so the= -cmd=3D parameter doesn't help much). It's common practice in other lan= guages to add a "hard breakpoint", for example in case of a failed asser= t (which should never fail anyway, as they are checked only in debug bui= lds, so depending on them isn't right). This is done by simply inserting= an "int 3" instruction in the code: asm { int 3; } However, Ddbg seems to just ignore these at the moment (while, when runn= ing the executable as it is, a "Win32 Exception" is raised). Would it be= hard to make Ddbg catch these exceptions and react as if a breakpoint w= as hit? P.S. I realise that this post may sound like it's written in an angry mo= od, but I'm actually very grateful for your work, Jascha :) D projects w= ould be considerably harder to maintain on Windows without Ddbg! -- = Best regards, Vladimir mailto:thecybershadow gmail.com
Jul 08 2007
Vladimir Panteleev wrote:However, Ddbg seems to just ignore these at the momentyep, atm, ddbg ignores all breakpoints that it didn't set itself. i'll take care of the int3-issue for the next relase. until then, you can use the OutputDebugString interface to simulate a manual int 3: OutputDebugStringA(toStringz("Ddbg: bp "~__FILE__~":"~.toString(__LINE__+1)~"; r")); if you wrap this nicely, it's similarly convenient.P.S. I realise that this post may sound like it's written in an angry mood, but I'm actually very grateful for your work, Jascha :) D projects would be considerably harder to maintain on Windows without Ddbg!didn't sound angry me. besides that, feel free to be angry. it helps to improve things ;)
Jul 08 2007
On Sun, 08 Jul 2007 21:12:13 +0300, Jascha Wetzel <firstname mainia.de> wrote:i'll take care of the int3-issue for the next relase.Great, thanks!didn't sound angry me. besides that, feel free to be angry. it helps to improve things ;)Hehe, maybe I was just tired and annoyed of my bugs :) -- Best regards, Vladimir mailto:thecybershadow gmail.com
Jul 08 2007
Reply to Vladimir,It comes often that during programming, I'd like to add a breakpoint at source level. Since I don't use an IDE, having to specify breakpoints in file:line format every time I run Ddbg (the line numbers change, so the -cmd= parameter doesn't help much). It's common practice in other languages to add a "hard breakpoint", for example in case of a failed assert (which should never fail anyway, as they are checked only in debug builds, so depending on them isn't right). This is done by simply inserting an "int 3" instruction in the code: asm { int 3; } However, Ddbg seems to just ignore these at the moment (while, when running the executable as it is, a "Win32 Exception" is raised). Would it be hard to make Ddbg catch these exceptions and react as if a breakpoint was hit? P.S. I realise that this post may sound like it's written in an angry mood, but I'm actually very grateful for your work, Jascha :) D projects would be considerably harder to maintain on Windows without Ddbg!if ddbg takes a "start up commands file" of some sort then you could add: pragma(msg, "bp "~__FILE__~":"~itoa!(__LINE__)); everywhere you want a breakpoint and then have your build copy these lines to a file. build root.d > startup I have a bunch of stuff like this on a project I'm working on but it's on linux and uses bash/grep/sed/etc.
Jul 08 2007