Remove assumptions that thread 0 is always the main thread.

Starting with Windows 10, the Windows loader is itself multi-threaded,
meaning that the loader spins up a few threads to do process
initialization before it executes main.  Windows delivers these
notifications asynchronously and they can come out of order, so
we can't be sure that the first thread we get a notification about
is actually the zero'th thread.

This patch fixes this by requesting the thread stopped at the
breakpoint that was specified, rather than getting thread 0 and
verifying that it is stopped at a breakpoint.

Differential Revision: http://reviews.llvm.org/D16247

llvm-svn: 258432

1 files changed, 3 insertions, 6 deletions

diff --git a/lldb/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py b/lldb/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
index de7a333a18f..30ed73b5205 100644
--- a/lldb/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
+++ b/lldb/packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
@@ -112,14 +112,11 @@ class BitfieldsTestCase(TestBase):
         self.assertTrue(process, PROCESS_IS_VALID)
 
         # The stop reason of the thread should be breakpoint.
-        thread = target.GetProcess().GetThreadAtIndex(0)
-        if thread.GetStopReason() != lldb.eStopReasonBreakpoint:
-            from lldbsuite.test.lldbutil import stop_reason_to_str
-            self.fail(STOPPED_DUE_TO_BREAKPOINT_WITH_STOP_REASON_AS %
-                      stop_reason_to_str(thread.GetStopReason()))
+        thread = lldbutil.get_stopped_thread(process, lldb.eStopReasonBreakpoint)
+        self.assertIsNotNone(thread)
 
         # The breakpoint should have a hit count of 1.
-        self.assertTrue(breakpoint.GetHitCount() == 1, BREAKPOINT_HIT_ONCE)
+        self.assertEqual(breakpoint.GetHitCount(), 1, BREAKPOINT_HIT_ONCE)
 
         # Lookup the "bits" variable which contains 8 bitfields.
         frame = thread.GetFrameAtIndex(0)