• "Vladimir Panteleev" <thecybershadow gmail.com> Jul 08 2007
• Jascha Wetzel <firstname mainia.de> Jul 08 2007
• "Vladimir Panteleev" <thecybershadow gmail.com> Jul 08 2007
• BCS <ao pathlink.com> Jul 08 2007

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

Vladimir Panteleev wrote:
 However, Ddbg seems to just ignore these at the moment


yep, 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 ;)

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

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.