Re: [Lldb-commits] [PATCH] D14226: Fix to solve Bug 23139 & Bug 23560

[Abhishek via lldb-commits]

abhishek.aggarwal updated this revision to Diff 40013.
abhishek.aggarwal added a comment.

Used Assert instead of If condition


http://reviews.llvm.org/D14226

Files:
  packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
  packages/Python/lldbsuite/test/expression_command/test/TestExprs.py
  
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-synth/TestDataFormatterSynth.py
  
packages/Python/lldbsuite/test/functionalities/embedded_interpreter/TestConvenienceVariables.py
  
packages/Python/lldbsuite/test/functionalities/inferior-crashing/TestInferiorCrashing.py
  
packages/Python/lldbsuite/test/functionalities/inline-stepping/TestInlineStepping.py
  packages/Python/lldbsuite/test/functionalities/memory/read/TestMemoryRead.py
  packages/Python/lldbsuite/test/tools/lldb-mi/control/TestMiExec.py
  packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py
  source/Plugins/Process/Utility/UnwindLLDB.cpp
  source/Plugins/Process/Utility/UnwindLLDB.h

Index: source/Plugins/Process/Utility/UnwindLLDB.h
===
--- source/Plugins/Process/Utility/UnwindLLDB.h
+++ source/Plugins/Process/Utility/UnwindLLDB.h
@@ -136,6 +136,15 @@
  
 std::vector m_user_supplied_trap_handler_functions;
 
+//-
+// Check if Full UnwindPlan of First frame is valid or not.
+// If not then try Fallback UnwindPlan of the frame. If Fallback
+// UnwindPlan succeeds then update the Full UnwindPlan with the
+// Fallback UnwindPlan.
+//-
+void
+UpdateUnwindPlanForFirstFrameIfInvalid (ABI* abi);
+
 CursorSP
 GetOneMoreFrame (ABI* abi);
 
Index: source/Plugins/Process/Utility/UnwindLLDB.cpp
===
--- source/Plugins/Process/Utility/UnwindLLDB.cpp
+++ source/Plugins/Process/Utility/UnwindLLDB.cpp
@@ -86,6 +86,9 @@
 if (m_frames.size() > 0)
 return true;
 
+ProcessSP process_sp (m_thread.GetProcess());
+ABI *abi = process_sp ? process_sp->GetABI().get() : NULL;
+
 // First, set up the 0th (initial) frame
 CursorSP first_cursor_sp(new Cursor ());
 RegisterContextLLDBSP reg_ctx_sp (new RegisterContextLLDB (m_thread, 
@@ -108,6 +111,10 @@
 // cursor own it in its shared pointer
 first_cursor_sp->reg_ctx_lldb_sp = reg_ctx_sp;
 m_frames.push_back (first_cursor_sp);
+
+// Update the Full Unwind Plan for this frame if not valid
+UpdateUnwindPlanForFirstFrameIfInvalid(abi);
+
 return true;
 
 unwind_done:
@@ -161,7 +168,14 @@
 // If the RegisterContextLLDB has a fallback UnwindPlan, it will switch to that and return
 // true.  Subsequent calls to TryFallbackUnwindPlan() will return false.
 if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan())
+{
+// TryFallbackUnwindPlan for prev_frame succeeded and updated reg_ctx_lldb_sp field of
+// prev_frame. However, cfa field of prev_frame still needs to be updated. Hence updating it.
+if ( !(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
+return nullptr;
+
 return GetOneMoreFrame (abi);
+}
 
 if (log)
 log->Printf ("%*sFrame %d did not get a RegisterContext, stopping.",
@@ -175,7 +189,14 @@
 // See if the regctx below this on the stack has a fallback unwind plan it can use.
 // Subsequent calls to TryFallbackUnwindPlan() will return false.
 if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan())
+{
+// TryFallbackUnwindPlan for prev_frame succeeded and updated reg_ctx_lldb_sp field of
+// prev_frame. However, cfa field of prev_frame still needs to be updated. Hence updating it.
+if ( !(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
+return nullptr;
+
 return GetOneMoreFrame (abi);
+}
 
 if (log)
 log->Printf("%*sFrame %d invalid RegisterContext for this frame, stopping stack walk", 
@@ -187,7 +208,14 @@
 // If the RegisterContextLLDB has a fallback UnwindPlan, it will switch to that and return
 // true.  Subsequent calls to TryFallbackUnwindPlan() will return false.
 if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan())
+{
+// TryFallbackUnwindPlan for prev_frame succeeded and updated reg_ctx_lldb_sp field of
+// prev_frame. However, cfa field of prev_frame still needs to be updated. Hence updating it.
+if ( !(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
+return nullptr;
+
 return GetOneMoreFrame (abi);
+}
 
 if (log)
 log->Printf("%*sFrame %d did not get CFA for this frame, stopping stack walk",
@@ -212,7 +240,14 

Re: [Lldb-commits] [PATCH] D14226: Fix to solve Bug 23139 & Bug 23560

[Abhishek via lldb-commits]

abhishek.aggarwal updated this revision to Diff 40014.
abhishek.aggarwal added a comment.

Removed log and inserted statement terminator


http://reviews.llvm.org/D14226

Files:
  packages/Python/lldbsuite/test/api/multithreaded/TestMultithreaded.py
  packages/Python/lldbsuite/test/expression_command/test/TestExprs.py
  
packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-synth/TestDataFormatterSynth.py
  
packages/Python/lldbsuite/test/functionalities/embedded_interpreter/TestConvenienceVariables.py
  
packages/Python/lldbsuite/test/functionalities/inferior-crashing/TestInferiorCrashing.py
  
packages/Python/lldbsuite/test/functionalities/inline-stepping/TestInlineStepping.py
  packages/Python/lldbsuite/test/functionalities/memory/read/TestMemoryRead.py
  packages/Python/lldbsuite/test/tools/lldb-mi/control/TestMiExec.py
  packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiVar.py
  source/Plugins/Process/Utility/UnwindLLDB.cpp
  source/Plugins/Process/Utility/UnwindLLDB.h

Index: source/Plugins/Process/Utility/UnwindLLDB.h
===
--- source/Plugins/Process/Utility/UnwindLLDB.h
+++ source/Plugins/Process/Utility/UnwindLLDB.h
@@ -136,6 +136,15 @@
  
 std::vector m_user_supplied_trap_handler_functions;
 
+//-
+// Check if Full UnwindPlan of First frame is valid or not.
+// If not then try Fallback UnwindPlan of the frame. If Fallback
+// UnwindPlan succeeds then update the Full UnwindPlan with the
+// Fallback UnwindPlan.
+//-
+void
+UpdateUnwindPlanForFirstFrameIfInvalid (ABI* abi);
+
 CursorSP
 GetOneMoreFrame (ABI* abi);
 
Index: source/Plugins/Process/Utility/UnwindLLDB.cpp
===
--- source/Plugins/Process/Utility/UnwindLLDB.cpp
+++ source/Plugins/Process/Utility/UnwindLLDB.cpp
@@ -86,6 +86,9 @@
 if (m_frames.size() > 0)
 return true;
 
+ProcessSP process_sp (m_thread.GetProcess());
+ABI *abi = process_sp ? process_sp->GetABI().get() : NULL;
+
 // First, set up the 0th (initial) frame
 CursorSP first_cursor_sp(new Cursor ());
 RegisterContextLLDBSP reg_ctx_sp (new RegisterContextLLDB (m_thread, 
@@ -108,6 +111,10 @@
 // cursor own it in its shared pointer
 first_cursor_sp->reg_ctx_lldb_sp = reg_ctx_sp;
 m_frames.push_back (first_cursor_sp);
+
+// Update the Full Unwind Plan for this frame if not valid
+UpdateUnwindPlanForFirstFrameIfInvalid(abi);
+
 return true;
 
 unwind_done:
@@ -161,7 +168,14 @@
 // If the RegisterContextLLDB has a fallback UnwindPlan, it will switch to that and return
 // true.  Subsequent calls to TryFallbackUnwindPlan() will return false.
 if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan())
+{
+// TryFallbackUnwindPlan for prev_frame succeeded and updated reg_ctx_lldb_sp field of
+// prev_frame. However, cfa field of prev_frame still needs to be updated. Hence updating it.
+if ( !(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
+return nullptr;
+
 return GetOneMoreFrame (abi);
+}
 
 if (log)
 log->Printf ("%*sFrame %d did not get a RegisterContext, stopping.",
@@ -175,7 +189,14 @@
 // See if the regctx below this on the stack has a fallback unwind plan it can use.
 // Subsequent calls to TryFallbackUnwindPlan() will return false.
 if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan())
+{
+// TryFallbackUnwindPlan for prev_frame succeeded and updated reg_ctx_lldb_sp field of
+// prev_frame. However, cfa field of prev_frame still needs to be updated. Hence updating it.
+if ( !(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
+return nullptr;
+
 return GetOneMoreFrame (abi);
+}
 
 if (log)
 log->Printf("%*sFrame %d invalid RegisterContext for this frame, stopping stack walk", 
@@ -187,7 +208,14 @@
 // If the RegisterContextLLDB has a fallback UnwindPlan, it will switch to that and return
 // true.  Subsequent calls to TryFallbackUnwindPlan() will return false.
 if (prev_frame->reg_ctx_lldb_sp->TryFallbackUnwindPlan())
+{
+// TryFallbackUnwindPlan for prev_frame succeeded and updated reg_ctx_lldb_sp field of
+// prev_frame. However, cfa field of prev_frame still needs to be updated. Hence updating it.
+if ( !(prev_frame->reg_ctx_lldb_sp->GetCFA(prev_frame->cfa)))
+return nullptr;
+
 return GetOneMoreFrame (abi);
+}
 
 if (log)
 log->Printf("%*sFrame %d did not get CFA for this frame, stopping stack walk",
@@ -212,

Re: [Lldb-commits] [PATCH] D14226: Fix to solve Bug 23139 & Bug 23560

[Abhishek via lldb-commits]

abhishek.aggarwal added a comment.

Hello Jason

No problem regarding the delay. Thanks a lot for reviewing the patch. I have 
made the changes as suggested by you. I will land it now.


http://reviews.llvm.org/D14226



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

Re: [Lldb-commits] [PATCH] D14536: Add empty symbols to symtab for skipped symbols

[Tamas Berghammer via lldb-commits]

tberghammer abandoned this revision.
tberghammer added a comment.

I haven't noticed we already store the symbol index. Abandon it in favor of the 
API you suggested


http://reviews.llvm.org/D14536



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

Re: [Lldb-commits] [PATCH] D14111: Use "_$" prefix instead of "$" for dynamic checker function inserted by LLDB during expression evaluation

[Dean De Leo via lldb-commits]

Hi,
is there any update related to this patch? I don't see any activity from the 
last two weeks.

@Greg Clayton: you have inserted two reviewers but they don't seem to have 
commented on it. Can you please give a look?

Thanks

On 02/11/15 05:15, Bhushan Attarde via lldb-commits wrote:

bhushan added a comment.

Hi Sean/Jim

Could you please find some time to review this?

Thanks.


Repository:
   rL LLVM

http://reviews.llvm.org/D14111



___
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] D14111: Use "_$" prefix instead of "$" for dynamic checker function inserted by LLDB during expression evaluation

[Dean De Leo via lldb-commits]

dean added a subscriber: dean.
dean added a comment.

Hi,
is there any update related to this patch? I don't see any activity from the 
last two weeks.

@Greg Clayton: you have inserted two reviewers but they don't seem to have 
commented on it. Can you please give a look?

Thanks


Repository:
  rL LLVM

http://reviews.llvm.org/D14111



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

[Lldb-commits] [PATCH] D14611: Remove a broken hack from Scalar::ULongLong and fix a test

[Tamas Berghammer via lldb-commits]

tberghammer created this revision.
tberghammer added reviewers: clayborg, granata.enrico.
tberghammer added a subscriber: lldb-commits.

Remove a broken hack from Scalar::ULongLong and fix a test

Change Test-rdar-12481949.py to expect GetValueAsUnsigned() to return
0x if the variable is an int32_t (signed, 4 byte integer) with
value of -1. The previous expectation where we expected the value to be
0x doesn't make sense as nothing explains why we would
treat it as an 8 byte value.

This CL also removes a hack from Scalar::ULongLong what was most likely
added to get this test passing as it only worked in case the value of
the variable is -1 and didn't make any sense even in that case.

http://reviews.llvm.org/D14611

Files:
  packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
  source/Core/Scalar.cpp

Index: source/Core/Scalar.cpp
===
--- source/Core/Scalar.cpp
+++ source/Core/Scalar.cpp
@@ -1574,8 +1574,6 @@
 case e_ulonglong:
 case e_sint128:
 case e_uint128:
-if(m_integer.isAllOnesValue())
-return *(const ulonglong_t 
*)(llvm::APInt::getAllOnesValue(128)).getRawData();
 return *(const ulonglong_t *)m_integer.getRawData();
 case e_float:
 return (ulonglong_t)m_float.convertToFloat();
Index: 
packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
===
--- 
packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
+++ 
packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
@@ -50,5 +50,5 @@
 self.assertTrue(self.frame().FindVariable("myvar").GetValueAsSigned() 
!= 0x, "GetValueAsSigned() does not say 0x")
 
 
self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() != -1, 
"GetValueAsUnsigned() does not say -1")
-
self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() == 
0x, "GetValueAsUnsigned() says 0x")
-self.assertTrue(self.frame().FindVariable("myvar").GetValueAsSigned() 
!= 0x, "GetValueAsUnsigned() does not say 0x")
+
self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() == 
0x, "GetValueAsUnsigned() says 0x")
+
self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() != 
0x, "GetValueAsUnsigned() does not says 0x")


Index: source/Core/Scalar.cpp
===
--- source/Core/Scalar.cpp
+++ source/Core/Scalar.cpp
@@ -1574,8 +1574,6 @@
 case e_ulonglong:
 case e_sint128:
 case e_uint128:
-if(m_integer.isAllOnesValue())
-return *(const ulonglong_t *)(llvm::APInt::getAllOnesValue(128)).getRawData();
 return *(const ulonglong_t *)m_integer.getRawData();
 case e_float:
 return (ulonglong_t)m_float.convertToFloat();
Index: packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
===
--- packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
+++ packages/Python/lldbsuite/test/python_api/rdar-12481949/Test-rdar-12481949.py
@@ -50,5 +50,5 @@
 self.assertTrue(self.frame().FindVariable("myvar").GetValueAsSigned() != 0x, "GetValueAsSigned() does not say 0x")
 
 self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() != -1, "GetValueAsUnsigned() does not say -1")
-self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() == 0x, "GetValueAsUnsigned() says 0x")
-self.assertTrue(self.frame().FindVariable("myvar").GetValueAsSigned() != 0x, "GetValueAsUnsigned() does not say 0x")
+self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() == 0x, "GetValueAsUnsigned() says 0x")
+self.assertTrue(self.frame().FindVariable("myvar").GetValueAsUnsigned() != 0x, "GetValueAsUnsigned() does not says 0x")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r252898 - Use uniqueness of C++ fully-qualified names to resolve conflicts

[Ramkumar Ramachandra via lldb-commits]

Author: artagnon
Date: Thu Nov 12 08:44:24 2015
New Revision: 252898

URL: http://llvm.org/viewvc/llvm-project?rev=252898&view=rev
Log:
Use uniqueness of C++ fully-qualified names to resolve conflicts

A very expected layout: source tree is in ~/src/llvm, the build directory is in
~/src/llvm-build, and the install location is in /usr/local/{lib,include}.

The DWARF information in /usr/local/lib/libLLVM.a for ilist.h points to
~/src/llvm-build/include/llvm/ADT/ilist.h. Now, when someone includes
"llvm/ADT/ilist.h" and links against /usr/local/lib/libLLVM.a. Disaster.

The DWARF information in libUser.so for ilist.h points to two locations: the one
in /usr/include, and the one in ~/src/llvm-build/include. LLDB gets confused.

Let's uniquify fully-qualified names and never trip on such a thing.

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

Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp?rev=252898&r1=252897&r2=252898&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
(original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp Thu Nov 
12 08:44:24 2015
@@ -457,24 +457,44 @@ DWARFASTParserClang::ParseTypeFromDWARF
 // and clang isn't good and sharing the stack space for 
variables in different blocks.
 std::unique_ptr 
unique_ast_entry_ap(new UniqueDWARFASTType());
 
-// Only try and unique the type if it has a name.
-if (type_name_const_str &&
-dwarf->GetUniqueDWARFASTTypeMap().Find 
(type_name_const_str,
-die,
-decl,
-
byte_size_valid ? byte_size : -1,
-
*unique_ast_entry_ap))
+if (type_name_const_str)
 {
-// We have already parsed this type or from another
-// compile unit. GCC loves to use the "one definition
-// rule" which can result in multiple definitions
-// of the same class over and over in each compile
-// unit.
-type_sp = unique_ast_entry_ap->m_type_sp;
-if (type_sp)
+LanguageType die_language = die.GetLanguage();
+bool handled = false;
+if (Language::LanguageIsCPlusPlus(die_language))
+{
+std::string qualified_name;
+if (die.GetQualifiedName(qualified_name))
+{
+handled = true;
+ConstString 
const_qualified_name(qualified_name);
+if 
(dwarf->GetUniqueDWARFASTTypeMap().Find(const_qualified_name, die, 
Declaration(),
+   
byte_size_valid ? byte_size : -1,
+   
*unique_ast_entry_ap))
+{
+type_sp = unique_ast_entry_ap->m_type_sp;
+if (type_sp)
+{
+dwarf->GetDIEToType()[die.GetDIE()] = 
type_sp.get();
+return type_sp;
+}
+}
+}
+}
+
+if (!handled)
+{
+if 
(dwarf->GetUniqueDWARFASTTypeMap().Find(type_name_const_str, die, decl,
+   
byte_size_valid ? byte_size : -1,
+   
*unique_ast_entry_ap))
 {
+type_sp = unique_ast_entry_ap->m_type_sp;
+if (type_sp)
+{
 dwarf->GetDIEToType()[die.GetDIE()] = 
type_sp.get();
 return type_sp;
+}
+}
 }
 }
 
@@ -1251,13 +1271,13 @@ DWARFASTParserClang::ParseTypeFromDWARF

   

Re: [Lldb-commits] [PATCH] D14549: Use uniqueness of C++ fully-qualified names to resolve conflicts

[Ramkumar Ramachandra via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL252898: Use uniqueness of C++ fully-qualified names to 
resolve conflicts (authored by artagnon).

Changed prior to commit:
  http://reviews.llvm.org/D14549?vs=39841&id=40044#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D14549

Files:
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp

Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
@@ -457,24 +457,44 @@
 // and clang isn't good and sharing the stack space for variables in different blocks.
 std::unique_ptr unique_ast_entry_ap(new UniqueDWARFASTType());
 
-// Only try and unique the type if it has a name.
-if (type_name_const_str &&
-dwarf->GetUniqueDWARFASTTypeMap().Find (type_name_const_str,
-die,
-decl,
-byte_size_valid ? byte_size : -1,
-*unique_ast_entry_ap))
+if (type_name_const_str)
 {
-// We have already parsed this type or from another
-// compile unit. GCC loves to use the "one definition
-// rule" which can result in multiple definitions
-// of the same class over and over in each compile
-// unit.
-type_sp = unique_ast_entry_ap->m_type_sp;
-if (type_sp)
+LanguageType die_language = die.GetLanguage();
+bool handled = false;
+if (Language::LanguageIsCPlusPlus(die_language))
+{
+std::string qualified_name;
+if (die.GetQualifiedName(qualified_name))
+{
+handled = true;
+ConstString const_qualified_name(qualified_name);
+if (dwarf->GetUniqueDWARFASTTypeMap().Find(const_qualified_name, die, Declaration(),
+   byte_size_valid ? byte_size : -1,
+   *unique_ast_entry_ap))
+{
+type_sp = unique_ast_entry_ap->m_type_sp;
+if (type_sp)
+{
+dwarf->GetDIEToType()[die.GetDIE()] = type_sp.get();
+return type_sp;
+}
+}
+}
+}
+
+if (!handled)
+{
+if (dwarf->GetUniqueDWARFASTTypeMap().Find(type_name_const_str, die, decl,
+   byte_size_valid ? byte_size : -1,
+   *unique_ast_entry_ap))
 {
+type_sp = unique_ast_entry_ap->m_type_sp;
+if (type_sp)
+{
 dwarf->GetDIEToType()[die.GetDIE()] = type_sp.get();
 return type_sp;
+}
+}
 }
 }
 
@@ -1251,13 +1271,13 @@
  class_type->GetName().GetCString(),
  die.GetID(),
  dwarf->GetObjectFile()->GetFileSpec().GetPath().c_str());
-
+
 const bool is_attr_used = false;
 // Neither GCC 4.2 nor clang++ currently set a valid accessibility
 // in the DWARF for C++ methods... Default to public for now...
 if (accessibility == eAccessNone)
 accessibility = eAccessPublic;
- 

[Lldb-commits] [lldb] r252906 - Begin converting uses of PyCallable to PythonCallable.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Thu Nov 12 10:23:16 2015
New Revision: 252906

URL: http://llvm.org/viewvc/llvm-project?rev=252906&view=rev
Log:
Begin converting uses of PyCallable to PythonCallable.

PyCallable is a class that exists solely within the swig wrapper
code.  PythonCallable is a more generic implementation of the same
idea that can be used by any Python-related interop code, and lives
in PythonDataObjects.h

The CL is mostly mechanical, and it doesn't cover every possible
user of PyCallable, because I want to minimize the impact of this
change (as well as making it easier to figure out what went wrong
in case this causes a failure).  I plan to finish up the rest of
the changes in a subsequent patch, culminating in the removal of
PyCallable entirely.

Modified:
lldb/trunk/scripts/Python/python-wrapper.swig
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h

Modified: lldb/trunk/scripts/Python/python-wrapper.swig
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/python-wrapper.swig?rev=252906&r1=252905&r2=252906&view=diff
==
--- lldb/trunk/scripts/Python/python-wrapper.swig (original)
+++ lldb/trunk/scripts/Python/python-wrapper.swig Thu Nov 12 10:23:16 2015
@@ -191,21 +191,19 @@ LLDBSwigPythonBreakpointCallbackFunction
 bool stop_at_breakpoint = true;
 
 PyErr_Cleaner py_err_cleaner(true);
-PythonDictionary dict = 
PythonModule::MainModule().ResolveName(session_dictionary_name).AsType();
+auto dict = 
PythonModule::MainModule().ResolveName(session_dictionary_name);
+auto pfunc = 
PythonObject::ResolveNameWithDictionary(python_function_name, 
dict);
 
-PyCallable pfunc = 
PyCallable::FindWithFunctionName(python_function_name,dict.get());
-
-if (!pfunc)
+if (!pfunc.IsAllocated())
 return stop_at_breakpoint;
 
-PyObject* pvalue = NULL;
-pvalue = pfunc(sb_frame, sb_bp_loc, dict.get());
+PythonObject frame_arg(PyRefType::Owned, SBTypeToSWIGWrapper(sb_frame));
+PythonObject bp_loc_arg(PyRefType::Owned, SBTypeToSWIGWrapper(sb_bp_loc));
+PythonObject result = pfunc(frame_arg, bp_loc_arg, dict);
 
-if (pvalue == Py_False)
+if (result.get() == Py_False)
 stop_at_breakpoint = false;
 
-Py_XDECREF (pvalue);
-
 return stop_at_breakpoint;
 }
 
@@ -229,21 +227,19 @@ LLDBSwigPythonWatchpointCallbackFunction
 
 PyErr_Cleaner py_err_cleaner(true);
 
-PythonDictionary dict = 
PythonModule::MainModule().ResolveName(session_dictionary_name).AsType();
-
-PyCallable pfunc = 
PyCallable::FindWithFunctionName(python_function_name,dict.get());
+auto dict = 
PythonModule::MainModule().ResolveName(session_dictionary_name);
+auto pfunc = 
PythonObject::ResolveNameWithDictionary(python_function_name, 
dict);
 
-if (!pfunc)
+if (!pfunc.IsAllocated())
 return stop_at_watchpoint;
 
-PyObject* pvalue = NULL;
-pvalue = pfunc(sb_frame, sb_wp, dict.get());
+PythonObject frame_arg(PyRefType::Owned, SBTypeToSWIGWrapper(sb_frame));
+PythonObject wp_arg(PyRefType::Owned, SBTypeToSWIGWrapper(sb_wp));
+PythonObject result = pfunc(frame_arg, wp_arg, dict);
 
-if (pvalue == Py_False)
+if (result.get() == Py_False)
 stop_at_watchpoint = false;
 
-Py_XDECREF (pvalue);
-
 return stop_at_watchpoint;
 }
 
@@ -294,7 +290,7 @@ LLDBSwigPythonCallTypeScript
 if (!python_function_name || !session_dictionary)
 return false;
 
-PyObject *pfunc_impl = NULL, *pvalue = NULL;
+PyObject *pfunc_impl = nullptr;
 
 if (pyfunct_wrapper && *pyfunct_wrapper && PyFunction_Check 
(*pyfunct_wrapper))
 {
@@ -314,33 +310,33 @@ LLDBSwigPythonCallTypeScript
 
 PyErr_Cleaner pyerr_cleanup(true);  // show Python errors
 
-if (!pfunc_impl)
+PythonCallable pfunc(PyRefType::Borrowed, pfunc_impl);
+
+if (!pfunc.IsAllocated())
 {
-pfunc_impl = 
PythonObject::ResolveNameWithDictionary(python_function_name, dict).release();
-if (!pfunc_impl || !PyCallable_Check (pfunc_impl))
+pfunc = 
PythonObject::ResolveNameWithDictionary(python_function_name, 
dict);
+if (!pfunc.IsAllocated())
 return false;
-else
+
+if (pyfunct_wrapper)
 {
-if (pyfunct_wrapper)
-*pyfunct_wrapper = pfunc_impl;
+*pyfunct_wrapper = pfunc.get();
+Py_XINCREF(pfunc.get());
 }
 }
 
-PyCallable pfunc = PyCallable::FindWithPythonObject(pfunc_impl);
-
-if (!pfunc)
-return false;
-
+PythonObject result;
+auto argc = pfunc.GetNumArguments();
 // if the third argument is supported, or varargs are allowed
-PyCallable::argc argc = pfunc.GetNumArguments();
-if (argc.num_args == 3 || argc.varargs == true)
-pvalue = pfunc(sb_value,dict.get(),sb_options);
+  

Re: [Lldb-commits] [PATCH] D14591: Implement register context for mini dump debugging

[Zachary Turner via lldb-commits]

zturner added inline comments.


Comment at: 
packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py:40
@@ +39,3 @@
+thread = self.process.GetThreadAtIndex(0)
+# The crash is in main, so there should be one frame on the stack.
+self.assertEqual(thread.GetNumFrames(), 1)

I remember us being able to get call stacks higher than main.  But now that I 
think about it I guess that's only true for live debugging since you have a 
physical copy of the module loaded in your process, and you can read it's EAT.  
In any case, this assumption probably won't be true anymore once we understand 
PDBs and symbol servers.  Although at that point hopefully we'll have many more 
tests covering different scenarios.


Comment at: 
packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py:45
@@ +44,3 @@
+pc = frame.GetPC()
+eip = frame.FindRegister("eip")
+self.assertTrue(eip.IsValid())

Does this work if you change `eip` to `pc`?  If so that would allow this test 
to work in the presence of 64 bit.


Comment at: source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp:193
@@ +192,3 @@
+const auto &mini_dump_thread = thread_list_ptr->Threads[i];
+std::shared_ptr thread_sp(new 
ThreadWinMiniDump(*this, mini_dump_thread.ThreadId));
+if (mini_dump_thread.ThreadContext.DataSize >= sizeof(CONTEXT))

Can you change this to

auto thread_sp = llvm::make_shared(*this, 
mini_dump_thread.ThreadId);


Comment at: source/Plugins/Process/Windows/MiniDump/ThreadWinMiniDump.h:42-44
@@ -44,4 +41,5 @@
 protected:
-std::string m_thread_name;
 lldb::RegisterContextSP m_reg_context_sp;
+class Data;
+std::unique_ptr m_data;  // for WinAPI-specific data
 

Why does this class need a separate `CONTEXT` than the one that is already 
stored in `m_reg_context_sp`?  It seems like now we're storing the `CONTEXT` 
twice.


Comment at: 
source/Plugins/Process/Windows/MiniDump/x64/RegisterContextWindowsMiniDump_x64.h:14
@@ +13,3 @@
+#include "lldb/lldb-forward.h"
+#include "../../Common/x64/RegisterContextWindows_x64.h"
+

Instead of using relative paths, I think you can write this as

#include "Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.h"


http://reviews.llvm.org/D14591



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

[Lldb-commits] [lldb] r252909 - Fix non-Windows build after r252906.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Thu Nov 12 11:01:48 2015
New Revision: 252909

URL: http://llvm.org/viewvc/llvm-project?rev=252909&view=rev
Log:
Fix non-Windows build after r252906.

Modified:
lldb/trunk/scripts/Python/python-wrapper.swig
lldb/trunk/scripts/lldb.swig
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h

Modified: lldb/trunk/scripts/Python/python-wrapper.swig
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/python-wrapper.swig?rev=252909&r1=252908&r2=252909&view=diff
==
--- lldb/trunk/scripts/Python/python-wrapper.swig (original)
+++ lldb/trunk/scripts/Python/python-wrapper.swig Thu Nov 12 11:01:48 2015
@@ -566,7 +566,7 @@ LLDBSwigPython_CalculateNumChildren
 }
 
 if (argc.count == 1)
-ret_val = std::min(ret_val, max);
+ret_val = std::min(ret_val, static_cast(max));
 
 return ret_val;
 }

Modified: lldb/trunk/scripts/lldb.swig
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/lldb.swig?rev=252909&r1=252908&r2=252909&view=diff
==
--- lldb/trunk/scripts/lldb.swig (original)
+++ lldb/trunk/scripts/lldb.swig Thu Nov 12 11:01:48 2015
@@ -48,6 +48,7 @@ import six
 
 /* C++ headers to be included. */
 %{
+#include 
 #include 
 %}
 

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp?rev=252909&r1=252908&r2=252909&view=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp 
(original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp 
Thu Nov 12 11:01:48 2015
@@ -109,7 +109,7 @@ PythonObject::Str() const
 }
 
 PythonObject
-PythonObject::ResolveNameWithDictionary(llvm::StringRef name, PythonDictionary 
dict)
+PythonObject::ResolveNameWithDictionary(llvm::StringRef name, const 
PythonDictionary &dict)
 {
 size_t dot_pos = name.find_first_of('.');
 llvm::StringRef piece = name.substr(0, dot_pos);

Modified: lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h?rev=252909&r1=252908&r2=252909&view=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h 
(original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.h Thu 
Nov 12 11:01:48 2015
@@ -205,11 +205,11 @@ public:
 Str() const;
 
 static PythonObject
-ResolveNameWithDictionary(llvm::StringRef name, PythonDictionary dict);
+ResolveNameWithDictionary(llvm::StringRef name, const PythonDictionary 
&dict);
 
 template
 static T
-ResolveNameWithDictionary(llvm::StringRef name, PythonDictionary dict)
+ResolveNameWithDictionary(llvm::StringRef name, const PythonDictionary 
&dict)
 {
 return ResolveNameWithDictionary(name, dict).AsType();
 }


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

[Lldb-commits] [lldb] r252914 - Allow renderscript runtime to read MIPS target arguments.

[Aidan Dodds via lldb-commits]

Author: aidandodds
Date: Thu Nov 12 11:39:42 2015
New Revision: 252914

URL: http://llvm.org/viewvc/llvm-project?rev=252914&view=rev
Log:
Allow renderscript runtime to read MIPS target arguments.

Modified:

lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp

Modified: 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp?rev=252914&r1=252913&r2=252914&view=diff
==
--- 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.cpp
 Thu Nov 12 11:39:42 2015
@@ -665,6 +665,45 @@ RenderScriptRuntime::GetArgSimple(Execut
 }
 break;
 }
+case llvm::Triple::ArchType::mipsel:
+{
+
+// read from the registers
+if (arg < 4){
+const RegisterInfo* rArg = reg_ctx->GetRegisterInfoAtIndex(arg 
+ 4);
+RegisterValue rVal;
+success = reg_ctx->ReadRegister(rArg, rVal);
+if (success)
+{
+*data = rVal.GetAsUInt64();
+}
+else
+{
+if (log)
+log->Printf("RenderScriptRuntime::GetArgSimple() - 
Mips - Error while reading the argument #%d", arg);
+}
+
+}
+
+// read from the stack
+else
+{
+uint64_t sp = reg_ctx->GetSP();
+uint32_t offset = arg * sizeof(uint32_t);
+process->ReadMemory(sp + offset, &data, sizeof(uint32_t), 
error);
+if (error.Fail())
+{
+if (log)
+log->Printf ("RenderScriptRuntime::GetArgSimple - 
error reading Mips stack: %s.", error.AsCString());
+}
+else
+{
+success = true;
+}
+}
+
+break;
+}
 case llvm::Triple::ArchType::mips64el:
 {
 // read from the registers
@@ -883,11 +922,12 @@ RenderScriptRuntime::LoadRuntimeHooks(ll
 if (targetArchType != llvm::Triple::ArchType::x86
 && targetArchType != llvm::Triple::ArchType::arm
 && targetArchType != llvm::Triple::ArchType::aarch64
+&& targetArchType != llvm::Triple::ArchType::mipsel
 && targetArchType != llvm::Triple::ArchType::mips64el
 )
 {
 if (log)
-log->Printf ("RenderScriptRuntime::LoadRuntimeHooks - Unable to 
hook runtime. Only X86, ARM, Mips64 supported currently.");
+log->Printf ("RenderScriptRuntime::LoadRuntimeHooks - Unable to 
hook runtime. Only X86, ARM, Mips supported currently.");
 
 return;
 }


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

Re: [Lldb-commits] [PATCH] D14591: Implement register context for mini dump debugging

[Adrian McCarthy via lldb-commits]

amccarth marked 3 inline comments as done.


Comment at: 
packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py:40
@@ +39,3 @@
+thread = self.process.GetThreadAtIndex(0)
+# The crash is in main, so there should be one frame on the stack.
+self.assertEqual(thread.GetNumFrames(), 1)

zturner wrote:
> I remember us being able to get call stacks higher than main.  But now that I 
> think about it I guess that's only true for live debugging since you have a 
> physical copy of the module loaded in your process, and you can read it's 
> EAT.  In any case, this assumption probably won't be true anymore once we 
> understand PDBs and symbol servers.  Although at that point hopefully we'll 
> have many more tests covering different scenarios.
Yes, I recognize that this will need to change when we have more debug info 
available. but it's sufficient for testing at this point.


Comment at: 
packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py:45
@@ +44,3 @@
+pc = frame.GetPC()
+eip = frame.FindRegister("eip")
+self.assertTrue(eip.IsValid())

zturner wrote:
> Does this work if you change `eip` to `pc`?  If so that would allow this test 
> to work in the presence of 64 bit.
Indeed, "pc" works, so I'll use that.


Comment at: source/Plugins/Process/Windows/MiniDump/ThreadWinMiniDump.h:42-44
@@ -44,4 +41,5 @@
 protected:
-std::string m_thread_name;
 lldb::RegisterContextSP m_reg_context_sp;
+class Data;
+std::unique_ptr m_data;  // for WinAPI-specific data
 

zturner wrote:
> Why does this class need a separate `CONTEXT` than the one that is already 
> stored in `m_reg_context_sp`?  It seems like now we're storing the `CONTEXT` 
> twice.
Because the register context isn't created right away.  It's lazily created 
later by this object, so this object needs a handle to it.  Note that the 
CONTEXT in the Data is just a pointer, so it's not actually a second copy.

The process object pulls the original CONTEXT from the mini dump, and it 
creates this thread object.  This thread object will later be called to create 
the register context object, so it has to keep track of the CONTEXT in order to 
do that.


http://reviews.llvm.org/D14591



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

[Lldb-commits] [lldb] r252939 - Finish PyCallable -> PythonCallable conversion.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Thu Nov 12 14:11:02 2015
New Revision: 252939

URL: http://llvm.org/viewvc/llvm-project?rev=252939&view=rev
Log:
Finish PyCallable -> PythonCallable conversion.

This finishes the effort to port python-wrapper.swig code over to
using PythonDataObjects.

Also included in this patch is the removal of `PyCallable` from
`python-wrapper.swig`, as it is no longer used after having been
replaced by `PythonCallable` everywhere.

There might be additional cleanup as followup patches, but it should
be all fairly simple and minor.

Modified:
lldb/trunk/scripts/Python/python-wrapper.swig

Modified: lldb/trunk/scripts/Python/python-wrapper.swig
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/python-wrapper.swig?rev=252939&r1=252938&r2=252939&view=diff
==
--- lldb/trunk/scripts/Python/python-wrapper.swig (original)
+++ lldb/trunk/scripts/Python/python-wrapper.swig Thu Nov 12 14:11:02 2015
@@ -26,142 +26,6 @@ private:
 bool m_print;
 };
 
-// TODO(zturner): This entire class should be moved to PythonDataObjects.h
-// and properly abstracted and unit-tested.
-class PyCallable
-{
-public:
-struct argc {
-size_t num_args;
-bool varargs : 1;
-bool kwargs : 1;
-};
-
-argc
-GetNumArguments ()
-{
-PyObject *py_func_obj = NULL;
-if (m_callable)
-{
-if (PyMethod_Check(m_callable))
-py_func_obj = PyMethod_GET_FUNCTION(m_callable);
-else
-py_func_obj = m_callable;
-}
-
-if (py_func_obj)
-{
-PyCodeObject* code = 
(PyCodeObject*)PyFunction_GET_CODE(py_func_obj);
-if (code)
-{
-size_t args = code->co_argcount;
-bool va=false,kw=false;
-if ((code->co_flags & 4) == 4)
-va = true;
-if ((code->co_flags & 8) == 8)
-kw = true;
-return {args,va,kw};
-}
-}
-return {SIZE_MAX,false,false};
-}
-
-operator
-bool ()
-{
-return m_callable != NULL;
-}
-
-template
-PyObject*
-operator () (Args... args)
-{
-return (*this)({SBTypeToSWIGWrapper(args)...});
-}
-
-PyObject*
-operator () (std::initializer_list args)
-{
-PyObject* retval = NULL;
-PyObject* pargs = PyTuple_New (args.size());
-if (pargs == NULL)
-{
-if (PyErr_Occurred())
-PyErr_Clear();
-return retval;
-}
-size_t idx = 0;
-for (auto arg : args)
-{
-if (!arg)
-return retval;
-Py_INCREF(arg); // _SetItem steals a reference
-PyTuple_SetItem(pargs,idx,arg);
-idx++;
-}
-retval = PyObject_CallObject (m_callable, pargs);
-Py_XDECREF (pargs);
-return retval;
-}
-
-static PyCallable
-FindWithPythonObject (PyObject* pfunc)
-{
-return PyCallable(pfunc);
-}
-
-static PyCallable
-FindWithFunctionName (const char *python_function_name,
-  const char *session_dictionary_name)
-{
-if (!python_function_name || !session_dictionary_name)
-return PyCallable();
-if ( (python_function_name[0] == 0) || (session_dictionary_name[0] == 
0) )
-return PyCallable();
-
-using namespace lldb_private;
-auto dict = 
PythonModule::MainModule().ResolveName(session_dictionary_name).AsType();
-return FindWithFunctionName(python_function_name, dict.get());
-}
-
-static PyCallable
-FindWithFunctionName (const char *python_function_name,
-  PyObject *py_session_dict)
-{
-if (!python_function_name || !py_session_dict)
-return PyCallable();
-if ( (python_function_name[0] == 0))
-return PyCallable();
-
-using namespace lldb_private;
-PythonDictionary session_dict(PyRefType::Borrowed, py_session_dict);
-PythonCallable result = 
PythonObject::ResolveNameWithDictionary(python_function_name, 
session_dict).AsType();
-return PyCallable(result.release());
-}
-
-static PyCallable
-FindWithMemberFunction (PyObject *self,
-const char *python_function_name)
-{
-if (self == NULL || self == Py_None)
-return PyCallable();
-if (!python_function_name || (python_function_name[0] == 0))
-return PyCallable();
-
-return PyCallable(PyObject_GetAttrString(self, python_function_name));
-}
-
-private:
-PyObject* m_callable;
-
-PyCallable (PyObject *callable = NULL) :
-m_callable(callable)
-{
-if (m_callable && PyCallable_Check(m_callable) == false)
-m_callable = NULL;
-}
-};
-

[Lldb-commits] [lldb] r252950 - Implement RegisterContext for Mini Dumps.

[Adrian McCarthy via lldb-commits]

Author: amccarth
Date: Thu Nov 12 15:16:15 2015
New Revision: 252950

URL: http://llvm.org/viewvc/llvm-project?rev=252950&view=rev
Log:
Implement RegisterContext for Mini Dumps.

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

Added:
lldb/trunk/source/Plugins/Process/Windows/MiniDump/x64/

lldb/trunk/source/Plugins/Process/Windows/MiniDump/x64/RegisterContextWindowsMiniDump_x64.cpp

lldb/trunk/source/Plugins/Process/Windows/MiniDump/x64/RegisterContextWindowsMiniDump_x64.h
lldb/trunk/source/Plugins/Process/Windows/MiniDump/x86/

lldb/trunk/source/Plugins/Process/Windows/MiniDump/x86/RegisterContextWindowsMiniDump_x86.cpp

lldb/trunk/source/Plugins/Process/Windows/MiniDump/x86/RegisterContextWindowsMiniDump_x86.h
Removed:

lldb/trunk/source/Plugins/Process/Windows/MiniDump/RegisterContextWindowsMiniDump.cpp

lldb/trunk/source/Plugins/Process/Windows/MiniDump/RegisterContextWindowsMiniDump.h
Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.h

lldb/trunk/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.cpp

lldb/trunk/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.h

lldb/trunk/source/Plugins/Process/Windows/Live/x86/RegisterContextWindowsLive_x86.cpp

lldb/trunk/source/Plugins/Process/Windows/Live/x86/RegisterContextWindowsLive_x86.h
lldb/trunk/source/Plugins/Process/Windows/MiniDump/CMakeLists.txt
lldb/trunk/source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp
lldb/trunk/source/Plugins/Process/Windows/MiniDump/ThreadWinMiniDump.cpp
lldb/trunk/source/Plugins/Process/Windows/MiniDump/ThreadWinMiniDump.h

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py?rev=252950&r1=252949&r2=252950&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
 Thu Nov 12 15:16:15 2015
@@ -32,6 +32,20 @@ class MiniDumpTestCase(TestBase):
 stop_description = thread.GetStopDescription(256);
 self.assertTrue("0xc005" in stop_description);
 
+@no_debug_info_test
+def test_stack_info_in_mini_dump(self):
+"""Test that we can see the stack."""
+self.assertEqual(self.process.GetNumThreads(), 1)
+thread = self.process.GetThreadAtIndex(0)
+# The crash is in main, so there should be one frame on the stack.
+self.assertEqual(thread.GetNumFrames(), 1)
+frame = thread.GetFrameAtIndex(0)
+self.assertTrue(frame.IsValid())
+pc = frame.GetPC()
+eip = frame.FindRegister("pc")
+self.assertTrue(eip.IsValid())
+self.assertEqual(pc, eip.GetValueAsUnsigned())
+
 def setUp(self):
 # Call super's setUp().
 TestBase.setUp(self)

Modified: 
lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.h?rev=252950&r1=252949&r2=252950&view=diff
==
--- lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.h 
(original)
+++ lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.h 
Thu Nov 12 15:16:15 2015
@@ -60,8 +60,6 @@ class RegisterContextWindows : public ll
 virtual bool CacheAllRegisterValues();
 
 CONTEXT m_context;
-
-  private:
 bool m_context_stale;
 };
 }

Modified: 
lldb/trunk/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.cpp?rev=252950&r1=252949&r2=252950&view=diff
==
--- 
lldb/trunk/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.cpp
 Thu Nov 12 15:16:15 2015
@@ -121,3 +121,58 @@ RegisterContextWindows_x86::GetRegisterS
 return &g_register_sets[reg_set];
 }
 
+bool
+RegisterContextWindows_x86::ReadRegister(const RegisterInfo *reg_info, 
RegisterValue ®_value)
+{
+if (!CacheAllRegisterValues())
+return false;
+
+uint32_t reg = reg_info->kinds[eRegisterKindLLDB];
+switch (reg)
+{
+case lldb_eax_i386:
+WINLOG_IFALL(WINDOWS_LOG_REGISTERS, "Read value 0x%x from EAX", 
m_context.Eax);
+reg_value.

Re: [Lldb-commits] [PATCH] D14591: Implement register context for mini dump debugging

[Adrian McCarthy via lldb-commits]

This revision was automatically updated to reflect the committed changes.
amccarth marked an inline comment as done.
Closed by commit rL252950: Implement RegisterContext for Mini Dumps. (authored 
by amccarth).

Changed prior to commit:
  http://reviews.llvm.org/D14591?vs=39978&id=40082#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D14591

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
  lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.h
  
lldb/trunk/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.cpp
  
lldb/trunk/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.h
  
lldb/trunk/source/Plugins/Process/Windows/Live/x86/RegisterContextWindowsLive_x86.cpp
  
lldb/trunk/source/Plugins/Process/Windows/Live/x86/RegisterContextWindowsLive_x86.h
  lldb/trunk/source/Plugins/Process/Windows/MiniDump/CMakeLists.txt
  lldb/trunk/source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp
  
lldb/trunk/source/Plugins/Process/Windows/MiniDump/RegisterContextWindowsMiniDump.cpp
  
lldb/trunk/source/Plugins/Process/Windows/MiniDump/RegisterContextWindowsMiniDump.h
  lldb/trunk/source/Plugins/Process/Windows/MiniDump/ThreadWinMiniDump.cpp
  lldb/trunk/source/Plugins/Process/Windows/MiniDump/ThreadWinMiniDump.h
  
lldb/trunk/source/Plugins/Process/Windows/MiniDump/x64/RegisterContextWindowsMiniDump_x64.cpp
  
lldb/trunk/source/Plugins/Process/Windows/MiniDump/x64/RegisterContextWindowsMiniDump_x64.h
  
lldb/trunk/source/Plugins/Process/Windows/MiniDump/x86/RegisterContextWindowsMiniDump_x86.cpp
  
lldb/trunk/source/Plugins/Process/Windows/MiniDump/x86/RegisterContextWindowsMiniDump_x86.h

Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/postmortem/minidump/TestMiniDump.py
@@ -32,6 +32,20 @@
 stop_description = thread.GetStopDescription(256);
 self.assertTrue("0xc005" in stop_description);
 
+@no_debug_info_test
+def test_stack_info_in_mini_dump(self):
+"""Test that we can see the stack."""
+self.assertEqual(self.process.GetNumThreads(), 1)
+thread = self.process.GetThreadAtIndex(0)
+# The crash is in main, so there should be one frame on the stack.
+self.assertEqual(thread.GetNumFrames(), 1)
+frame = thread.GetFrameAtIndex(0)
+self.assertTrue(frame.IsValid())
+pc = frame.GetPC()
+eip = frame.FindRegister("pc")
+self.assertTrue(eip.IsValid())
+self.assertEqual(pc, eip.GetValueAsUnsigned())
+
 def setUp(self):
 # Call super's setUp().
 TestBase.setUp(self)
Index: lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.h
===
--- lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.h
+++ lldb/trunk/source/Plugins/Process/Windows/Common/RegisterContextWindows.h
@@ -60,8 +60,6 @@
 virtual bool CacheAllRegisterValues();
 
 CONTEXT m_context;
-
-  private:
 bool m_context_stale;
 };
 }
Index: lldb/trunk/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.cpp
===
--- lldb/trunk/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.cpp
+++ lldb/trunk/source/Plugins/Process/Windows/Common/x86/RegisterContextWindows_x86.cpp
@@ -121,3 +121,58 @@
 return &g_register_sets[reg_set];
 }
 
+bool
+RegisterContextWindows_x86::ReadRegister(const RegisterInfo *reg_info, RegisterValue ®_value)
+{
+if (!CacheAllRegisterValues())
+return false;
+
+uint32_t reg = reg_info->kinds[eRegisterKindLLDB];
+switch (reg)
+{
+case lldb_eax_i386:
+WINLOG_IFALL(WINDOWS_LOG_REGISTERS, "Read value 0x%x from EAX", m_context.Eax);
+reg_value.SetUInt32(m_context.Eax);
+break;
+case lldb_ebx_i386:
+WINLOG_IFALL(WINDOWS_LOG_REGISTERS, "Read value 0x%x from EBX", m_context.Ebx);
+reg_value.SetUInt32(m_context.Ebx);
+break;
+case lldb_ecx_i386:
+WINLOG_IFALL(WINDOWS_LOG_REGISTERS, "Read value 0x%x from ECX", m_context.Ecx);
+reg_value.SetUInt32(m_context.Ecx);
+break;
+case lldb_edx_i386:
+WINLOG_IFALL(WINDOWS_LOG_REGISTERS, "Read value 0x%x from EDX", m_context.Edx);
+reg_value.SetUInt32(m_context.Edx);
+break;
+case lldb_edi_i386:
+WINLOG_IFALL(WINDOWS_LOG_REGISTERS, "Read value 0x%x from EDI", m_context.Edi);
+reg_value.SetUInt32(m_context.Edi);
+break;
+case lldb_esi_i386:
+ 

Re: [Lldb-commits] [PATCH] D14542: [lldb] Fix name lookup in ClangASTContext

[Dawn Perchik via lldb-commits]

dawn added a comment.

See inline comment.



Comment at: source/Symbol/ClangASTContext.cpp:9191
@@ -9189,2 +9190,3 @@
+continue;
 searched.insert(it->second);
 symbol_file->ParseDeclsForContext(CompilerDeclContext(this, 
it->second));

Minor efficiency improvement - change these 3 lines to:
if (!searched.insert(it->second).first)
continue;
No need for new patch - just change in final commit.


http://reviews.llvm.org/D14542



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

[Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Jim Ingham via lldb-commits]

Author: jingham
Date: Thu Nov 12 16:32:09 2015
New Revision: 252963

URL: http://llvm.org/viewvc/llvm-project?rev=252963&view=rev
Log:
Another little stepping optimization: if any of the source step commands are 
running through a range 
of addresses, and the range has no branches, instead of running to the last 
instruction and
single-stepping over that, run to the first instruction after the end of the 
range.  If there
are no branches in the current range, then the bytes right after it have to be 
in the current
function, and have to be instructions not data in code, so this is safe.  And 
it cuts down one
extra stepi per source range step.

Incidentally, this also works around a bug in the llvm Intel assembler where it 
treats the "rep" 
prefix as a separate instruction from the repeated instruction.  If that were 
at the end of a
line range, then we would put a trap in place of the repeated instruction, 
which is undefined
behavior.  Current processors just ignore the repetition in this case, which 
changes program behavior.
Since there would never be a line range break after the rep prefix, always 
doing the range stepping 
to the beginning of the new range avoids this problem.



Modified:
lldb/trunk/source/Target/ThreadPlanStepRange.cpp

Modified: lldb/trunk/source/Target/ThreadPlanStepRange.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadPlanStepRange.cpp?rev=252963&r1=252962&r2=252963&view=diff
==
--- lldb/trunk/source/Target/ThreadPlanStepRange.cpp (original)
+++ lldb/trunk/source/Target/ThreadPlanStepRange.cpp Thu Nov 12 16:32:09 2015
@@ -390,12 +390,19 @@ ThreadPlanStepRange::SetNextBranchBreakp
 if (branch_index == UINT32_MAX)
 {
 branch_index = instructions->GetSize() - 1;
+InstructionSP last_inst = 
instructions->GetInstructionAtIndex(branch_index);
+size_t last_inst_size = last_inst->GetOpcode().GetByteSize();
+run_to_address = last_inst->GetAddress();
+run_to_address.Slide(last_inst_size);
+}
+else if (branch_index - pc_index > 1)
+{
+run_to_address = 
instructions->GetInstructionAtIndex(branch_index)->GetAddress();
 }
 
-if (branch_index - pc_index > 1)
+if (run_to_address.IsValid())
 {
 const bool is_internal = true;
-run_to_address = 
instructions->GetInstructionAtIndex(branch_index)->GetAddress();
 m_next_branch_bp_sp = GetTarget().CreateBreakpoint(run_to_address, 
is_internal, false);
 if (m_next_branch_bp_sp)
 {


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

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Zachary Turner via lldb-commits]

Hi Jim,

This breaks about 12 tests on Windows.  The patch looks simple, but this
isn't really my area, is there anything I can give you to help diagnose
what might be wrong?  The following tests fail:

FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8
6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows zturner-win81 8
6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows
zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
GenuineIntel)
FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows
zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
GenuineIntel)
FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows zturner-win81 8
6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8 6.2.9200
AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
FAIL: LLDB (suite) :: TestFormatPropagation.py (Windows zturner-win81 8
6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
FAIL: LLDB (suite) :: TestFrames.py (Windows zturner-win81 8 6.2.9200 AMD64
Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
FAIL: LLDB (suite) :: TestInlineStepping.py (Windows zturner-win81 8
6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
FAIL: LLDB (suite) :: TestSBData.py (Windows zturner-win81 8 6.2.9200 AMD64
Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
FAIL: LLDB (suite) :: TestStepNoDebug.py (Windows zturner-win81 8 6.2.9200
AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
FAIL: LLDB (suite) :: TestThreadJump.py (Windows zturner-win81 8 6.2.9200
AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)

And here's the error I get from one of the failing tests, although I don't
know how much insight it provides.

Traceback (most recent call last):
  File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py",
line 536, in wrapper
return func(self, *args, **kwargs)
  File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py",
line 2228, in dwarf_test_method
return attrvalue(self)
  File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py",
line 608, in wrapper
func(*args, **kwargs)
  File
"D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
line 41, in test_step_in_with_python
self.do_step_in_past_nodebug()
  File
"D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
line 105, in do_step_in_past_nodebug
self.hit_correct_line ("intermediate_return_value =
called_from_nodebug_actual(some_value)")
  File
"D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
line 57, in hit_correct_line
self.assertTrue (cur_line == target_line, "Stepped to line %d instead
of expected %d with pattern '%s'."%(cur_line, target_line, pattern))
AssertionError: False is not True : Stepped to line 0 instead of expected
19 with pattern 'intermediate_return_value =
called_from_nodebug_actual(some_value)'.
Config=i686-d:\src\llvmbuild\ninja_release\bin\clang.exe
Session info generated @ Thu Nov 12 15:44:43 2015
To rerun this test, issue the following command from the 'test' directory:

If it's not obvious what the problem is, can we revert this until we figure
it out and then reland it?

On Thu, Nov 12, 2015 at 2:34 PM Jim Ingham via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: jingham
> Date: Thu Nov 12 16:32:09 2015
> New Revision: 252963
>
> URL: http://llvm.org/viewvc/llvm-project?rev=252963&view=rev
> Log:
> Another little stepping optimization: if any of the source step commands
> are running through a range
> of addresses, and the range has no branches, instead of running to the
> last instruction and
> single-stepping over that, run to the first instruction after the end of
> the range.  If there
> are no branches in the current range, then the bytes right after it have
> to be in the current
> function, and have to be instructions not data in code, so this is safe.
> And it cuts down one
> extra stepi per source range step.
>
> Incidentally, this also works around a bug in the llvm Intel assembler
> where it treats the "rep"
> prefix as a separate instruction from the repeated instruction.  If that
> were at the end of a
> line range, then we would put a trap in place of the repeated instruction,
> which is undefined
> behavior.  Current processors just ignore the repetition in this case,
> which changes program behavior.
> Since there would never be a line range break after the rep prefix, always
> doing the range stepping
> to the beginning of the new range avoids this problem.
>
> 
>
> Modified:
> lldb/trunk/source/Target/ThreadPlanStepRange.cpp
>
> Modified: l

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Jim Ingham via lldb-commits]

Is the line they stepped to - instead of the expected line - always line 0?

Jim

> On Nov 12, 2015, at 3:52 PM, Zachary Turner  wrote:
> 
> Hi Jim,
> 
> This breaks about 12 tests on Windows.  The patch looks simple, but this 
> isn't really my area, is there anything I can give you to help diagnose what 
> might be wrong?  The following tests fail:
> 
> FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8 6.2.9200 
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows zturner-win81 8 
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows 
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, 
> GenuineIntel)
> FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows zturner-win81 
> 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows zturner-win81 8 
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8 6.2.9200 AMD64 
> Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> FAIL: LLDB (suite) :: TestFormatPropagation.py (Windows zturner-win81 8 
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> FAIL: LLDB (suite) :: TestFrames.py (Windows zturner-win81 8 6.2.9200 AMD64 
> Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> FAIL: LLDB (suite) :: TestInlineStepping.py (Windows zturner-win81 8 6.2.9200 
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> FAIL: LLDB (suite) :: TestSBData.py (Windows zturner-win81 8 6.2.9200 AMD64 
> Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> FAIL: LLDB (suite) :: TestStepNoDebug.py (Windows zturner-win81 8 6.2.9200 
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> FAIL: LLDB (suite) :: TestThreadJump.py (Windows zturner-win81 8 6.2.9200 
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> 
> And here's the error I get from one of the failing tests, although I don't 
> know how much insight it provides.  
> 
> Traceback (most recent call last):
>   File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", 
> line 536, in wrapper
> return func(self, *args, **kwargs)
>   File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", 
> line 2228, in dwarf_test_method
> return attrvalue(self)
>   File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", 
> line 608, in wrapper
> func(*args, **kwargs)
>   File 
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
>  line 41, in test_step_in_with_python
> self.do_step_in_past_nodebug()
>   File 
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
>  line 105, in do_step_in_past_nodebug
> self.hit_correct_line ("intermediate_return_value = 
> called_from_nodebug_actual(some_value)")
>   File 
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
>  line 57, in hit_correct_line
> self.assertTrue (cur_line == target_line, "Stepped to line %d instead of 
> expected %d with pattern '%s'."%(cur_line, target_line, pattern))
> AssertionError: False is not True : Stepped to line 0 instead of expected 19 
> with pattern 'intermediate_return_value = 
> called_from_nodebug_actual(some_value)'.
> Config=i686-d:\src\llvmbuild\ninja_release\bin\clang.exe
> Session info generated @ Thu Nov 12 15:44:43 2015
> To rerun this test, issue the following command from the 'test' directory:
> 
> If it's not obvious what the problem is, can we revert this until we figure 
> it out and then reland it?
> 
> On Thu, Nov 12, 2015 at 2:34 PM Jim Ingham via lldb-commits 
>  wrote:
> Author: jingham
> Date: Thu Nov 12 16:32:09 2015
> New Revision: 252963
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=252963&view=rev
> Log:
> Another little stepping optimization: if any of the source step commands are 
> running through a range
> of addresses, and the range has no branches, instead of running to the last 
> instruction and
> single-stepping over that, run to the first instruction after the end of the 
> range.  If there
> are no branches in the current range, then the bytes right after it have to 
> be in the current
> function, and have to be instructions not data in code, so this is safe.  And 
> it cuts down one
> extra stepi per source range step.
> 
> Incidentally, this also works around a bug in the llvm Intel assembler where 
> it treats the "rep"
> prefix as a separate instruction from the repeated instruction.  If that were 
> at the end of a
> line range, then we would put a trap in place of the repeated instruction, 
> which is undefined
> behavior.  Current processors just ignore the repetition in t

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Zachary Turner via lldb-commits]

The error messages are always different because the error message is
printed by the test.  I'm going to try to load up the executable
for TestStepNoDebug in the debugger and get a disassembly and do the step

On Thu, Nov 12, 2015 at 4:01 PM Jim Ingham  wrote:

> Is the line they stepped to - instead of the expected line - always line 0?
>
> Jim
>
> > On Nov 12, 2015, at 3:52 PM, Zachary Turner  wrote:
> >
> > Hi Jim,
> >
> > This breaks about 12 tests on Windows.  The patch looks simple, but this
> isn't really my area, is there anything I can give you to help diagnose
> what might be wrong?  The following tests fail:
> >
> > FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows zturner-win81
> 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8 6.2.9200
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestFormatPropagation.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestFrames.py (Windows zturner-win81 8 6.2.9200
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestInlineStepping.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestSBData.py (Windows zturner-win81 8 6.2.9200
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestStepNoDebug.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestThreadJump.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> >
> > And here's the error I get from one of the failing tests, although I
> don't know how much insight it provides.
> >
> > Traceback (most recent call last):
> >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
> 536, in wrapper
> > return func(self, *args, **kwargs)
> >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
> 2228, in dwarf_test_method
> > return attrvalue(self)
> >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
> 608, in wrapper
> > func(*args, **kwargs)
> >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
> line 41, in test_step_in_with_python
> > self.do_step_in_past_nodebug()
> >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
> line 105, in do_step_in_past_nodebug
> > self.hit_correct_line ("intermediate_return_value =
> called_from_nodebug_actual(some_value)")
> >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
> line 57, in hit_correct_line
> > self.assertTrue (cur_line == target_line, "Stepped to line %d
> instead of expected %d with pattern '%s'."%(cur_line, target_line, pattern))
> > AssertionError: False is not True : Stepped to line 0 instead of
> expected 19 with pattern 'intermediate_return_value =
> called_from_nodebug_actual(some_value)'.
> > Config=i686-d:\src\llvmbuild\ninja_release\bin\clang.exe
> > Session info generated @ Thu Nov 12 15:44:43 2015
> > To rerun this test, issue the following command from the 'test'
> directory:
> >
> > If it's not obvious what the problem is, can we revert this until we
> figure it out and then reland it?
> >
> > On Thu, Nov 12, 2015 at 2:34 PM Jim Ingham via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> > Author: jingham
> > Date: Thu Nov 12 16:32:09 2015
> > New Revision: 252963
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=252963&view=rev
> > Log:
> > Another little stepping optimization: if any of the source step commands
> are running through a range
> > of addresses, and the range has no branches, instead of running to the
> last instruction and
> > single-stepping over that, run to the first instruction after the end of
> the range.  If there
> > are no branches in the current range, then the bytes right after it have
> to be in the current
> > function, and have to be instructions not data in code, so this is
> safe.  And it cuts down one
> > extra stepi per source range ste

[Lldb-commits] [lldb] r252980 - Revert "Another little stepping optimization: if any of the source step commands are running through a range "

[Ying Chen via lldb-commits]

Author: chying
Date: Thu Nov 12 18:31:21 2015
New Revision: 252980

URL: http://llvm.org/viewvc/llvm-project?rev=252980&view=rev
Log:
Revert "Another little stepping optimization: if any of the source step 
commands are running through a range "

- Revert because this commit introduce several failures in lldb test suite
- http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391
- This reverts commit 78943bb678c2893703ee4e8b41969372740c8a6f.

Modified:
lldb/trunk/source/Target/ThreadPlanStepRange.cpp

Modified: lldb/trunk/source/Target/ThreadPlanStepRange.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadPlanStepRange.cpp?rev=252980&r1=252979&r2=252980&view=diff
==
--- lldb/trunk/source/Target/ThreadPlanStepRange.cpp (original)
+++ lldb/trunk/source/Target/ThreadPlanStepRange.cpp Thu Nov 12 18:31:21 2015
@@ -390,19 +390,12 @@ ThreadPlanStepRange::SetNextBranchBreakp
 if (branch_index == UINT32_MAX)
 {
 branch_index = instructions->GetSize() - 1;
-InstructionSP last_inst = 
instructions->GetInstructionAtIndex(branch_index);
-size_t last_inst_size = last_inst->GetOpcode().GetByteSize();
-run_to_address = last_inst->GetAddress();
-run_to_address.Slide(last_inst_size);
-}
-else if (branch_index - pc_index > 1)
-{
-run_to_address = 
instructions->GetInstructionAtIndex(branch_index)->GetAddress();
 }
 
-if (run_to_address.IsValid())
+if (branch_index - pc_index > 1)
 {
 const bool is_internal = true;
+run_to_address = 
instructions->GetInstructionAtIndex(branch_index)->GetAddress();
 m_next_branch_bp_sp = GetTarget().CreateBreakpoint(run_to_address, 
is_internal, false);
 if (m_next_branch_bp_sp)
 {


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

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Jim Ingham via lldb-commits]

If you can debug a failing case, and do whatever step operation got you to the 
wrong place, then run up to that step, and do:

(lldb) log enable -f  lldb step

and then do the step, then send me that log plus the disassembly for the 
function you were stepping in and the output of:

(lldb) image dump line-table 

for the source file you were stepping in.

I should be able to see from there why we were stepping to the wrong place.

Jim

> On Nov 12, 2015, at 4:03 PM, Zachary Turner  wrote:
> 
> The error messages are always different because the error message is printed 
> by the test.  I'm going to try to load up the executable for TestStepNoDebug 
> in the debugger and get a disassembly and do the step
> 
> On Thu, Nov 12, 2015 at 4:01 PM Jim Ingham  wrote:
> Is the line they stepped to - instead of the expected line - always line 0?
> 
> Jim
> 
> > On Nov 12, 2015, at 3:52 PM, Zachary Turner  wrote:
> >
> > Hi Jim,
> >
> > This breaks about 12 tests on Windows.  The patch looks simple, but this 
> > isn't really my area, is there anything I can give you to help diagnose 
> > what might be wrong?  The following tests fail:
> >
> > FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8 
> > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows zturner-win81 8 
> > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows 
> > zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, 
> > GenuineIntel)
> > FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows 
> > zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, 
> > GenuineIntel)
> > FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows zturner-win81 8 
> > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8 6.2.9200 
> > AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestFormatPropagation.py (Windows zturner-win81 8 
> > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestFrames.py (Windows zturner-win81 8 6.2.9200 AMD64 
> > Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestInlineStepping.py (Windows zturner-win81 8 
> > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestSBData.py (Windows zturner-win81 8 6.2.9200 AMD64 
> > Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestStepNoDebug.py (Windows zturner-win81 8 6.2.9200 
> > AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > FAIL: LLDB (suite) :: TestThreadJump.py (Windows zturner-win81 8 6.2.9200 
> > AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> >
> > And here's the error I get from one of the failing tests, although I don't 
> > know how much insight it provides.
> >
> > Traceback (most recent call last):
> >   File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", 
> > line 536, in wrapper
> > return func(self, *args, **kwargs)
> >   File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", 
> > line 2228, in dwarf_test_method
> > return attrvalue(self)
> >   File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", 
> > line 608, in wrapper
> > func(*args, **kwargs)
> >   File 
> > "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
> >  line 41, in test_step_in_with_python
> > self.do_step_in_past_nodebug()
> >   File 
> > "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
> >  line 105, in do_step_in_past_nodebug
> > self.hit_correct_line ("intermediate_return_value = 
> > called_from_nodebug_actual(some_value)")
> >   File 
> > "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
> >  line 57, in hit_correct_line
> > self.assertTrue (cur_line == target_line, "Stepped to line %d instead 
> > of expected %d with pattern '%s'."%(cur_line, target_line, pattern))
> > AssertionError: False is not True : Stepped to line 0 instead of expected 
> > 19 with pattern 'intermediate_return_value = 
> > called_from_nodebug_actual(some_value)'.
> > Config=i686-d:\src\llvmbuild\ninja_release\bin\clang.exe
> > Session info generated @ Thu Nov 12 15:44:43 2015
> > To rerun this test, issue the following command from the 'test' directory:
> >
> > If it's not obvious what the problem is, can we revert this until we figure 
> > it out and then reland it?
> >
> > On Thu, Nov 12, 2015 at 2:34 PM Jim Ingham via lldb-commits 
> >  wrote:
> > Author: jingham
> > Date: Thu Nov 12 16:32:09 2015
> > New Revision: 252963
> >
> > URL: http://llvm.org/viewvc/llvm-project?re

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Ying Chen via lldb-commits]

I reverted this patch for now.
Please resubmit if you have a fix.

Thanks,
Ying

On Thu, Nov 12, 2015 at 4:36 PM, Jim Ingham via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> If you can debug a failing case, and do whatever step operation got you to
> the wrong place, then run up to that step, and do:
>
> (lldb) log enable -f  lldb step
>
> and then do the step, then send me that log plus the disassembly for the
> function you were stepping in and the output of:
>
> (lldb) image dump line-table 
>
> for the source file you were stepping in.
>
> I should be able to see from there why we were stepping to the wrong place.
>
> Jim
>
> > On Nov 12, 2015, at 4:03 PM, Zachary Turner  wrote:
> >
> > The error messages are always different because the error message is
> printed by the test.  I'm going to try to load up the executable for
> TestStepNoDebug in the debugger and get a disassembly and do the step
> >
> > On Thu, Nov 12, 2015 at 4:01 PM Jim Ingham  wrote:
> > Is the line they stepped to - instead of the expected line - always line
> 0?
> >
> > Jim
> >
> > > On Nov 12, 2015, at 3:52 PM, Zachary Turner 
> wrote:
> > >
> > > Hi Jim,
> > >
> > > This breaks about 12 tests on Windows.  The patch looks simple, but
> this isn't really my area, is there anything I can give you to help
> diagnose what might be wrong?  The following tests fail:
> > >
> > > FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows zturner-win81
> 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8 6.2.9200
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestFormatPropagation.py (Windows zturner-win81
> 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestFrames.py (Windows zturner-win81 8 6.2.9200
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestInlineStepping.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestSBData.py (Windows zturner-win81 8 6.2.9200
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestStepNoDebug.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestThreadJump.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > >
> > > And here's the error I get from one of the failing tests, although I
> don't know how much insight it provides.
> > >
> > > Traceback (most recent call last):
> > >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
> 536, in wrapper
> > > return func(self, *args, **kwargs)
> > >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
> 2228, in dwarf_test_method
> > > return attrvalue(self)
> > >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
> 608, in wrapper
> > > func(*args, **kwargs)
> > >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
> line 41, in test_step_in_with_python
> > > self.do_step_in_past_nodebug()
> > >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
> line 105, in do_step_in_past_nodebug
> > > self.hit_correct_line ("intermediate_return_value =
> called_from_nodebug_actual(some_value)")
> > >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
> line 57, in hit_correct_line
> > > self.assertTrue (cur_line == target_line, "Stepped to line %d
> instead of expected %d with pattern '%s'."%(cur_line, target_line, pattern))
> > > AssertionError: False is not True : Stepped to line 0 instead of
> expected 19 with pattern 'intermediate_return_value =
> called_from_nodebug_actual(some_value)'.
> > > Config=i686-d:\src\llvmbuild\ninja_release\bin\clang.exe
> > > Session info generated @ Thu Nov 12 15:44:43 2015
> > > To rerun this test, issue the following command from the 'test'
> directory:
> > >
> > > If it's not obvious what the problem is, can we revert this until we
> figure it out and then reland

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Zachary Turner via lldb-commits]

I'm going to try the "with patch" version again with logging enabled as you
suggest.  Will update soon

On Thu, Nov 12, 2015 at 4:36 PM Jim Ingham  wrote:

> If you can debug a failing case, and do whatever step operation got you to
> the wrong place, then run up to that step, and do:
>
> (lldb) log enable -f  lldb step
>
> and then do the step, then send me that log plus the disassembly for the
> function you were stepping in and the output of:
>
> (lldb) image dump line-table 
>
> for the source file you were stepping in.
>
> I should be able to see from there why we were stepping to the wrong place.
>
> Jim
>
> > On Nov 12, 2015, at 4:03 PM, Zachary Turner  wrote:
> >
> > The error messages are always different because the error message is
> printed by the test.  I'm going to try to load up the executable for
> TestStepNoDebug in the debugger and get a disassembly and do the step
> >
> > On Thu, Nov 12, 2015 at 4:01 PM Jim Ingham  wrote:
> > Is the line they stepped to - instead of the expected line - always line
> 0?
> >
> > Jim
> >
> > > On Nov 12, 2015, at 3:52 PM, Zachary Turner 
> wrote:
> > >
> > > Hi Jim,
> > >
> > > This breaks about 12 tests on Windows.  The patch looks simple, but
> this isn't really my area, is there anything I can give you to help
> diagnose what might be wrong?  The following tests fail:
> > >
> > > FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows zturner-win81
> 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8 6.2.9200
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestFormatPropagation.py (Windows zturner-win81
> 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestFrames.py (Windows zturner-win81 8 6.2.9200
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestInlineStepping.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestSBData.py (Windows zturner-win81 8 6.2.9200
> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestStepNoDebug.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestThreadJump.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > >
> > > And here's the error I get from one of the failing tests, although I
> don't know how much insight it provides.
> > >
> > > Traceback (most recent call last):
> > >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
> 536, in wrapper
> > > return func(self, *args, **kwargs)
> > >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
> 2228, in dwarf_test_method
> > > return attrvalue(self)
> > >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
> 608, in wrapper
> > > func(*args, **kwargs)
> > >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
> line 41, in test_step_in_with_python
> > > self.do_step_in_past_nodebug()
> > >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
> line 105, in do_step_in_past_nodebug
> > > self.hit_correct_line ("intermediate_return_value =
> called_from_nodebug_actual(some_value)")
> > >   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
> line 57, in hit_correct_line
> > > self.assertTrue (cur_line == target_line, "Stepped to line %d
> instead of expected %d with pattern '%s'."%(cur_line, target_line, pattern))
> > > AssertionError: False is not True : Stepped to line 0 instead of
> expected 19 with pattern 'intermediate_return_value =
> called_from_nodebug_actual(some_value)'.
> > > Config=i686-d:\src\llvmbuild\ninja_release\bin\clang.exe
> > > Session info generated @ Thu Nov 12 15:44:43 2015
> > > To rerun this test, issue the following command from the 'test'
> directory:
> > >
> > > If it's not obvious what the problem is, can we revert this until we
> figure it out and then reland it?
> > >
> > > On Thu, 

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Zachary Turner via lldb-commits]

Here's the log.  Disassembly of those two functions was posted earlier.
Let me know if you need anything else:

ThreadPlanStepRange::SetNextBranchBreakpoint - Setting breakpoint -1 (site
2) to run to address 0x94902e
Thread::PushPlan(0x0654FBB0): "Stepping in through line with-debug.c:12.",
tid = 0xb6b0.
Process::PrivateResume() m_stop_id = 2, public state: stopped private
state: stopped
Thread::PushPlan(0x0654FBB0): "Single stepping past breakpoint site 1 at
0x94902b", tid = 0xb6b0.
lldb_private::ThreadPlan::WillResume Thread #1 (0x0654FBB0): tid = 0xb6b0,
pc = 0x0094902b, sp = 0x00a5f8d8, fp = 0x00a5f8e8, plan = 'Step over
breakpoint trap', state = stepping, stop others = 1
Process thinks the process has resumed.
Current Plan for thread 1(0654FBB0) (0xb6b0, stepping): Step over
breakpoint trap being asked whether we should report run.

ThreadList::lldb_private::ThreadList::ShouldStop: 1 threads, 1 unsuspended
threads
Thread::lldb_private::Thread::ShouldStop(0654FBB0) for tid = 0xb6b0 0xb6b0,
pc = 0x0094902e
 Thread::ShouldStop Begin 
Plan stack initial state:
  thread #1: tid = 0xb6b0:
Active plan stack:
  Element 0: Base thread plan.
  Element 1: Stepping in through line with-debug.c:12 using
ranges:[0x0094902b-0x0094902e).
  Element 2: Single stepping past breakpoint site 1 at 0x94902b

Plan Step over breakpoint trap explains stop, auto-continue 1.
Plan Step over breakpoint trap should stop: 0.
Completed step over breakpoint plan.
Popping plan: "Step over breakpoint trap", tid = 0xb6b0.
ThreadPlanStepInRange reached 0x0094902e.
Step range plan stepped to another range of same line:
[0x0094902e-0x00949040), file =
D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\with-debug.c,
line = 12, column = 3
Plan Step Range stepping in should stop: 0.
Plan stack final state:
  thread #1: tid = 0xb6b0:
Active plan stack:
  Element 0: Base thread plan.
  Element 1: Stepping in through line with-debug.c:12 using ranges: 0:
[0x0094902b-0x0094902e) 1: [0x0094902e-0x00949040).
Completed Plan Stack:
  Element 0: Single stepping past breakpoint site 1 at 0x94902b

 Thread::ShouldStop End (returning 0) 
ThreadList::lldb_private::ThreadList::ShouldStop overall should_stop = 0
ThreadList::lldb_private::ThreadList::ShouldReportStop 1 threads
Thread::ShouldReportStop() tid = 0xb6b0: returning vote  for complete
stack's back plan
ThreadPlan::ShouldReportStop() returning vote: no
ThreadList::lldb_private::ThreadList::ShouldReportStop returning no
Process::PrivateResume() m_stop_id = 3, public state: running private
state: stopped
Thread::PushPlan(0x0654FBB0): "Single stepping past breakpoint site 2 at
0x94902e", tid = 0xb6b0.
lldb_private::ThreadPlan::WillResume Thread #1 (0x0654FBB0): tid = 0xb6b0,
pc = 0x0094902e, sp = 0x00a5f8d8, fp = 0x00a5f8e8, plan = 'Step over
breakpoint trap', state = stepping, stop others = 1
Process thinks the process has resumed.

ThreadList::lldb_private::ThreadList::ShouldStop: 1 threads, 1 unsuspended
threads
Thread::lldb_private::Thread::ShouldStop(0654FBB0) for tid = 0xb6b0 0xb6b0,
pc = 0x00949031
 Thread::ShouldStop Begin 
Plan stack initial state:
  thread #1: tid = 0xb6b0:
Active plan stack:
  Element 0: Base thread plan.
  Element 1: Stepping in through line with-debug.c:12 using ranges: 0:
[0x0094902b-0x0094902e) 1: [0x0094902e-0x00949040).
  Element 2: Single stepping past breakpoint site 2 at 0x94902e

Plan Step over breakpoint trap explains stop, auto-continue 1.
Plan Step over breakpoint trap should stop: 0.
Completed step over breakpoint plan.
Popping plan: "Step over breakpoint trap", tid = 0xb6b0.
ThreadPlanStepInRange reached 0x00949031.
Plan Step Range stepping in should stop: 0.
Plan stack final state:
  thread #1: tid = 0xb6b0:
Active plan stack:
  Element 0: Base thread plan.
  Element 1: Stepping in through line with-debug.c:12 using ranges: 0:
[0x0094902b-0x0094902e) 1: [0x0094902e-0x00949040).
Completed Plan Stack:
  Element 0: Single stepping past breakpoint site 2 at 0x94902e

 Thread::ShouldStop End (returning 0) 
ThreadList::lldb_private::ThreadList::ShouldStop overall should_stop = 0
ThreadList::lldb_private::ThreadList::ShouldReportStop 1 threads
Thread::ShouldReportStop() tid = 0xb6b0: returning vote  for complete
stack's back plan
ThreadPlan::ShouldReportStop() returning vote: no
ThreadList::lldb_private::ThreadList::ShouldReportStop returning no
Process::PrivateResume() m_stop_id = 4, public state: running private
state: stopped
lldb_private::ThreadPlan::WillResume Thread #1 (0x0654FBB0): tid = 0xb6b0,
pc = 0x00949031, sp = 0x00a5f8e8, fp = 0x00a5f8e8, plan = 'Step Range
stepping in', state = running, stop others = 1
Process thinks the process has resumed.
Removing next branch breakpoint: -1.


On Thu, Nov 12, 2015 at 4:40 PM Zachary Turner  wrote:

> I'm going to try the "with

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Zachary Turner via lldb-commits]

I went ahead and created two logs.  One for the working case and one for
the non-working case.  I'm attaching instead of inlining, let me know if
this doesn't work:

Might help to diff them.


doesnt_work.log
Description: Binary data


works.log
Description: Binary data
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Zachary Turner via lldb-commits]

Ahh, seems it wasn't just Windows that was affected by this.  Makes me feel
a little better :)

Posting the link to the buildbot failures here so that Jim can get full
logs if it helps.
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391

On Thu, Nov 12, 2015 at 4:37 PM Ying Chen  wrote:

> I reverted this patch for now.
> Please resubmit if you have a fix.
>
> Thanks,
> Ying
>
> On Thu, Nov 12, 2015 at 4:36 PM, Jim Ingham via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> If you can debug a failing case, and do whatever step operation got you
>> to the wrong place, then run up to that step, and do:
>>
>> (lldb) log enable -f  lldb step
>>
>> and then do the step, then send me that log plus the disassembly for the
>> function you were stepping in and the output of:
>>
>> (lldb) image dump line-table 
>>
>> for the source file you were stepping in.
>>
>> I should be able to see from there why we were stepping to the wrong
>> place.
>>
>> Jim
>>
>> > On Nov 12, 2015, at 4:03 PM, Zachary Turner  wrote:
>> >
>> > The error messages are always different because the error message is
>> printed by the test.  I'm going to try to load up the executable for
>> TestStepNoDebug in the debugger and get a disassembly and do the step
>> >
>> > On Thu, Nov 12, 2015 at 4:01 PM Jim Ingham  wrote:
>> > Is the line they stepped to - instead of the expected line - always
>> line 0?
>> >
>> > Jim
>> >
>> > > On Nov 12, 2015, at 3:52 PM, Zachary Turner 
>> wrote:
>> > >
>> > > Hi Jim,
>> > >
>> > > This breaks about 12 tests on Windows.  The patch looks simple, but
>> this isn't really my area, is there anything I can give you to help
>> diagnose what might be wrong?  The following tests fail:
>> > >
>> > > FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8
>> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>> > > FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows
>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>> GenuineIntel)
>> > > FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows
>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>> GenuineIntel)
>> > > FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows
>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>> GenuineIntel)
>> > > FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows
>> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
>> GenuineIntel)
>> > > FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8
>> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>> > > FAIL: LLDB (suite) :: TestFormatPropagation.py (Windows zturner-win81
>> 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>> > > FAIL: LLDB (suite) :: TestFrames.py (Windows zturner-win81 8 6.2.9200
>> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>> > > FAIL: LLDB (suite) :: TestInlineStepping.py (Windows zturner-win81 8
>> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>> > > FAIL: LLDB (suite) :: TestSBData.py (Windows zturner-win81 8 6.2.9200
>> AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>> > > FAIL: LLDB (suite) :: TestStepNoDebug.py (Windows zturner-win81 8
>> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>> > > FAIL: LLDB (suite) :: TestThreadJump.py (Windows zturner-win81 8
>> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
>> > >
>> > > And here's the error I get from one of the failing tests, although I
>> don't know how much insight it provides.
>> > >
>> > > Traceback (most recent call last):
>> > >   File
>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
>> 536, in wrapper
>> > > return func(self, *args, **kwargs)
>> > >   File
>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
>> 2228, in dwarf_test_method
>> > > return attrvalue(self)
>> > >   File
>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\lldbtest.py", line
>> 608, in wrapper
>> > > func(*args, **kwargs)
>> > >   File
>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
>> line 41, in test_step_in_with_python
>> > > self.do_step_in_past_nodebug()
>> > >   File
>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
>> line 105, in do_step_in_past_nodebug
>> > > self.hit_correct_line ("intermediate_return_value =
>> called_from_nodebug_actual(some_value)")
>> > >   File
>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\step-avoids-no-debug\TestStepNoDebug.py",
>> line 57, in hit_correct_line
>> > > self.assertTrue (cur_line == target_line, "Stepped to line %d
>> instead of expected %d with pattern '%s'."%(cur_line, target_line, pattern))
>> > > AssertionError: False is not True : Stepped to

[Lldb-commits] [lldb] r252992 - Delete `PyObjectToString` and use `PythonObject::Str()`.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Thu Nov 12 19:24:25 2015
New Revision: 252992

URL: http://llvm.org/viewvc/llvm-project?rev=252992&view=rev
Log:
Delete `PyObjectToString` and use `PythonObject::Str()`.

The latter function, from PythonDataObjects, is Python 3 ready and
the former was not.

Modified:
lldb/trunk/scripts/Python/python-wrapper.swig

Modified: lldb/trunk/scripts/Python/python-wrapper.swig
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/python-wrapper.swig?rev=252992&r1=252991&r2=252992&view=diff
==
--- lldb/trunk/scripts/Python/python-wrapper.swig (original)
+++ lldb/trunk/scripts/Python/python-wrapper.swig Thu Nov 12 19:24:25 2015
@@ -107,33 +107,6 @@ LLDBSwigPythonWatchpointCallbackFunction
 return stop_at_watchpoint;
 }
 
-bool
-PyObjectToString (PyObject* object,
-  std::string& retval)
-{
-retval.clear();
-bool was_ok = false;
-if (object != NULL && object != Py_None)
-{
-if (PyString_Check(object))
-{
-retval.assign(PyString_AsString(object));
-was_ok = true;
-}
-else
-{
-PyObject* value_as_string = PyObject_Str(object);
-if (value_as_string && value_as_string != Py_None && 
PyString_Check(value_as_string))
-{
-retval.assign(PyString_AsString(value_as_string));
-was_ok = true;
-}
-Py_XDECREF(value_as_string);
-}
-}
-return was_ok;
-}
-
 SWIGEXPORT bool
 LLDBSwigPythonCallTypeScript
 (
@@ -199,7 +172,7 @@ LLDBSwigPythonCallTypeScript
 else
 result = pfunc(value_arg,dict);
 
-PyObjectToString(result.get(), retval);
+retval = result.Str().GetString().str();
 
 return true;
 }
@@ -763,10 +736,9 @@ std::string& output)
 PythonObject process_arg(PyRefType::Owned, 
SBTypeToSWIGWrapper(process_sb));
 auto result = pfunc(process_arg, dict);
 
-if (PyObjectToString(result.get(), output))
-return true;
+output = result.Str().GetString().str();
 
-return false;
+return true;
 }
 
 SWIGEXPORT bool
@@ -794,10 +766,9 @@ std::string& output)
 PythonObject thread_arg(PyRefType::Owned, SBTypeToSWIGWrapper(thread_sb));
 auto result = pfunc(thread_arg, dict);
 
-if (PyObjectToString(result.get(), output))
-return true;
+output = result.Str().GetString().str();
 
-return false;
+return true;
 }
 
 SWIGEXPORT bool
@@ -824,10 +795,10 @@ std::string& output)
 lldb::SBTarget target_sb(target);
 PythonObject target_arg(PyRefType::Owned, SBTypeToSWIGWrapper(target_sb));
 auto result = pfunc(target_arg, dict);
-if (PyObjectToString(result.get(),output))
-return true;
 
-return false;
+output = result.Str().GetString().str();
+
+return true;
 }
 
 SWIGEXPORT bool
@@ -855,10 +826,9 @@ std::string& output)
 PythonObject frame_arg(PyRefType::Owned, SBTypeToSWIGWrapper(frame_sb));
 auto result = pfunc(frame_arg, dict);
 
-if (PyObjectToString(result.get(),output))
-return true;
+output = result.Str().GetString().str();
 
-return false;
+return true;
 }
 
 SWIGEXPORT bool
@@ -886,10 +856,9 @@ std::string& output)
 PythonObject value_arg(PyRefType::Owned, SBTypeToSWIGWrapper(value_sb));
 auto result = pfunc(value_arg, dict);
 
-if (PyObjectToString(result.get(), output))
-return true;
+output = result.Str().GetString().str();
 
-return false;
+return true;
 }
 
 SWIGEXPORT bool


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

[Lldb-commits] [lldb] r252995 - Update .gitignore to exclude pyproj folder (used for Python IDE)

[Zachary Turner via lldb-commits]

Author: zturner
Date: Thu Nov 12 19:24:58 2015
New Revision: 252995

URL: http://llvm.org/viewvc/llvm-project?rev=252995&view=rev
Log:
Update .gitignore to exclude pyproj folder (used for Python IDE)

Modified:
lldb/trunk/.gitignore

Modified: lldb/trunk/.gitignore
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/.gitignore?rev=252995&r1=252994&r2=252995&view=diff
==
--- lldb/trunk/.gitignore (original)
+++ lldb/trunk/.gitignore Thu Nov 12 19:24:58 2015
@@ -29,6 +29,7 @@ DerivedData/
 .remote-build.conf
 
 build/
+pyproj/
 llvm-build/
 *xcuserdata
 xcshareddata/


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

[Lldb-commits] [lldb] r252994 - Introduce a `PythonExceptionState` class.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Thu Nov 12 19:24:52 2015
New Revision: 252994

URL: http://llvm.org/viewvc/llvm-project?rev=252994&view=rev
Log:
Introduce a `PythonExceptionState` class.

This is a helper class which supports a number of
features including exception to string formatting with
backtrace handling and auto-restore of exception state
upon scope exit.

Additionally, unit tests are included to verify the
feature set of the class.

Added:
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.h
lldb/trunk/unittests/ScriptInterpreter/Python/PythonExceptionStateTests.cpp
Modified:
lldb/trunk/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt

lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
lldb/trunk/unittests/ScriptInterpreter/Python/CMakeLists.txt

Modified: lldb/trunk/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt?rev=252994&r1=252993&r2=252994&view=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt (original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt Thu Nov 
12 19:24:52 2015
@@ -1,4 +1,5 @@
 add_lldb_library(lldbPluginScriptInterpreterPython
   PythonDataObjects.cpp
+  PythonExceptionState.cpp
   ScriptInterpreterPython.cpp
   )

Added: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp?rev=252994&view=auto
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp 
(added)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp 
Thu Nov 12 19:24:52 2015
@@ -0,0 +1,195 @@
+//===-- PythonExceptionState.cpp *- C++ 
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "lldb-python.h"
+#include "PythonExceptionState.h"
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace lldb_private;
+
+PythonExceptionState::PythonExceptionState(bool restore_on_exit)
+: m_restore_on_exit(restore_on_exit)
+{
+Acquire(restore_on_exit);
+}
+
+PythonExceptionState::~PythonExceptionState()
+{
+if (m_restore_on_exit)
+Restore();
+}
+
+void
+PythonExceptionState::Acquire(bool restore_on_exit)
+{
+// If a state is already acquired, the user needs to decide whether they
+// want to discard or restore it.  Don't allow the potential silent
+// loss of a valid state.
+assert(!IsError());
+
+if (!HasErrorOccurred())
+return;
+
+PyObject *py_type = nullptr;
+PyObject *py_value = nullptr;
+PyObject *py_traceback = nullptr;
+PyErr_Fetch(&py_type, &py_value, &py_traceback);
+// PyErr_Fetch clears the error flag.
+assert(!HasErrorOccurred());
+
+// Ownership of the objects returned by `PyErr_Fetch` is transferred
+// to us.
+m_type.Reset(PyRefType::Owned, py_type);
+m_value.Reset(PyRefType::Owned, py_value);
+m_traceback.Reset(PyRefType::Owned, py_traceback);
+}
+
+void
+PythonExceptionState::Restore()
+{
+if (m_type.IsValid())
+{
+// The documentation for PyErr_Restore says "Do not pass a null type 
and
+// non-null value or traceback.  So only restore if type was non-null
+// to begin with.  In this case we're passing ownership back to Python
+// so release them all.
+PyErr_Restore(m_type.release(), m_value.release(), 
m_traceback.release());
+}
+
+// After we restore, we should not hold onto the exception state.  Demand 
that
+// it be re-acquired.
+Discard();
+}
+
+void
+PythonExceptionState::Discard()
+{
+m_type.Reset();
+m_value.Reset();
+m_traceback.Reset();
+}
+
+bool
+PythonExceptionState::HasErrorOccurred()
+{
+return PyErr_Occurred();
+}
+
+bool
+PythonExceptionState::IsError() const
+{
+return m_type.IsValid() || m_value.IsValid() || m_traceback.IsValid();
+}
+
+PythonObject
+PythonExceptionState::GetType() const
+{
+return m_type;
+}
+
+PythonObject
+PythonExceptionState::GetValue() const
+{
+return m_value;
+}
+
+PythonObject
+PythonExceptionState::GetTraceback() const
+{
+return m_traceback;
+}
+
+std::string
+PythonExceptionState::Format() const
+{
+// Don't allow this function to modify the error state.
+PythonExceptionState state(true);
+
+std::string backtrace = ReadBackt

[Lldb-commits] [lldb] r252993 - gtest - Make a `PythonTestSuite` base class for setup / teardown.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Thu Nov 12 19:24:35 2015
New Revision: 252993

URL: http://llvm.org/viewvc/llvm-project?rev=252993&view=rev
Log:
gtest - Make a `PythonTestSuite` base class for setup / teardown.

This allows other potential unit test suites (of which one is
forthcoming in a subsequent patch) to re-use the same initialization
and teardown of the GIL.

Added:
lldb/trunk/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
lldb/trunk/unittests/ScriptInterpreter/Python/PythonTestSuite.h
Modified:
lldb/trunk/unittests/ScriptInterpreter/Python/CMakeLists.txt
lldb/trunk/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp

Modified: lldb/trunk/unittests/ScriptInterpreter/Python/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/ScriptInterpreter/Python/CMakeLists.txt?rev=252993&r1=252992&r2=252993&view=diff
==
--- lldb/trunk/unittests/ScriptInterpreter/Python/CMakeLists.txt (original)
+++ lldb/trunk/unittests/ScriptInterpreter/Python/CMakeLists.txt Thu Nov 12 
19:24:35 2015
@@ -1,5 +1,6 @@
 add_lldb_unittest(ScriptInterpreterPythonTests
   PythonDataObjectsTests.cpp
+  PythonTestSuite.cpp
   )
 
   target_link_libraries(ScriptInterpreterPythonTests 
lldbPluginScriptInterpreterPython ${PYTHON_LIBRARY})

Modified: 
lldb/trunk/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp?rev=252993&r1=252992&r2=252993&view=diff
==
--- lldb/trunk/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp 
(original)
+++ lldb/trunk/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp 
Thu Nov 12 19:24:35 2015
@@ -16,25 +16,17 @@
 #include "Plugins/ScriptInterpreter/Python/PythonDataObjects.h"
 #include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h"
 
+#include "PythonTestSuite.h"
+
 using namespace lldb_private;
 
-class PythonDataObjectsTest : public testing::Test
+class PythonDataObjectsTest : public PythonTestSuite
 {
   public:
 void
 SetUp() override
 {
-HostInfoBase::Initialize();
-// ScriptInterpreterPython::Initialize() depends on HostInfo being
-// initializedso it can compute the python directory etc.
-ScriptInterpreterPython::Initialize();
-
-// Although we don't care about concurrency for the purposes of running
-// this test suite, Python requires the GIL to be locked even for
-// deallocating memory, which can happen when you call Py_DECREF or
-// Py_INCREF.  So acquire the GIL for the entire duration of this
-// test suite.
-m_gil_state = PyGILState_Ensure();
+PythonTestSuite::SetUp();
 
 PythonString sys_module("sys");
 m_sys_module.Reset(PyRefType::Owned, 
PyImport_Import(sys_module.get()));
@@ -48,18 +40,14 @@ class PythonDataObjectsTest : public tes
 m_sys_module.Reset();
 m_main_module.Reset();
 m_builtins_module.Reset();
-PyGILState_Release(m_gil_state);
 
-ScriptInterpreterPython::Terminate();
+PythonTestSuite::TearDown();
 }
 
   protected:
 PythonModule m_sys_module;
 PythonModule m_main_module;
 PythonModule m_builtins_module;
-
-  private:
-PyGILState_STATE m_gil_state;
 };
 
 TEST_F(PythonDataObjectsTest, TestOwnedReferences)

Added: lldb/trunk/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp?rev=252993&view=auto
==
--- lldb/trunk/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp (added)
+++ lldb/trunk/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp Thu Nov 
12 19:24:35 2015
@@ -0,0 +1,42 @@
+//===-- PythonTestSuite.cpp -*- C++ 
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "gtest/gtest.h"
+
+#include "lldb/Host/HostInfo.h"
+#include "Plugins/ScriptInterpreter/Python/lldb-python.h"
+#include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h"
+
+#include "PythonTestSuite.h"
+
+using namespace lldb_private;
+
+void
+PythonTestSuite::SetUp()
+{
+HostInfoBase::Initialize();
+// ScriptInterpreterPython::Initialize() depends on HostInfo being
+// initializedso it can compute the python directory etc.
+ScriptInterpreterPython::Initialize();
+
+// Although we don't care about concurrency for the purposes of running
+// this test suite, Python requires the GIL to be loc

[Lldb-commits] [lldb] r252998 - Add PythonExceptionState.cppto the xocde project file.

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Thu Nov 12 19:43:49 2015
New Revision: 252998

URL: http://llvm.org/viewvc/llvm-project?rev=252998&view=rev
Log:
Add PythonExceptionState.cppto the xocde project file.

Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=252998&r1=252997&r2=252998&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Thu Nov 12 19:43:49 2015
@@ -902,6 +902,8 @@
AFB3D2801AC262AB003B4B30 /* MICmdCmdGdbShow.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = AFB3D27E1AC262AB003B4B30 /* MICmdCmdGdbShow.cpp 
*/; };
AFC234081AF85CE000CDE8B6 /* CommandObjectLanguage.cpp in 
CopyFiles */ = {isa = PBXBuildFile; fileRef = AFC234061AF85CE000CDE8B6 /* 
CommandObjectLanguage.cpp */; };
AFC234091AF85CE100CDE8B6 /* CommandObjectLanguage.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = AFC234061AF85CE000CDE8B6 /* 
CommandObjectLanguage.cpp */; };
+   AFCB2BBD1BF577F40018B553 /* PythonExceptionState.cpp in Sources 
*/ = {isa = PBXBuildFile; fileRef = AFCB2BBB1BF577F40018B553 /* 
PythonExceptionState.cpp */; };
+   AFCB2BBE1BF577F40018B553 /* PythonExceptionState.h in Headers 
*/ = {isa = PBXBuildFile; fileRef = AFCB2BBC1BF577F40018B553 /* 
PythonExceptionState.h */; };
AFDCDBCB19DD0F42005EA55E /* SBExecutionContext.h in Headers */ 
= {isa = PBXBuildFile; fileRef = 940B02F419DC96CB00AD0F52 /* 
SBExecutionContext.h */; settings = {ATTRIBUTES = (Public, ); }; };
AFDFDFD119E34D3400EAE509 /* ConnectionFileDescriptorPosix.cpp 
in Sources */ = {isa = PBXBuildFile; fileRef = AFDFDFD019E34D3400EAE509 /* 
ConnectionFileDescriptorPosix.cpp */; };
AFEC3362194A8ABA00FF05C6 /* StructuredData.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = AFEC3361194A8ABA00FF05C6 /* StructuredData.cpp 
*/; };
@@ -2825,6 +2827,8 @@
AFB3D27F1AC262AB003B4B30 /* MICmdCmdGdbShow.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
MICmdCmdGdbShow.h; path = "tools/lldb-mi/MICmdCmdGdbShow.h"; sourceTree = 
SOURCE_ROOT; };
AFC234061AF85CE000CDE8B6 /* CommandObjectLanguage.cpp */ = {isa 
= PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = CommandObjectLanguage.cpp; path = 
source/Commands/CommandObjectLanguage.cpp; sourceTree = ""; };
AFC234071AF85CE000CDE8B6 /* CommandObjectLanguage.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
CommandObjectLanguage.h; path = source/Commands/CommandObjectLanguage.h; 
sourceTree = ""; };
+   AFCB2BBB1BF577F40018B553 /* PythonExceptionState.cpp */ = {isa 
= PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = PythonExceptionState.cpp; path = 
ScriptInterpreter/Python/PythonExceptionState.cpp; sourceTree = ""; };
+   AFCB2BBC1BF577F40018B553 /* PythonExceptionState.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; name = 
PythonExceptionState.h; path = ScriptInterpreter/Python/PythonExceptionState.h; 
sourceTree = ""; };
AFDFDFD019E34D3400EAE509 /* ConnectionFileDescriptorPosix.cpp 
*/ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = 
sourcecode.cpp.cpp; path = ConnectionFileDescriptorPosix.cpp; sourceTree = 
""; };
AFEC3361194A8ABA00FF05C6 /* StructuredData.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = StructuredData.cpp; path = source/Core/StructuredData.cpp; sourceTree = 
""; };
AFF87C86150FF669000E1742 /* com.apple.debugserver.plist */ = 
{isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = text.plist.xml; 
name = com.apple.debugserver.plist; path = 
tools/debugserver/source/com.apple.debugserver.plist; sourceTree = ""; };
@@ -5172,6 +5176,8 @@
3FBA69E21B60672A0008F44A /* lldb-python.h */,
3FBA69E31B60672A0008F44A /* 
PythonDataObjects.cpp */,
3FBA69E41B60672A0008F44A /* PythonDataObjects.h 
*/,
+   AFCB2BBB1BF577F40018B553 /* 
PythonExceptionState.cpp */,
+   AFCB2BBC1BF577F40018B553 /* 
PythonExceptionState.h */,
3FBA69E51B60672A0008F44A /* 
ScriptInterpreterPython.cpp */,
3FBA69E61B60672A0008F44A /* 
ScriptInterpreterPython.h */,
);
@@ -5893,6 +5899,7 @@
AF8AD63A1BEC28C400150209 /* 
PlatformRemoteAppleWatch.h in Headers */,
2579066

[Lldb-commits] [lldb] r253002 - Fix a bug in PythonExceptionState and add unittest coverage.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Thu Nov 12 19:50:19 2015
New Revision: 253002

URL: http://llvm.org/viewvc/llvm-project?rev=253002&view=rev
Log:
Fix a bug in PythonExceptionState and add unittest coverage.

I forgot to reset the restore flag when calling member function
`Acquire`.  The newly added unittest should cover this case.

Modified:
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.h
lldb/trunk/unittests/ScriptInterpreter/Python/PythonExceptionStateTests.cpp

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp?rev=253002&r1=253001&r2=253002&view=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp 
(original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.cpp 
Thu Nov 12 19:50:19 2015
@@ -50,6 +50,7 @@ PythonExceptionState::Acquire(bool resto
 m_type.Reset(PyRefType::Owned, py_type);
 m_value.Reset(PyRefType::Owned, py_value);
 m_traceback.Reset(PyRefType::Owned, py_traceback);
+m_restore_on_exit = restore_on_exit;
 }
 
 void
@@ -77,6 +78,15 @@ PythonExceptionState::Discard()
 m_traceback.Reset();
 }
 
+void
+PythonExceptionState::Reset()
+{
+if (m_restore_on_exit)
+Restore();
+else
+Discard();
+}
+
 bool
 PythonExceptionState::HasErrorOccurred()
 {

Modified: 
lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.h?rev=253002&r1=253001&r2=253002&view=diff
==
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.h 
(original)
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/PythonExceptionState.h 
Thu Nov 12 19:50:19 2015
@@ -30,6 +30,9 @@ class PythonExceptionState
 void
 Discard();
 
+void
+Reset();
+
 static bool
 HasErrorOccurred();
 

Modified: 
lldb/trunk/unittests/ScriptInterpreter/Python/PythonExceptionStateTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/ScriptInterpreter/Python/PythonExceptionStateTests.cpp?rev=253002&r1=253001&r2=253002&view=diff
==
--- lldb/trunk/unittests/ScriptInterpreter/Python/PythonExceptionStateTests.cpp 
(original)
+++ lldb/trunk/unittests/ScriptInterpreter/Python/PythonExceptionStateTests.cpp 
Thu Nov 12 19:50:19 2015
@@ -79,6 +79,33 @@ TEST_F(PythonExceptionStateTest, TestDis
 EXPECT_FALSE(PythonExceptionState::HasErrorOccurred());
 }
 
+TEST_F(PythonExceptionStateTest, TestResetSemantics)
+{
+PyErr_Clear();
+
+// Resetting when auto-restore is true should restore.
+RaiseException();
+PythonExceptionState error(true);
+EXPECT_TRUE(error.IsError());
+EXPECT_FALSE(PythonExceptionState::HasErrorOccurred());
+error.Reset();
+EXPECT_FALSE(error.IsError());
+EXPECT_TRUE(PythonExceptionState::HasErrorOccurred());
+
+PyErr_Clear();
+
+// Resetting when auto-restore is false should discard.
+RaiseException();
+PythonExceptionState error2(false);
+EXPECT_TRUE(error2.IsError());
+EXPECT_FALSE(PythonExceptionState::HasErrorOccurred());
+error2.Reset();
+EXPECT_FALSE(error2.IsError());
+EXPECT_FALSE(PythonExceptionState::HasErrorOccurred());
+
+PyErr_Clear();
+}
+
 TEST_F(PythonExceptionStateTest, TestManualRestoreSemantics)
 {
 PyErr_Clear();
@@ -119,3 +146,29 @@ TEST_F(PythonExceptionStateTest, TestAut
 
 PyErr_Clear();
 }
+
+TEST_F(PythonExceptionStateTest, TestAutoRestoreChanged)
+{
+// Test that if we re-acquire with different auto-restore semantics,
+// that the new semantics are respected.
+PyErr_Clear();
+
+RaiseException();
+PythonExceptionState error(false);
+EXPECT_TRUE(error.IsError());
+
+error.Reset();
+EXPECT_FALSE(error.IsError());
+EXPECT_FALSE(PythonExceptionState::HasErrorOccurred());
+
+RaiseException();
+error.Acquire(true);
+EXPECT_TRUE(error.IsError());
+EXPECT_FALSE(PythonExceptionState::HasErrorOccurred());
+
+error.Reset();
+EXPECT_FALSE(error.IsError());
+EXPECT_TRUE(PythonExceptionState::HasErrorOccurred());
+
+PyErr_Clear();
+}
\ No newline at end of file


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

[Lldb-commits] [lldb] r253004 - Add PythonTestSuite.cpp to project file for lldb-gtest.

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Thu Nov 12 20:02:30 2015
New Revision: 253004

URL: http://llvm.org/viewvc/llvm-project?rev=253004&view=rev
Log:
Add PythonTestSuite.cpp to project file for lldb-gtest.

Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=253004&r1=253003&r2=253004&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Thu Nov 12 20:02:30 2015
@@ -880,6 +880,7 @@
AF2BA6EC1A707E3400C5248A /* UriParser.cpp in Sources */ = {isa 
= PBXBuildFile; fileRef = 33064C991A5C7A330033D415 /* UriParser.cpp */; };
AF2BCA6C18C7EFDE005B4526 /* JITLoaderGDB.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = AF2BCA6918C7EFDE005B4526 /* JITLoaderGDB.cpp */; 
};
AF37E10A17C861F20061E18E /* ProcessRunLock.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = AF37E10917C861F20061E18E /* ProcessRunLock.cpp 
*/; };
+   AF45E1FE1BF57C8D000563EB /* PythonTestSuite.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = AF45E1FC1BF57C8D000563EB /* PythonTestSuite.cpp 
*/; };
AF45FDE518A1F3AC0007051C /* AppleGetThreadItemInfoHandler.cpp 
in Sources */ = {isa = PBXBuildFile; fileRef = AF45FDE318A1F3AC0007051C /* 
AppleGetThreadItemInfoHandler.cpp */; };
AF77E08F1A033C700096C0EA /* ABISysV_ppc.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = AF77E08D1A033C700096C0EA /* ABISysV_ppc.cpp */; 
};
AF77E0931A033C7F0096C0EA /* ABISysV_ppc64.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = AF77E0911A033C7F0096C0EA /* ABISysV_ppc64.cpp 
*/; };
@@ -2786,6 +2787,8 @@
AF3F54BF1B3BA5D500186E73 /* 
RegisterContextPOSIXProcessMonitor_powerpc.h */ = {isa = PBXFileReference; 
fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = 
RegisterContextPOSIXProcessMonitor_powerpc.h; sourceTree = ""; };
AF3F54C01B3BA5D500186E73 /* 
RegisterContextPOSIXProcessMonitor_x86.cpp */ = {isa = PBXFileReference; 
fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; path = 
RegisterContextPOSIXProcessMonitor_x86.cpp; sourceTree = ""; };
AF3F54C11B3BA5D500186E73 /* 
RegisterContextPOSIXProcessMonitor_x86.h */ = {isa = PBXFileReference; 
fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = 
RegisterContextPOSIXProcessMonitor_x86.h; sourceTree = ""; };
+   AF45E1FC1BF57C8D000563EB /* PythonTestSuite.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
path = PythonTestSuite.cpp; sourceTree = ""; };
+   AF45E1FD1BF57C8D000563EB /* PythonTestSuite.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = 
PythonTestSuite.h; sourceTree = ""; };
AF45FDE318A1F3AC0007051C /* AppleGetThreadItemInfoHandler.cpp 
*/ = {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = 
sourcecode.cpp.cpp; path = AppleGetThreadItemInfoHandler.cpp; sourceTree = 
""; };
AF45FDE418A1F3AC0007051C /* AppleGetThreadItemInfoHandler.h */ 
= {isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = 
sourcecode.c.h; path = AppleGetThreadItemInfoHandler.h; sourceTree = ""; 
};
AF68D2541255416E002FF25B /* RegisterContextLLDB.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = RegisterContextLLDB.cpp; path = Utility/RegisterContextLLDB.cpp; 
sourceTree = ""; };
@@ -3095,6 +3098,8 @@
children = (
2321F94C1BDD360F00BA9A93 /* CMakeLists.txt */,
2321F94D1BDD360F00BA9A93 /* 
PythonDataObjectsTests.cpp */,
+   AF45E1FC1BF57C8D000563EB /* PythonTestSuite.cpp 
*/,
+   AF45E1FD1BF57C8D000563EB /* PythonTestSuite.h 
*/,
);
path = Python;
sourceTree = "";
@@ -6305,6 +6310,7 @@
files = (
AEC6FFA01BE970A2007882C1 /* GoParserTest.cpp in 
Sources */,
239504E51BDD454B00963CEA /* UriParserTest.cpp 
in Sources */,
+   AF45E1FE1BF57C8D000563EB /* PythonTestSuite.cpp 
in Sources */,
239504DF1BDD453200963CEA /* SocketTest.cpp in 
Sources */,
239504E11BDD453E00963CEA /* TestArgs.cpp in 
Sources */,
239504E21BDD454500963CEA /* 
PythonDataObjectsTests.cpp in Sources */,


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

[Lldb-commits] [PATCH] D14631: [dwarf] Handle DWARF forms for address other than DW_FORM_GNU_addr_index and DW_FORM_addr.

[Dawn Perchik via lldb-commits]

dawn created this revision.
dawn added reviewers: tberghammer, clayborg, tfiala.
dawn added a subscriber: lldb-commits.
dawn set the repository for this revision to rL LLVM.

Other compilers (and older Clang compilers) use data4/data8 forms to specify 
addresses in DWARF.  This patch fixes lldb to correctly read the addresses in 
DWARF generated by those compilers.

Repository:
  rL LLVM

http://reviews.llvm.org/D14631

Files:
  source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp

Index: source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
===
--- source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
+++ source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
@@ -477,11 +477,10 @@
 {
 SymbolFileDWARF* symbol_file = m_cu->GetSymbolFileDWARF();
 
-if (m_form == DW_FORM_addr)
+if (m_form != DW_FORM_GNU_addr_index)
 return Unsigned();
 
 assert(m_cu);
-assert(m_form == DW_FORM_GNU_addr_index);
 
 if (!symbol_file)
 return 0;


Index: source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
===
--- source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
+++ source/Plugins/SymbolFile/DWARF/DWARFFormValue.cpp
@@ -477,11 +477,10 @@
 {
 SymbolFileDWARF* symbol_file = m_cu->GetSymbolFileDWARF();
 
-if (m_form == DW_FORM_addr)
+if (m_form != DW_FORM_GNU_addr_index)
 return Unsigned();
 
 assert(m_cu);
-assert(m_form == DW_FORM_GNU_addr_index);
 
 if (!symbol_file)
 return 0;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r253008 - Fix commit 252963 to work around a bug on some platforms where they don't

[Jim Ingham via lldb-commits]

Author: jingham
Date: Thu Nov 12 21:37:48 2015
New Revision: 253008

URL: http://llvm.org/viewvc/llvm-project?rev=253008&view=rev
Log:
Fix commit 252963 to work around a bug on some platforms where they don't 
correctly handle stepping over one breakpoint directly onto another breakpoint. 
 
This isn't fixing that bug, but rather just changing 252963 to not use 
breakpoints
if it is only stepping one instruction.

Modified:
lldb/trunk/source/Target/ThreadPlanStepRange.cpp

Modified: lldb/trunk/source/Target/ThreadPlanStepRange.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/ThreadPlanStepRange.cpp?rev=253008&r1=253007&r2=253008&view=diff
==
--- lldb/trunk/source/Target/ThreadPlanStepRange.cpp (original)
+++ lldb/trunk/source/Target/ThreadPlanStepRange.cpp Thu Nov 12 21:37:48 2015
@@ -389,13 +389,23 @@ ThreadPlanStepRange::SetNextBranchBreakp
 // If we didn't find a branch, run to the end of the range.
 if (branch_index == UINT32_MAX)
 {
-branch_index = instructions->GetSize() - 1;
+uint32_t last_index = instructions->GetSize() - 1;
+if (last_index - pc_index > 1)
+{
+InstructionSP last_inst = 
instructions->GetInstructionAtIndex(last_index);
+size_t last_inst_size = last_inst->GetOpcode().GetByteSize();
+run_to_address = last_inst->GetAddress();
+run_to_address.Slide(last_inst_size);
+}
+}
+else if (branch_index - pc_index > 1)
+{
+run_to_address = 
instructions->GetInstructionAtIndex(branch_index)->GetAddress();
 }
 
-if (branch_index - pc_index > 1)
+if (run_to_address.IsValid())
 {
 const bool is_internal = true;
-run_to_address = 
instructions->GetInstructionAtIndex(branch_index)->GetAddress();
 m_next_branch_bp_sp = GetTarget().CreateBreakpoint(run_to_address, 
is_internal, false);
 if (m_next_branch_bp_sp)
 {


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

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Jim Ingham via lldb-commits]

Okay, I think I fixed this, the fix is: r253008.  That passes cleanly on Linux 
for me, but I don't have a windows machine handy to test.

What was happening is that originally lldb had a bug where if you were stopped 
on a breakpoint and then the next instruction also had a breakpoint, the plan 
that was stepping over the breakpoint would see a stop reason of "trace" so it 
would think it knew why it stopped and would auto-continue, since that's what 
you do when you are doing "step over a breakpoint and keep going."  

I fixed this by having the lower layers of the process plugin correct the stop 
reason from trace to breakpoint when a trace ended up on another breakpoint, 
but apparently Linux and Windows don't have this fix.  That was done a while 
ago, so maybe they weren't around then, I have to think about that...

Anyway, the old code in ThreadPlanStepRange had a short-cut that if we only 
needed to go one instruction, it wouldn't do it with a breakpoint, but just 
stepi.  I didn't preserve that in the change I made, so we got into trouble.  
So for now I just put that short-cut back.

I wondered how this managed to cause so many Linux failures, but the OS X 
testsuite was clean...

Jim



> On Nov 12, 2015, at 4:57 PM, Zachary Turner  wrote:
> 
> Ahh, seems it wasn't just Windows that was affected by this.  Makes me feel a 
> little better :)
> 
> Posting the link to the buildbot failures here so that Jim can get full logs 
> if it helps.
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391
> 
> On Thu, Nov 12, 2015 at 4:37 PM Ying Chen  wrote:
> I reverted this patch for now.
> Please resubmit if you have a fix.
> 
> Thanks,
> Ying
> 
> On Thu, Nov 12, 2015 at 4:36 PM, Jim Ingham via lldb-commits 
>  wrote:
> If you can debug a failing case, and do whatever step operation got you to 
> the wrong place, then run up to that step, and do:
> 
> (lldb) log enable -f  lldb step
> 
> and then do the step, then send me that log plus the disassembly for the 
> function you were stepping in and the output of:
> 
> (lldb) image dump line-table 
> 
> for the source file you were stepping in.
> 
> I should be able to see from there why we were stepping to the wrong place.
> 
> Jim
> 
> > On Nov 12, 2015, at 4:03 PM, Zachary Turner  wrote:
> >
> > The error messages are always different because the error message is 
> > printed by the test.  I'm going to try to load up the executable for 
> > TestStepNoDebug in the debugger and get a disassembly and do the step
> >
> > On Thu, Nov 12, 2015 at 4:01 PM Jim Ingham  wrote:
> > Is the line they stepped to - instead of the expected line - always line 0?
> >
> > Jim
> >
> > > On Nov 12, 2015, at 3:52 PM, Zachary Turner  wrote:
> > >
> > > Hi Jim,
> > >
> > > This breaks about 12 tests on Windows.  The patch looks simple, but this 
> > > isn't really my area, is there anything I can give you to help diagnose 
> > > what might be wrong?  The following tests fail:
> > >
> > > FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8 
> > > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows zturner-win81 
> > > 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows 
> > > zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, 
> > > GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows 
> > > zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, 
> > > GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows zturner-win81 8 
> > > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8 6.2.9200 
> > > AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestFormatPropagation.py (Windows zturner-win81 8 
> > > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestFrames.py (Windows zturner-win81 8 6.2.9200 
> > > AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestInlineStepping.py (Windows zturner-win81 8 
> > > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestSBData.py (Windows zturner-win81 8 6.2.9200 
> > > AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestStepNoDebug.py (Windows zturner-win81 8 
> > > 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > FAIL: LLDB (suite) :: TestThreadJump.py (Windows zturner-win81 8 6.2.9200 
> > > AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > >
> > > And here's the error I get from one of the failing tests, although I 
> > > don't know how much insight it provides.
> > >
> > > Traceback (most recent call last):
> > >   File 
> > > "D:\src\ll

Re: [Lldb-commits] [lldb] r252963 - Another little stepping optimization: if any of the source step commands are running through a range

[Zachary Turner via lldb-commits]

Thanks!  Do you think you could add a test that does specifically that?
Set two breakpoints back to back, even in the same function, ane ensure
that the second one gets hit.  If your theory is right this test will fail
on Windows and Linux (and then we'll have to xfail it) but at least we'll
have a test that's isolated to the root of the problem.

On Thu, Nov 12, 2015 at 7:47 PM Jim Ingham  wrote:

> Okay, I think I fixed this, the fix is: r253008.  That passes cleanly on
> Linux for me, but I don't have a windows machine handy to test.
>
> What was happening is that originally lldb had a bug where if you were
> stopped on a breakpoint and then the next instruction also had a
> breakpoint, the plan that was stepping over the breakpoint would see a stop
> reason of "trace" so it would think it knew why it stopped and would
> auto-continue, since that's what you do when you are doing "step over a
> breakpoint and keep going."
>
> I fixed this by having the lower layers of the process plugin correct the
> stop reason from trace to breakpoint when a trace ended up on another
> breakpoint, but apparently Linux and Windows don't have this fix.  That was
> done a while ago, so maybe they weren't around then, I have to think about
> that...
>
> Anyway, the old code in ThreadPlanStepRange had a short-cut that if we
> only needed to go one instruction, it wouldn't do it with a breakpoint, but
> just stepi.  I didn't preserve that in the change I made, so we got into
> trouble.  So for now I just put that short-cut back.
>
> I wondered how this managed to cause so many Linux failures, but the OS X
> testsuite was clean...
>
> Jim
>
>
>
> > On Nov 12, 2015, at 4:57 PM, Zachary Turner  wrote:
> >
> > Ahh, seems it wasn't just Windows that was affected by this.  Makes me
> feel a little better :)
> >
> > Posting the link to the buildbot failures here so that Jim can get full
> logs if it helps.
> >
> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/8391
> >
> > On Thu, Nov 12, 2015 at 4:37 PM Ying Chen  wrote:
> > I reverted this patch for now.
> > Please resubmit if you have a fix.
> >
> > Thanks,
> > Ying
> >
> > On Thu, Nov 12, 2015 at 4:36 PM, Jim Ingham via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
> > If you can debug a failing case, and do whatever step operation got you
> to the wrong place, then run up to that step, and do:
> >
> > (lldb) log enable -f  lldb step
> >
> > and then do the step, then send me that log plus the disassembly for the
> function you were stepping in and the output of:
> >
> > (lldb) image dump line-table 
> >
> > for the source file you were stepping in.
> >
> > I should be able to see from there why we were stepping to the wrong
> place.
> >
> > Jim
> >
> > > On Nov 12, 2015, at 4:03 PM, Zachary Turner 
> wrote:
> > >
> > > The error messages are always different because the error message is
> printed by the test.  I'm going to try to load up the executable for
> TestStepNoDebug in the debugger and get a disassembly and do the step
> > >
> > > On Thu, Nov 12, 2015 at 4:01 PM Jim Ingham  wrote:
> > > Is the line they stepped to - instead of the expected line - always
> line 0?
> > >
> > > Jim
> > >
> > > > On Nov 12, 2015, at 3:52 PM, Zachary Turner 
> wrote:
> > > >
> > > > Hi Jim,
> > > >
> > > > This breaks about 12 tests on Windows.  The patch looks simple, but
> this isn't really my area, is there anything I can give you to help
> diagnose what might be wrong?  The following tests fail:
> > > >
> > > > FAIL: LLDB (suite) :: Test-rdar-9974002.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > > FAIL: LLDB (suite) :: TestDataFormatterHexCaps.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > > > FAIL: LLDB (suite) :: TestDataFormatterNamedSummaries.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > > > FAIL: LLDB (suite) :: TestDataFormatterPythonSynth.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > > > FAIL: LLDB (suite) :: TestDataFormatterSynth.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > > > FAIL: LLDB (suite) :: TestDiamond.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > > FAIL: LLDB (suite) :: TestFormatPropagation.py (Windows
> zturner-win81 8 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7,
> GenuineIntel)
> > > > FAIL: LLDB (suite) :: TestFrames.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > > FAIL: LLDB (suite) :: TestInlineStepping.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)
> > > > FAIL: LLDB (suite) :: TestSBData.py (Windows zturner-win81 8
> 6.2.9200 AMD64 Intel64 Family 6 Model 45 Stepping 7, GenuineIntel)

[Lldb-commits] [PATCH] D14633: [LLDB][MIPS] Clear bug 25194 - LLDB-Server Assertion raised when single stepping on MIPS

[Sagar Thakur via lldb-commits]

sagar created this revision.
sagar added reviewers: clayborg, tberghammer.
sagar added subscribers: nitesh.jain, jaydeep, bhushan, mohit.bhakkad, 
lldb-commits.
sagar set the repository for this revision to rL LLVM.
Herald added a subscriber: dsanders.

This patch will clear bug 25194 - LLDB-Server Assertion raised when single 
stepping on MIPS. The problem was that while emulating instructions, old and 
new pc values would have garbage value in their upper 32 bits. Therefore 
checking if pc was changed (old_pc == new_pc) would always return false, 
because of which pc was not getting updated.

>/* If we haven't changed the PC, change it here */
>if (old_pc == new_pc)
>{
>new_pc += 4;
>Context context;
>if (!WriteRegisterUnsigned (context, eRegisterKindDWARF, 
> >dwarf_pc_mips, new_pc))
>return false;
>}


Repository:
  rL LLVM

http://reviews.llvm.org/D14633

Files:
  source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
  source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.h

Index: source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.h
===
--- source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.h
+++ source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.h
@@ -80,6 +80,12 @@
 return SupportsEmulatingInstructionsOfTypeStatic (inst_type);
 }
 
+uint32_t
+ReadRegisterUnsigned (lldb::RegisterKind reg_kind,
+  uint32_t reg_num,
+  uint32_t fail_value, 
+  bool *success_ptr);
+
 bool
 ReadInstruction () override;
 
Index: source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
===
--- source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
+++ source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
@@ -760,6 +760,20 @@
 return false;
 }
 
+uint32_t
+EmulateInstructionMIPS::ReadRegisterUnsigned (lldb::RegisterKind reg_kind,
+  uint32_t reg_num,
+  uint32_t fail_value, 
+  bool *success_ptr)
+{
+RegisterValue reg_value;
+if (ReadRegister (reg_kind, reg_num, reg_value))
+return reg_value.GetAsUInt32(fail_value, success_ptr);
+if (success_ptr)
+*success_ptr = false;
+return fail_value;
+}
+
 bool 
 EmulateInstructionMIPS::ReadInstruction ()
 {
@@ -817,7 +831,7 @@
 if (opcode_data == NULL)
 return false;
 
-uint64_t old_pc = 0, new_pc = 0;
+uint32_t old_pc = 0, new_pc = 0;
 const bool auto_advance_pc = evaluate_options & 
eEmulateInstructionOptionAutoAdvancePC;
 
 if (auto_advance_pc)


Index: source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.h
===
--- source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.h
+++ source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.h
@@ -80,6 +80,12 @@
 return SupportsEmulatingInstructionsOfTypeStatic (inst_type);
 }
 
+uint32_t
+ReadRegisterUnsigned (lldb::RegisterKind reg_kind,
+  uint32_t reg_num,
+  uint32_t fail_value, 
+  bool *success_ptr);
+
 bool
 ReadInstruction () override;
 
Index: source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
===
--- source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
+++ source/Plugins/Instruction/MIPS/EmulateInstructionMIPS.cpp
@@ -760,6 +760,20 @@
 return false;
 }
 
+uint32_t
+EmulateInstructionMIPS::ReadRegisterUnsigned (lldb::RegisterKind reg_kind,
+  uint32_t reg_num,
+  uint32_t fail_value, 
+  bool *success_ptr)
+{
+RegisterValue reg_value;
+if (ReadRegister (reg_kind, reg_num, reg_value))
+return reg_value.GetAsUInt32(fail_value, success_ptr);
+if (success_ptr)
+*success_ptr = false;
+return fail_value;
+}
+
 bool 
 EmulateInstructionMIPS::ReadInstruction ()
 {
@@ -817,7 +831,7 @@
 if (opcode_data == NULL)
 return false;
 
-uint64_t old_pc = 0, new_pc = 0;
+uint32_t old_pc = 0, new_pc = 0;
 const bool auto_advance_pc = evaluate_options & eEmulateInstructionOptionAutoAdvancePC;
 
 if (auto_advance_pc)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D14634: [LLDB][MIPS] Fix TestDisassembleBreakpoint.py for MIPS

[Nitesh Jain via lldb-commits]

nitesh.jain created this revision.
nitesh.jain added reviewers: clayborg, ovyalov, jaydeep.
nitesh.jain added subscribers: bhushan, sagar, mohit.bhakkad, lldb-commits.
nitesh.jain set the repository for this revision to rL LLVM.

The "break" is opcode for breakpoint instruction.

Repository:
  rL LLVM

http://reviews.llvm.org/D14634

Files:
  
packages/Python/lldbsuite/test/functionalities/disassembly/TestDisassembleBreakpoint.py

Index: 
packages/Python/lldbsuite/test/functionalities/disassembly/TestDisassembleBreakpoint.py
===
--- 
packages/Python/lldbsuite/test/functionalities/disassembly/TestDisassembleBreakpoint.py
+++ 
packages/Python/lldbsuite/test/functionalities/disassembly/TestDisassembleBreakpoint.py
@@ -32,12 +32,16 @@
 disassembly = self.res.GetOutput()
 
 # ARCH, if not specified, defaults to x86_64.
-if self.getArchitecture() in ["", 'x86_64', 'i386', 'i686']:
+arch = self.getArchitecture()
+if arch in ["", 'x86_64', 'i386', 'i686']:
 breakpoint_opcodes = ["int3"]
 instructions = [' mov', ' addl ', 'ret']
-elif self.getArchitecture() in ["arm", "aarch64"]:
+elif arch in ["arm", "aarch64"]:
 breakpoint_opcodes = ["brk", "udf"]
 instructions = [' add ', ' ldr ', ' str ']
+elif re.match("mips" , arch):
+breakpoint_opcodes = ["break"]
+instructions = ['lw', 'sw', 'jr']
 else:
 # TODO please add your arch here
 self.fail('unimplemented for arch = 
"{arch}"'.format(arch=self.getArchitecture()))


Index: packages/Python/lldbsuite/test/functionalities/disassembly/TestDisassembleBreakpoint.py
===
--- packages/Python/lldbsuite/test/functionalities/disassembly/TestDisassembleBreakpoint.py
+++ packages/Python/lldbsuite/test/functionalities/disassembly/TestDisassembleBreakpoint.py
@@ -32,12 +32,16 @@
 disassembly = self.res.GetOutput()
 
 # ARCH, if not specified, defaults to x86_64.
-if self.getArchitecture() in ["", 'x86_64', 'i386', 'i686']:
+arch = self.getArchitecture()
+if arch in ["", 'x86_64', 'i386', 'i686']:
 breakpoint_opcodes = ["int3"]
 instructions = [' mov', ' addl ', 'ret']
-elif self.getArchitecture() in ["arm", "aarch64"]:
+elif arch in ["arm", "aarch64"]:
 breakpoint_opcodes = ["brk", "udf"]
 instructions = [' add ', ' ldr ', ' str ']
+elif re.match("mips" , arch):
+breakpoint_opcodes = ["break"]
+instructions = ['lw', 'sw', 'jr']
 else:
 # TODO please add your arch here
 self.fail('unimplemented for arch = "{arch}"'.format(arch=self.getArchitecture()))
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D14635: [LLDB][MIPS] Fix lldbplatformutil.py Failure

[Nitesh Jain via lldb-commits]

nitesh.jain created this revision.
nitesh.jain added reviewers: jaydeep, clayborg, ovyalov.
nitesh.jain added subscribers: bhushan, sagar, mohit.bhakkad, lldb-commits.
nitesh.jain set the repository for this revision to rL LLVM.

This patch check whether first register is readable.

Repository:
  rL LLVM

http://reviews.llvm.org/D14635

Files:
  packages/Python/lldbsuite/test/lldbplatformutil.py

Index: packages/Python/lldbsuite/test/lldbplatformutil.py
===
--- packages/Python/lldbsuite/test/lldbplatformutil.py
+++ packages/Python/lldbsuite/test/lldbplatformutil.py
@@ -1,13 +1,16 @@
 """ This module contains functions used by the test cases to hide the
 architecture and/or the platform dependent nature of the tests. """
-
+import re
 def check_first_register_readable(test_case):
-if test_case.getArchitecture() in ['x86_64', 'i386']:
+arch = test_case.getArchitecture()
+if arch in ['x86_64', 'i386']:
 test_case.expect("register read eax", substrs = ['eax = 0x'])
-elif test_case.getArchitecture() in ['arm']:
+elif arch in ['arm']:
test_case.expect("register read r0", substrs = ['r0 = 0x'])
-elif test_case.getArchitecture() in ['aarch64']:
+elif arch in ['aarch64']:
 test_case.expect("register read x0", substrs = ['x0 = 0x'])
+elif re.match("mips",arch):
+test_case.expect("register read zero", substrs = ['zero = 0x'])
 else:
 # TODO: Add check for other architectures
 test_case.fail("Unsupported architecture for test case (arch: %s)" % 
test_case.getArchitecture())


Index: packages/Python/lldbsuite/test/lldbplatformutil.py
===
--- packages/Python/lldbsuite/test/lldbplatformutil.py
+++ packages/Python/lldbsuite/test/lldbplatformutil.py
@@ -1,13 +1,16 @@
 """ This module contains functions used by the test cases to hide the
 architecture and/or the platform dependent nature of the tests. """
-
+import re
 def check_first_register_readable(test_case):
-if test_case.getArchitecture() in ['x86_64', 'i386']:
+arch = test_case.getArchitecture()
+if arch in ['x86_64', 'i386']:
 test_case.expect("register read eax", substrs = ['eax = 0x'])
-elif test_case.getArchitecture() in ['arm']:
+elif arch in ['arm']:
 	test_case.expect("register read r0", substrs = ['r0 = 0x'])
-elif test_case.getArchitecture() in ['aarch64']:
+elif arch in ['aarch64']:
 test_case.expect("register read x0", substrs = ['x0 = 0x'])
+elif re.match("mips",arch):
+test_case.expect("register read zero", substrs = ['zero = 0x'])
 else:
 # TODO: Add check for other architectures
 test_case.fail("Unsupported architecture for test case (arch: %s)" % test_case.getArchitecture())
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits