date:20160115

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

2016-01-15 Thread Pavel Labath via lldb-commits

I don't really understand the purpose of the test, but if the purpose
of it is to check whether something appears on stdout, then a pexpect
test does seem like the right tool for the job.

I have tried entering the commands from the test manually, and the
required text does *not* appear when using the lldb built on the
buildbot, while it *does* appear when using the lldb I build locally.
So, this appears to be a genuine bug caused by something in the
buildbot environment, but it's not clear to me now what it could be.

That said, there is currently a big problem with the way this test is
written, and that's the fact that the prompt expectation does not play
well with the lldb's colored prompt feature. LLDB colors the prompt by
overwriting the text which was already written by editline, resulting
in something like "(lldb) \33[2m(lldb) \33[22m" written to stdout.
This throws pexpect completely off scent, as the prompt substring
appears twice, causing the commands and their expectations to
misalign. Right now it does not matter, because as soon as you start
looking for the pattern "this is a test string", the streams will
align up, but it can cause you a lot of problems if you execute a
command and then try to observe some external side effects of it,
because pexpect will return before the command has even been given a
chance to complete.

BTW: the skipIfRemote decorator is not needed. It was needed on
TestBatchMode, because that one actually runs executables, which needs
some plumbing to work remotely, but since this test just plays with
python commands it will execute just fine in the remote mode.

pl

On 14 January 2016 at 19:06, Jim Ingham via lldb-commits
 wrote:
> Well, actually on Unix MOST things are files, it was Plan 9 in which that all 
> things are files, IIRC...
>
> Jim
>
>> On Jan 14, 2016, at 11:04 AM, Jim Ingham  wrote:
>>
>> Yes, on unix all things are files and all files work the same except when 
>> they don't.  I'd rather test the thing we ACTUALLY care about, rather than 
>> testing something else and assuming that it is going to work in the case we 
>> care about as well.
>>
>> Jim
>>
>>> On Jan 14, 2016, at 10:58 AM, Zachary Turner  wrote:
>>>
>>> Wouldn't testing with output redirecxted to a file still test that it is 
>>> being streamed as it is obtained rather than a big dump at the end?  I mean 
>>> that's what stdout is right?  Just a file.  If you use a file on the 
>>> filesystem instead, just check the contents of the file after each 
>>> operation.
>>>
>>> On Thu, Jan 14, 2016 at 10:42 AM Jim Ingham  wrote:
>>> I worry giving up on testing using Python's stdout for the immediate output 
>>> stream.  This is a very useful feature, allowing users to make Python based 
>>> commands that produce a bunch of output, and stream the output as it is 
>>> being gathered rather than having the command stall and then dump a bunch 
>>> of text at the end.  This isn't speculative, that's how many of the 
>>> commands that the OS X kernel team ships for inspecting kernel state work.
>>>
>>> So we really should be testing this feature.  Maybe the flakiness on Linux 
>>> is just a pexpect bug, and streaming to stdout would always work correctly 
>>> hooked up to a "real" terminal.  But until we know that we should presume 
>>> that it is something in LLDB->Python or in the way we use Python, and keep 
>>> testing it.
>>>
>>> If you want to separate the two issues, then it would be fine to write 
>>> another test that just tests the type maps for FILE *, but I still think 
>>> this one is valuable.
>>>
>>> Jim
>>>
 On Jan 14, 2016, at 10:16 AM, Zachary Turner via lldb-commits 
  wrote:

 How much time do you think it would take to determine whether or not using 
 the file-based approach would work?  Because on the surface it sounds 
 fairly straightforward, and fixing it that way would allow us to not have 
 to xfail this on more platforms for reasons that we don't understand.

 On Thu, Jan 14, 2016 at 10:15 AM Enrico Granata via lldb-commits 
  wrote:
 The log just shows a timeout is happening in pexpect() - which I don’t 
 have a ready explanation for

 X-failing for now is the proper recourse. But you might want to debug this 
 at some point, since it’s weird behavior. It looks like the command is not 
 even just silently erroring out - from the log you sent it looked stuck 
 somewhere..

 Is there any chance you can step through and see where the hang is 
 happening?

> On Jan 14, 2016, at 3:03 AM, Tamas Berghammer  
> wrote:
>
> I XFAIL-ed the test for Linux to get the build bot green again and filed 
> a bug at https://llvm.org/bugs/show_bug.cgi?id=26139
>
> On Thu, Jan 14, 2016 at 2:18 AM Ying Chen via

Re: [Lldb-commits] [PATCH] D16186: Unconditionally accept symbol sizes from elf

2016-01-15 Thread Greg Clayton via lldb-commits

clayborg requested changes to this revision.
clayborg added a comment.
This revision now requires changes to proceed.

See inlined comments.



Comment at: source/Symbol/Symtab.cpp:974-978
@@ -973,5 +973,7 @@
 Symbol  = m_symbols[entry.data];
-
-symbol.SetByteSize(end_section_file_addr - 
symbol_file_addr);
-symbol.SetSizeIsSynthesized(true);
+if (!symbol.GetByteSizeIsValid())
+{
+symbol.SetByteSize(end_section_file_addr - 
symbol_file_addr);
+symbol.SetSizeIsSynthesized(true);
+}
 }

You can remove this if statement right? Symbol byte size will always be valid 
no?


Comment at: source/Symbol/Symtab.cpp:1070-1071
@@ +1069,4 @@
+Symbol* symbol = SymbolAtIndex(entry->data);
+if (symbol->ContainsFileAddress(file_addr))
+return symbol;
+}

Why do we need to check this? Won't 
"m_file_addr_to_index.FindEntryThatContains(file_addr);" already check this for 
us?


http://reviews.llvm.org/D16186



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D16186: Unconditionally accept symbol sizes from elf

2016-01-15 Thread Tamas Berghammer via lldb-commits

tberghammer added inline comments.


Comment at: source/Symbol/Symtab.cpp:974-978
@@ -973,5 +973,7 @@
 Symbol  = m_symbols[entry.data];
-
-symbol.SetByteSize(end_section_file_addr - 
symbol_file_addr);
-symbol.SetSizeIsSynthesized(true);
+if (!symbol.GetByteSizeIsValid())
+{
+symbol.SetByteSize(end_section_file_addr - 
symbol_file_addr);
+symbol.SetSizeIsSynthesized(true);
+}
 }

clayborg wrote:
> You can remove this if statement right? Symbol byte size will always be valid 
> no?
I case of ELF all synbol size will be valid but I think this code is used for 
mach-o as well where they won't. The condition is kind of saying "if (mach-o)"


Comment at: source/Symbol/Symtab.cpp:1070-1071
@@ +1069,4 @@
+Symbol* symbol = SymbolAtIndex(entry->data);
+if (symbol->ContainsFileAddress(file_addr))
+return symbol;
+}

clayborg wrote:
> Why do we need to check this? Won't 
> "m_file_addr_to_index.FindEntryThatContains(file_addr);" already check this 
> for us?
The m_file_addr_to_index initialized with extending all 0 byte entry until the 
next entry so it can handle mach-o as well and because of this an entry can 
cover a larger address range then it's symbol.

An alternative implementation would be to sort the symbols based on address. 
Then calculate the size for all of them if they are not valid (mach-o) and 
finally generate the entries based on that. That way we can get rid of this 
condition but Symtab::InitAddressIndexes would become more complicated and most 
likely a bit less efficient.


http://reviews.llvm.org/D16186



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r257901 - Fix decoration of TestConcurrentEvents

2016-01-15 Thread Pavel Labath via lldb-commits

Author: labath
Date: Fri Jan 15 10:20:01 2016
New Revision: 257901

URL: http://llvm.org/viewvc/llvm-project?rev=257901=rev
Log:
Fix decoration of TestConcurrentEvents

TestConcurrentEvents was marked with a XFAIL decorator at class level, which 
actually does not
work, and causes the class to be silently skipped everywhere. It seems that 
making it work at
class level is quite a difficult task, so I will just move it to the individual 
test methods. I
will follow this up with a commit which makes the decorator blow up in case 
someone tries to
apply it to a class in the future.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentEvents.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentEvents.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentEvents.py?rev=257901=257900=257901=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentEvents.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/concurrent_events/TestConcurrentEvents.py
 Fri Jan 15 10:20:01 2016
@@ -21,7 +21,6 @@ from lldbsuite.test.lldbtest import *
 import lldbsuite.test.lldbutil as lldbutil
 
 @skipIfWindows
-@expectedFailureAll(archs=['mips64', 'mips64el']) # Atomic sequences are not 
supported yet for MIPS in LLDB. 
 class ConcurrentEventsTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
@@ -30,24 +29,28 @@ class ConcurrentEventsTestCase(TestBase)
 ## Tests for multiple threads that generate a single event.
 #
 @unittest2.skipIf(TestBase.skipLongRunningTest(), "Skip this long running 
test")
+@expectedFailureAll(archs=['mips64', 'mips64el']) # Atomic sequences are 
not supported yet for MIPS in LLDB.
 def test_many_breakpoints(self):
 """Test 100 breakpoints from 100 threads."""
 self.build(dictionary=self.getBuildFlags())
 self.do_thread_actions(num_breakpoint_threads=100)
 
 @unittest2.skipIf(TestBase.skipLongRunningTest(), "Skip this long running 
test")
+@expectedFailureAll(archs=['mips64', 'mips64el']) # Atomic sequences are 
not supported yet for MIPS in LLDB.
 def test_many_watchpoints(self):
 """Test 100 watchpoints from 100 threads."""
 self.build(dictionary=self.getBuildFlags())
 self.do_thread_actions(num_watchpoint_threads=100)
 
 @unittest2.skipIf(TestBase.skipLongRunningTest(), "Skip this long running 
test")
+@expectedFailureAll(archs=['mips64', 'mips64el']) # Atomic sequences are 
not supported yet for MIPS in LLDB.
 def test_many_signals(self):
 """Test 100 signals from 100 threads."""
 self.build(dictionary=self.getBuildFlags())
 self.do_thread_actions(num_signal_threads=100)
 
 @unittest2.skipIf(TestBase.skipLongRunningTest(), "Skip this long running 
test")
+@expectedFailureAll(archs=['mips64', 'mips64el']) # Atomic sequences are 
not supported yet for MIPS in LLDB.
 def test_many_crash(self):
 """Test 100 threads that cause a segfault."""
 self.build(dictionary=self.getBuildFlags())
@@ -58,18 +61,21 @@ class ConcurrentEventsTestCase(TestBase)
 ## Tests for concurrent signal and breakpoint
 #
 @skipIfFreeBSD # timing out on buildbot
+@expectedFailureAll(archs=['mips64', 'mips64el']) # Atomic sequences are 
not supported yet for MIPS in LLDB.
 def test_signal_break(self):
 """Test signal and a breakpoint in multiple threads."""
 self.build(dictionary=self.getBuildFlags())
 self.do_thread_actions(num_breakpoint_threads=1, num_signal_threads=1)
 
 @skipIfFreeBSD # timing out on buildbot
+@expectedFailureAll(archs=['mips64', 'mips64el']) # Atomic sequences are 
not supported yet for MIPS in LLDB.
 def test_delay_signal_break(self):
 """Test (1-second delay) signal and a breakpoint in multiple 
threads."""
 self.build(dictionary=self.getBuildFlags())
 self.do_thread_actions(num_breakpoint_threads=1, 
num_delay_signal_threads=1)
 
 @skipIfFreeBSD # timing out on buildbot
+@expectedFailureAll(archs=['mips64', 'mips64el']) # Atomic sequences are 
not supported yet for MIPS in LLDB.
 def test_signal_delay_break(self):
 """Test signal and a (1 second delay) breakpoint in multiple 
threads."""
 self.build(dictionary=self.getBuildFlags())
@@ -81,6 +87,7 @@ class ConcurrentEventsTestCase(TestBase)
 #
 @skipIfFreeBSD # timing out on buildbot
 @skipIfRemoteDueToDeadlock
+@expectedFailureAll(archs=['mips64', 'mips64el']) # Atomic sequences are 
not supported yet for MIPS in LLDB.
 def test_watch_break(self):
 """Test watchpoint and a breakpoint in multiple threads."""

[Lldb-commits] [PATCH] D16234: Implement missing GoASTContext methods

2016-01-15 Thread Ryan Brown via lldb-commits

ribrdb created this revision.
ribrdb added a reviewer: clayborg.
ribrdb added a subscriber: lldb-commits.
ribrdb set the repository for this revision to rL LLVM.

Repository:
  rL LLVM

http://reviews.llvm.org/D16234

Files:
  source/Symbol/GoASTContext.cpp

Index: source/Symbol/GoASTContext.cpp
===
--- source/Symbol/GoASTContext.cpp
+++ source/Symbol/GoASTContext.cpp
@@ -13,6 +13,7 @@
 
 #include "lldb/Core/Module.h"
 #include "lldb/Core/PluginManager.h"
+#include "lldb/Core/StreamFile.h"
 #include "lldb/Core/UniqueCStringMap.h"
 #include "lldb/Core/ValueObject.h"
 #include "lldb/DataFormatters/StringPrinter.h"
@@ -1268,13 +1269,115 @@
 //--
 // Dumping types
 //--
+#define DEPTH_INCREMENT 2
+
 void
 GoASTContext::DumpValue(lldb::opaque_compiler_type_t type, ExecutionContext *exe_ctx, Stream *s, lldb::Format format,
-const DataExtractor , lldb::offset_t data_offset, size_t data_byte_size,
+const DataExtractor , lldb::offset_t data_byte_offset, size_t data_byte_size,
 uint32_t bitfield_bit_size, uint32_t bitfield_bit_offset, bool show_types, bool show_summary,
 bool verbose, uint32_t depth)
 {
-assert(false);
+if (IsTypedefType(type))
+type = GetTypedefedType(type).GetOpaqueQualType();
+if (!type)
+return;
+GoType *t = static_cast(type);
+
+if (GoStruct *st = t->GetStruct())
+{
+if (GetCompleteType(type))
+{
+uint32_t field_idx = 0;
+for (auto* field = st->GetField(field_idx); field != nullptr; field_idx++)
+{
+// Print the starting squiggly bracket (if this is the
+// first member) or comma (for member 2 and beyond) for
+// the struct/union/class member.
+if (field_idx == 0)
+s->PutChar('{');
+else
+s->PutChar(',');
+
+// Indent
+s->Printf("\n%*s", depth + DEPTH_INCREMENT, "");
+
+// Print the member type if requested
+if (show_types)
+{
+ConstString field_type_name = field->m_type.GetTypeName();
+s->Printf("(%s) ", field_type_name.AsCString());
+}
+// Print the member name and equal sign
+s->Printf("%s = ", field->m_name.AsCString());
+
+
+// Dump the value of the member
+CompilerType field_type = field->m_type;
+field_type.DumpValue (exe_ctx,
+ s,  // Stream to dump to
+ field_type.GetFormat(), // The format with which to display the member
+ data,   // Data buffer containing all bytes for this type
+ data_byte_offset + field->m_byte_offset,// Offset into "data" where to grab value from
+ field->m_type.GetByteSize(exe_ctx->GetBestExecutionContextScope()),  // Size of this type in bytes
+ 0,  // Bitfield bit size
+ 0,  // Bitfield bit offset
+ show_types, // Boolean indicating if we should show the variable types
+ show_summary,   // Boolean indicating if we should show a summary for the current type
+ verbose,// Verbose output?
+ depth + DEPTH_INCREMENT);   // Scope depth for any types that have children
+}
+
+// Indent the trailing squiggly bracket
+if (field_idx > 0)
+s->Printf("\n%*s}", depth, "");
+
+}
+}
+
+if (GoArray *a = t->GetArray()) {
+CompilerType element_clang_type = a->GetElementType();
+lldb::Format element_format = element_clang_type.GetFormat();
+uint32_t element_byte_size = element_clang_type.GetByteSize(exe_ctx->GetBestExecutionContextScope());
+
+uint64_t element_idx;
+for (element_idx = 0; element_idx < a->GetLength(); ++element_idx)
+{
+// Print the starting squiggly bracket (if this is the
+// first member) or comman (for member 2 and beyong) for
+// the struct/union/class member.
+if (element_idx == 0)
+

[Lldb-commits] [lldb] r257926 - Implement missing GoASTContext methods

2016-01-15 Thread Ryan Brown via lldb-commits

Author: ribrdb
Date: Fri Jan 15 13:35:48 2016
New Revision: 257926

URL: http://llvm.org/viewvc/llvm-project?rev=257926=rev
Log:
Implement missing GoASTContext methods

Modified:
lldb/trunk/source/Symbol/GoASTContext.cpp

Modified: lldb/trunk/source/Symbol/GoASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/GoASTContext.cpp?rev=257926=257925=257926=diff
==
--- lldb/trunk/source/Symbol/GoASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/GoASTContext.cpp Fri Jan 15 13:35:48 2016
@@ -13,6 +13,7 @@
 
 #include "lldb/Core/Module.h"
 #include "lldb/Core/PluginManager.h"
+#include "lldb/Core/StreamFile.h"
 #include "lldb/Core/UniqueCStringMap.h"
 #include "lldb/Core/ValueObject.h"
 #include "lldb/DataFormatters/StringPrinter.h"
@@ -1268,13 +1269,115 @@ GoASTContext::ConvertStringToFloatValue(
 //--
 // Dumping types
 //--
+#define DEPTH_INCREMENT 2
+
 void
 GoASTContext::DumpValue(lldb::opaque_compiler_type_t type, ExecutionContext 
*exe_ctx, Stream *s, lldb::Format format,
-const DataExtractor , lldb::offset_t data_offset, 
size_t data_byte_size,
+const DataExtractor , lldb::offset_t 
data_byte_offset, size_t data_byte_size,
 uint32_t bitfield_bit_size, uint32_t 
bitfield_bit_offset, bool show_types, bool show_summary,
 bool verbose, uint32_t depth)
 {
-assert(false);
+if (IsTypedefType(type))
+type = GetTypedefedType(type).GetOpaqueQualType();
+if (!type)
+return;
+GoType *t = static_cast(type);
+
+if (GoStruct *st = t->GetStruct())
+{
+if (GetCompleteType(type))
+{
+uint32_t field_idx = 0;
+for (auto* field = st->GetField(field_idx); field != nullptr; 
field_idx++)
+{
+// Print the starting squiggly bracket (if this is the
+// first member) or comma (for member 2 and beyond) for
+// the struct/union/class member.
+if (field_idx == 0)
+s->PutChar('{');
+else
+s->PutChar(',');
+
+// Indent
+s->Printf("\n%*s", depth + DEPTH_INCREMENT, "");
+
+// Print the member type if requested
+if (show_types)
+{
+ConstString field_type_name = field->m_type.GetTypeName();
+s->Printf("(%s) ", field_type_name.AsCString());
+}
+// Print the member name and equal sign
+s->Printf("%s = ", field->m_name.AsCString());
+
+
+// Dump the value of the member
+CompilerType field_type = field->m_type;
+field_type.DumpValue (exe_ctx,
+ s,  // 
Stream to dump to
+ field_type.GetFormat(), // 
The format with which to display the member
+ data,   // 
Data buffer containing all bytes for this type
+ data_byte_offset + 
field->m_byte_offset,// Offset into "data" where to grab value from
+ 
field->m_type.GetByteSize(exe_ctx->GetBestExecutionContextScope()),  // 
Size of this type in bytes
+ 0,  // 
Bitfield bit size
+ 0,  // 
Bitfield bit offset
+ show_types, // 
Boolean indicating if we should show the variable types
+ show_summary,   // 
Boolean indicating if we should show a summary for the current type
+ verbose,// 
Verbose output?
+ depth + DEPTH_INCREMENT);   // 
Scope depth for any types that have children
+}
+
+// Indent the trailing squiggly bracket
+if (field_idx > 0)
+s->Printf("\n%*s}", depth, "");
+
+}
+}
+
+if (GoArray *a = t->GetArray()) {
+CompilerType element_clang_type = a->GetElementType();
+lldb::Format element_format = element_clang_type.GetFormat();
+uint32_t element_byte_size = 
element_clang_type.GetByteSize(exe_ctx->GetBestExecutionContextScope());
+
+uint64_t element_idx;
+for (element_idx = 0; element_idx < a->GetLength(); ++element_idx)
+{

Re: [Lldb-commits] [PATCH] D16186: Unconditionally accept symbol sizes from elf

2016-01-15 Thread Greg Clayton via lldb-commits

clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.

Never mind, sorry, missed that this was in Symbol.cpp, I was still thinking of 
the ObjectFileELF...


http://reviews.llvm.org/D16186



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r257931 - Small fixes to ensure TestLogging.py tests work with Python 3.5 as well as 2.7.

2016-01-15 Thread Adrian McCarthy via lldb-commits

Author: amccarth
Date: Fri Jan 15 14:45:06 2016
New Revision: 257931

URL: http://llvm.org/viewvc/llvm-project?rev=257931=rev
Log:
Small fixes to ensure TestLogging.py tests work with Python 3.5 as well as 2.7.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/logging/TestLogging.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/logging/TestLogging.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/logging/TestLogging.py?rev=257931=257930=257931=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/logging/TestLogging.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/logging/TestLogging.py Fri Jan 15 
14:45:06 2016
@@ -61,7 +61,7 @@ class LogTestCase(TestBase):
 f.close ()
 os.remove (log_file)
 
-self.assertTrue(log_lines > 0, "Something was written to the log 
file.")
+self.assertGreater(len(log_lines), 0, "Something was written to the 
log file.")
 
 # Check that lldb truncates its log files
 @no_debug_info_test
@@ -83,7 +83,7 @@ class LogTestCase(TestBase):
 contents = f.read ()
 
 # check that it got removed
-self.assertTrue(string.find(contents, "bacon") == -1)
+self.assertEquals(contents.find("bacon"), -1)
 
 # Check that lldb can append to a log file
 @no_debug_info_test
@@ -104,4 +104,4 @@ class LogTestCase(TestBase):
 contents = f.read ()
 
 # check that it is still there
-self.assertTrue(string.find(contents, "bacon") == 0)
+self.assertEquals(contents.find("bacon"), 0)


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r257926 - Implement missing GoASTContext methods

2016-01-15 Thread Ryan Brown via lldb-commits

It would be nice if we could get this into 3.8 to get rid of these asserts.

-- Ryan Brown

On Fri, Jan 15, 2016 at 11:35 AM, Ryan Brown via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: ribrdb
> Date: Fri Jan 15 13:35:48 2016
> New Revision: 257926
>
> URL: http://llvm.org/viewvc/llvm-project?rev=257926=rev
> Log:
> Implement missing GoASTContext methods
>
> Modified:
> lldb/trunk/source/Symbol/GoASTContext.cpp
>
> Modified: lldb/trunk/source/Symbol/GoASTContext.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/GoASTContext.cpp?rev=257926=257925=257926=diff
>
> ==
> --- lldb/trunk/source/Symbol/GoASTContext.cpp (original)
> +++ lldb/trunk/source/Symbol/GoASTContext.cpp Fri Jan 15 13:35:48 2016
> @@ -13,6 +13,7 @@
>
>  #include "lldb/Core/Module.h"
>  #include "lldb/Core/PluginManager.h"
> +#include "lldb/Core/StreamFile.h"
>  #include "lldb/Core/UniqueCStringMap.h"
>  #include "lldb/Core/ValueObject.h"
>  #include "lldb/DataFormatters/StringPrinter.h"
> @@ -1268,13 +1269,115 @@ GoASTContext::ConvertStringToFloatValue(
>  //--
>  // Dumping types
>  //--
> +#define DEPTH_INCREMENT 2
> +
>  void
>  GoASTContext::DumpValue(lldb::opaque_compiler_type_t type,
> ExecutionContext *exe_ctx, Stream *s, lldb::Format format,
> -const DataExtractor , lldb::offset_t
> data_offset, size_t data_byte_size,
> +const DataExtractor , lldb::offset_t
> data_byte_offset, size_t data_byte_size,
>  uint32_t bitfield_bit_size, uint32_t
> bitfield_bit_offset, bool show_types, bool show_summary,
>  bool verbose, uint32_t depth)
>  {
> -assert(false);
> +if (IsTypedefType(type))
> +type = GetTypedefedType(type).GetOpaqueQualType();
> +if (!type)
> +return;
> +GoType *t = static_cast(type);
> +
> +if (GoStruct *st = t->GetStruct())
> +{
> +if (GetCompleteType(type))
> +{
> +uint32_t field_idx = 0;
> +for (auto* field = st->GetField(field_idx); field != nullptr;
> field_idx++)
> +{
> +// Print the starting squiggly bracket (if this is the
> +// first member) or comma (for member 2 and beyond) for
> +// the struct/union/class member.
> +if (field_idx == 0)
> +s->PutChar('{');
> +else
> +s->PutChar(',');
> +
> +// Indent
> +s->Printf("\n%*s", depth + DEPTH_INCREMENT, "");
> +
> +// Print the member type if requested
> +if (show_types)
> +{
> +ConstString field_type_name =
> field->m_type.GetTypeName();
> +s->Printf("(%s) ", field_type_name.AsCString());
> +}
> +// Print the member name and equal sign
> +s->Printf("%s = ", field->m_name.AsCString());
> +
> +
> +// Dump the value of the member
> +CompilerType field_type = field->m_type;
> +field_type.DumpValue (exe_ctx,
> + s,
> // Stream to dump to
> + field_type.GetFormat(),
>  // The format with which to display the member
> + data,
>  // Data buffer containing all bytes for this type
> + data_byte_offset +
> field->m_byte_offset,// Offset into "data" where to grab value from
> +
>  field->m_type.GetByteSize(exe_ctx->GetBestExecutionContextScope()),
> // Size of this type in bytes
> + 0,
> // Bitfield bit size
> + 0,
> // Bitfield bit offset
> + show_types,
>  // Boolean indicating if we should show the variable types
> + show_summary,
>  // Boolean indicating if we should show a summary for the current type
> + verbose,
> // Verbose output?
> + depth + DEPTH_INCREMENT);
>  // Scope depth for any types that have children
> +}
> +
> +// Indent the trailing squiggly bracket
> +if (field_idx > 0)
> +s->Printf("\n%*s}", depth, "");
> +
> +}
> +}
> +
> +if (GoArray *a = t->GetArray()) {
> +CompilerType element_clang_type = a->GetElementType();
> +lldb::Format element_format = element_clang_type.GetFormat();
> +uint32_t element_byte_size =
> element_clang_type.GetByteSize(exe_ctx->GetBestExecutionContextScope());
> +
> +uint64_t

[Lldb-commits] [PATCH] D16237: Fixes to ensure TestLogging.py tests work with Python 3.5 as well as 2.7.

2016-01-15 Thread Adrian McCarthy via lldb-commits

amccarth created this revision.
amccarth added a reviewer: zturner.
amccarth added a subscriber: lldb-commits.

Tested on Windows with Python 3.5.

http://reviews.llvm.org/D16237

Files:
  packages/Python/lldbsuite/test/logging/TestLogging.py

Index: packages/Python/lldbsuite/test/logging/TestLogging.py
===
--- packages/Python/lldbsuite/test/logging/TestLogging.py
+++ packages/Python/lldbsuite/test/logging/TestLogging.py
@@ -61,7 +61,7 @@
 f.close ()
 os.remove (log_file)
 
-self.assertTrue(log_lines > 0, "Something was written to the log 
file.")
+self.assertTrue(len(log_lines) > 0, "Something was written to the log 
file.")
 
 # Check that lldb truncates its log files
 @no_debug_info_test
@@ -83,7 +83,7 @@
 contents = f.read ()
 
 # check that it got removed
-self.assertTrue(string.find(contents, "bacon") == -1)
+self.assertTrue(contents.find("bacon") == -1)
 
 # Check that lldb can append to a log file
 @no_debug_info_test
@@ -104,4 +104,4 @@
 contents = f.read ()
 
 # check that it is still there
-self.assertTrue(string.find(contents, "bacon") == 0)
+self.assertTrue(contents.find("bacon") == 0)


Index: packages/Python/lldbsuite/test/logging/TestLogging.py
===
--- packages/Python/lldbsuite/test/logging/TestLogging.py
+++ packages/Python/lldbsuite/test/logging/TestLogging.py
@@ -61,7 +61,7 @@
 f.close ()
 os.remove (log_file)
 
-self.assertTrue(log_lines > 0, "Something was written to the log file.")
+self.assertTrue(len(log_lines) > 0, "Something was written to the log file.")
 
 # Check that lldb truncates its log files
 @no_debug_info_test
@@ -83,7 +83,7 @@
 contents = f.read ()
 
 # check that it got removed
-self.assertTrue(string.find(contents, "bacon") == -1)
+self.assertTrue(contents.find("bacon") == -1)
 
 # Check that lldb can append to a log file
 @no_debug_info_test
@@ -104,4 +104,4 @@
 contents = f.read ()
 
 # check that it is still there
-self.assertTrue(string.find(contents, "bacon") == 0)
+self.assertTrue(contents.find("bacon") == 0)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D16237: Fixes to ensure TestLogging.py tests work with Python 3.5 as well as 2.7.

2016-01-15 Thread Zachary Turner via lldb-commits

On Fri, Jan 15, 2016 at 11:57 AM Adrian McCarthy 
wrote:

> amccarth created this revision.
> amccarth added a reviewer: zturner.
> amccarth added a subscriber: lldb-commits.
>
> Tested on Windows with Python 3.5.
>
> http://reviews.llvm.org/D16237
>
> Files:
>   packages/Python/lldbsuite/test/logging/TestLogging.py
>
> Index: packages/Python/lldbsuite/test/logging/TestLogging.py
> ===
> --- packages/Python/lldbsuite/test/logging/TestLogging.py
> +++ packages/Python/lldbsuite/test/logging/TestLogging.py
> @@ -61,7 +61,7 @@
>  f.close ()
>  os.remove (log_file)
>
> -self.assertTrue(log_lines > 0, "Something was written to the log
> file.")
> +self.assertTrue(len(log_lines) > 0, "Something was written to the
> log file.")
>
Can you use self.assertGreater


>  # Check that lldb truncates its log files
>  @no_debug_info_test
> @@ -83,7 +83,7 @@
>  contents = f.read ()
>
>  # check that it got removed
> -self.assertTrue(string.find(contents, "bacon") == -1)
> +self.assertTrue(contents.find("bacon") == -1)
>
and self.assertEqual
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D16237: Fixes to ensure TestLogging.py tests work with Python 3.5 as well as 2.7.

2016-01-15 Thread Adrian McCarthy via lldb-commits

amccarth updated this revision to Diff 45023.
amccarth added a comment.

Used the more explicit assertion methods.


http://reviews.llvm.org/D16237

Files:
  packages/Python/lldbsuite/test/logging/TestLogging.py

Index: packages/Python/lldbsuite/test/logging/TestLogging.py
===
--- packages/Python/lldbsuite/test/logging/TestLogging.py
+++ packages/Python/lldbsuite/test/logging/TestLogging.py
@@ -61,7 +61,7 @@
 f.close ()
 os.remove (log_file)
 
-self.assertTrue(log_lines > 0, "Something was written to the log 
file.")
+self.assertGreater(len(log_lines), 0, "Something was written to the 
log file.")
 
 # Check that lldb truncates its log files
 @no_debug_info_test
@@ -83,7 +83,7 @@
 contents = f.read ()
 
 # check that it got removed
-self.assertTrue(string.find(contents, "bacon") == -1)
+self.assertEquals(contents.find("bacon"), -1)
 
 # Check that lldb can append to a log file
 @no_debug_info_test
@@ -104,4 +104,4 @@
 contents = f.read ()
 
 # check that it is still there
-self.assertTrue(string.find(contents, "bacon") == 0)
+self.assertEquals(contents.find("bacon"), 0)


Index: packages/Python/lldbsuite/test/logging/TestLogging.py
===
--- packages/Python/lldbsuite/test/logging/TestLogging.py
+++ packages/Python/lldbsuite/test/logging/TestLogging.py
@@ -61,7 +61,7 @@
 f.close ()
 os.remove (log_file)
 
-self.assertTrue(log_lines > 0, "Something was written to the log file.")
+self.assertGreater(len(log_lines), 0, "Something was written to the log file.")
 
 # Check that lldb truncates its log files
 @no_debug_info_test
@@ -83,7 +83,7 @@
 contents = f.read ()
 
 # check that it got removed
-self.assertTrue(string.find(contents, "bacon") == -1)
+self.assertEquals(contents.find("bacon"), -1)
 
 # Check that lldb can append to a log file
 @no_debug_info_test
@@ -104,4 +104,4 @@
 contents = f.read ()
 
 # check that it is still there
-self.assertTrue(string.find(contents, "bacon") == 0)
+self.assertEquals(contents.find("bacon"), 0)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D16237: Fixes to ensure TestLogging.py tests work with Python 3.5 as well as 2.7.

2016-01-15 Thread Zachary Turner via lldb-commits

looks good

On Fri, Jan 15, 2016 at 12:44 PM Adrian McCarthy 
wrote:

> amccarth updated this revision to Diff 45023.
> amccarth added a comment.
>
> Used the more explicit assertion methods.
>
>
> http://reviews.llvm.org/D16237
>
> Files:
>   packages/Python/lldbsuite/test/logging/TestLogging.py
>
> Index: packages/Python/lldbsuite/test/logging/TestLogging.py
> ===
> --- packages/Python/lldbsuite/test/logging/TestLogging.py
> +++ packages/Python/lldbsuite/test/logging/TestLogging.py
> @@ -61,7 +61,7 @@
>  f.close ()
>  os.remove (log_file)
>
> -self.assertTrue(log_lines > 0, "Something was written to the log
> file.")
> +self.assertGreater(len(log_lines), 0, "Something was written to
> the log file.")
>
>  # Check that lldb truncates its log files
>  @no_debug_info_test
> @@ -83,7 +83,7 @@
>  contents = f.read ()
>
>  # check that it got removed
> -self.assertTrue(string.find(contents, "bacon") == -1)
> +self.assertEquals(contents.find("bacon"), -1)
>
>  # Check that lldb can append to a log file
>  @no_debug_info_test
> @@ -104,4 +104,4 @@
>  contents = f.read ()
>
>  # check that it is still there
> -self.assertTrue(string.find(contents, "bacon") == 0)
> +self.assertEquals(contents.find("bacon"), 0)
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D16244: Implementing the method Target::TargetEventData::Dump (Stream *s) so that its clients can easily dump it out for informational messages.

2016-01-15 Thread Thakur Vishwesh Singh via lldb-commits

vishwesh created this revision.
vishwesh added reviewers: ovyalov, abidh, clayborg.
vishwesh added a subscriber: lldb-commits.

http://reviews.llvm.org/D16244

Files:
  source/Target/Target.cpp

Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -4147,6 +4147,12 @@
 void
 Target::TargetEventData::Dump (Stream *s) const
 {
+for (size_t i = 0; i < m_module_list.GetSize(); ++i)
+{
+if (i != 0)
+ *s << ", ";
+m_module_list.GetModuleAtIndex(i)->GetDescription(s, 
lldb::eDescriptionLevelBrief);
+}
 }
 
 const Target::TargetEventData *


Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -4147,6 +4147,12 @@
 void
 Target::TargetEventData::Dump (Stream *s) const
 {
+for (size_t i = 0; i < m_module_list.GetSize(); ++i)
+{
+if (i != 0)
+ *s << ", ";
+m_module_list.GetModuleAtIndex(i)->GetDescription(s, lldb::eDescriptionLevelBrief);
+}
 }
 
 const Target::TargetEventData *
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r257945 - Fix ResourceWarning about unclosed file in use_lldb_suite_root.py.

2016-01-15 Thread Zachary Turner via lldb-commits

Author: zturner
Date: Fri Jan 15 16:22:35 2016
New Revision: 257945

URL: http://llvm.org/viewvc/llvm-project?rev=257945=rev
Log:
Fix ResourceWarning about unclosed file in use_lldb_suite_root.py.

Modified:
lldb/trunk/scripts/Python/use_lldb_suite.py
lldb/trunk/scripts/use_lldb_suite.py
lldb/trunk/test/use_lldb_suite.py

Modified: lldb/trunk/scripts/Python/use_lldb_suite.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/use_lldb_suite.py?rev=257945=257944=257945=diff
==
--- lldb/trunk/scripts/Python/use_lldb_suite.py (original)
+++ lldb/trunk/scripts/Python/use_lldb_suite.py Fri Jan 15 16:22:35 2016
@@ -17,6 +17,9 @@ def find_lldb_root():
 lldb_root = find_lldb_root()
 if lldb_root is not None:
 import imp
-module = imp.find_module("use_lldb_suite_root", [lldb_root])
-if module is not None:
-imp.load_module("use_lldb_suite_root", *module)
+fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
+try:
+imp.load_module("use_lldb_suite_root", fp, pathname, desc)
+finally:
+if fp:
+fp.close()

Modified: lldb/trunk/scripts/use_lldb_suite.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/use_lldb_suite.py?rev=257945=257944=257945=diff
==
--- lldb/trunk/scripts/use_lldb_suite.py (original)
+++ lldb/trunk/scripts/use_lldb_suite.py Fri Jan 15 16:22:35 2016
@@ -17,6 +17,9 @@ def find_lldb_root():
 lldb_root = find_lldb_root()
 if lldb_root is not None:
 import imp
-module = imp.find_module("use_lldb_suite_root", [lldb_root])
-if module is not None:
-imp.load_module("use_lldb_suite_root", *module)
+fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
+try:
+imp.load_module("use_lldb_suite_root", fp, pathname, desc)
+finally:
+if fp:
+fp.close()

Modified: lldb/trunk/test/use_lldb_suite.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/test/use_lldb_suite.py?rev=257945=257944=257945=diff
==
--- lldb/trunk/test/use_lldb_suite.py (original)
+++ lldb/trunk/test/use_lldb_suite.py Fri Jan 15 16:22:35 2016
@@ -17,6 +17,9 @@ def find_lldb_root():
 lldb_root = find_lldb_root()
 if lldb_root is not None:
 import imp
-module = imp.find_module("use_lldb_suite_root", [lldb_root])
-if module is not None:
-imp.load_module("use_lldb_suite_root", *module)
+fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
+try:
+imp.load_module("use_lldb_suite_root", fp, pathname, desc)
+finally:
+if fp:
+fp.close()


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r257946 - Fix TestDebugBreak.py.

2016-01-15 Thread Zachary Turner via lldb-commits

Author: zturner
Date: Fri Jan 15 16:22:40 2016
New Revision: 257946

URL: http://llvm.org/viewvc/llvm-project?rev=257946=rev
Log:
Fix TestDebugBreak.py.

We can't assume that the main thread of an inferior has index 0,
even in a single-threaded app.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py?rev=257946=257945=257946=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
 Fri Jan 15 16:22:40 2016
@@ -26,13 +26,14 @@ class DebugBreakTestCase(TestBase):
 
 # We've hit the first stop, so grab the frame.
 self.assertEqual(process.GetState(), lldb.eStateStopped)
-thread = process.GetThreadAtIndex(0)
+thread = lldbutil.get_stopped_thread(process, 
lldb.eStopReasonException)
+self.assertIsNotNone(thread, "Unable to find thread stopped at the 
__debugbreak()")
 frame = thread.GetFrameAtIndex(0)
 
 # We should be in funciton 'bar'.
 self.assertTrue(frame.IsValid())
 function_name = frame.GetFunctionName()
-self.assertTrue('bar' in function_name)
+self.assertTrue('bar' in function_name, "Unexpected function name 
{}".format(function_name))
 
 # We should be able to evaluate the parameter foo.
 value = frame.EvaluateExpression('*foo')


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r257946 - Fix TestDebugBreak.py.

2016-01-15 Thread Siva Chandra via lldb-commits

SGTM. You want to do it?

On Fri, Jan 15, 2016 at 3:24 PM, Zachary Turner  wrote:
> How about `lldb.eStopReasonException if osIsWindows() else
> lldb.eStopReasonSignal`?
>
> Seems like that should work for everyone?
>
> On Fri, Jan 15, 2016 at 3:20 PM Siva Chandra  wrote:
>>
>> This fails for i386 (not enabled for x86_64 anyway):
>>
>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/10400
>>
>> If I replace lldb.eStopReasonException with lldb.eStopReasonSignal on
>> my local machine, it works.
>>
>> On Fri, Jan 15, 2016 at 2:22 PM, Zachary Turner via lldb-commits
>>  wrote:
>> > Author: zturner
>> > Date: Fri Jan 15 16:22:40 2016
>> > New Revision: 257946
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=257946=rev
>> > Log:
>> > Fix TestDebugBreak.py.
>> >
>> > We can't assume that the main thread of an inferior has index 0,
>> > even in a single-threaded app.
>> >
>> > Modified:
>> >
>> > lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
>> >
>> > Modified:
>> > lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
>> > URL:
>> > http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py?rev=257946=257945=257946=diff
>> >
>> > ==
>> > ---
>> > lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
>> > (original)
>> > +++
>> > lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
>> > Fri Jan 15 16:22:40 2016
>> > @@ -26,13 +26,14 @@ class DebugBreakTestCase(TestBase):
>> >
>> >  # We've hit the first stop, so grab the frame.
>> >  self.assertEqual(process.GetState(), lldb.eStateStopped)
>> > -thread = process.GetThreadAtIndex(0)
>> > +thread = lldbutil.get_stopped_thread(process,
>> > lldb.eStopReasonException)
>> > +self.assertIsNotNone(thread, "Unable to find thread stopped at
>> > the __debugbreak()")
>> >  frame = thread.GetFrameAtIndex(0)
>> >
>> >  # We should be in funciton 'bar'.
>> >  self.assertTrue(frame.IsValid())
>> >  function_name = frame.GetFunctionName()
>> > -self.assertTrue('bar' in function_name)
>> > +self.assertTrue('bar' in function_name, "Unexpected function
>> > name {}".format(function_name))
>> >
>> >  # We should be able to evaluate the parameter foo.
>> >  value = frame.EvaluateExpression('*foo')
>> >
>> >
>> > ___
>> > lldb-commits mailing list
>> > lldb-commits@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D16247: Don't assume that thread 0 is always the main thread

2016-01-15 Thread Zachary Turner via lldb-commits

zturner created this revision.
zturner added a reviewer: jingham.
zturner added a subscriber: lldb-commits.

Even in a single-threaded app, Windows will often create background threads on 
startup and these threads can appear in any order with respect to the actual 
main thread.  So everywhere that is doing something like 
`process.GetThreadAtIndex(0)` in our test suite is broken on Windows.  This 
fixes a large number of these cases, although there are still a few more 
difficult ones remaining that I don't plan to address right now.

http://reviews.llvm.org/D16247

Files:
  packages/Python/lldbsuite/test/expression_command/test/TestExprs.py
  
packages/Python/lldbsuite/test/functionalities/breakpoint/consecutive_breakpoins/TestConsecutiveBreakpoints.py
  
packages/Python/lldbsuite/test/functionalities/conditional_break/TestConditionalBreak.py
  
packages/Python/lldbsuite/test/functionalities/thread/crash_during_step/TestCrashDuringStep.py
  
packages/Python/lldbsuite/test/functionalities/thread/multi_break/TestMultipleBreakpoints.py
  
packages/Python/lldbsuite/test/functionalities/thread/state/TestThreadStates.py
  packages/Python/lldbsuite/test/lang/c/array_types/TestArrayTypes.py
  packages/Python/lldbsuite/test/lang/c/bitfields/TestBitfields.py
  packages/Python/lldbsuite/test/lang/cpp/class_static/TestStaticVariables.py
  packages/Python/lldbsuite/test/lang/cpp/class_types/TestClassTypes.py
  
packages/Python/lldbsuite/test/lang/cpp/class_types/TestClassTypesDisassembly.py
  packages/Python/lldbsuite/test/lang/cpp/diamond/TestDiamond.py
  packages/Python/lldbsuite/test/lang/cpp/stl/TestStdCXXDisassembly.py
  packages/Python/lldbsuite/test/python_api/frame/TestFrames.py
  packages/Python/lldbsuite/test/python_api/frame/inlines/TestInlinedFrame.py
  packages/Python/lldbsuite/test/python_api/hello_world/TestHelloWorld.py
  packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py

Index: packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
===
--- packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
+++ packages/Python/lldbsuite/test/python_api/sbdata/TestSBData.py
@@ -38,8 +38,9 @@
 target = self.dbg.GetSelectedTarget()
 
 process = target.GetProcess()
-
-thread = process.GetThreadAtIndex(0)
+
+thread = lldbutil.get_stopped_thread(process, lldb.eStopReasonBreakpoint)
+self.assertIsNotNone(thread)
 
 frame = thread.GetSelectedFrame()
 if self.TraceOn():
Index: packages/Python/lldbsuite/test/python_api/hello_world/TestHelloWorld.py
===
--- packages/Python/lldbsuite/test/python_api/hello_world/TestHelloWorld.py
+++ packages/Python/lldbsuite/test/python_api/hello_world/TestHelloWorld.py
@@ -64,14 +64,11 @@
 process = target.GetProcess()
 self.assertTrue(process, PROCESS_IS_VALID)
 
-thread = process.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)
 
 @add_test_categories(['pyapi'])
 @expectedFailureWindows("llvm.org/pr24600")
Index: packages/Python/lldbsuite/test/python_api/frame/inlines/TestInlinedFrame.py
===
--- packages/Python/lldbsuite/test/python_api/frame/inlines/TestInlinedFrame.py
+++ packages/Python/lldbsuite/test/python_api/frame/inlines/TestInlinedFrame.py
@@ -60,7 +60,10 @@
 #
 # outer_inline (argc);
 #
-frame0 = process.GetThreadAtIndex(0).GetFrameAtIndex(0)
+thread = lldbutil.get_stopped_thread(process, lldb.eStopReasonBreakpoint)
+self.assertIsNotNone(thread)
+
+frame0 = thread.GetFrameAtIndex(0)
 if frame0.IsInlined():
 filename = frame0.GetLineEntry().GetFileSpec().GetFilename()
 self.assertTrue(filename == self.source)
Index: packages/Python/lldbsuite/test/python_api/frame/TestFrames.py
===
--- packages/Python/lldbsuite/test/python_api/frame/TestFrames.py
+++ packages/Python/lldbsuite/test/python_api/frame/TestFrames.py
@@ -49,7 +49,8 @@
 from six import StringIO as SixStringIO
 session = SixStringIO()
 while process.GetState() == lldb.eStateStopped:
-thread = process.GetThreadAtIndex(0)
+thread =

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

2016-01-15 Thread Siva Chandra via lldb-commits

On Fri, Jan 15, 2016 at 2:18 AM, Pavel Labath via lldb-commits
 wrote:
> I don't really understand the purpose of the test, but if the purpose
> of it is to check whether something appears on stdout, then a pexpect
> test does seem like the right tool for the job.
>
> I have tried entering the commands from the test manually, and the
> required text does *not* appear when using the lldb built on the
> buildbot, while it *does* appear when using the lldb I build locally.
> So, this appears to be a genuine bug caused by something in the
> buildbot environment, but it's not clear to me now what it could be.

FWIW, before I asked Ying to take this over, I observed the same.
However, Ying *was* able to reproduce this on her local WS
consistently!

> That said, there is currently a big problem with the way this test is
> written, and that's the fact that the prompt expectation does not play
> well with the lldb's colored prompt feature. LLDB colors the prompt by
> overwriting the text which was already written by editline, resulting
> in something like "(lldb) \33[2m(lldb) \33[22m" written to stdout.
> This throws pexpect completely off scent, as the prompt substring
> appears twice, causing the commands and their expectations to
> misalign. Right now it does not matter, because as soon as you start
> looking for the pattern "this is a test string", the streams will
> align up, but it can cause you a lot of problems if you execute a
> command and then try to observe some external side effects of it,
> because pexpect will return before the command has even been given a
> chance to complete.

I suspected colors as well, but it is something different which is
causing the failure on the bot machine. To spawn LLDB without colors
though, we could pass --no-use-colors like here:
http://reviews.llvm.org/D6671

> BTW: the skipIfRemote decorator is not needed. It was needed on
> TestBatchMode, because that one actually runs executables, which needs
> some plumbing to work remotely, but since this test just plays with
> python commands it will execute just fine in the remote mode.
>
> pl
>
> On 14 January 2016 at 19:06, Jim Ingham via lldb-commits
>  wrote:
>> Well, actually on Unix MOST things are files, it was Plan 9 in which that 
>> all things are files, IIRC...
>>
>> Jim
>>
>>> On Jan 14, 2016, at 11:04 AM, Jim Ingham  wrote:
>>>
>>> Yes, on unix all things are files and all files work the same except when 
>>> they don't.  I'd rather test the thing we ACTUALLY care about, rather than 
>>> testing something else and assuming that it is going to work in the case we 
>>> care about as well.
>>>
>>> Jim
>>>
 On Jan 14, 2016, at 10:58 AM, Zachary Turner  wrote:

 Wouldn't testing with output redirecxted to a file still test that it is 
 being streamed as it is obtained rather than a big dump at the end?  I 
 mean that's what stdout is right?  Just a file.  If you use a file on the 
 filesystem instead, just check the contents of the file after each 
 operation.

 On Thu, Jan 14, 2016 at 10:42 AM Jim Ingham  wrote:
 I worry giving up on testing using Python's stdout for the immediate 
 output stream.  This is a very useful feature, allowing users to make 
 Python based commands that produce a bunch of output, and stream the 
 output as it is being gathered rather than having the command stall and 
 then dump a bunch of text at the end.  This isn't speculative, that's how 
 many of the commands that the OS X kernel team ships for inspecting kernel 
 state work.

 So we really should be testing this feature.  Maybe the flakiness on Linux 
 is just a pexpect bug, and streaming to stdout would always work correctly 
 hooked up to a "real" terminal.  But until we know that we should presume 
 that it is something in LLDB->Python or in the way we use Python, and keep 
 testing it.

 If you want to separate the two issues, then it would be fine to write 
 another test that just tests the type maps for FILE *, but I still think 
 this one is valuable.

 Jim

> On Jan 14, 2016, at 10:16 AM, Zachary Turner via lldb-commits 
>  wrote:
>
> How much time do you think it would take to determine whether or not 
> using the file-based approach would work?  Because on the surface it 
> sounds fairly straightforward, and fixing it that way would allow us to 
> not have to xfail this on more platforms for reasons that we don't 
> understand.
>
> On Thu, Jan 14, 2016 at 10:15 AM Enrico Granata via lldb-commits 
>  wrote:
> The log just shows a timeout is happening in pexpect() - which I don’t 
> have a ready explanation for
>
> X-failing for now is the proper recourse. But you might want to debug

Re: [Lldb-commits] [lldb] r257946 - Fix TestDebugBreak.py.

2016-01-15 Thread Siva Chandra via lldb-commits

Thanks a lot.

On Fri, Jan 15, 2016 at 3:26 PM, Zachary Turner  wrote:
> Sure
>
> On Fri, Jan 15, 2016 at 3:25 PM Siva Chandra  wrote:
>>
>> SGTM. You want to do it?
>>
>> On Fri, Jan 15, 2016 at 3:24 PM, Zachary Turner 
>> wrote:
>> > How about `lldb.eStopReasonException if osIsWindows() else
>> > lldb.eStopReasonSignal`?
>> >
>> > Seems like that should work for everyone?
>> >
>> > On Fri, Jan 15, 2016 at 3:20 PM Siva Chandra 
>> > wrote:
>> >>
>> >> This fails for i386 (not enabled for x86_64 anyway):
>> >>
>> >>
>> >> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/10400
>> >>
>> >> If I replace lldb.eStopReasonException with lldb.eStopReasonSignal on
>> >> my local machine, it works.
>> >>
>> >> On Fri, Jan 15, 2016 at 2:22 PM, Zachary Turner via lldb-commits
>> >>  wrote:
>> >> > Author: zturner
>> >> > Date: Fri Jan 15 16:22:40 2016
>> >> > New Revision: 257946
>> >> >
>> >> > URL: http://llvm.org/viewvc/llvm-project?rev=257946=rev
>> >> > Log:
>> >> > Fix TestDebugBreak.py.
>> >> >
>> >> > We can't assume that the main thread of an inferior has index 0,
>> >> > even in a single-threaded app.
>> >> >
>> >> > Modified:
>> >> >
>> >> >
>> >> > lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
>> >> >
>> >> > Modified:
>> >> >
>> >> > lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
>> >> > URL:
>> >> >
>> >> > http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py?rev=257946=257945=257946=diff
>> >> >
>> >> >
>> >> > ==
>> >> > ---
>> >> >
>> >> > lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
>> >> > (original)
>> >> > +++
>> >> >
>> >> > lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
>> >> > Fri Jan 15 16:22:40 2016
>> >> > @@ -26,13 +26,14 @@ class DebugBreakTestCase(TestBase):
>> >> >
>> >> >  # We've hit the first stop, so grab the frame.
>> >> >  self.assertEqual(process.GetState(), lldb.eStateStopped)
>> >> > -thread = process.GetThreadAtIndex(0)
>> >> > +thread = lldbutil.get_stopped_thread(process,
>> >> > lldb.eStopReasonException)
>> >> > +self.assertIsNotNone(thread, "Unable to find thread stopped
>> >> > at
>> >> > the __debugbreak()")
>> >> >  frame = thread.GetFrameAtIndex(0)
>> >> >
>> >> >  # We should be in funciton 'bar'.
>> >> >  self.assertTrue(frame.IsValid())
>> >> >  function_name = frame.GetFunctionName()
>> >> > -self.assertTrue('bar' in function_name)
>> >> > +self.assertTrue('bar' in function_name, "Unexpected function
>> >> > name {}".format(function_name))
>> >> >
>> >> >  # We should be able to evaluate the parameter foo.
>> >> >  value = frame.EvaluateExpression('*foo')
>> >> >
>> >> >
>> >> > ___
>> >> > lldb-commits mailing list
>> >> > lldb-commits@lists.llvm.org
>> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r257946 - Fix TestDebugBreak.py.

2016-01-15 Thread Siva Chandra via lldb-commits

This fails for i386 (not enabled for x86_64 anyway):
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/10400

If I replace lldb.eStopReasonException with lldb.eStopReasonSignal on
my local machine, it works.

On Fri, Jan 15, 2016 at 2:22 PM, Zachary Turner via lldb-commits
 wrote:
> Author: zturner
> Date: Fri Jan 15 16:22:40 2016
> New Revision: 257946
>
> URL: http://llvm.org/viewvc/llvm-project?rev=257946=rev
> Log:
> Fix TestDebugBreak.py.
>
> We can't assume that the main thread of an inferior has index 0,
> even in a single-threaded app.
>
> Modified:
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
>
> Modified: 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py?rev=257946=257945=257946=diff
> ==
> --- 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
>  (original)
> +++ 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
>  Fri Jan 15 16:22:40 2016
> @@ -26,13 +26,14 @@ class DebugBreakTestCase(TestBase):
>
>  # We've hit the first stop, so grab the frame.
>  self.assertEqual(process.GetState(), lldb.eStateStopped)
> -thread = process.GetThreadAtIndex(0)
> +thread = lldbutil.get_stopped_thread(process, 
> lldb.eStopReasonException)
> +self.assertIsNotNone(thread, "Unable to find thread stopped at the 
> __debugbreak()")
>  frame = thread.GetFrameAtIndex(0)
>
>  # We should be in funciton 'bar'.
>  self.assertTrue(frame.IsValid())
>  function_name = frame.GetFunctionName()
> -self.assertTrue('bar' in function_name)
> +self.assertTrue('bar' in function_name, "Unexpected function name 
> {}".format(function_name))
>
>  # We should be able to evaluate the parameter foo.
>  value = frame.EvaluateExpression('*foo')
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D16244: Implementing the method Target::TargetEventData::Dump (Stream *s) so that its clients can easily dump it out for informational messages.

2016-01-15 Thread Oleksiy Vyalov via lldb-commits

ovyalov accepted this revision.
ovyalov added a comment.

LGTM


http://reviews.llvm.org/D16244



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r257946 - Fix TestDebugBreak.py.

2016-01-15 Thread Zachary Turner via lldb-commits

Sure

On Fri, Jan 15, 2016 at 3:25 PM Siva Chandra  wrote:

> SGTM. You want to do it?
>
> On Fri, Jan 15, 2016 at 3:24 PM, Zachary Turner 
> wrote:
> > How about `lldb.eStopReasonException if osIsWindows() else
> > lldb.eStopReasonSignal`?
> >
> > Seems like that should work for everyone?
> >
> > On Fri, Jan 15, 2016 at 3:20 PM Siva Chandra 
> wrote:
> >>
> >> This fails for i386 (not enabled for x86_64 anyway):
> >>
> >>
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/10400
> >>
> >> If I replace lldb.eStopReasonException with lldb.eStopReasonSignal on
> >> my local machine, it works.
> >>
> >> On Fri, Jan 15, 2016 at 2:22 PM, Zachary Turner via lldb-commits
> >>  wrote:
> >> > Author: zturner
> >> > Date: Fri Jan 15 16:22:40 2016
> >> > New Revision: 257946
> >> >
> >> > URL: http://llvm.org/viewvc/llvm-project?rev=257946=rev
> >> > Log:
> >> > Fix TestDebugBreak.py.
> >> >
> >> > We can't assume that the main thread of an inferior has index 0,
> >> > even in a single-threaded app.
> >> >
> >> > Modified:
> >> >
> >> >
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
> >> >
> >> > Modified:
> >> >
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
> >> > URL:
> >> >
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py?rev=257946=257945=257946=diff
> >> >
> >> >
> ==
> >> > ---
> >> >
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
> >> > (original)
> >> > +++
> >> >
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
> >> > Fri Jan 15 16:22:40 2016
> >> > @@ -26,13 +26,14 @@ class DebugBreakTestCase(TestBase):
> >> >
> >> >  # We've hit the first stop, so grab the frame.
> >> >  self.assertEqual(process.GetState(), lldb.eStateStopped)
> >> > -thread = process.GetThreadAtIndex(0)
> >> > +thread = lldbutil.get_stopped_thread(process,
> >> > lldb.eStopReasonException)
> >> > +self.assertIsNotNone(thread, "Unable to find thread stopped
> at
> >> > the __debugbreak()")
> >> >  frame = thread.GetFrameAtIndex(0)
> >> >
> >> >  # We should be in funciton 'bar'.
> >> >  self.assertTrue(frame.IsValid())
> >> >  function_name = frame.GetFunctionName()
> >> > -self.assertTrue('bar' in function_name)
> >> > +self.assertTrue('bar' in function_name, "Unexpected function
> >> > name {}".format(function_name))
> >> >
> >> >  # We should be able to evaluate the parameter foo.
> >> >  value = frame.EvaluateExpression('*foo')
> >> >
> >> >
> >> > ___
> >> > lldb-commits mailing list
> >> > lldb-commits@lists.llvm.org
> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r257946 - Fix TestDebugBreak.py.

2016-01-15 Thread Zachary Turner via lldb-commits

How about `lldb.eStopReasonException if osIsWindows() else
lldb.eStopReasonSignal`?

Seems like that should work for everyone?

On Fri, Jan 15, 2016 at 3:20 PM Siva Chandra  wrote:

> This fails for i386 (not enabled for x86_64 anyway):
>
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/10400
>
> If I replace lldb.eStopReasonException with lldb.eStopReasonSignal on
> my local machine, it works.
>
> On Fri, Jan 15, 2016 at 2:22 PM, Zachary Turner via lldb-commits
>  wrote:
> > Author: zturner
> > Date: Fri Jan 15 16:22:40 2016
> > New Revision: 257946
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=257946=rev
> > Log:
> > Fix TestDebugBreak.py.
> >
> > We can't assume that the main thread of an inferior has index 0,
> > even in a single-threaded app.
> >
> > Modified:
> >
>  
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
> >
> > Modified:
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
> > URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py?rev=257946=257945=257946=diff
> >
> ==
> > ---
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
> (original)
> > +++
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
> Fri Jan 15 16:22:40 2016
> > @@ -26,13 +26,14 @@ class DebugBreakTestCase(TestBase):
> >
> >  # We've hit the first stop, so grab the frame.
> >  self.assertEqual(process.GetState(), lldb.eStateStopped)
> > -thread = process.GetThreadAtIndex(0)
> > +thread = lldbutil.get_stopped_thread(process,
> lldb.eStopReasonException)
> > +self.assertIsNotNone(thread, "Unable to find thread stopped at
> the __debugbreak()")
> >  frame = thread.GetFrameAtIndex(0)
> >
> >  # We should be in funciton 'bar'.
> >  self.assertTrue(frame.IsValid())
> >  function_name = frame.GetFunctionName()
> > -self.assertTrue('bar' in function_name)
> > +self.assertTrue('bar' in function_name, "Unexpected function
> name {}".format(function_name))
> >
> >  # We should be able to evaluate the parameter foo.
> >  value = frame.EvaluateExpression('*foo')
> >
> >
> > ___
> > lldb-commits mailing list
> > lldb-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D16247: Don't assume that thread 0 is always the main thread

2016-01-15 Thread Adrian McCarthy via lldb-commits

amccarth added a subscriber: amccarth.
amccarth added a comment.

A GetMainThread method in SBAPI might be a nice addition to GetThreadAtIndex.


http://reviews.llvm.org/D16247



___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r257959 - On non-Windows platforms, asm int 3 generates an eStopReasonSignal.

2016-01-15 Thread Zachary Turner via lldb-commits

Author: zturner
Date: Fri Jan 15 17:44:45 2016
New Revision: 257959

URL: http://llvm.org/viewvc/llvm-project?rev=257959=rev
Log:
On non-Windows platforms, asm int 3 generates an eStopReasonSignal.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py?rev=257959=257958=257959=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/debugbreak/TestDebugBreak.py
 Fri Jan 15 17:44:45 2016
@@ -26,7 +26,8 @@ class DebugBreakTestCase(TestBase):
 
 # We've hit the first stop, so grab the frame.
 self.assertEqual(process.GetState(), lldb.eStateStopped)
-thread = lldbutil.get_stopped_thread(process, 
lldb.eStopReasonException)
+stop_reason = lldb.eStopReasonException if (getPlatform()=="windows") 
else lldb.eStopReasonSignal
+thread = lldbutil.get_stopped_thread(process, stop_reason)
 self.assertIsNotNone(thread, "Unable to find thread stopped at the 
__debugbreak()")
 frame = thread.GetFrameAtIndex(0)
 


___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

Re: [Lldb-commits] [PATCH] D16186: Unconditionally accept symbol sizes from elf

Re: [Lldb-commits] [PATCH] D16186: Unconditionally accept symbol sizes from elf

[Lldb-commits] [lldb] r257901 - Fix decoration of TestConcurrentEvents

[Lldb-commits] [PATCH] D16234: Implement missing GoASTContext methods

[Lldb-commits] [lldb] r257926 - Implement missing GoASTContext methods

Re: [Lldb-commits] [PATCH] D16186: Unconditionally accept symbol sizes from elf

[Lldb-commits] [lldb] r257931 - Small fixes to ensure TestLogging.py tests work with Python 3.5 as well as 2.7.

Re: [Lldb-commits] [lldb] r257926 - Implement missing GoASTContext methods

[Lldb-commits] [PATCH] D16237: Fixes to ensure TestLogging.py tests work with Python 3.5 as well as 2.7.

Re: [Lldb-commits] [PATCH] D16237: Fixes to ensure TestLogging.py tests work with Python 3.5 as well as 2.7.

Re: [Lldb-commits] [PATCH] D16237: Fixes to ensure TestLogging.py tests work with Python 3.5 as well as 2.7.

Re: [Lldb-commits] [PATCH] D16237: Fixes to ensure TestLogging.py tests work with Python 3.5 as well as 2.7.

[Lldb-commits] [PATCH] D16244: Implementing the method Target::TargetEventData::Dump (Stream *s) so that its clients can easily dump it out for informational messages.

[Lldb-commits] [lldb] r257945 - Fix ResourceWarning about unclosed file in use_lldb_suite_root.py.

[Lldb-commits] [lldb] r257946 - Fix TestDebugBreak.py.

Re: [Lldb-commits] [lldb] r257946 - Fix TestDebugBreak.py.

[Lldb-commits] [PATCH] D16247: Don't assume that thread 0 is always the main thread

Re: [Lldb-commits] [lldb] r257644 - Fix an issue where scripted commands would not actually print any of their output if an immediate output file was set in the result object via a Python file object

Re: [Lldb-commits] [lldb] r257946 - Fix TestDebugBreak.py.

Re: [Lldb-commits] [lldb] r257946 - Fix TestDebugBreak.py.

Re: [Lldb-commits] [PATCH] D16244: Implementing the method Target::TargetEventData::Dump (Stream *s) so that its clients can easily dump it out for informational messages.

Re: [Lldb-commits] [lldb] r257946 - Fix TestDebugBreak.py.

Re: [Lldb-commits] [lldb] r257946 - Fix TestDebugBreak.py.

Re: [Lldb-commits] [PATCH] D16247: Don't assume that thread 0 is always the main thread

[Lldb-commits] [lldb] r257959 - On non-Windows platforms, asm int 3 generates an eStopReasonSignal.

26 matches

Site Navigation

Mail list logo

Footer information