How to break in at the call site that invokes the break point

re: How to break in at the call site that invokes the break point

strik — Tue, 09 May 2006 10:06:05 GMT

I hope it is not only __debugbreak() which you do not call in production code, but also your macro TRAP() and DebugBreak(), which do not belong in production code.

Or are there legitimate reasons to add them in production code?

re: How to break in at the call site that invokes the break point

doronh — Tue, 09 May 2006 20:19:29 GMT

look at how TRAP() is defined. It only does something if DBG is defined (e.g. a chk build). If DBG is not defined or is zero, TRAP() evaluates to a no-op, so it still exists in the code .c(pp) file, but does not exist in the generated binary.

Embedding an int3 or DbgBreakPoint in a release driver can have disastrous affects. If that code is executed and a kernel debugger is not attached, the machine bug checks due to an unhandled exception.

Interesting Finds

Jason Haley — Tue, 09 May 2006 22:13:19 GMT

re: How to break in at the call site that invokes the break point

Skywing — Tue, 09 May 2006 22:19:30 GMT

__debugbreak was added in CL 13 (VC7), IIRC.

re: How to break in at the call site that invokes the break point

doronh — Thu, 11 May 2006 00:39:51 GMT

thx skywing, that is good info to have

d

re: How to break in at the call site that invokes the break point

Ishai — Thu, 11 May 2006 18:41:35 GMT

Since __debugbreak() is a compiler intrinsic it does not prevent optimizations like inline __asm {int 3} does. As a result, if you have two instances of if (something failed) { TRAP(); return STATUS_SOME_ERROR; } the compiler tends to generate a single breakpoint for both calls which is probably not what you wanted (at least not what I wanted when I moved to __debugbreak())

re: How to break in at the call site that invokes the break point

doronh — Thu, 11 May 2006 19:41:08 GMT

Ishai, I don't see this as a problem. Why? Because my TRAP()s are not on in an optimized free build. My debug builds, where TRAP() is turned on, are not optimized so the problem does not show up. A chk optimized build is possible, but I rarely find them useful.

If you really wanted the TRAP()s to not be folded, I think you could do something like this (I haven't tested this on an optimized build to see if it really works though)

#define TRAP()             \ 
__pragma optimize("", off) \ 
__debugbreak()             \
__pragma optimize("", on)

A Hole In My Head How to break in at the call site that invokes the | Portable Greenhouse

Mon, 01 Jun 2009 14:15:59 GMT

PingBack from http://portablegreenhousesite.info/story.php?id=14481