[Lldb-commits] [PATCH] D15834: Handle hardcoded breakpoints on Windows (e.g., int3 or __debugbreak())

[Adrian McCarthy via lldb-commits]

amccarth added a comment.

In http://reviews.llvm.org/D15834#318623, @labath wrote:

> Linux tests the same functionality in TestBuiltinTrap.py. Would it make sense to merge these two tests, given that the only difference is which compiler intrinsic is used to generate the int3 trap?


Yes, it makes sense to combine the tests.  The existing test does use the SB API very well, and TestBuiltinTrap.py is in a Linux-specific part of the test tree, so this may be more of re-working the Linux test to work much like this new one.


================
Comment at: source/Plugins/Process/Windows/Live/ProcessWindowsLive.cpp:601-605
@@ -579,5 +600,7 @@
             {
+                // The thread hit a hard-coded breakpoint like an `int 3` or `__debugbreak()`.
                 WINLOG_IFALL(WINDOWS_LOG_BREAKPOINTS | WINDOWS_LOG_EXCEPTION,
-                             "Breakpoint site %d is not valid for this thread, creating empty stop info.",
-                             site->GetID());
+                                "No breakpoint site matches for this thread. __debugbreak()?  "
+                                "Creating stop info with the exception.");
+                // FALLTHROUGH:  We'll treat this as a generic exception record in the default case.
             }
----------------
zturner wrote:
> When you do a disassembly, does the arrow point to the int 3 or to the instruction after the int 3?
> 
> Also what does the output look like when you do a backtrace?
It points to the instruction after the int 3.

(lldb) thread backtrace
* thread #1: tid = 0x4d70, 0x00a8903b a.out`main(argc=1, argv=0x0019c800) + 59 at main.c:12, stop reason = Exception 0x80000003 encountered at address 0xa8903a
  * frame #0: 0x00a8903b a.out`main(argc=1, argv=0x0019c800) + 59 at main.c:12
    frame #1: 0x00a89157 a.out`.text$mn + 254


http://reviews.llvm.org/D15834