[Lldb-commits] [PATCH] D17708: Add/Improve complex, vector, aggregate types handling for SysV ARM (hard/soft) ABI.

[Muhammad Omair Javaid via lldb-commits]

omjavaid created this revision.
omjavaid added a reviewer: tberghammer.
omjavaid added a subscriber: lldb-commits.
Herald added subscribers: rengolin, aemerson.

This patch adds code to SysV ARM ABI for handling complex and aggregates 
containing complex return types.

It also improves support for handling vectors and aggregates containing vector 
return types for both ARM hard and soft ABIs.

This patch further enables vector value tests for both gcc and clang.

There is some work in progress to add more comprehensive return value tests and 
will be followed up in couple of days.

http://reviews.llvm.org/D17708

Files:
  packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
  source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp

Index: source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp
===
--- source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp
+++ source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp
@@ -452,12 +452,16 @@
 bool is_signed;
 bool is_complex;
 uint32_t float_count;
+bool is_vfp_candidate = false;
+uint8_t vfp_count = 0;
+uint8_t vfp_byte_size = 0;
 
 // Get the pointer to the first stack argument so we have a place to start 
 // when reading data
 
 const RegisterInfo *r0_reg_info = reg_ctx->GetRegisterInfo(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_ARG1);
 size_t bit_width = compiler_type.GetBitSize(&thread);
+size_t byte_size = compiler_type.GetByteSize(&thread);
 
 if (compiler_type.IsIntegerType (is_signed))
 {   
@@ -504,8 +508,13 @@
 }
 else if (compiler_type.IsVectorType(nullptr, nullptr))
 {
-size_t byte_size = compiler_type.GetByteSize(&thread);
-if (byte_size <= 16)
+if (IsArmHardFloat(thread) && (byte_size == 8 || byte_size == 16))
+{
+is_vfp_candidate = true;
+vfp_byte_size = 8;
+vfp_count = (byte_size == 8?1:2);
+}
+else if (byte_size <= 16)
 {
 DataBufferHeap buffer(16, 0);
 uint32_t* buffer_ptr = (uint32_t*)buffer.GetBytes();
@@ -576,84 +585,84 @@
 }
 else
 {
+if (is_complex && float_count == 2)
+{
+if (IsArmHardFloat(thread))
+{
+is_vfp_candidate = true;
+vfp_byte_size = byte_size / 2;
+vfp_count = 2;
+}
+else if (!GetReturnValuePassedInMemory(thread, reg_ctx, bit_width / 8, value))
+return return_valobj_sp;
+}
+else
 // not handled yet
 return return_valobj_sp;
 }
 }
 else if (compiler_type.IsAggregateType())
 {
-size_t byte_size = compiler_type.GetByteSize(&thread);
 if (IsArmHardFloat(thread))
 {
 CompilerType base_type;
 const uint32_t homogeneous_count = compiler_type.IsHomogeneousAggregate (&base_type);
 
 if (homogeneous_count > 0 && homogeneous_count <= 4)
 {
-if (base_type.IsFloatingPointType(float_count, is_complex))
+if (base_type.IsVectorType(nullptr, nullptr))
+{
+uint64_t base_byte_size = base_type.GetByteSize(nullptr);
+if (base_byte_size == 8 || base_byte_size == 16)
+{
+is_vfp_candidate = true;
+vfp_byte_size = 8;
+vfp_count = (base_type.GetByteSize(nullptr) == 8 ? homogeneous_count : homogeneous_count * 2);
+}
+}
+else if (base_type.IsFloatingPointType(float_count, is_complex))
 {
 if (float_count == 1 && !is_complex)
 {
-ProcessSP process_sp (thread.GetProcess());
-ByteOrder byte_order = process_sp->GetByteOrder();
+is_vfp_candidate = true;
+vfp_byte_size = base_type.GetByteSize(nullptr);
+vfp_count = homogeneous_count;
+}
+}
+}
+else if (homogeneous_count == 0)
+{
+const uint32_t num_children = compiler_type.GetNumFields ();
 
-DataBufferSP data_sp (new DataBufferHeap(byte_size, 0));
-const size_t base_byte_size = base_type.GetByteSize(nullptr);
-uint32_t data_offset = 0;
+if (num_children > 0 && num_children <=2)
+{
+uint32_t index = 0;
+for (index = 0; index < num_children; index++)
+{
+std::string name;
+base_type = compiler_type.GetFieldAtIndex (index, name, NULL, NULL, NULL);
 
-  

[Lldb-commits] [PATCH] D17710: Simplify GetGlobalProperties functions of Thread/Process/Target

[Pavel Labath via lldb-commits]

labath created this revision.
labath added reviewers: clayborg, zturner.
labath added a subscriber: lldb-commits.

"Initialization of function-local statics is guaranteed to occur only once even 
when called from
multiple threads, and may be more efficient than the equivalent code using 
std::call_once."


I'd add that it's also more readable.

http://reviews.llvm.org/D17710

Files:
  source/Target/Process.cpp
  source/Target/Target.cpp
  source/Target/Thread.cpp

Index: source/Target/Thread.cpp
===
--- source/Target/Thread.cpp
+++ source/Target/Thread.cpp
@@ -61,11 +61,7 @@
 {
 // NOTE: intentional leak so we don't crash if global destructor chain gets
 // called as other threads still use the result of this function
-static ThreadPropertiesSP *g_settings_sp_ptr = nullptr;
-static std::once_flag g_once_flag;
-std::call_once(g_once_flag,  []() {
-g_settings_sp_ptr = new ThreadPropertiesSP(new ThreadProperties 
(true));
-});
+static ThreadPropertiesSP *g_settings_sp_ptr = new ThreadPropertiesSP(new 
ThreadProperties (true));
 return *g_settings_sp_ptr;
 }
 
Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -2780,11 +2780,7 @@
 {
 // NOTE: intentional leak so we don't crash if global destructor chain gets
 // called as other threads still use the result of this function
-static TargetPropertiesSP *g_settings_sp_ptr = nullptr;
-static std::once_flag g_once_flag;
-std::call_once(g_once_flag,  []() {
-g_settings_sp_ptr = new TargetPropertiesSP(new 
TargetProperties(nullptr));
-});
+static TargetPropertiesSP *g_settings_sp_ptr = new TargetPropertiesSP(new 
TargetProperties(nullptr));
 return *g_settings_sp_ptr;
 }
 
Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -835,11 +835,7 @@
 {
 // NOTE: intentional leak so we don't crash if global destructor chain gets
 // called as other threads still use the result of this function
-static ProcessPropertiesSP *g_settings_sp_ptr = nullptr;
-static std::once_flag g_once_flag;
-std::call_once(g_once_flag,  []() {
-g_settings_sp_ptr = new ProcessPropertiesSP(new ProcessProperties 
(NULL));
-});
+static ProcessPropertiesSP *g_settings_sp_ptr = new 
ProcessPropertiesSP(new ProcessProperties (NULL));
 return *g_settings_sp_ptr;
 }
 


Index: source/Target/Thread.cpp
===
--- source/Target/Thread.cpp
+++ source/Target/Thread.cpp
@@ -61,11 +61,7 @@
 {
 // NOTE: intentional leak so we don't crash if global destructor chain gets
 // called as other threads still use the result of this function
-static ThreadPropertiesSP *g_settings_sp_ptr = nullptr;
-static std::once_flag g_once_flag;
-std::call_once(g_once_flag,  []() {
-g_settings_sp_ptr = new ThreadPropertiesSP(new ThreadProperties (true));
-});
+static ThreadPropertiesSP *g_settings_sp_ptr = new ThreadPropertiesSP(new ThreadProperties (true));
 return *g_settings_sp_ptr;
 }
 
Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -2780,11 +2780,7 @@
 {
 // NOTE: intentional leak so we don't crash if global destructor chain gets
 // called as other threads still use the result of this function
-static TargetPropertiesSP *g_settings_sp_ptr = nullptr;
-static std::once_flag g_once_flag;
-std::call_once(g_once_flag,  []() {
-g_settings_sp_ptr = new TargetPropertiesSP(new TargetProperties(nullptr));
-});
+static TargetPropertiesSP *g_settings_sp_ptr = new TargetPropertiesSP(new TargetProperties(nullptr));
 return *g_settings_sp_ptr;
 }
 
Index: source/Target/Process.cpp
===
--- source/Target/Process.cpp
+++ source/Target/Process.cpp
@@ -835,11 +835,7 @@
 {
 // NOTE: intentional leak so we don't crash if global destructor chain gets
 // called as other threads still use the result of this function
-static ProcessPropertiesSP *g_settings_sp_ptr = nullptr;
-static std::once_flag g_once_flag;
-std::call_once(g_once_flag,  []() {
-g_settings_sp_ptr = new ProcessPropertiesSP(new ProcessProperties (NULL));
-});
+static ProcessPropertiesSP *g_settings_sp_ptr = new ProcessPropertiesSP(new ProcessProperties (NULL));
 return *g_settings_sp_ptr;
 }
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r262214 - Fix compiler warnings in the java code

[Pavel Labath via lldb-commits]

Author: labath
Date: Mon Feb 29 05:44:15 2016
New Revision: 262214

URL: http://llvm.org/viewvc/llvm-project?rev=262214&view=rev
Log:
Fix compiler warnings in the java code

Modified:
lldb/trunk/source/Plugins/Language/Java/JavaLanguage.h
lldb/trunk/source/Symbol/JavaASTContext.cpp

Modified: lldb/trunk/source/Plugins/Language/Java/JavaLanguage.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/Java/JavaLanguage.h?rev=262214&r1=262213&r2=262214&view=diff
==
--- lldb/trunk/source/Plugins/Language/Java/JavaLanguage.h (original)
+++ lldb/trunk/source/Plugins/Language/Java/JavaLanguage.h Mon Feb 29 05:44:15 
2016
@@ -56,7 +56,7 @@ public:
 IsNilReference(ValueObject &valobj) override;
 
 lldb::TypeCategoryImplSP
-GetFormatters();
+GetFormatters() override;
 };
 
 } // namespace lldb_private

Modified: lldb/trunk/source/Symbol/JavaASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/JavaASTContext.cpp?rev=262214&r1=262213&r2=262214&view=diff
==
--- lldb/trunk/source/Symbol/JavaASTContext.cpp (original)
+++ lldb/trunk/source/Symbol/JavaASTContext.cpp Mon Feb 29 05:44:15 2016
@@ -366,8 +366,7 @@ public:
 JavaArrayType(CompilerType element_type, const DWARFExpression 
&length_expression, const lldb::addr_t data_offset)
 : JavaType(JavaType::eKindArray),
   m_element_type(element_type),
-  m_length_expression(length_expression),
-  m_data_offset(data_offset)
+  m_length_expression(length_expression)
 {
 }
 
@@ -422,7 +421,6 @@ public:
 private:
 CompilerType m_element_type;
 DWARFExpression m_length_expression;
-lldb::addr_t m_data_offset;
 };
 
 } // end of anonymous namespace


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

Re: [Lldb-commits] [PATCH] D17708: Add/Improve complex, vector, aggregate types handling for SysV ARM (hard/soft) ABI.

[Tamas Berghammer via lldb-commits]

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

Looks good (it would be nice if we can split GetReturnValueObjectImpl to 
multiple function as it starts to become pretty big and hard to read but I 
don't think we shouldn't do it as part of this CL)



Comment at: source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp:586-588
@@ -576,3 +585,5 @@
 }
 else
 {
+if (is_complex && float_count == 2)
+{

(nit): It can be an "else if"


Comment at: source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp:599-601
@@ -579,3 +598,5 @@
+}
+else
 // not handled yet
 return return_valobj_sp;
 }

(nit); Indentation


http://reviews.llvm.org/D17708



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

[Lldb-commits] [lldb] r262218 - Add/Improve complex, vector, aggregate types handling for SysV ARM (hard/soft) ABI.

[Omair Javaid via lldb-commits]

Author: omjavaid
Date: Mon Feb 29 07:39:20 2016
New Revision: 262218

URL: http://llvm.org/viewvc/llvm-project?rev=262218&view=rev
Log:
Add/Improve complex, vector, aggregate types handling for SysV ARM (hard/soft) 
ABI.

For details see:

Differential revision: http://reviews.llvm.org/D17708


Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
lldb/trunk/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py?rev=262218&r1=262217&r2=262218&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
 Mon Feb 29 07:39:20 2016
@@ -151,11 +151,11 @@ class ReturnValueTestCase(TestBase):
 #self.return_and_test_struct_value ("return_one_int_one_double_packed")
 self.return_and_test_struct_value ("return_one_int_one_long")
 
+self.return_and_test_struct_value ("return_vector_size_float32_8")
+self.return_and_test_struct_value ("return_vector_size_float32_16")
+self.return_and_test_struct_value ("return_vector_size_float32_32")
 # icc and gcc don't support this extension.
 if self.getCompiler().endswith('clang'):
-self.return_and_test_struct_value ("return_vector_size_float32_8")
-self.return_and_test_struct_value ("return_vector_size_float32_16")
-self.return_and_test_struct_value ("return_vector_size_float32_32")
 self.return_and_test_struct_value 
("return_ext_vector_size_float32_2")
 self.return_and_test_struct_value 
("return_ext_vector_size_float32_4")
 self.return_and_test_struct_value 
("return_ext_vector_size_float32_8")

Modified: lldb/trunk/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp?rev=262218&r1=262217&r2=262218&view=diff
==
--- lldb/trunk/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp (original)
+++ lldb/trunk/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp Mon Feb 29 07:39:20 
2016
@@ -452,12 +452,16 @@ ABISysV_arm::GetReturnValueObjectImpl (T
 bool is_signed;
 bool is_complex;
 uint32_t float_count;
+bool is_vfp_candidate = false;
+uint8_t vfp_count = 0;
+uint8_t vfp_byte_size = 0;
 
 // Get the pointer to the first stack argument so we have a place to start 
 // when reading data
 
 const RegisterInfo *r0_reg_info = 
reg_ctx->GetRegisterInfo(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_ARG1);
 size_t bit_width = compiler_type.GetBitSize(&thread);
+size_t byte_size = compiler_type.GetByteSize(&thread);
 
 if (compiler_type.IsIntegerType (is_signed))
 {   
@@ -504,8 +508,13 @@ ABISysV_arm::GetReturnValueObjectImpl (T
 }
 else if (compiler_type.IsVectorType(nullptr, nullptr))
 {
-size_t byte_size = compiler_type.GetByteSize(&thread);
-if (byte_size <= 16)
+if (IsArmHardFloat(thread) && (byte_size == 8 || byte_size == 16))
+{
+is_vfp_candidate = true;
+vfp_byte_size = 8;
+vfp_count = (byte_size == 8?1:2);
+}
+else if (byte_size <= 16)
 {
 DataBufferHeap buffer(16, 0);
 uint32_t* buffer_ptr = (uint32_t*)buffer.GetBytes();
@@ -574,15 +583,23 @@ ABISysV_arm::GetReturnValueObjectImpl (T
 }
 }
 }
-else
+else if (is_complex && float_count == 2)
 {
+if (IsArmHardFloat(thread))
+{
+is_vfp_candidate = true;
+vfp_byte_size = byte_size / 2;
+vfp_count = 2;
+}
+else if (!GetReturnValuePassedInMemory(thread, reg_ctx, bit_width 
/ 8, value))
+return return_valobj_sp;
+}
+else
 // not handled yet
 return return_valobj_sp;
-}
 }
 else if (compiler_type.IsAggregateType())
 {
-size_t byte_size = compiler_type.GetByteSize(&thread);
 if (IsArmHardFloat(thread))
 {
 CompilerType base_type;
@@ -590,70 +607,59 @@ ABISysV_arm::GetReturnValueObjectImpl (T
 
 if (homogeneous_count > 0 && homogeneous_count <= 4)
 {
-if (base_type.IsFloatingPointType(float_count, is_complex))
+if (base_type.IsVectorType(nullptr, nullptr))
+{
+uint64_t base_byte_size = base_type.GetByteSize(nullptr);
+ 

Re: [Lldb-commits] [PATCH] D17708: Add/Improve complex, vector, aggregate types handling for SysV ARM (hard/soft) ABI.

[Muhammad Omair Javaid via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL262218: Add/Improve complex, vector, aggregate types 
handling for SysV ARM… (authored by omjavaid).

Changed prior to commit:
  http://reviews.llvm.org/D17708?vs=49353&id=49364#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17708

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
  lldb/trunk/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp

Index: lldb/trunk/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp
===
--- lldb/trunk/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp
+++ lldb/trunk/source/Plugins/ABI/SysV-arm/ABISysV_arm.cpp
@@ -452,12 +452,16 @@
 bool is_signed;
 bool is_complex;
 uint32_t float_count;
+bool is_vfp_candidate = false;
+uint8_t vfp_count = 0;
+uint8_t vfp_byte_size = 0;
 
 // Get the pointer to the first stack argument so we have a place to start 
 // when reading data
 
 const RegisterInfo *r0_reg_info = reg_ctx->GetRegisterInfo(eRegisterKindGeneric, LLDB_REGNUM_GENERIC_ARG1);
 size_t bit_width = compiler_type.GetBitSize(&thread);
+size_t byte_size = compiler_type.GetByteSize(&thread);
 
 if (compiler_type.IsIntegerType (is_signed))
 {   
@@ -504,8 +508,13 @@
 }
 else if (compiler_type.IsVectorType(nullptr, nullptr))
 {
-size_t byte_size = compiler_type.GetByteSize(&thread);
-if (byte_size <= 16)
+if (IsArmHardFloat(thread) && (byte_size == 8 || byte_size == 16))
+{
+is_vfp_candidate = true;
+vfp_byte_size = 8;
+vfp_count = (byte_size == 8?1:2);
+}
+else if (byte_size <= 16)
 {
 DataBufferHeap buffer(16, 0);
 uint32_t* buffer_ptr = (uint32_t*)buffer.GetBytes();
@@ -574,86 +583,83 @@
 }
 }
 }
-else
+else if (is_complex && float_count == 2)
 {
+if (IsArmHardFloat(thread))
+{
+is_vfp_candidate = true;
+vfp_byte_size = byte_size / 2;
+vfp_count = 2;
+}
+else if (!GetReturnValuePassedInMemory(thread, reg_ctx, bit_width / 8, value))
+return return_valobj_sp;
+}
+else
 // not handled yet
 return return_valobj_sp;
-}
 }
 else if (compiler_type.IsAggregateType())
 {
-size_t byte_size = compiler_type.GetByteSize(&thread);
 if (IsArmHardFloat(thread))
 {
 CompilerType base_type;
 const uint32_t homogeneous_count = compiler_type.IsHomogeneousAggregate (&base_type);
 
 if (homogeneous_count > 0 && homogeneous_count <= 4)
 {
-if (base_type.IsFloatingPointType(float_count, is_complex))
+if (base_type.IsVectorType(nullptr, nullptr))
+{
+uint64_t base_byte_size = base_type.GetByteSize(nullptr);
+if (base_byte_size == 8 || base_byte_size == 16)
+{
+is_vfp_candidate = true;
+vfp_byte_size = 8;
+vfp_count = (base_type.GetByteSize(nullptr) == 8 ? homogeneous_count : homogeneous_count * 2);
+}
+}
+else if (base_type.IsFloatingPointType(float_count, is_complex))
 {
 if (float_count == 1 && !is_complex)
 {
-ProcessSP process_sp (thread.GetProcess());
-ByteOrder byte_order = process_sp->GetByteOrder();
+is_vfp_candidate = true;
+vfp_byte_size = base_type.GetByteSize(nullptr);
+vfp_count = homogeneous_count;
+}
+}
+}
+else if (homogeneous_count == 0)
+{
+const uint32_t num_children = compiler_type.GetNumFields ();
 
-DataBufferSP data_sp (new DataBufferHeap(byte_size, 0));
-const size_t base_byte_size = base_type.GetByteSize(nullptr);
-uint32_t data_offset = 0;
+if (num_children > 0 && num_children <=2)
+{
+uint32_t index = 0;
+for (index = 0; index < num_children; index++)
+{
+std::string name;
+base_type = compiler_type.GetFieldAtIndex (index, name, NULL, NULL, NULL);
 
-for (uint32_t reg_index = 0; reg_index < homogeneous_count; reg_index++)
+if (base_type.IsFloatingPointType(float_count, is_complex))
 {
-uint32_t regnum = 0;
-
-  

[Lldb-commits] [PATCH] D17716: Add complex and aggregate with vector types return value test cases

[Muhammad Omair Javaid via lldb-commits]

omjavaid created this revision.
omjavaid added a reviewer: tberghammer.
omjavaid added a subscriber: lldb-commits.

This patch adds tests to test complex return types and aggregate return types 
with vector elements.

http://reviews.llvm.org/D17716

Files:
  packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
  packages/Python/lldbsuite/test/functionalities/return-value/call-func.c

Index: packages/Python/lldbsuite/test/functionalities/return-value/call-func.c
===
--- packages/Python/lldbsuite/test/functionalities/return-value/call-func.c
+++ packages/Python/lldbsuite/test/functionalities/return-value/call-func.c
@@ -1,3 +1,4 @@
+#include /* Standard Library of Complex Numbers */
 // Some convenient things to return:
 static char *g_first_pointer = "I am the first";
 static char *g_second_pointer = "I am the second";
@@ -345,6 +346,77 @@
 return value;
 }
 
+struct two_vectors_8_bytes
+{
+  vector_size_float32_8 first_vector_8_bytes;
+  vector_size_float32_8 second_vector_8_bytes;
+};
+
+struct two_vectors_8_bytes
+return_two_vectors_8_bytes (struct two_vectors_8_bytes value)
+{
+  return value;
+}
+
+struct four_vectors_16_bytes
+{
+  vector_size_float32_16 first_vector_16_bytes;
+  vector_size_float32_16 second_vector_16_bytes;
+  vector_size_float32_16 third_vector_16_bytes;
+  vector_size_float32_16 fourth_vector_16_bytes;
+};
+
+struct four_vectors_16_bytes
+return_four_vectors_16_bytes (struct four_vectors_16_bytes value)
+{
+  return value;
+}
+
+struct four_vectors_32_bytes
+{
+  vector_size_float32_32 first_vector_32_bytes;
+  vector_size_float32_32 second_vector_32_bytes;
+  vector_size_float32_32 third_vector_32_bytes;
+  vector_size_float32_32 fourth_vector_32_bytes;
+};
+
+struct four_vectors_32_bytes
+return_four_vectors_32_bytes (struct four_vectors_32_bytes value)
+{
+  return value;
+}
+
+double complex
+return_one_complex (double complex value)
+{
+  return value;
+}
+
+struct two_complex
+{
+  double complex z0;
+  double complex z1;
+};
+
+struct two_complex
+return_two_complex (struct two_complex value)
+{
+  return value;
+}
+
+struct three_complex
+{
+  float complex z0;
+  float complex z1;
+  float complex z2;
+};
+
+struct three_complex
+return_three_complex (struct three_complex value)
+{
+  return value;
+}
+
 int 
 main ()
 {
@@ -395,10 +467,22 @@
   return_one_int_one_double_packed ((struct one_int_one_double_packed) {10, 20.0});
   return_one_int_one_long ((struct one_int_one_long) {10, 20});
 
+  return_one_complex ((complex) {(1.1,2.1)});
+  return_two_complex ((struct two_complex) {(7.89, 8.52), (6.31, 9.12)});
+  return_three_complex ((struct three_complex) {(7.89, 8.52), (6.31, 9.12), (1.1,2.1)});
+
   return_vector_size_float32_8 (( vector_size_float32_8 ){1.5, 2.25});
   return_vector_size_float32_16 (( vector_size_float32_16 ){1.5, 2.25, 4.125, 8.0625});
   return_vector_size_float32_32 (( vector_size_float32_32 ){1.5, 2.25, 4.125, 8.0625, 7.89, 8.52, 6.31, 9.12});
 
+  return_two_vectors_8_bytes ((struct two_vectors_8_bytes ){{1.5, 2.25}, {4.125, 8.0625}});
+  return_four_vectors_16_bytes ((struct four_vectors_16_bytes ){{1.5, 2.25, 4.125, 8.0625}, {7.89, 8.52, 6.31, 9.12},
+{9.80, 1.52, 7.31, 6.33}, {1.188, 4.61, 0.31, 0.12}});
+  return_four_vectors_32_bytes ((struct four_vectors_32_bytes ){{1.5, 2.25, 4.125, 8.0625, 7.89, 8.52, 6.31, 9.12},
+{9.80, 1.52, 7.31, 6.33, 1.188, 4.61, 0.31, 0.12},
+{1.1, 2.15, 0.125, 3.0625, 0.89, 4.52, 2.31, 8.12},
+{0.80, 1.52, 7.77, 2.26, 8.188, 0.61, 5.31, 77.12}});
+
   return_ext_vector_size_float32_2 ((ext_vector_size_float32_2){ 16.5, 32.25});
   return_ext_vector_size_float32_4 ((ext_vector_size_float32_4){ 16.5, 32.25, 64.125, 128.0625});
   return_ext_vector_size_float32_8 ((ext_vector_size_float32_8){ 16.5, 32.25, 64.125, 128.0625, 1.59, 3.57, 8.63, 9.12 });
Index: packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
===
--- packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
+++ packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
@@ -151,9 +151,17 @@
 #self.return_and_test_struct_value ("return_one_int_one_double_packed")
 self.return_and_test_struct_value ("return_one_int_one_long")
 
+self.return_and_test_struct_value ("return_one_complex")
+self.return_and_test_struct_value ("return_two_complex")
+self.return_and_test_struct_value ("return_three_complex")
+
 self.return_and_test_struct_value ("return_vector_size_float32_8")
 self.return_and_test_struct_value ("return_vector_si

Re: [Lldb-commits] [PATCH] D17716: Add complex and aggregate with vector types return value test cases

[Tamas Berghammer via lldb-commits]

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

Looks good but please verify that the new test is passes on other architectures 
and XFAIL the test accordingly.

If you have to XFAIL something then I would prefer to split this test to 
smaller tests so we don't have to XFAIL everything just because of 1 check is 
failing


http://reviews.llvm.org/D17716



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

[Lldb-commits] [lldb] r262223 - Revert a part of "Add/Improve complex, vector, aggregate types handling for SysV ARM (hard/soft) ABI."

[Pavel Labath via lldb-commits]

Author: labath
Date: Mon Feb 29 08:26:45 2016
New Revision: 262223

URL: http://llvm.org/viewvc/llvm-project?rev=262223&view=rev
Log:
Revert a part of "Add/Improve complex, vector, aggregate types handling for 
SysV ARM (hard/soft) ABI."

This partially reverts commit r262218.

The commit added additional checks to a test case. The test case is too big so 
it's not feasible
to XFAIL it completely. Suggest to implement the checks as a separate test 
case, which can then
be XFAILed more surgically.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py?rev=262223&r1=26&r2=262223&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/return-value/TestReturnValue.py
 Mon Feb 29 08:26:45 2016
@@ -151,11 +151,11 @@ class ReturnValueTestCase(TestBase):
 #self.return_and_test_struct_value ("return_one_int_one_double_packed")
 self.return_and_test_struct_value ("return_one_int_one_long")
 
-self.return_and_test_struct_value ("return_vector_size_float32_8")
-self.return_and_test_struct_value ("return_vector_size_float32_16")
-self.return_and_test_struct_value ("return_vector_size_float32_32")
 # icc and gcc don't support this extension.
 if self.getCompiler().endswith('clang'):
+self.return_and_test_struct_value ("return_vector_size_float32_8")
+self.return_and_test_struct_value ("return_vector_size_float32_16")
+self.return_and_test_struct_value ("return_vector_size_float32_32")
 self.return_and_test_struct_value 
("return_ext_vector_size_float32_2")
 self.return_and_test_struct_value 
("return_ext_vector_size_float32_4")
 self.return_and_test_struct_value 
("return_ext_vector_size_float32_8")


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

Re: [Lldb-commits] [PATCH] D17716: Add complex and aggregate with vector types return value test cases

[Pavel Labath via lldb-commits]

labath added a subscriber: labath.
labath requested changes to this revision.
labath added a reviewer: labath.
labath added a comment.
This revision now requires changes to proceed.

I agree with Tamas here. Your previous patch also added a some tests here, 
which were breaking on some configurations (linux+gcc in this case). It's not a 
good idea no XFAIL the whole test just because of the added checks (which can 
be tested completely independently of the original test). If you don't want to 
refactor the existing checks, then please at least put the new checks (and the 
ones I just reverted) into a test of it's own.

Thanks.


http://reviews.llvm.org/D17716



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

[Lldb-commits] [PATCH] D17719: Track expression language from one place in ClangExpressionParser

[Luke Drummond via lldb-commits]

ldrumm created this revision.
ldrumm added reviewers: clayborg, spyffe.
ldrumm added a subscriber: lldb-commits.

The current expression language is currently tracked in a few places within the 
`ClangExpressionParser` constructor. This patch adds a private 
`lldb::LanguageType`  attribute to the `ClangExpressionParser` class and tracks 
the expression language from that one place.

http://reviews.llvm.org/D17719

Files:
  source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
  source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h

Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
@@ -129,6 +129,8 @@
 class LLDBPreprocessorCallbacks;
 LLDBPreprocessorCallbacks   *m_pp_callbacks; ///< 
Called when the preprocessor encounters module imports
 std::unique_ptr m_ast_context;
+lldb::LanguageType   m_language;///< The 
the source language of the expression
+/// which 
may be explicitly set or inferred.
 };
 
 }
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -157,7 +157,7 @@
 
 // 1. Create a new compiler instance.
 m_compiler.reset(new CompilerInstance());
-lldb::LanguageType frame_lang = expr.Language(); // defaults to 
lldb::eLanguageTypeUnknown
+m_language = expr.Language(); // defaults to lldb::eLanguageTypeUnknown
 bool overridden_target_opts = false;
 lldb_private::LanguageRuntime *lang_rt = nullptr;
 lldb::TargetSP target_sp;
@@ -176,14 +176,14 @@
 
 // Make sure the user hasn't provided a preferred execution language
 // with `expression --language X -- ...`
-if (frame && frame_lang == lldb::eLanguageTypeUnknown)
-frame_lang = frame->GetLanguage();
+if (frame && m_language == lldb::eLanguageTypeUnknown)
+m_language = frame->GetLanguage();
 
-if (frame_lang != lldb::eLanguageTypeUnknown)
+if (m_language != lldb::eLanguageTypeUnknown)
 {
-lang_rt = 
exe_scope->CalculateProcess()->GetLanguageRuntime(frame_lang);
+lang_rt = 
exe_scope->CalculateProcess()->GetLanguageRuntime(m_language);
 if (log)
-log->Printf("Frame has language of type %s", 
Language::GetNameForLanguageType(frame_lang));
+log->Printf("Frame has language of type %s", 
Language::GetNameForLanguageType(m_language));
 }
 
 // 2. Configure the compiler with a set of default options that are 
appropriate
@@ -263,9 +263,7 @@
 assert (m_compiler->hasTarget());
 
 // 5. Set language options.
-lldb::LanguageType language = expr.Language();
-
-switch (language)
+switch (m_language)
 {
 case lldb::eLanguageTypeC:
 case lldb::eLanguageTypeC89:


Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
@@ -129,6 +129,8 @@
 class LLDBPreprocessorCallbacks;
 LLDBPreprocessorCallbacks   *m_pp_callbacks; ///< Called when the preprocessor encounters module imports
 std::unique_ptr m_ast_context;
+lldb::LanguageType   m_language;///< The the source language of the expression
+/// which may be explicitly set or inferred.
 };
 
 }
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -157,7 +157,7 @@
 
 // 1. Create a new compiler instance.
 m_compiler.reset(new CompilerInstance());
-lldb::LanguageType frame_lang = expr.Language(); // defaults to lldb::eLanguageTypeUnknown
+m_language = expr.Language(); // defaults to lldb::eLanguageTypeUnknown
 bool overridden_target_opts = false;
 lldb_private::LanguageRuntime *lang_rt = nullptr;
 lldb::TargetSP target_sp;
@@ -176,14 +176,14 @@
 
 // Make sure the user hasn't provided a preferred execution language
 // with `expression --language X -- ...`
-if (frame && frame_lang == lldb::eLanguageTypeUnknown)
-frame_lang = frame->GetLanguage();
+if (frame && m_language == lldb::eLanguageTypeUnknown)
+m_language = frame->GetLanguage()

Re: [Lldb-commits] [PATCH] D17710: Simplify GetGlobalProperties functions of Thread/Process/Target

[Zachary Turner via lldb-commits]

The reason for this is that msvc didn't support this until 2015. I'm fine
with these changes but i think you guys still need 2013 for a while longer,
right?
On Mon, Feb 29, 2016 at 3:38 AM Pavel Labath  wrote:

> labath created this revision.
> labath added reviewers: clayborg, zturner.
> labath added a subscriber: lldb-commits.
>
> "Initialization of function-local statics is guaranteed to occur only once
> even when called from
> multiple threads, and may be more efficient than the equivalent code using
> std::call_once."
> 
>
> I'd add that it's also more readable.
>
> http://reviews.llvm.org/D17710
>
> Files:
>   source/Target/Process.cpp
>   source/Target/Target.cpp
>   source/Target/Thread.cpp
>
> Index: source/Target/Thread.cpp
> ===
> --- source/Target/Thread.cpp
> +++ source/Target/Thread.cpp
> @@ -61,11 +61,7 @@
>  {
>  // NOTE: intentional leak so we don't crash if global destructor
> chain gets
>  // called as other threads still use the result of this function
> -static ThreadPropertiesSP *g_settings_sp_ptr = nullptr;
> -static std::once_flag g_once_flag;
> -std::call_once(g_once_flag,  []() {
> -g_settings_sp_ptr = new ThreadPropertiesSP(new ThreadProperties
> (true));
> -});
> +static ThreadPropertiesSP *g_settings_sp_ptr = new
> ThreadPropertiesSP(new ThreadProperties (true));
>  return *g_settings_sp_ptr;
>  }
>
> Index: source/Target/Target.cpp
> ===
> --- source/Target/Target.cpp
> +++ source/Target/Target.cpp
> @@ -2780,11 +2780,7 @@
>  {
>  // NOTE: intentional leak so we don't crash if global destructor
> chain gets
>  // called as other threads still use the result of this function
> -static TargetPropertiesSP *g_settings_sp_ptr = nullptr;
> -static std::once_flag g_once_flag;
> -std::call_once(g_once_flag,  []() {
> -g_settings_sp_ptr = new TargetPropertiesSP(new
> TargetProperties(nullptr));
> -});
> +static TargetPropertiesSP *g_settings_sp_ptr = new
> TargetPropertiesSP(new TargetProperties(nullptr));
>  return *g_settings_sp_ptr;
>  }
>
> Index: source/Target/Process.cpp
> ===
> --- source/Target/Process.cpp
> +++ source/Target/Process.cpp
> @@ -835,11 +835,7 @@
>  {
>  // NOTE: intentional leak so we don't crash if global destructor
> chain gets
>  // called as other threads still use the result of this function
> -static ProcessPropertiesSP *g_settings_sp_ptr = nullptr;
> -static std::once_flag g_once_flag;
> -std::call_once(g_once_flag,  []() {
> -g_settings_sp_ptr = new ProcessPropertiesSP(new ProcessProperties
> (NULL));
> -});
> +static ProcessPropertiesSP *g_settings_sp_ptr = new
> ProcessPropertiesSP(new ProcessProperties (NULL));
>  return *g_settings_sp_ptr;
>  }
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D17710: Simplify GetGlobalProperties functions of Thread/Process/Target

[Pavel Labath via lldb-commits]

labath added a comment.

I suspected something like that might be up. Thanks.

The VS2015 migration for us is taking longer than expected, but we are now 
nearing the end, hopefully. If there are no objections, I'll land this after we 
are done.


http://reviews.llvm.org/D17710



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

Re: [Lldb-commits] [lldb] r262041 - Fix bug with register values byte order in expression evaluation.

[Aidan Dodds via lldb-commits]

Sorry about the breakage, and thanks for working on a patch Chaoren.
Hopefully Marianne will revise her merge request if this fix is still 
important for her.


On 28/02/2016 00:06, Todd Fiala wrote:
I brought the state of the lines changed there to what they were prior 
to the change. If you adjusted those same lines, then yes that got undone.


We were failing different tests in those files.  Your change may have 
fixed the new issues on Linux, but did not address the new failures on 
OS X.  The OS X bot went green after the revert.


-Todd

On Feb 27, 2016, at 4:01 PM, Chaoren Lin > wrote:


I thought I fixed it with http://reviews.llvm.org/D17658. Did you 
revert that as well?


On Sat, Feb 27, 2016 at 3:14 PM, Todd Fiala > wrote:


Hi all,

The new assert was failing on the OS X testbot here:
http://lab.llvm.org:8080/green/job/lldb_build_test/

The nag mail didn't make it to you since we have it only fire on
the transition from good build to bad build, and Tamas had the
privilege of earning that with a minor Xcode breakage just
shortly before this issue showed up.  However, that bot as been
broken since this change went in.

I reverted it in r262156.

Feel free to reapply if you have a suggested fix for the test
failure introduced.

Thanks!

-Todd

On Fri, Feb 26, 2016 at 12:08 PM, Chaoren Lin via lldb-commits
mailto:lldb-commits@lists.llvm.org>> wrote:

Hmm. Weird. That assert is failing on Linux:

http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/11833

On Fri, Feb 26, 2016 at 9:40 AM, Aidan Dodds via lldb-commits
mailto:lldb-commits@lists.llvm.org>> wrote:

Author: aidandodds
Date: Fri Feb 26 11:40:50 2016
New Revision: 262041

URL: http://llvm.org/viewvc/llvm-project?rev=262041&view=rev
Log:
Fix bug with register values byte order in expression
evaluation.

The evaluation of expressions containing register values
was broken for targets for which endianness differs from
host.

Committed on behalf of: mamai
mailto:marianne.mailhot.sarra...@gmail.com>>

Differential revision: http://reviews.llvm.org/D17167

Modified:
lldb/trunk/source/Expression/Materializer.cpp

Modified: lldb/trunk/source/Expression/Materializer.cpp
URL:

http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/Materializer.cpp?rev=262041&r1=262040&r2=262041&view=diff

==
--- lldb/trunk/source/Expression/Materializer.cpp (original)
+++ lldb/trunk/source/Expression/Materializer.cpp Fri Feb
26 11:40:50 2016
@@ -26,6 +26,7 @@
 #include "lldb/Target/StackFrame.h"
 #include "lldb/Target/Target.h"
 #include "lldb/Target/Thread.h"
+#include "lldb/Utility/LLDBAssert.h"

 using namespace lldb_private;

@@ -1275,9 +1276,14 @@ public:
 m_register_contents.reset(new
DataBufferHeap(register_data.GetDataStart(),
register_data.GetByteSize()));

 Error write_error;
-
- map.WriteMemory(load_addr,
register_data.GetDataStart(),
register_data.GetByteSize(), write_error);
-
+
+Scalar scalar;
+ reg_value.GetScalarValue(scalar);
+
+ lldbassert(scalar.GetByteSize() ==
register_data.GetByteSize());
+
+ map.WriteScalarToMemory(load_addr, scalar,
scalar.GetByteSize(), write_error);
+
 if (!write_error.Success())
 {
 err.SetErrorStringWithFormat("couldn't write the
contents of register %s: %s", m_register_info.name
, write_error.AsCString());


___
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




-- 
-Todd





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

[Lldb-commits] [PATCH] D17724: Replace getopt with llvm::cl in lldb driver

[Pavel Labath via lldb-commits]

labath created this revision.
labath added reviewers: clayborg, zturner.
labath added a subscriber: lldb-commits.

This replaces the hand-rolled getopt option parser in lldb driver with the one 
in llvm. This
results in a lot less code, as the llvm's parser does much of the work (e.g., 
formatting of
--help output) for us, and side-steps the problem of using the internal getopt 
implementation in
liblldb on platforms which don't have a system getopt (windows, netbsd).

This change has tiny behaviour changes, which I try to enumerate here:
- boolean arguments can no longer be specified twice (e.g., --no-lldbinit 
--no-lldbinit will
  result in an error). I needed to tweak TestFormats to account for this. Can 
be changed, but I'm
  not sure if there is any need for it.
- I have removed the --script-language option, as it seemed to be ignored 
anyway.
- --help output has changed a bit and now reads (note one has to pass 
--help-hidden to see
  short option letters. again can be changed, but i think it makes the initial 
help more
  readable):

USAGE: lldb [options] 

OPTIONS:

General options:

  -arch= - Tells the debugger to use the specified 
architecture when starting and running the program.   must be one of 
the architectures for which the program was compiled.
  -attach-name=  - Tells the debugger to attach to a process 
with the given name.
  -attach-pid= - Tells the debugger to attach to a process 
with the given pid
  -batch - Tells the debugger to running the commands 
from -s, -S, -o & -O, and then quit.  However if any run command stopped due to 
a signal or crash, the debugger will return to the interactive prompt at the 
place of the crash.
  -core= - Tells the debugger to use the file  
as the core file.
  -debug - Tells the debugger to print out extra 
information for debugging itself.
  -editor- Tells the debugger to open source files 
using the host's "external editor" mechanism.
  -file= - Tells the debugger to use the file  
as the program to be debugged.
  -no-lldbinit   - Do not automatically parse any '.lldbinit' 
files.
  -no-use-colors - Do not use colors.
  -one-line= - Tells the debugger to execute this one-line 
lldb command after any file provided on the command line has been loaded.
  -one-line-before-file= - Tells the debugger to execute this one-line 
lldb command before any file provided on the command line has been loaded.
  -one-line-on-crash=- When in batch mode, tells the debugger to 
execute this one-line lldb command if the target crashes.
  -repl= - Runs lldb in REPL mode with a stub process.
  -repl-langauge=- Chooses the language for the REPL.
  -source=   - Tells the debugger to read in and execute 
the lldb commands in the given file, after any file provided on the command 
line has been loaded.
  -source-before-file=   - Tells the debugger to read in and execute 
the lldb commands in the given file, before any file provided on the command 
line has been loaded.
  -source-on-crash=  - When in batch mode, tells the debugger to 
source this file of lldb commands if the target crashes.
  -source-quietly- Don't echo the commands when executing them.
  -wait-for  - Tells the debugger to wait for a process 
with the given pid or name to launch before attaching.

Generic Options:

  -help  - Display available options (-help-hidden for 
more)
  -help-list - Display list of available options 
(-help-list-hidden for more)
  -version   - Display the version of this program

If you don't provide -file then the first argument will be the file to be
debugged which means that 'lldb --  [ []]' also
works.  But remember to end the options with "--" if any of your
arguments begin with "-".

Multiple "-source" and "-one-line" options can be provided.  They will be
processed from left to right in order, with the source files and commands
interleaved.

http://reviews.llvm.org/D17724

Files:
  packages/Python/lldbsuite/test/driver/batch_mode/TestBatchMode.py
  packages/Python/lldbsuite/test/driver/batch_mode/source.file
  packages/Python/lldbsuite/test/functionalities/format/TestFormats.py
  tools/driver/Driver.cpp
  tools/driver/Driver.h
  tools/driver/Platform.h

Index: tools/driver/Platform.h
===
--- tools/driver/Platform.h
+++ tools/driver/Platform.h
@@ -12,9 +12,6 @@
 
 #if defined( _WIN32 )
 
-// this will stop signal.h being included
-#define _INC_SIGNAL
-#include "lldb/Host/HostGetOpt.h"
 #include 
 #if defined( _MSC_VER )
 #include 
Index: tools/driver/Driver.h
===
--- tools/driver/Driver.h
+++ tools/driver/Dri

Re: [Lldb-commits] [PATCH] D17724: Replace getopt with llvm::cl in lldb driver

[Zachary Turner via lldb-commits]

Love this change in principle. I will look over it on the windows side to
make sure nothing breaks.

One question: we are using getopt still for parsing interactive command
lines right?
On Mon, Feb 29, 2016 at 9:26 AM Pavel Labath  wrote:

> labath created this revision.
> labath added reviewers: clayborg, zturner.
> labath added a subscriber: lldb-commits.
>
> This replaces the hand-rolled getopt option parser in lldb driver with the
> one in llvm. This
> results in a lot less code, as the llvm's parser does much of the work
> (e.g., formatting of
> --help output) for us, and side-steps the problem of using the internal
> getopt implementation in
> liblldb on platforms which don't have a system getopt (windows, netbsd).
>
> This change has tiny behaviour changes, which I try to enumerate here:
> - boolean arguments can no longer be specified twice (e.g., --no-lldbinit
> --no-lldbinit will
>   result in an error). I needed to tweak TestFormats to account for this.
> Can be changed, but I'm
>   not sure if there is any need for it.
> - I have removed the --script-language option, as it seemed to be ignored
> anyway.
> - --help output has changed a bit and now reads (note one has to pass
> --help-hidden to see
>   short option letters. again can be changed, but i think it makes the
> initial help more
>   readable):
>
> USAGE: lldb [options] 
>
> OPTIONS:
>
> General options:
>
>   -arch= - Tells the debugger to use the specified
> architecture when starting and running the program.   must be one
> of the architectures for which the program was compiled.
>   -attach-name=  - Tells the debugger to attach to a
> process with the given name.
>   -attach-pid= - Tells the debugger to attach to a
> process with the given pid
>   -batch - Tells the debugger to running the
> commands from -s, -S, -o & -O, and then quit.  However if any run command
> stopped due to a signal or crash, the debugger will return to the
> interactive prompt at the place of the crash.
>   -core= - Tells the debugger to use the file
>  as the core file.
>   -debug - Tells the debugger to print out extra
> information for debugging itself.
>   -editor- Tells the debugger to open source files
> using the host's "external editor" mechanism.
>   -file= - Tells the debugger to use the file
>  as the program to be debugged.
>   -no-lldbinit   - Do not automatically parse any
> '.lldbinit' files.
>   -no-use-colors - Do not use colors.
>   -one-line= - Tells the debugger to execute this
> one-line lldb command after any file provided on the command line has been
> loaded.
>   -one-line-before-file= - Tells the debugger to execute this
> one-line lldb command before any file provided on the command line has been
> loaded.
>   -one-line-on-crash=- When in batch mode, tells the debugger
> to execute this one-line lldb command if the target crashes.
>   -repl= - Runs lldb in REPL mode with a stub
> process.
>   -repl-langauge=- Chooses the language for the REPL.
>   -source=   - Tells the debugger to read in and
> execute the lldb commands in the given file, after any file provided on the
> command line has been loaded.
>   -source-before-file=   - Tells the debugger to read in and
> execute the lldb commands in the given file, before any file provided on
> the command line has been loaded.
>   -source-on-crash=  - When in batch mode, tells the debugger
> to source this file of lldb commands if the target crashes.
>   -source-quietly- Don't echo the commands when executing
> them.
>   -wait-for  - Tells the debugger to wait for a
> process with the given pid or name to launch before attaching.
>
> Generic Options:
>
>   -help  - Display available options (-help-hidden
> for more)
>   -help-list - Display list of available options
> (-help-list-hidden for more)
>   -version   - Display the version of this program
>
> If you don't provide -file then the first argument will be the file to be
> debugged which means that 'lldb --  [ []]' also
> works.  But remember to end the options with "--" if any of your
> arguments begin with "-".
>
> Multiple "-source" and "-one-line" options can be provided.  They will be
> processed from left to right in order, with the source files and commands
> interleaved.
>
> http://reviews.llvm.org/D17724
>
> Files:
>   packages/Python/lldbsuite/test/driver/batch_mode/TestBatchMode.py
>   packages/Python/lldbsuite/test/driver/batch_mode/source.file
>   packages/Python/lldbsuite/test/functionalities/format/TestFormats.py
>   tools/driver/Driver.cpp
>   tools/driver/Driver.h
>   tools/driver/Platform.h
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org

Re: [Lldb-commits] [PATCH] D17724: Replace getopt with llvm::cl in lldb driver

[Pavel Labath via lldb-commits]

labath added a comment.

Yes, we are, and unfortunately we can't get rid of it that easily there, as 
llvm:cl does not really have interactive uses in mind (global variables 
everywhere, --help kills your program, etc.). It probably wouldn't be **too** 
hard to add a version which can do that, as all the blocks are in place, but 
that's way out of my scope now. ;)


http://reviews.llvm.org/D17724



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

Re: [Lldb-commits] [PATCH] D17650: Fix TestInlines.py on Windows

[Adrian McCarthy via lldb-commits]

amccarth added a comment.

I'm going to interpret silence as consent.  This review was mostly FYI.


http://reviews.llvm.org/D17650



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

Re: [Lldb-commits] [lldb] r262041 - Fix bug with register values byte order in expression evaluation.

[Chaoren Lin via lldb-commits]

I think the issue is that on OS X, GetScalarValue fails to return false
when the value is *not* actually scalar. When it's not scalar, it should be
using WriteMemory instead, right? Or is it possible for GetScalarValue to
succeed but return something with a different byte size?

On Mon, Feb 29, 2016 at 10:05 AM, Marianne Mailhot-Sarrasin <
marianne1...@hotmail.com> wrote:

> Really sorry about the breakage.
>
> Is there anybody who understands what is the issue of using
> WriteScalarToMemory when the register value is a scalar?
>
> From my understanding, using WriteScalarToMemory handles the byte swap
> needed when the Host endianness is different from the Target endianness,
> which is not done by WriteMemory. Therefor using WriteScalarToMemory is
> fixing the evaluation of the registers on my out-of-tree target.
>
>
> 2016-02-29 11:06 GMT-05:00 Aidan Dodds :
>
>> Sorry about the breakage, and thanks for working on a patch Chaoren.
>> Hopefully Marianne will revise her merge request if this fix is still
>> important for her.
>>
>> On 28/02/2016 00:06, Todd Fiala wrote:
>>
>> I brought the state of the lines changed there to what they were prior to
>> the change. If you adjusted those same lines, then yes that got undone.
>>
>> We were failing different tests in those files.  Your change may have
>> fixed the new issues on Linux, but did not address the new failures on OS
>> X.  The OS X bot went green after the revert.
>>
>> -Todd
>>
>> On Feb 27, 2016, at 4:01 PM, Chaoren Lin < 
>> chaor...@google.com> wrote:
>>
>> I thought I fixed it with  
>> http://reviews.llvm.org/D17658. Did you revert that as well?
>>
>> On Sat, Feb 27, 2016 at 3:14 PM, Todd Fiala < 
>> todd.fi...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> The new assert was failing on the OS X testbot here:
>>> http://lab.llvm.org:8080/green/job/lldb_build_test/
>>>
>>> The nag mail didn't make it to you since we have it only fire on the
>>> transition from good build to bad build, and Tamas had the privilege of
>>> earning that with a minor Xcode breakage just shortly before this issue
>>> showed up.  However, that bot as been broken since this change went in.
>>>
>>> I reverted it in r262156.
>>>
>>> Feel free to reapply if you have a suggested fix for the test failure
>>> introduced.
>>>
>>> Thanks!
>>>
>>> -Todd
>>>
>>> On Fri, Feb 26, 2016 at 12:08 PM, Chaoren Lin via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 Hmm. Weird. That assert is failing on Linux:
 
 http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/11833

 On Fri, Feb 26, 2016 at 9:40 AM, Aidan Dodds via lldb-commits <
 lldb-commits@lists.llvm.org> wrote:

> Author: aidandodds
> Date: Fri Feb 26 11:40:50 2016
> New Revision: 262041
>
> URL: http://llvm.org/viewvc/llvm-project?rev=262041&view=rev
> Log:
> Fix bug with register values byte order in expression evaluation.
>
> The evaluation of expressions containing register values was broken
> for targets for which endianness differs from host.
>
> Committed on behalf of: mamai < 
> marianne.mailhot.sarra...@gmail.com>
>
> Differential revision: 
> http://reviews.llvm.org/D17167
>
> Modified:
> lldb/trunk/source/Expression/Materializer.cpp
>
> Modified: lldb/trunk/source/Expression/Materializer.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/Materializer.cpp?rev=262041&r1=262040&r2=262041&view=diff
>
> ==
> --- lldb/trunk/source/Expression/Materializer.cpp (original)
> +++ lldb/trunk/source/Expression/Materializer.cpp Fri Feb 26 11:40:50
> 2016
> @@ -26,6 +26,7 @@
>  #include "lldb/Target/StackFrame.h"
>  #include "lldb/Target/Target.h"
>  #include "lldb/Target/Thread.h"
> +#include "lldb/Utility/LLDBAssert.h"
>
>  using namespace lldb_private;
>
> @@ -1275,9 +1276,14 @@ public:
>  m_register_contents.reset(new
> DataBufferHeap(register_data.GetDataStart(), 
> register_data.GetByteSize()));
>
>  Error write_error;
> -
> -map.WriteMemory(load_addr, register_data.GetDataStart(),
> register_data.GetByteSize(), write_error);
> -
> +
> +Scalar scalar;
> +reg_value.GetScalarValue(scalar);
> +
> +lldbassert(scalar.GetByteSize() ==
> register_data.GetByteSize());
> +
> +map.WriteScalarToMemory(load_addr, scalar,
> scalar.GetByteSize(), write_error);
> +
>  if (!write_error.Success())
>  {
>  err.SetErrorStringWithFormat("couldn't write the contents
> of register %s: %s", m_register_info.name, write_error.AsCString(

Re: [Lldb-commits] [PATCH] D17363: Add SymbolFilePDB with basic support for line tables.

[Greg Clayton via lldb-commits]

> On Feb 26, 2016, at 3:33 PM, Zachary Turner  wrote:
> 
> Ok, so back to check_inlines.  I realized after I hit send that the 
> explanation I had written out is exactly what I thought I had to do for 
> check_inlines == true.  
> 
> I guess a concrete example would make it clearer.  If I have this code:
> 
> // foo.cpp
> #include "foo.h"
> 
> int main(int argc, char **argv) { return 0; }
> 
> 
> And I run this C++ code:
> 
> // After this, sc_list should have 1 entry.
> ResolveSymbolContext("foo.h", 0, true, eSymbolContextCompUnit, sc_list);
> 

1 entry yes.

> // After this, sc_list should have how many entries?  1 or 0?
> ResolveSymbolContext("foo.h", 0, false, eSymbolContextCompUnit, sc_list);

0 entries unless you actually have a compile unit for "foo.h" where "foo.h" 
_is_ the main compile unit file.

> how many entries are in sc_list after the second call?  If it's still 1, then 
> what is the difference with the first case?
> 
> Is the only difference what I put into the line tables?  In the 'true' case, 
> I fill out the line tables with all the contributions from foo.h, but in the 
> 'false' case I don't?  But both still return the same number of entries in 
> sc_list?

No. You fill in a SymbolContext for each line entry that matches. If 
check_inlines is true, you through the line table for your compile unit (where 
"foo.cpp" is your compile unit's main source file) and search for all line 
entries that match regardless of if "foo.h" == compile unit file ("foo.cpp"). 
If check_inlines is false, then you _only_ look through the line table if the 
file matches your compile unit file (in this case "foo.h" != "foo.cpp" so you 
wouldn't look at _any_ line entries in "foo.cpp".

> (Sorry this is so confusing, I'm planning to document this process as I go so 
> that the next person that comes along will be able to have all this 
> information up front)

This option should almost be removed and we should assume "check_inlines == 
true" all the time. It can save time sometimes, but the user really always 
wants "check_inlines == true". 

Greg

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

Re: [Lldb-commits] [PATCH] D17719: Track expression language from one place in ClangExpressionParser

[Greg Clayton via lldb-commits]

clayborg resigned from this revision.
clayborg removed a reviewer: clayborg.
clayborg added a comment.

I will let Sean review this one as the expression parser is his area of 
expertise.


http://reviews.llvm.org/D17719



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

Re: [Lldb-commits] [PATCH] D17710: Simplify GetGlobalProperties functions of Thread/Process/Target

[Greg Clayton via lldb-commits]

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

Looks good to me, commit when you know this will work with MSVC versions you 
need. All other platforms will be good to go.


http://reviews.llvm.org/D17710



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

Re: [Lldb-commits] [PATCH] D17363: Add SymbolFilePDB with basic support for line tables.

[Zachary Turner via lldb-commits]

Thanks!  I think I've got a handle on it.  I'll upload another patch this
week hopefully.

On Mon, Feb 29, 2016 at 10:30 AM Greg Clayton  wrote:

>
> > On Feb 26, 2016, at 3:33 PM, Zachary Turner  wrote:
> >
> > Ok, so back to check_inlines.  I realized after I hit send that the
> explanation I had written out is exactly what I thought I had to do for
> check_inlines == true.
> >
> > I guess a concrete example would make it clearer.  If I have this code:
> >
> > // foo.cpp
> > #include "foo.h"
> >
> > int main(int argc, char **argv) { return 0; }
> >
> >
> > And I run this C++ code:
> >
> > // After this, sc_list should have 1 entry.
> > ResolveSymbolContext("foo.h", 0, true, eSymbolContextCompUnit, sc_list);
> >
>
> 1 entry yes.
>
> > // After this, sc_list should have how many entries?  1 or 0?
> > ResolveSymbolContext("foo.h", 0, false, eSymbolContextCompUnit, sc_list);
>
> 0 entries unless you actually have a compile unit for "foo.h" where
> "foo.h" _is_ the main compile unit file.
>
> > how many entries are in sc_list after the second call?  If it's still 1,
> then what is the difference with the first case?
> >
> > Is the only difference what I put into the line tables?  In the 'true'
> case, I fill out the line tables with all the contributions from foo.h, but
> in the 'false' case I don't?  But both still return the same number of
> entries in sc_list?
>
> No. You fill in a SymbolContext for each line entry that matches. If
> check_inlines is true, you through the line table for your compile unit
> (where "foo.cpp" is your compile unit's main source file) and search for
> all line entries that match regardless of if "foo.h" == compile unit file
> ("foo.cpp"). If check_inlines is false, then you _only_ look through the
> line table if the file matches your compile unit file (in this case "foo.h"
> != "foo.cpp" so you wouldn't look at _any_ line entries in "foo.cpp".
>
> > (Sorry this is so confusing, I'm planning to document this process as I
> go so that the next person that comes along will be able to have all this
> information up front)
>
> This option should almost be removed and we should assume "check_inlines
> == true" all the time. It can save time sometimes, but the user really
> always wants "check_inlines == true".
>
> Greg
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D17724: Replace getopt with llvm::cl in lldb driver

[Greg Clayton via lldb-commits]

clayborg added a comment.

As long as both long and short options are still supported? Can you still type 
any of:

- --arch=x86_64
- --arch x86_64
- -arch=x86_64
- -arch x86_64
- -ax86_64
- -a x86_64

Are we able to track which options can be used with other options with the llvm 
solution? I didn't look too close. There were bits in the old option 
definitions which defined with options could be specified with which other 
options. The other thing that might throw people for a loop is if llvm doesn't 
support this style:

% lldb /bin/ls --arch=x86_64 -- -lAF

getopt_long allowed you to have arguments mixed in between the options so the 
arguments would have bee "/bin/ls" and "-lAF". Options would have been 
"--arch=x86_64".


http://reviews.llvm.org/D17724



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

Re: [Lldb-commits] [PATCH] D17724: Replace getopt with llvm::cl in lldb driver

[Zachary Turner via lldb-commits]

long and short options are supported, but the one I'm not sure about is the
case where you use a short option with no space.  Your example "-ax86_64"
might not work.  It might, just that it should be tested.  I'm 99%
confident the rest of them all work.

Also not sure about this example: "% lldb /bin/ls --arch=x86_64 -- -lAF"

If I understand correctly, this runs LLDB with the --arch=x86_64 argument,
and specifies the program to debug as "/bin/ls -IAF"?

Seems like a confusing syntax to me, is there any other way to specify this
currently?  like:

% lldb "/bin/ls -IAF" --arch=x86_64
% lldb /bin/ls --arch-x86_64 --args=-IAF

Or something along those lines?

On Mon, Feb 29, 2016 at 10:46 AM Greg Clayton  wrote:

> clayborg added a comment.
>
> As long as both long and short options are still supported? Can you still
> type any of:
>
> - --arch=x86_64
> - --arch x86_64
> - -arch=x86_64
> - -arch x86_64
> - -ax86_64
> - -a x86_64
>
> Are we able to track which options can be used with other options with the
> llvm solution? I didn't look too close. There were bits in the old option
> definitions which defined with options could be specified with which other
> options. The other thing that might throw people for a loop is if llvm
> doesn't support this style:
>
> % lldb /bin/ls --arch=x86_64 -- -lAF
>
> getopt_long allowed you to have arguments mixed in between the options so
> the arguments would have bee "/bin/ls" and "-lAF". Options would have been
> "--arch=x86_64".
>
>
> http://reviews.llvm.org/D17724
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D17724: Replace getopt with llvm::cl in lldb driver

[Greg Clayton via lldb-commits]

clayborg added a comment.

In http://reviews.llvm.org/D17724#364454, @zturner wrote:

> long and short options are supported, but the one I'm not sure about is the
>  case where you use a short option with no space.  Your example "-ax86_64"
>  might not work.  It might, just that it should be tested.  I'm 99%
>  confident the rest of them all work.
>
> Also not sure about this example: "% lldb /bin/ls --arch=x86_64 -- -lAF"
>
> If I understand correctly, this runs LLDB with the --arch=x86_64 argument,
>  and specifies the program to debug as "/bin/ls -IAF"?


Yes.

> Seems like a confusing syntax to me, is there any other way to specify this

>  currently?  like:

> 

> % lldb "/bin/ls -IAF" --arch=x86_64

>  % lldb /bin/ls --arch-x86_64 --args=-IAF

> 

> Or something along those lines?


Not sure, I am just pointing out what is going to change for people by making 
this switch due to the way getopt_long works.

For LLVM you might need to do this:

% lldb --arch=x86_64 -- /bin/ls -lAF

All args might need to be past all of the options and after the "--". I just 
don't know and was pointing out the differences people are likely to be 
confused by.


http://reviews.llvm.org/D17724



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

Re: [Lldb-commits] [PATCH] D17724: Replace getopt with llvm::cl in lldb driver

[Jim Ingham via lldb-commits]

The straightforward way to do specify a complex command line for debugging is:

lldb —arch=x86_64 — /bin/ls -IAF

everything after the — are arguments to the program.  This also allows you to 
cut & paste whole command lines.  It works by the trick that if you haven’t 
specified a file before the — then the first of these arguments will be the 
file.  The other way, where you supply the file in among the arguments was to 
accommodate the ordinary lldb usage in the case where you do something like:

lldb /bin/ls —arch=x86_64 — oops I forgot I wanted to add arguments

I don’t find either of these particularly confusing, the “—“ is used all over 
in unix & lldb, so that seems pretty straightforward, and I don’t think adding 
extra levels of quoting around the command line is going to make this any 
easier.

Jim


> On Feb 29, 2016, at 10:52 AM, Zachary Turner via lldb-commits 
>  wrote:
> 
> long and short options are supported, but the one I'm not sure about is the 
> case where you use a short option with no space.  Your example "-ax86_64" 
> might not work.  It might, just that it should be tested.  I'm 99% confident 
> the rest of them all work.
> 
> Also not sure about this example: "% lldb /bin/ls --arch=x86_64 -- -lAF"
> 
> If I understand correctly, this runs LLDB with the --arch=x86_64 argument, 
> and specifies the program to debug as "/bin/ls -IAF"?
> 
> Seems like a confusing syntax to me, is there any other way to specify this 
> currently?  like:
> 
> % lldb "/bin/ls -IAF" --arch=x86_64
> % lldb /bin/ls --arch-x86_64 --args=-IAF
> 
> Or something along those lines?
> 
> On Mon, Feb 29, 2016 at 10:46 AM Greg Clayton  > wrote:
> clayborg added a comment.
> 
> As long as both long and short options are still supported? Can you still 
> type any of:
> 
> - --arch=x86_64
> - --arch x86_64
> - -arch=x86_64
> - -arch x86_64
> - -ax86_64
> - -a x86_64
> 
> Are we able to track which options can be used with other options with the 
> llvm solution? I didn't look too close. There were bits in the old option 
> definitions which defined with options could be specified with which other 
> options. The other thing that might throw people for a loop is if llvm 
> doesn't support this style:
> 
> % lldb /bin/ls --arch=x86_64 -- -lAF
> 
> getopt_long allowed you to have arguments mixed in between the options so the 
> arguments would have bee "/bin/ls" and "-lAF". Options would have been 
> "--arch=x86_64".
> 
> 
> http://reviews.llvm.org/D17724 
> 
> 
> 
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

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

[Lldb-commits] [lldb] r262246 - Fix Clang-tidy modernize-use-nullptr warnings in source/Plugins/Language; other minor fixes.

[Eugene Zelenko via lldb-commits]

Author: eugenezelenko
Date: Mon Feb 29 13:41:30 2016
New Revision: 262246

URL: http://llvm.org/viewvc/llvm-project?rev=262246&view=rev
Log:
Fix Clang-tidy modernize-use-nullptr warnings in source/Plugins/Language; other 
minor fixes.

Modified:
lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxx.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxInitializerList.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxList.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxMap.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxVector.cpp
lldb/trunk/source/Plugins/Language/CPlusPlus/LibStdcpp.cpp
lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp
lldb/trunk/source/Plugins/Language/ObjC/NSArray.cpp
lldb/trunk/source/Plugins/Language/ObjC/NSDictionary.cpp
lldb/trunk/source/Plugins/Language/ObjC/NSSet.cpp
lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp
lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.h

Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp?rev=262246&r1=262245&r2=262246&view=diff
==
--- lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp 
(original)
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/CPlusPlusLanguage.cpp Mon Feb 
29 13:41:30 2016
@@ -1,4 +1,4 @@
-//===-- CPlusPlusLanguage.cpp --*- C++ 
-*-===//
+//===-- CPlusPlusLanguage.cpp ---*- C++ 
-*-===//
 //
 // The LLVM Compiler Infrastructure
 //
@@ -9,9 +9,17 @@
 
 #include "CPlusPlusLanguage.h"
 
+// C Includes
+// C++ Includes
+#include 
+#include 
+#include 
+#include 
 
+// Other libraries and framework includes
 #include "llvm/ADT/StringRef.h"
 
+// Project includes
 #include "lldb/Core/ConstString.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Core/RegularExpression.h"
@@ -26,11 +34,6 @@
 #include "LibCxxAtomic.h"
 #include "LibStdcpp.h"
 
-#include 
-#include 
-#include 
-#include 
-
 using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::formatters;
@@ -56,10 +59,10 @@ CPlusPlusLanguage::GetPluginNameStatic()
 return g_name;
 }
 
-
 //--
 // PluginInterface protocol
 //--
+
 lldb_private::ConstString
 CPlusPlusLanguage::GetPluginName()
 {
@@ -75,6 +78,7 @@ CPlusPlusLanguage::GetPluginVersion()
 //--
 // Static Functions
 //--
+
 Language *
 CPlusPlusLanguage::CreateInstance (lldb::LanguageType language)
 {
@@ -320,10 +324,7 @@ CPlusPlusLanguage::IsCPPMangledName (con
 // this is a C++ mangled name, but we can put that off till there is 
actually more than one
 // we care about.
 
-if (name && name[0] == '_' && name[1] == 'Z')
-return true;
-else
-return false;
+return (name != nullptr && name[0] == '_' && name[1] == 'Z');
 }
 
 bool
@@ -345,7 +346,6 @@ class CPPRuntimeEquivalents
 public:
 CPPRuntimeEquivalents ()
 {
-
 m_impl.Append(ConstString("std::basic_string, std::allocator >").AsCString(), 
ConstString("basic_string"));
 
 // these two (with a prefixed std::) occur when c++stdlib string class 
occurs as a template argument in some STL container
@@ -365,11 +365,10 @@ public:
 FindExactMatches (ConstString& type_name,
   std::vector& equivalents)
 {
-
 uint32_t count = 0;
 
 for (ImplData match = 
m_impl.FindFirstValueForName(type_name.AsCString());
- match != NULL;
+ match != nullptr;
  match = m_impl.FindNextValueForName(match))
 {
 equivalents.push_back(match->value);
@@ -388,7 +387,6 @@ public:
 FindPartialMatches (ConstString& type_name,
 std::vector& equivalents)
 {
-
 uint32_t count = 0;
 
 const char* type_name_cstr = type_name.AsCString();
@@ -407,11 +405,9 @@ public:
 }
 
 return count;
-
 }
 
 private:
-
 std::string& replace (std::string& target,
   std::string& pattern,
   std::string& with)
@@ -430,14 +426,13 @@ private:
 const char *matching_key,
 std::vector& equivalents)
 {
-
 std::string matching_key_str(matching_key);
 ConstString original_const(original);
 
 uint32_t count

[Lldb-commits] [lldb] r262254 - Add an LLDB data formatter for single-element NSArray and NSDictionary Cocoa containers

[Enrico Granata via lldb-commits]

Author: enrico
Date: Mon Feb 29 15:06:50 2016
New Revision: 262254

URL: http://llvm.org/viewvc/llvm-project?rev=262254&view=rev
Log:
Add an LLDB data formatter for single-element NSArray and NSDictionary Cocoa 
containers

Fixes rdar://23715118


Modified:
lldb/trunk/include/lldb/Core/ValueObject.h
lldb/trunk/include/lldb/Core/ValueObjectConstResult.h
lldb/trunk/include/lldb/Core/ValueObjectConstResultCast.h
lldb/trunk/include/lldb/Core/ValueObjectConstResultChild.h
lldb/trunk/include/lldb/Core/ValueObjectConstResultImpl.h
lldb/trunk/source/Core/ValueObject.cpp
lldb/trunk/source/Core/ValueObjectConstResult.cpp
lldb/trunk/source/Core/ValueObjectConstResultCast.cpp
lldb/trunk/source/Core/ValueObjectConstResultChild.cpp
lldb/trunk/source/Core/ValueObjectConstResultImpl.cpp
lldb/trunk/source/Plugins/Language/ObjC/NSArray.cpp
lldb/trunk/source/Plugins/Language/ObjC/NSDictionary.cpp
lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp

Modified: lldb/trunk/include/lldb/Core/ValueObject.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/ValueObject.h?rev=262254&r1=262253&r2=262254&view=diff
==
--- lldb/trunk/include/lldb/Core/ValueObject.h (original)
+++ lldb/trunk/include/lldb/Core/ValueObject.h Mon Feb 29 15:06:50 2016
@@ -699,7 +699,10 @@ public:
 GetSyntheticExpressionPathChild(const char* expression, bool can_create);
 
 virtual lldb::ValueObjectSP
-GetSyntheticChildAtOffset(uint32_t offset, const CompilerType& type, bool 
can_create);
+GetSyntheticChildAtOffset(uint32_t offset,
+  const CompilerType& type,
+  bool can_create,
+  ConstString name_const_str = ConstString());
 
 virtual lldb::ValueObjectSP
 GetSyntheticBase (uint32_t offset, const CompilerType& type, bool 
can_create);

Modified: lldb/trunk/include/lldb/Core/ValueObjectConstResult.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/ValueObjectConstResult.h?rev=262254&r1=262253&r2=262254&view=diff
==
--- lldb/trunk/include/lldb/Core/ValueObjectConstResult.h (original)
+++ lldb/trunk/include/lldb/Core/ValueObjectConstResult.h Mon Feb 29 15:06:50 
2016
@@ -97,7 +97,10 @@ public:
 CreateChildAtIndex(size_t idx, bool synthetic_array_member, int32_t 
synthetic_index) override;
 
 lldb::ValueObjectSP
-GetSyntheticChildAtOffset(uint32_t offset, const CompilerType& type, bool 
can_create) override;
+GetSyntheticChildAtOffset(uint32_t offset,
+  const CompilerType& type,
+  bool can_create,
+  ConstString name_const_str = ConstString()) 
override;
 
 lldb::ValueObjectSP
 AddressOf(Error &error) override;

Modified: lldb/trunk/include/lldb/Core/ValueObjectConstResultCast.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/ValueObjectConstResultCast.h?rev=262254&r1=262253&r2=262254&view=diff
==
--- lldb/trunk/include/lldb/Core/ValueObjectConstResultCast.h (original)
+++ lldb/trunk/include/lldb/Core/ValueObjectConstResultCast.h Mon Feb 29 
15:06:50 2016
@@ -47,7 +47,8 @@ public:
 lldb::ValueObjectSP
 GetSyntheticChildAtOffset(uint32_t offset,
   const CompilerType& type,
-  bool can_create) override;
+  bool can_create,
+  ConstString name_const_str = ConstString()) 
override;
 
 lldb::ValueObjectSP
 AddressOf (Error &error) override;

Modified: lldb/trunk/include/lldb/Core/ValueObjectConstResultChild.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/ValueObjectConstResultChild.h?rev=262254&r1=262253&r2=262254&view=diff
==
--- lldb/trunk/include/lldb/Core/ValueObjectConstResultChild.h (original)
+++ lldb/trunk/include/lldb/Core/ValueObjectConstResultChild.h Mon Feb 29 
15:06:50 2016
@@ -53,7 +53,10 @@ public:
 }
 
 lldb::ValueObjectSP
-GetSyntheticChildAtOffset(uint32_t offset, const CompilerType& type, bool 
can_create) override;
+GetSyntheticChildAtOffset(uint32_t offset,
+  const CompilerType& type,
+  bool can_create,
+  ConstString name_const_str = ConstString()) 
override;
 
 lldb::ValueObjectSP
 AddressOf (Error &error) override;

Modified: lldb/trunk/include/lldb/Core/ValueObjectConstResultImpl.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/ValueObjectConstResultImpl.h?rev=262254&r1=262253&r2=262254&view=diff
===

Re: [Lldb-commits] [PATCH] D17650: Fix TestInlines.py on Windows

[Adrian McCarthy via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL262255: Fix TestInlines.py on Windows (authored by amccarth).

Changed prior to commit:
  http://reviews.llvm.org/D17650?vs=49208&id=49409#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17650

Files:
  lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/Makefile
  lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/TestInlines.py
  lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/inlines.c
  lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/inlines.h
  lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/Makefile
  lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/TestInlines.py
  lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/inlines.cpp
  lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/inlines.h

Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/TestInlines.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/TestInlines.py
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/TestInlines.py
@@ -0,0 +1,52 @@
+"""Test variable lookup when stopped in inline functions."""
+
+from __future__ import print_function
+
+import os, time
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class InlinesTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def setUp(self):
+# Call super's setUp().
+TestBase.setUp(self)
+# Find the line number to break inside main().
+self.line = line_number('inlines.cpp', '// Set break point at this line.')
+
+@expectedFailureAll("llvm.org/pr26710", oslist=["linux"], compiler="gcc")
+def test(self):
+"""Test that local variables are visible in expressions."""
+self.build()
+self.runToBreakpoint()
+
+# Check that 'frame variable' finds a variable
+self.expect("frame variable inner_input", VARIABLES_DISPLAYED_CORRECTLY,
+startstr = '(int) inner_input =')
+
+# Check that 'expr' finds a variable
+self.expect("expr inner_input", VARIABLES_DISPLAYED_CORRECTLY,
+startstr = '(int) $0 =')
+
+def runToBreakpoint(self):
+exe = os.path.join(os.getcwd(), "a.out")
+self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
+
+# Break inside the main.
+lldbutil.run_break_set_by_file_and_line(self, "inlines.cpp", self.line, num_expected_locations=2,
+loc_exact=True)
+
+self.runCmd("run", RUN_SUCCEEDED)
+
+# The stop reason of the thread should be breakpoint.
+self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
+substrs = ['stopped',
+   'stop reason = breakpoint'])
+
+# The breakpoint should have a hit count of 1.
+self.expect("breakpoint list -f", BREAKPOINT_HIT_ONCE,
+substrs = [' resolved, hit count = 1'])
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/inlines.h
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/inlines.h
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/inlines.h
@@ -0,0 +1,4 @@
+int inner_inline (int inner_input, int mod_value);
+int outer_inline (int outer_input);
+int not_inlined_2 (int input);
+int not_inlined_1 (int input);
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/inlines.cpp
===
--- lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/inlines.cpp
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/inlines.cpp
@@ -0,0 +1,53 @@
+#include 
+#include "inlines.h"
+
+#define INLINE_ME __inline__ __attribute__((always_inline))
+
+int
+not_inlined_2 (int input)
+{
+  printf ("Called in not_inlined_2 with : %d.\n", input);
+  return input;
+}
+
+int 
+not_inlined_1 (int input)
+{
+  printf ("Called in not_inlined_1 with %d.\n", input);
+  return not_inlined_2(input);
+}
+  
+INLINE_ME int
+inner_inline (int inner_input, int mod_value)
+{
+  int inner_result;
+  inner_result = inner_input % mod_value;
+  printf ("Returning: %d.\n", inner_result);
+  return not_inlined_1 (inner_result); // Set break point at this line.
+}
+
+INLINE_ME int
+outer_inline (int outer_input)
+{
+  int outer_result;
+
+  outer_result = inner_inline (outer_input, outer_input % 3);
+  return outer_result;
+}
+
+int
+main (int argc, char **argv)
+{
+  printf ("Starting...\n");
+
+  int (*func_ptr) (int);
+  func_ptr = outer_inline;
+
+  outer_inline (argc);
+
+  func_ptr (argc);
+
+  return 0;
+}
+
+
Index: lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/Makefile
==

[Lldb-commits] [lldb] r262255 - Fix TestInlines.py on Windows

[Adrian McCarthy via lldb-commits]

Author: amccarth
Date: Mon Feb 29 15:13:29 2016
New Revision: 262255

URL: http://llvm.org/viewvc/llvm-project?rev=262255&view=rev
Log:
Fix TestInlines.py on Windows

The inlining semantics for C and C++ are different, which affects the test's 
expectation of the number of times the function should appear in the binary.  
In the case of this test, C semantics means there should be three instances of 
inner_inline, while C++ semantics means there should be only two.

On Windows, clang uses C++ inline semantics even for C code, and there doesn't 
seem to be a combination of compiler flags to avoid this.

So, for consistency, I've recast the test to use C++ everywhere.  Since the 
test resided under lang/c, it seemed appropriate to move it to lang/cpp.

This does not address the other XFAIL for this test on Linux/gcc.  See 
https://llvm.org/bugs/show_bug.cgi?id=26710

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

Added:
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/Makefile
  - copied, changed from r262028, 
lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/Makefile
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/TestInlines.py
  - copied, changed from r262028, 
lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/TestInlines.py
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/inlines.cpp
  - copied, changed from r262028, 
lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/inlines.c
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/inlines/inlines.h
  - copied, changed from r262028, 
lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/inlines.h
Removed:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/Makefile
lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/TestInlines.py
lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/inlines.c
lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/inlines.h

Removed: lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/Makefile?rev=262254&view=auto
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/Makefile (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/Makefile (removed)
@@ -1,5 +0,0 @@
-LEVEL = ../../../make
-
-C_SOURCES := inlines.c
-
-include $(LEVEL)/Makefile.rules

Removed: lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/TestInlines.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/TestInlines.py?rev=262254&view=auto
==
--- lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/TestInlines.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/lang/c/inlines/TestInlines.py 
(removed)
@@ -1,52 +0,0 @@
-"""Test variable lookup when stopped in inline functions."""
-
-from __future__ import print_function
-
-import os, time
-import lldb
-from lldbsuite.test.decorators import *
-from lldbsuite.test.lldbtest import *
-from lldbsuite.test import lldbutil
-
-class InlinesTestCase(TestBase):
-
-mydir = TestBase.compute_mydir(__file__)
-
-def setUp(self):
-# Call super's setUp().
-TestBase.setUp(self)
-# Find the line number to break inside main().
-self.line = line_number('inlines.c', '// Set break point at this 
line.')
-
-@expectedFailureAll("llvm.org/pr26710", oslist=["linux"], compiler="gcc")
-@expectedFailureAll("llvm.org/pr26710", oslist=["windows"], 
compiler="clang")
-def test(self):
-"""Test that local variables are visible in expressions."""
-self.build()
-self.runToBreakpoint()
-
-# Check that 'frame variable' finds a variable
-self.expect("frame variable inner_input", 
VARIABLES_DISPLAYED_CORRECTLY,
-startstr = '(int) inner_input =')
-
-# Check that 'expr' finds a variable
-self.expect("expr inner_input", VARIABLES_DISPLAYED_CORRECTLY,
-startstr = '(int) $0 =')
-
-def runToBreakpoint(self):
-exe = os.path.join(os.getcwd(), "a.out")
-self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
-
-# Break inside the main.
-lldbutil.run_break_set_by_file_and_line (self, "inlines.c", self.line, 
num_expected_locations=3, loc_exact=True)
-
-self.runCmd("run", RUN_SUCCEEDED)
-
-# The stop reason of the thread should be breakpoint.
-self.expect("thread list", STOPPED_DUE_TO_BREAKPOINT,
-substrs = ['stopped',
-   'stop reason = breakpoint'])
-
-# The breakpoint should have a hit count of 1.
-self.expect("breakpoint list -f", BREAKPOIN

[Lldb-commits] [lldb] r262256 - NFC: Refactor ProcessWinMiniDump to use a more traditional pimpl idiom.

[Adrian McCarthy via lldb-commits]

Author: amccarth
Date: Mon Feb 29 15:15:23 2016
New Revision: 262256

URL: http://llvm.org/viewvc/llvm-project?rev=262256&view=rev
Log:
NFC:  Refactor ProcessWinMiniDump to use a more traditional pimpl idiom.

This is a mechanical refactor.  There should be no functional changes in this 
commit.

Instead of encapsulating just the Windows-specific data, ProcessWinMiniDump now 
uses a private implementation class.  This reduces indirections (in the 
source).  It makes it easier to add private helper methods without touching the 
header and allows them to have platform-specific types as parameters.  The only 
trick was that the pimpl class needed a back pointer in order to call a couple 
methods.

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

Modified: 
lldb/trunk/source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp?rev=262256&r1=262255&r2=262256&view=diff
==
--- lldb/trunk/source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp 
(original)
+++ lldb/trunk/source/Plugins/Process/Windows/MiniDump/ProcessWinMiniDump.cpp 
Mon Feb 29 15:15:23 2016
@@ -43,44 +43,75 @@
 
 using namespace lldb_private;
 
-namespace
+// Implementation class for ProcessWinMiniDump encapsulates the 
Windows-specific
+// code, keeping non-portable types out of the header files.
+// TODO(amccarth):  Determine if we need a mutex for access.  Given that this 
is
+// postmortem debugging, I don't think so.
+class ProcessWinMiniDump::Impl
 {
+public:
+Impl(const FileSpec &core_file, ProcessWinMiniDump *self);
+~Impl();
 
-// Getting a string out of a mini dump is a chore.  You're usually given a
-// relative virtual address (RVA), which points to a counted string that's in
-// Windows Unicode (UTF-16).  This wrapper handles all the redirection and
-// returns a UTF-8 copy of the string.
-std::string
-GetMiniDumpString(const void *base_addr, const RVA rva)
-{
-std::string result;
-if (!base_addr)
+Error
+DoLoadCore();
+
+bool
+UpdateThreadList(ThreadList &old_thread_list, ThreadList &new_thread_list);
+
+void
+RefreshStateAfterStop();
+
+size_t
+DoReadMemory(lldb::addr_t addr, void *buf, size_t size, Error &error);
+
+Error
+GetMemoryRegionInfo(lldb::addr_t load_addr, lldb_private::MemoryRegionInfo 
&info);
+
+private:
+// Describes a range of memory captured in the mini dump.
+struct Range
 {
-return result;
-}
-auto md_string = reinterpret_cast(static_cast(base_addr) + rva);
-auto source_start = reinterpret_cast(md_string->Buffer);
-const auto source_length = ::wcslen(md_string->Buffer);
-const auto source_end = source_start + source_length;
-result.resize(4*source_length);  // worst case length
-auto result_start = reinterpret_cast(&result[0]);
-const auto result_end = result_start + result.size();
-ConvertUTF16toUTF8(&source_start, source_end, &result_start, result_end, 
strictConversion);
-const auto result_size = std::distance(reinterpret_cast(&result[0]), result_start);
-result.resize(result_size);  // shrink to actual length
-return result;
-}
+lldb::addr_t start; // virtual address of the beginning of the range
+size_t size;// size of the range in bytes
+const uint8_t *ptr; // absolute pointer to the first byte of the range
+};
 
-}  // anonymous namespace
+// If the mini dump has a memory range that contains the desired address, 
it
+// returns true with the details of the range in *range_out.  Otherwise, it
+// returns false.
+bool
+FindMemoryRange(lldb::addr_t addr, Range *range_out) const;
 
-// Encapsulates the private data for ProcessWinMiniDump.
-// TODO(amccarth):  Determine if we need a mutex for access.
-class ProcessWinMiniDump::Data
-{
-public:
-Data();
-~Data();
+lldb_private::Error
+MapMiniDumpIntoMemory();
 
+lldb_private::ArchSpec
+DetermineArchitecture();
+
+void
+ReadExceptionRecord();
+
+void
+ReadMiscInfo();
+
+void
+ReadModuleList();
+
+// A thin wrapper around WinAPI's MiniDumpReadDumpStream to avoid redundant
+// checks.  If there's a failure (e.g., if the requested stream doesn't 
exist),
+// the function returns nullptr and sets *size_out to 0.
+void *
+FindDumpStream(unsigned stream_number, size_t *size_out) const;
+
+// Getting a string out of a mini dump is a chore.  You're usually given a
+// relative virtual address (RVA), which points to a counted string that's 
in
+// Windows Unicode (UTF-16).  This wrapper handles all the redirection and
+// returns a UTF-8 copy of the string.
+std::string
+GetMiniDumpString(RVA r

Re: [Lldb-commits] [PATCH] D17363: Add SymbolFilePDB with basic support for line tables.

[Zachary Turner via lldb-commits]

I'm running into what I think is the final issue.  My SymbolFilePDB plugin
creates created many many times.  Specifically, every single call to
SymbolVendor::FindPlugin(module) will cause a brand new instance of
SymbolFilePDB to get created.  This effectively kills any caching I've got
going on, and causes the PDB to get parsed numerous times, but worse is an
actual bug since I have to be able to persist certain values across calls
to a plugin for the same executable.

Any thoughts how to solve this?  In this particular case that's failing,
I'm calling SymbolVendor::FindPlugin(module) to get the initial SymbolFile
plugin, then parsing some things, then calling I'm calling
LineTable::FindLineEntryByAddress().  This tries to grab the support files,
but it does so against a brand new instance of SymbolFilePDB, and it's
impossible for me to do the lookup this way, I need the same SymbolFilePDB
pointer that I created originally.

On Mon, Feb 29, 2016 at 10:40 AM Zachary Turner  wrote:

> Thanks!  I think I've got a handle on it.  I'll upload another patch this
> week hopefully.
>
> On Mon, Feb 29, 2016 at 10:30 AM Greg Clayton  wrote:
>
>>
>> > On Feb 26, 2016, at 3:33 PM, Zachary Turner  wrote:
>> >
>> > Ok, so back to check_inlines.  I realized after I hit send that the
>> explanation I had written out is exactly what I thought I had to do for
>> check_inlines == true.
>> >
>> > I guess a concrete example would make it clearer.  If I have this code:
>> >
>> > // foo.cpp
>> > #include "foo.h"
>> >
>> > int main(int argc, char **argv) { return 0; }
>> >
>> >
>> > And I run this C++ code:
>> >
>> > // After this, sc_list should have 1 entry.
>> > ResolveSymbolContext("foo.h", 0, true, eSymbolContextCompUnit, sc_list);
>> >
>>
>> 1 entry yes.
>>
>> > // After this, sc_list should have how many entries?  1 or 0?
>> > ResolveSymbolContext("foo.h", 0, false, eSymbolContextCompUnit,
>> sc_list);
>>
>> 0 entries unless you actually have a compile unit for "foo.h" where
>> "foo.h" _is_ the main compile unit file.
>>
>> > how many entries are in sc_list after the second call?  If it's still
>> 1, then what is the difference with the first case?
>> >
>> > Is the only difference what I put into the line tables?  In the 'true'
>> case, I fill out the line tables with all the contributions from foo.h, but
>> in the 'false' case I don't?  But both still return the same number of
>> entries in sc_list?
>>
>> No. You fill in a SymbolContext for each line entry that matches. If
>> check_inlines is true, you through the line table for your compile unit
>> (where "foo.cpp" is your compile unit's main source file) and search for
>> all line entries that match regardless of if "foo.h" == compile unit file
>> ("foo.cpp"). If check_inlines is false, then you _only_ look through the
>> line table if the file matches your compile unit file (in this case "foo.h"
>> != "foo.cpp" so you wouldn't look at _any_ line entries in "foo.cpp".
>>
>> > (Sorry this is so confusing, I'm planning to document this process as I
>> go so that the next person that comes along will be able to have all this
>> information up front)
>>
>> This option should almost be removed and we should assume "check_inlines
>> == true" all the time. It can save time sometimes, but the user really
>> always wants "check_inlines == true".
>>
>> Greg
>>
>>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r262259 - Change the user-visible name for the argument type language to source-language

[Enrico Granata via lldb-commits]

Author: enrico
Date: Mon Feb 29 15:37:01 2016
New Revision: 262259

URL: http://llvm.org/viewvc/llvm-project?rev=262259&view=rev
Log:
Change the user-visible name for the argument type language to source-language

This makes it so that help language provides help on the language command and 
help source-language provides the list of source languages one can pass as an 
option

Fixes rdar://24869942


Modified:
lldb/trunk/source/Interpreter/CommandObject.cpp

Modified: lldb/trunk/source/Interpreter/CommandObject.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/CommandObject.cpp?rev=262259&r1=262258&r2=262259&view=diff
==
--- lldb/trunk/source/Interpreter/CommandObject.cpp (original)
+++ lldb/trunk/source/Interpreter/CommandObject.cpp Mon Feb 29 15:37:01 2016
@@ -1170,7 +1170,7 @@ CommandObject::g_arguments_data[] =
 { eArgTypeGDBFormat, "gdb-format", CommandCompletions::eNoCompletion, { 
GDBFormatHelpTextCallback, true }, nullptr },
 { eArgTypeHelpText, "help-text", CommandCompletions::eNoCompletion, { 
nullptr, false }, "Text to be used as help for some other entity in LLDB" },
 { eArgTypeIndex, "index", CommandCompletions::eNoCompletion, { nullptr, 
false }, "An index into a list." },
-{ eArgTypeLanguage, "language", CommandCompletions::eNoCompletion, { 
LanguageTypeHelpTextCallback, true }, nullptr },
+{ eArgTypeLanguage, "source-language", CommandCompletions::eNoCompletion, 
{ LanguageTypeHelpTextCallback, true }, nullptr },
 { eArgTypeLineNum, "linenum", CommandCompletions::eNoCompletion, { 
nullptr, false }, "Line number in a source file." },
 { eArgTypeLogCategory, "log-category", CommandCompletions::eNoCompletion, 
{ nullptr, false }, "The name of a category within a log channel, e.g. all (try 
\"log list\" to see a list of all channels and their categories." },
 { eArgTypeLogChannel, "log-channel", CommandCompletions::eNoCompletion, { 
nullptr, false }, "The name of a log channel, e.g. process.gdb-remote (try 
\"log list\" to see a list of all channels and their categories)." },


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

[Lldb-commits] [lldb] r262260 - Fix a typo in my previous commit. This would cause mutable NSArrays to show up empty

[Enrico Granata via lldb-commits]

Author: enrico
Date: Mon Feb 29 15:41:19 2016
New Revision: 262260

URL: http://llvm.org/viewvc/llvm-project?rev=262260&view=rev
Log:
Fix a typo in my previous commit. This would cause mutable NSArrays to show up 
empty

Modified:
lldb/trunk/source/Plugins/Language/ObjC/NSArray.cpp

Modified: lldb/trunk/source/Plugins/Language/ObjC/NSArray.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/ObjC/NSArray.cpp?rev=262260&r1=262259&r2=262260&view=diff
==
--- lldb/trunk/source/Plugins/Language/ObjC/NSArray.cpp (original)
+++ lldb/trunk/source/Plugins/Language/ObjC/NSArray.cpp Mon Feb 29 15:41:19 2016
@@ -788,7 +788,7 @@ SyntheticChildrenFrontEnd* lldb_private:
 {
 return (new NSArrayISyntheticFrontEnd(valobj_sp));
 }
-else if (class_name == g_NSArrayM)
+else if (class_name == g_NSArray0)
 {
 return (new NSArray0SyntheticFrontEnd(valobj_sp));
 }


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

Re: [Lldb-commits] [PATCH] D17363: Add SymbolFilePDB with basic support for line tables.

[Zachary Turner via lldb-commits]

I guess I could make the CreateInstance() method of SymbolFilePDB do some
"smarts" to cache instances of SymbolFilePDB already created, and either
return those or create a new one depending on whether we've loaded an
instance for the requested executable or not.

On Mon, Feb 29, 2016 at 1:26 PM Zachary Turner  wrote:

> I'm running into what I think is the final issue.  My SymbolFilePDB plugin
> creates created many many times.  Specifically, every single call to
> SymbolVendor::FindPlugin(module) will cause a brand new instance of
> SymbolFilePDB to get created.  This effectively kills any caching I've got
> going on, and causes the PDB to get parsed numerous times, but worse is an
> actual bug since I have to be able to persist certain values across calls
> to a plugin for the same executable.
>
> Any thoughts how to solve this?  In this particular case that's failing,
> I'm calling SymbolVendor::FindPlugin(module) to get the initial SymbolFile
> plugin, then parsing some things, then calling I'm calling
> LineTable::FindLineEntryByAddress().  This tries to grab the support files,
> but it does so against a brand new instance of SymbolFilePDB, and it's
> impossible for me to do the lookup this way, I need the same SymbolFilePDB
> pointer that I created originally.
>
> On Mon, Feb 29, 2016 at 10:40 AM Zachary Turner 
> wrote:
>
>> Thanks!  I think I've got a handle on it.  I'll upload another patch this
>> week hopefully.
>>
>> On Mon, Feb 29, 2016 at 10:30 AM Greg Clayton  wrote:
>>
>>>
>>> > On Feb 26, 2016, at 3:33 PM, Zachary Turner 
>>> wrote:
>>> >
>>> > Ok, so back to check_inlines.  I realized after I hit send that the
>>> explanation I had written out is exactly what I thought I had to do for
>>> check_inlines == true.
>>> >
>>> > I guess a concrete example would make it clearer.  If I have this code:
>>> >
>>> > // foo.cpp
>>> > #include "foo.h"
>>> >
>>> > int main(int argc, char **argv) { return 0; }
>>> >
>>> >
>>> > And I run this C++ code:
>>> >
>>> > // After this, sc_list should have 1 entry.
>>> > ResolveSymbolContext("foo.h", 0, true, eSymbolContextCompUnit,
>>> sc_list);
>>> >
>>>
>>> 1 entry yes.
>>>
>>> > // After this, sc_list should have how many entries?  1 or 0?
>>> > ResolveSymbolContext("foo.h", 0, false, eSymbolContextCompUnit,
>>> sc_list);
>>>
>>> 0 entries unless you actually have a compile unit for "foo.h" where
>>> "foo.h" _is_ the main compile unit file.
>>>
>>> > how many entries are in sc_list after the second call?  If it's still
>>> 1, then what is the difference with the first case?
>>> >
>>> > Is the only difference what I put into the line tables?  In the 'true'
>>> case, I fill out the line tables with all the contributions from foo.h, but
>>> in the 'false' case I don't?  But both still return the same number of
>>> entries in sc_list?
>>>
>>> No. You fill in a SymbolContext for each line entry that matches. If
>>> check_inlines is true, you through the line table for your compile unit
>>> (where "foo.cpp" is your compile unit's main source file) and search for
>>> all line entries that match regardless of if "foo.h" == compile unit file
>>> ("foo.cpp"). If check_inlines is false, then you _only_ look through the
>>> line table if the file matches your compile unit file (in this case "foo.h"
>>> != "foo.cpp" so you wouldn't look at _any_ line entries in "foo.cpp".
>>>
>>> > (Sorry this is so confusing, I'm planning to document this process as
>>> I go so that the next person that comes along will be able to have all this
>>> information up front)
>>>
>>> This option should almost be removed and we should assume "check_inlines
>>> == true" all the time. It can save time sometimes, but the user really
>>> always wants "check_inlines == true".
>>>
>>> Greg
>>>
>>>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D17363: Add SymbolFilePDB with basic support for line tables.

[Greg Clayton via lldb-commits]

You shouldn't have to do any of this. There should be a 1 to 1 mapping between 
a Module and a SymbolVendor which has a single SymbolFile. My guess is that you 
should just return:

kAllAbilities

for SymbolFilePDB::CalculateAbilities (). Try that and let me know how this 
goes. These abilities are bit fields and it becomes hard to compare the 
abilities returned from a symbol file if they don't match. 

To make sure you understand: for a given module, we should attempt to find a 
SymbolVendor/SymbolFile 1 time. We will iterate through all SymbolFile plugins 
and pick the one with the best abilities. SymbolFileSymtab might be returning a 
mask of things it can return that are greater than the one returned from 
SymbolFilePDB. So if you return kAllAbilities from 
SymbolFilePDB::CalculateAbilities() it will ensure that SymbolFilePDB is picked 
(make sure no one else is returning this) and your Module should have the same 
SymbolVendor/SymbolFile for the life of the lldb_private::Module. If that isn't 
happening that is a bug that you will need to fix. DWARF creates a single 
instance.

No need to do any fancy caching to any other work around.

Greg

> On Feb 29, 2016, at 1:26 PM, Zachary Turner  wrote:
> 
> I'm running into what I think is the final issue.  My SymbolFilePDB plugin 
> creates created many many times.  Specifically, every single call to 
> SymbolVendor::FindPlugin(module) will cause a brand new instance of 
> SymbolFilePDB to get created.  This effectively kills any caching I've got 
> going on, and causes the PDB to get parsed numerous times, but worse is an 
> actual bug since I have to be able to persist certain values across calls to 
> a plugin for the same executable.
> 
> Any thoughts how to solve this?  In this particular case that's failing, I'm 
> calling SymbolVendor::FindPlugin(module) to get the initial SymbolFile 
> plugin, then parsing some things, then calling I'm calling 
> LineTable::FindLineEntryByAddress().  This tries to grab the support files, 
> but it does so against a brand new instance of SymbolFilePDB, and it's 
> impossible for me to do the lookup this way, I need the same SymbolFilePDB 
> pointer that I created originally.
> 
> On Mon, Feb 29, 2016 at 10:40 AM Zachary Turner  wrote:
> Thanks!  I think I've got a handle on it.  I'll upload another patch this 
> week hopefully.
> 
> On Mon, Feb 29, 2016 at 10:30 AM Greg Clayton  wrote:
> 
> > On Feb 26, 2016, at 3:33 PM, Zachary Turner  wrote:
> >
> > Ok, so back to check_inlines.  I realized after I hit send that the 
> > explanation I had written out is exactly what I thought I had to do for 
> > check_inlines == true.
> >
> > I guess a concrete example would make it clearer.  If I have this code:
> >
> > // foo.cpp
> > #include "foo.h"
> >
> > int main(int argc, char **argv) { return 0; }
> >
> >
> > And I run this C++ code:
> >
> > // After this, sc_list should have 1 entry.
> > ResolveSymbolContext("foo.h", 0, true, eSymbolContextCompUnit, sc_list);
> >
> 
> 1 entry yes.
> 
> > // After this, sc_list should have how many entries?  1 or 0?
> > ResolveSymbolContext("foo.h", 0, false, eSymbolContextCompUnit, sc_list);
> 
> 0 entries unless you actually have a compile unit for "foo.h" where "foo.h" 
> _is_ the main compile unit file.
> 
> > how many entries are in sc_list after the second call?  If it's still 1, 
> > then what is the difference with the first case?
> >
> > Is the only difference what I put into the line tables?  In the 'true' 
> > case, I fill out the line tables with all the contributions from foo.h, but 
> > in the 'false' case I don't?  But both still return the same number of 
> > entries in sc_list?
> 
> No. You fill in a SymbolContext for each line entry that matches. If 
> check_inlines is true, you through the line table for your compile unit 
> (where "foo.cpp" is your compile unit's main source file) and search for all 
> line entries that match regardless of if "foo.h" == compile unit file 
> ("foo.cpp"). If check_inlines is false, then you _only_ look through the line 
> table if the file matches your compile unit file (in this case "foo.h" != 
> "foo.cpp" so you wouldn't look at _any_ line entries in "foo.cpp".
> 
> > (Sorry this is so confusing, I'm planning to document this process as I go 
> > so that the next person that comes along will be able to have all this 
> > information up front)
> 
> This option should almost be removed and we should assume "check_inlines == 
> true" all the time. It can save time sometimes, but the user really always 
> wants "check_inlines == true".
> 
> Greg
> 

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

Re: [Lldb-commits] [PATCH] D17363: Add SymbolFilePDB with basic support for line tables.

[Zachary Turner via lldb-commits]

I think I see the problem.  Somewhere I was calling
SymbolVendor::FindPlugin(module) instead of module->GetSymbolVendor()


On Mon, Feb 29, 2016 at 2:48 PM Greg Clayton  wrote:

> You shouldn't have to do any of this. There should be a 1 to 1 mapping
> between a Module and a SymbolVendor which has a single SymbolFile. My guess
> is that you should just return:
>
> kAllAbilities
>
> for SymbolFilePDB::CalculateAbilities (). Try that and let me know how
> this goes. These abilities are bit fields and it becomes hard to compare
> the abilities returned from a symbol file if they don't match.
>
> To make sure you understand: for a given module, we should attempt to find
> a SymbolVendor/SymbolFile 1 time. We will iterate through all SymbolFile
> plugins and pick the one with the best abilities. SymbolFileSymtab might be
> returning a mask of things it can return that are greater than the one
> returned from SymbolFilePDB. So if you return kAllAbilities from
> SymbolFilePDB::CalculateAbilities() it will ensure that SymbolFilePDB is
> picked (make sure no one else is returning this) and your Module should
> have the same SymbolVendor/SymbolFile for the life of the
> lldb_private::Module. If that isn't happening that is a bug that you will
> need to fix. DWARF creates a single instance.
>
> No need to do any fancy caching to any other work around.
>
> Greg
>
> > On Feb 29, 2016, at 1:26 PM, Zachary Turner  wrote:
> >
> > I'm running into what I think is the final issue.  My SymbolFilePDB
> plugin creates created many many times.  Specifically, every single call to
> SymbolVendor::FindPlugin(module) will cause a brand new instance of
> SymbolFilePDB to get created.  This effectively kills any caching I've got
> going on, and causes the PDB to get parsed numerous times, but worse is an
> actual bug since I have to be able to persist certain values across calls
> to a plugin for the same executable.
> >
> > Any thoughts how to solve this?  In this particular case that's failing,
> I'm calling SymbolVendor::FindPlugin(module) to get the initial SymbolFile
> plugin, then parsing some things, then calling I'm calling
> LineTable::FindLineEntryByAddress().  This tries to grab the support files,
> but it does so against a brand new instance of SymbolFilePDB, and it's
> impossible for me to do the lookup this way, I need the same SymbolFilePDB
> pointer that I created originally.
> >
> > On Mon, Feb 29, 2016 at 10:40 AM Zachary Turner 
> wrote:
> > Thanks!  I think I've got a handle on it.  I'll upload another patch
> this week hopefully.
> >
> > On Mon, Feb 29, 2016 at 10:30 AM Greg Clayton 
> wrote:
> >
> > > On Feb 26, 2016, at 3:33 PM, Zachary Turner 
> wrote:
> > >
> > > Ok, so back to check_inlines.  I realized after I hit send that the
> explanation I had written out is exactly what I thought I had to do for
> check_inlines == true.
> > >
> > > I guess a concrete example would make it clearer.  If I have this code:
> > >
> > > // foo.cpp
> > > #include "foo.h"
> > >
> > > int main(int argc, char **argv) { return 0; }
> > >
> > >
> > > And I run this C++ code:
> > >
> > > // After this, sc_list should have 1 entry.
> > > ResolveSymbolContext("foo.h", 0, true, eSymbolContextCompUnit,
> sc_list);
> > >
> >
> > 1 entry yes.
> >
> > > // After this, sc_list should have how many entries?  1 or 0?
> > > ResolveSymbolContext("foo.h", 0, false, eSymbolContextCompUnit,
> sc_list);
> >
> > 0 entries unless you actually have a compile unit for "foo.h" where
> "foo.h" _is_ the main compile unit file.
> >
> > > how many entries are in sc_list after the second call?  If it's still
> 1, then what is the difference with the first case?
> > >
> > > Is the only difference what I put into the line tables?  In the 'true'
> case, I fill out the line tables with all the contributions from foo.h, but
> in the 'false' case I don't?  But both still return the same number of
> entries in sc_list?
> >
> > No. You fill in a SymbolContext for each line entry that matches. If
> check_inlines is true, you through the line table for your compile unit
> (where "foo.cpp" is your compile unit's main source file) and search for
> all line entries that match regardless of if "foo.h" == compile unit file
> ("foo.cpp"). If check_inlines is false, then you _only_ look through the
> line table if the file matches your compile unit file (in this case "foo.h"
> != "foo.cpp" so you wouldn't look at _any_ line entries in "foo.cpp".
> >
> > > (Sorry this is so confusing, I'm planning to document this process as
> I go so that the next person that comes along will be able to have all this
> information up front)
> >
> > This option should almost be removed and we should assume "check_inlines
> == true" all the time. It can save time sometimes, but the user really
> always wants "check_inlines == true".
> >
> > Greg
> >
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/l

[Lldb-commits] [lldb] r262271 - When 'help' cannot find a command, produce additional help text that also points the user to the apropos and type lookup commands

[Enrico Granata via lldb-commits]

Author: enrico
Date: Mon Feb 29 17:22:53 2016
New Revision: 262271

URL: http://llvm.org/viewvc/llvm-project?rev=262271&view=rev
Log:
When 'help' cannot find a command, produce additional help text that also 
points the user to the apropos and type lookup commands

This is useful in cases such as, e.g.

(lldb) help NSString
(the user meant type lookup)

or

(lldb) help kill
(the user is looking for process kill)

Fixes rdar://24868537


Modified:
lldb/trunk/packages/Python/lldbsuite/test/help/TestHelp.py
lldb/trunk/source/Commands/CommandObjectCommands.cpp
lldb/trunk/source/Commands/CommandObjectHelp.cpp
lldb/trunk/source/Commands/CommandObjectHelp.h
lldb/trunk/source/Commands/CommandObjectSyntax.cpp

Modified: lldb/trunk/packages/Python/lldbsuite/test/help/TestHelp.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/help/TestHelp.py?rev=262271&r1=262270&r2=262271&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/help/TestHelp.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/help/TestHelp.py Mon Feb 29 
17:22:53 2016
@@ -165,3 +165,18 @@ class HelpCommandTestCase(TestBase):
 substrs = ['The following subcommands are supported:'],
 patterns = ['expression +--',
 'variable +--'])
+
+@no_debug_info_test
+def test_help_provides_alternatives(self):
+"""Test that help on commands that don't exist provides information on 
additional help avenues"""
+self.expect("help thisisnotadebuggercommand",
+substrs = ["'thisisnotadebuggercommand' is not a known command.",
+"Try 'help' to see a current list of commands.",
+"Try 'apropos thisisnotadebuggercommand' for a list of related 
commands.",
+"Try 'type lookup thisisnotadebuggercommand' for information on 
types, methods, functions, modules, etc."], error=True)
+
+self.expect("help process thisisnotadebuggercommand",
+substrs = ["'process thisisnotadebuggercommand' is not a known 
command.",
+"Try 'help' to see a current list of commands.",
+"Try 'apropos thisisnotadebuggercommand' for a list of related 
commands.",
+"Try 'type lookup thisisnotadebuggercommand' for information on 
types, methods, functions, modules, etc."])

Modified: lldb/trunk/source/Commands/CommandObjectCommands.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectCommands.cpp?rev=262271&r1=262270&r2=262271&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectCommands.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectCommands.cpp Mon Feb 29 17:22:53 
2016
@@ -14,6 +14,7 @@
 
 // Project includes
 #include "CommandObjectCommands.h"
+#include "CommandObjectHelp.h"
 #include "lldb/Core/Debugger.h"
 #include "lldb/Core/IOHandler.h"
 #include "lldb/Core/StringList.h"
@@ -920,8 +921,16 @@ protected:
 }
 else
 {
-result.AppendErrorWithFormat ("'%s' is not a known 
command.\nTry 'help' to see a current list of commands.\n",
-  command_name);
+StreamString error_msg_stream;
+const bool generate_apropos = true;
+const bool generate_type_lookup = false;
+
CommandObjectHelp::GenerateAdditionalHelpAvenuesMessage(&error_msg_stream,
+
command_name,
+
nullptr,
+
nullptr,
+
generate_apropos,
+
generate_type_lookup);
+result.AppendErrorWithFormat ("%s", 
error_msg_stream.GetData());
 result.SetStatus (eReturnStatusFailed);
 }
 }

Modified: lldb/trunk/source/Commands/CommandObjectHelp.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectHelp.cpp?rev=262271&r1=262270&r2=262271&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectHelp.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectHelp.cpp Mon Feb 29 17:22:53 2016
@@ -24,6 +24,37 @@ using namespace lldb_private;
 // CommandObjectHelp
 //-
 
+void
+CommandObjectHelp::GenerateAdditionalHelpAvenuesMessage (Stream *s,
+ const char* command,
+ const char* prefix,
+  

[Lldb-commits] [lldb] r262281 - Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target/Process.cpp; other minor fixes.

[Eugene Zelenko via lldb-commits]

Author: eugenezelenko
Date: Mon Feb 29 18:55:51 2016
New Revision: 262281

URL: http://llvm.org/viewvc/llvm-project?rev=262281&view=rev
Log:
Fix Clang-tidy modernize-use-nullptr warnings in some files in 
source/Target/Process.cpp; other minor fixes.

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

Modified: lldb/trunk/source/Target/Process.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Process.cpp?rev=262281&r1=262280&r2=262281&view=diff
==
--- lldb/trunk/source/Target/Process.cpp (original)
+++ lldb/trunk/source/Target/Process.cpp Mon Feb 29 18:55:51 2016
@@ -11,6 +11,7 @@
 // C++ Includes
 #include 
 #include 
+
 // Other libraries and framework includes
 // Project includes
 #include "lldb/Target/Process.h"
@@ -113,17 +114,17 @@ public:
 static PropertyDefinition
 g_properties[] =
 {
-{ "disable-memory-cache" , OptionValue::eTypeBoolean, false, 
DISABLE_MEM_CACHE_DEFAULT, NULL, NULL, "Disable reading and caching of memory 
in fixed-size units." },
-{ "extra-startup-command", OptionValue::eTypeArray  , false, 
OptionValue::eTypeString, NULL, NULL, "A list containing extra commands 
understood by the particular process plugin used.  "
+{ "disable-memory-cache" , OptionValue::eTypeBoolean, false, 
DISABLE_MEM_CACHE_DEFAULT, nullptr, nullptr, "Disable reading and caching of 
memory in fixed-size units." },
+{ "extra-startup-command", OptionValue::eTypeArray  , false, 
OptionValue::eTypeString, nullptr, nullptr, "A list containing extra commands 
understood by the particular process plugin used.  "

"For instance, to turn on debugserver logging set this 
to \"QSetLogging:bitmask=LOG_DEFAULT;\"" },
-{ "ignore-breakpoints-in-expressions", OptionValue::eTypeBoolean, true, 
true, NULL, NULL, "If true, breakpoints will be ignored during expression 
evaluation." },
-{ "unwind-on-error-in-expressions", OptionValue::eTypeBoolean, true, true, 
NULL, NULL, "If true, errors in expression evaluation will unwind the stack 
back to the state before the call." },
-{ "python-os-plugin-path", OptionValue::eTypeFileSpec, false, true, NULL, 
NULL, "A path to a python OS plug-in module file that contains a 
OperatingSystemPlugIn class." },
-{ "stop-on-sharedlibrary-events" , OptionValue::eTypeBoolean, true, false, 
NULL, NULL, "If true, stop when a shared library is loaded or unloaded." },
-{ "detach-keeps-stopped" , OptionValue::eTypeBoolean, true, false, NULL, 
NULL, "If true, detach will attempt to keep the process stopped." },
-{ "memory-cache-line-size" , OptionValue::eTypeUInt64, false, 512, NULL, 
NULL, "The memory cache line size" },
-{ "optimization-warnings" , OptionValue::eTypeBoolean, false, true, NULL, 
NULL, "If true, warn when stopped in code that is optimized where stepping and 
variable availability may not behave as expected." },
-{  NULL  , OptionValue::eTypeInvalid, false, 0, NULL, 
NULL, NULL  }
+{ "ignore-breakpoints-in-expressions", OptionValue::eTypeBoolean, true, 
true, nullptr, nullptr, "If true, breakpoints will be ignored during expression 
evaluation." },
+{ "unwind-on-error-in-expressions", OptionValue::eTypeBoolean, true, true, 
nullptr, nullptr, "If true, errors in expression evaluation will unwind the 
stack back to the state before the call." },
+{ "python-os-plugin-path", OptionValue::eTypeFileSpec, false, true, 
nullptr, nullptr, "A path to a python OS plug-in module file that contains a 
OperatingSystemPlugIn class." },
+{ "stop-on-sharedlibrary-events" , OptionValue::eTypeBoolean, true, false, 
nullptr, nullptr, "If true, stop when a shared library is loaded or unloaded." 
},
+{ "detach-keeps-stopped" , OptionValue::eTypeBoolean, true, false, 
nullptr, nullptr, "If true, detach will attempt to keep the process stopped." },
+{ "memory-cache-line-size" , OptionValue::eTypeUInt64, false, 512, 
nullptr, nullptr, "The memory cache line size" },
+{ "optimization-warnings" , OptionValue::eTypeBoolean, false, true, 
nullptr, nullptr, "If true, warn when stopped in code that is optimized where 
stepping and variable availability may not behave as expected." },
+{  nullptr  , OptionValue::eTypeInvalid, false, 0, 
nullptr, nullptr, nullptr  }
 };
 
 enum {
@@ -139,10 +140,10 @@ enum {
 };
 
 ProcessProperties::ProcessProperties (lldb_private::Process *process) :
-Properties (),
-m_process (process) // Can be NULL for global ProcessProperties
+Properties(),
+m_process(process) // Can be nullptr for global ProcessProperties
 {
-if (process == NULL)
+if (process == nullptr)
 {
 // Global process properties, set them up one time
 m_collection_sp.reset (new 
ProcessOptionValueProperties(ConstString("process")));
@@ -173,14 +174,14 @@ bool
 ProcessP

Re: [Lldb-commits] [PATCH] D17724: Replace getopt with llvm::cl in lldb driver

[Kamil Rytarowski via lldb-commits]

krytarowski added a subscriber: krytarowski.
krytarowski added a comment.

In general I prefer to outsource these things to underlaying OSes with their 
own implementations, not enforcing the "right one" to everybody.

I'm used to NetBSD syntax, that differs with `GNU` and even if I'm using their 
software, I automatically pickup the more portable syntax for my command-line.

Other than my preferences, I have nothing against this code to happen.


http://reviews.llvm.org/D17724



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

Re: [Lldb-commits] [PATCH] D17724: Replace getopt with llvm::cl in lldb driver

[Kamil Rytarowski via lldb-commits]

krytarowski added a comment.

Just to make it clear -- NetBSD has system `getopt`(3), we just deliberately 
rejected `-long -only` syntax.


http://reviews.llvm.org/D17724



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

[Lldb-commits] [PATCH] D17745: Fix bug with function resolution when using IR Interpreter

[Ted Woodward via lldb-commits]

ted created this revision.
ted added a reviewer: spyffe.
ted added a subscriber: lldb-commits.

Recent changes to the expression parser broke function name resolution when 
using the IR interpreter instead of JIT. This patch changes the IRMemoryMap 
ivar in InterpreterStackFrame to an IRExecutionUnitSP (which is a subclass), 
allowing InterpreterStackFrame::ResolveConstantValue() to call FindSymbol() on 
the name of the Value when it's a FunctionVal. It also changes 
IRExecutionUnit::FindInSymbols() to call GetFileAddress() on the symball if 
ResolveCallableAddress() fails and there is no valid Process.

http://reviews.llvm.org/D17745

Files:
  include/lldb/Expression/IRInterpreter.h
  source/Expression/IRExecutionUnit.cpp
  source/Expression/IRInterpreter.cpp
  source/Expression/LLVMUserExpression.cpp

Index: source/Expression/LLVMUserExpression.cpp
===
--- source/Expression/LLVMUserExpression.cpp
+++ source/Expression/LLVMUserExpression.cpp
@@ -120,8 +120,8 @@
 function_stack_bottom = m_stack_frame_bottom;
 function_stack_top = m_stack_frame_top;
 
-IRInterpreter::Interpret(*module, *function, args, *m_execution_unit_sp.get(), interpreter_error,
- function_stack_bottom, function_stack_top, exe_ctx);
+IRInterpreter::Interpret(*module, *function, args, m_execution_unit_sp, interpreter_error,
+function_stack_bottom, function_stack_top, exe_ctx);
 
 if (m_materialized_address != LLDB_INVALID_ADDRESS)
 if (exe_ctx.GetProcessPtr())
Index: source/Expression/IRInterpreter.cpp
===
--- source/Expression/IRInterpreter.cpp
+++ source/Expression/IRInterpreter.cpp
@@ -7,14 +7,16 @@
 //
 //===--===//
 
+#include "lldb/Core/ConstString.h"
 #include "lldb/Core/DataExtractor.h"
 #include "lldb/Core/Error.h"
 #include "lldb/Core/Log.h"
 #include "lldb/Core/ModuleSpec.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/Scalar.h"
 #include "lldb/Core/StreamString.h"
 #include "lldb/Core/ValueObject.h"
+#include "lldb/Expression/IRExecutionUnit.h"
 #include "lldb/Expression/IRMemoryMap.h"
 #include "lldb/Expression/IRInterpreter.h"
 #include "lldb/Host/Endian.h"
@@ -101,7 +103,7 @@
 
 ValueMapm_values;
 DataLayout &m_target_data;
-lldb_private::IRMemoryMap  &m_memory_map;
+lldb::IRExecutionUnitSP m_execution_unit_sp;
 const BasicBlock   *m_bb;
 BasicBlock::const_iterator  m_ii;
 BasicBlock::const_iterator  m_ie;
@@ -114,11 +116,11 @@
 size_t  m_addr_byte_size;
 
 InterpreterStackFrame (DataLayout &target_data,
-   lldb_private::IRMemoryMap &memory_map,
+   lldb::IRExecutionUnitSP execution_unit_sp,
lldb::addr_t stack_frame_bottom,
lldb::addr_t stack_frame_top) :
 m_target_data (target_data),
-m_memory_map (memory_map)
+m_execution_unit_sp (execution_unit_sp)
 {
 m_byte_order = (target_data.isLittleEndian() ? lldb::eByteOrderLittle : lldb::eByteOrderBig);
 m_addr_byte_size = (target_data.getPointerSize(0));
@@ -203,7 +205,7 @@
 lldb_private::DataExtractor value_extractor;
 lldb_private::Error extract_error;
 
-m_memory_map.GetMemoryData(value_extractor, process_address, value_size, extract_error);
+m_execution_unit_sp.get()->GetMemoryData(value_extractor, process_address, value_size, extract_error);
 
 if (!extract_error.Success())
 return false;
@@ -242,7 +244,7 @@
 
 lldb_private::Error write_error;
 
-m_memory_map.WriteMemory(process_address, buf.GetBytes(), buf.GetByteSize(), write_error);
+m_execution_unit_sp.get()->WriteMemory(process_address, buf.GetBytes(), buf.GetByteSize(), write_error);
 
 return write_error.Success();
 }
@@ -253,6 +255,17 @@
 {
 default:
 break;
+case Value::FunctionVal:
+if (const Function *constant_func = dyn_cast(constant))
+{
+lldb_private::ConstString name(constant_func->getName());
+lldb::addr_t addr = m_execution_unit_sp->FindSymbol(name);
+if (addr == LLDB_INVALID_ADDRESS)
+return false;
+value = APInt(m_target_data.getPointerSizeInBits(), addr);
+return true;
+}
+break;
 case Value::ConstantIntVal:
 if (const ConstantInt *constant_int = dyn_cast(constant))
 {
@@ -329,12 +342,12 @@
 
 lldb_private::

Re: [Lldb-commits] [lldb] r262041 - Fix bug with register values byte order in expression evaluation.

[Marianne Mailhot-Sarrasin via lldb-commits]

Really sorry about the breakage.

Is there anybody who understands what is the issue of using
WriteScalarToMemory when the register value is a scalar?

>From my understanding, using WriteScalarToMemory handles the byte swap
needed when the Host endianness is different from the Target endianness,
which is not done by WriteMemory. Therefor using WriteScalarToMemory is
fixing the evaluation of the registers on my out-of-tree target.


2016-02-29 11:06 GMT-05:00 Aidan Dodds :

> Sorry about the breakage, and thanks for working on a patch Chaoren.
> Hopefully Marianne will revise her merge request if this fix is still
> important for her.
>
> On 28/02/2016 00:06, Todd Fiala wrote:
>
> I brought the state of the lines changed there to what they were prior to
> the change. If you adjusted those same lines, then yes that got undone.
>
> We were failing different tests in those files.  Your change may have
> fixed the new issues on Linux, but did not address the new failures on OS
> X.  The OS X bot went green after the revert.
>
> -Todd
>
> On Feb 27, 2016, at 4:01 PM, Chaoren Lin < 
> chaor...@google.com> wrote:
>
> I thought I fixed it with  
> http://reviews.llvm.org/D17658. Did you revert that as well?
>
> On Sat, Feb 27, 2016 at 3:14 PM, Todd Fiala < 
> todd.fi...@gmail.com> wrote:
>
>> Hi all,
>>
>> The new assert was failing on the OS X testbot here:
>> http://lab.llvm.org:8080/green/job/lldb_build_test/
>>
>> The nag mail didn't make it to you since we have it only fire on the
>> transition from good build to bad build, and Tamas had the privilege of
>> earning that with a minor Xcode breakage just shortly before this issue
>> showed up.  However, that bot as been broken since this change went in.
>>
>> I reverted it in r262156.
>>
>> Feel free to reapply if you have a suggested fix for the test failure
>> introduced.
>>
>> Thanks!
>>
>> -Todd
>>
>> On Fri, Feb 26, 2016 at 12:08 PM, Chaoren Lin via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> Hmm. Weird. That assert is failing on Linux:
>>> 
>>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/11833
>>>
>>> On Fri, Feb 26, 2016 at 9:40 AM, Aidan Dodds via lldb-commits <
>>> lldb-commits@lists.llvm.org> wrote:
>>>
 Author: aidandodds
 Date: Fri Feb 26 11:40:50 2016
 New Revision: 262041

 URL: http://llvm.org/viewvc/llvm-project?rev=262041&view=rev
 Log:
 Fix bug with register values byte order in expression evaluation.

 The evaluation of expressions containing register values was broken for
 targets for which endianness differs from host.

 Committed on behalf of: mamai < 
 marianne.mailhot.sarra...@gmail.com>

 Differential revision: 
 http://reviews.llvm.org/D17167

 Modified:
 lldb/trunk/source/Expression/Materializer.cpp

 Modified: lldb/trunk/source/Expression/Materializer.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/Materializer.cpp?rev=262041&r1=262040&r2=262041&view=diff

 ==
 --- lldb/trunk/source/Expression/Materializer.cpp (original)
 +++ lldb/trunk/source/Expression/Materializer.cpp Fri Feb 26 11:40:50
 2016
 @@ -26,6 +26,7 @@
  #include "lldb/Target/StackFrame.h"
  #include "lldb/Target/Target.h"
  #include "lldb/Target/Thread.h"
 +#include "lldb/Utility/LLDBAssert.h"

  using namespace lldb_private;

 @@ -1275,9 +1276,14 @@ public:
  m_register_contents.reset(new
 DataBufferHeap(register_data.GetDataStart(), register_data.GetByteSize()));

  Error write_error;
 -
 -map.WriteMemory(load_addr, register_data.GetDataStart(),
 register_data.GetByteSize(), write_error);
 -
 +
 +Scalar scalar;
 +reg_value.GetScalarValue(scalar);
 +
 +lldbassert(scalar.GetByteSize() ==
 register_data.GetByteSize());
 +
 +map.WriteScalarToMemory(load_addr, scalar,
 scalar.GetByteSize(), write_error);
 +
  if (!write_error.Success())
  {
  err.SetErrorStringWithFormat("couldn't write the contents
 of register %s: %s", m_register_info.name, write_error.AsCString());


 ___
 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
>>>
>>>
>>
>>
>> --
>> -Todd
>>
>
>
>
___
lldb-commits mailing list
lldb-commits@lis

Re: [Lldb-commits] [PATCH] D17745: Fix bug with function resolution when using IR Interpreter

[Sean Callanan via lldb-commits]

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

Aside from one minor object ownership issue this is good to go.  Change the 
`IRExecutionUnitSP` to an `IRExecutionUnit&` and you have my blessing!



Comment at: source/Expression/IRInterpreter.cpp:106
@@ -103,3 +105,3 @@
 DataLayout &m_target_data;
-lldb_private::IRMemoryMap  &m_memory_map;
+lldb::IRExecutionUnitSP m_execution_unit_sp;
 const BasicBlock   *m_bb;

As noted below, this can just be an `IRExecutionUnit&`.


Comment at: source/Expression/IRInterpreter.cpp:689
@@ -674,3 +688,3 @@
   llvm::ArrayRef args,
-  lldb_private::IRMemoryMap &memory_map,
+  lldb::IRExecutionUnitSP execution_unit_sp,
   lldb_private::Error &error,

Given that the caller of `Interpret` has an `execution_unit_sp`, and 
`Interpret` does not create any objects that live longer than the `Interpret` 
invocation (specifically, the `InterpreterStackFrame` is stack-allocated) I 
believe we should not need to take the shared pointer.  An `IRExecutionUnit&` 
should suffice.


http://reviews.llvm.org/D17745



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

Re: [Lldb-commits] [PATCH] D17363: Add SymbolFilePDB with basic support for line tables.

[Zachary Turner via lldb-commits]

zturner updated this revision to Diff 49442.
zturner added a comment.

Note this should compile now on every platform.  Look over the unit tests to 
see my assumptions about how the API should work.  Hopefully this makes 
reviewing things easier (it definitely made getting things to work easier)


http://reviews.llvm.org/D17363

Files:
  cmake/LLDBDependencies.cmake
  cmake/modules/AddLLDB.cmake
  include/lldb/Host/FileSpec.h
  include/lldb/Host/windows/HostInfoWindows.h
  source/API/SystemInitializerFull.cpp
  source/Host/common/FileSpec.cpp
  source/Host/windows/HostInfoWindows.cpp
  source/Initialization/SystemInitializerCommon.cpp
  source/Plugins/SymbolFile/CMakeLists.txt
  source/Plugins/SymbolFile/PDB/CMakeLists.txt
  source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
  source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
  unittests/CMakeLists.txt
  unittests/SymbolFile/CMakeLists.txt
  unittests/SymbolFile/PDB/CMakeLists.txt
  unittests/SymbolFile/PDB/Inputs/test-dwarf.cpp
  unittests/SymbolFile/PDB/Inputs/test-dwarf.exe
  unittests/SymbolFile/PDB/Inputs/test-pdb.cpp
  unittests/SymbolFile/PDB/Inputs/test-pdb.exe
  unittests/SymbolFile/PDB/Inputs/test-pdb.pdb
  unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp

Index: unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp
===
--- /dev/null
+++ unittests/SymbolFile/PDB/SymbolFilePDBTests.cpp
@@ -0,0 +1,340 @@
+//===-- PythonDataObjectsTests.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 "llvm/ADT/STLExtras.h"
+#include "llvm/Config/config.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Path.h"
+
+#include "lldb/Core/Address.h"
+#include "lldb/Core/ArchSpec.h"
+#include "lldb/Core/Module.h"
+#include "lldb/Core/ModuleSpec.h"
+#include "lldb/Host/FileSpec.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Symbol/CompileUnit.h"
+#include "lldb/Symbol/LineTable.h"
+#include "lldb/Symbol/SymbolVendor.h"
+
+#include "Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h"
+#include "Plugins/SymbolFile/DWARF/SymbolFileDWARF.h"
+#include "Plugins/SymbolFile/PDB/SymbolFilePDB.h"
+
+#if defined(_MSC_VER)
+#include 
+#endif
+
+extern const char *TestMainArgv0;
+
+using namespace lldb_private;
+
+class SymbolFilePDBTests : public testing::Test
+{
+public:
+void
+SetUp() override
+{
+#if defined(_MSC_VER)
+::CoInitializeEx(nullptr, COINIT_MULTITHREADED);
+#endif
+
+HostInfoBase::Initialize();
+ObjectFilePECOFF::Initialize();
+SymbolFileDWARF::Initialize();
+SymbolFilePDB::Initialize();
+
+llvm::StringRef exe_folder = llvm::sys::path::parent_path(TestMainArgv0);
+llvm::SmallString<128> inputs_folder = exe_folder;
+llvm::sys::path::append(inputs_folder, "Inputs");
+
+m_pdb_test_exe = inputs_folder;
+m_dwarf_test_exe = inputs_folder;
+llvm::sys::path::append(m_pdb_test_exe, "test-pdb.exe");
+llvm::sys::path::append(m_dwarf_test_exe, "test-dwarf.exe");
+}
+
+void
+TearDown() override
+{
+#if defined(_MSC_VER)
+::CoUninitialize();
+#endif
+SymbolFilePDB::Terminate();
+SymbolFileDWARF::Terminate();
+ObjectFilePECOFF::Terminate();
+}
+
+protected:
+llvm::SmallString<128> m_pdb_test_exe;
+llvm::SmallString<128> m_dwarf_test_exe;
+
+bool
+FileSpecMatchesAsBaseOrFull(const FileSpec &left, const FileSpec &right) const
+{
+// If the filenames don't match, the paths can't be equal
+if (!left.FileEquals(right))
+return false;
+// If BOTH have a directory, also compare the directories.
+if (left.GetDirectory() && right.GetDirectory())
+return left.DirectoryEquals(right);
+
+// If one has a directory but not the other, they match.
+return true;
+}
+
+void
+VerifyLineEntry(lldb::ModuleSP module, const SymbolContext &sc, const FileSpec &spec, LineTable <, uint32_t line,
+lldb::addr_t addr)
+{
+LineEntry entry;
+Address address;
+EXPECT_TRUE(module->ResolveFileAddress(addr, address));
+
+EXPECT_TRUE(lt.FindLineEntryByAddress(address, entry));
+EXPECT_EQ(line, entry.line);
+EXPECT_EQ(address, entry.range.GetBaseAddress());
+
+EXPECT_TRUE(FileSpecMatchesAsBaseOrFull(spec, entry.file));
+}
+
+bool
+ContainsCompileUnit(const SymbolContextList &sc_list, const FileSpec &spec) const
+{
+for (int i = 0; i < sc_list.GetSize(); ++i)
+{
+const SymbolContext &sc = sc_list[i];
+if (FileSpecMatchesAsBaseOrFull(*sc.comp_unit, spec))
+

[Lldb-commits] [lldb] r262287 - Fix MSVC build failure in source/Target/Process.cpp.

[Eugene Zelenko via lldb-commits]

Author: eugenezelenko
Date: Mon Feb 29 20:08:37 2016
New Revision: 262287

URL: http://llvm.org/viewvc/llvm-project?rev=262287&view=rev
Log:
Fix MSVC build failure in source/Target/Process.cpp.

Will be good idea to introduce macro/constexpr for NULL thread_result_t.

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

Modified: lldb/trunk/source/Target/Process.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Process.cpp?rev=262287&r1=262286&r2=262287&view=diff
==
--- lldb/trunk/source/Target/Process.cpp (original)
+++ lldb/trunk/source/Target/Process.cpp Mon Feb 29 20:08:37 2016
@@ -4139,7 +4139,7 @@ Process::ControlPrivateStateThread (uint
 log->Printf ("The control event killed the private state 
thread without having to cancel.");
 }
 
-thread_result_t result = nullptr;
+thread_result_t result = NULL;
 private_state_thread.Join(&result);
 m_private_state_thread.Reset();
 }


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

Re: [Lldb-commits] [PATCH] D17597: [LLDB][MIPS] Fix TestDisassembleBreakpoint

[Jaydeep Patil via lldb-commits]

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

Looks good to me.


Repository:
  rL LLVM

http://reviews.llvm.org/D17597



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

[Lldb-commits] [PATCH] D17750: arm ios doesn't have elf.h, sys/procfs.h, need to avoid including them on apple systems

[Jason Molenda via lldb-commits]

jasonmolenda created this revision.
jasonmolenda added reviewers: tberghammer, omjavaid.
jasonmolenda added a subscriber: lldb-commits.
jasonmolenda set the repository for this revision to rL LLVM.
Herald added subscribers: rengolin, aemerson.

I'm getting lldb to build for ios again and had build failures with 
NativeRegisterContextLinux_arm.cpp and Linux/Procfs.h which assume they're 
building for linux when being built or aarch64/etc.  

Would some patch like this be acceptable?  It's not pretty, but that's always 
the way with the C preprocessor as we pile on conditionals. :)

Repository:
  rL LLVM

http://reviews.llvm.org/D17750

Files:
  source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
  source/Plugins/Process/Linux/Procfs.h

Index: source/Plugins/Process/Linux/Procfs.h
===
--- source/Plugins/Process/Linux/Procfs.h
+++ source/Plugins/Process/Linux/Procfs.h
@@ -26,6 +26,8 @@
 #endif // NT_FPREGSET
 #endif
 #else  // __ANDROID__
+#if !defined (__APPLE__)
 #include 
+#endif // __APPLE__
 #endif // __ANDROID__
 
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
@@ -7,7 +7,7 @@
 //
 
//===--===//
 
-#if defined(__arm__) || defined(__arm64__) || defined(__aarch64__)
+#if !defined (__APPLE__) && (defined(__arm__) || defined(__arm64__) || 
defined(__aarch64__))
 
 #include "NativeRegisterContextLinux_arm.h"
 


Index: source/Plugins/Process/Linux/Procfs.h
===
--- source/Plugins/Process/Linux/Procfs.h
+++ source/Plugins/Process/Linux/Procfs.h
@@ -26,6 +26,8 @@
 #endif // NT_FPREGSET
 #endif
 #else  // __ANDROID__
+#if !defined (__APPLE__)
 #include 
+#endif // __APPLE__
 #endif // __ANDROID__
 
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp
@@ -7,7 +7,7 @@
 //
 //===--===//
 
-#if defined(__arm__) || defined(__arm64__) || defined(__aarch64__)
+#if !defined (__APPLE__) && (defined(__arm__) || defined(__arm64__) || defined(__aarch64__))
 
 #include "NativeRegisterContextLinux_arm.h"
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r262300 - Update the on-device arm specific code to match the API changes

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Mon Feb 29 23:34:05 2016
New Revision: 262300

URL: http://llvm.org/viewvc/llvm-project?rev=262300&view=rev
Log:
Update the on-device arm specific code to match the API changes
that happened in other parts of this file so it builds cleanly
for arm again.

Modified:
lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp

Modified: lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp?rev=262300&r1=262299&r2=262300&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp Mon Feb 29 
23:34:05 2016
@@ -3080,7 +3080,7 @@ ObjectFileMachO::ParseSymtab ()
 {
 // This is 
usually the second N_SO entry that contains just the filename,
 // so here we 
combine it with the first one if we are minimizing the symbol table
-const char 
*so_path = sym[sym_idx - 1].GetMangled().GetDemangledName().AsCString();
+const char 
*so_path = sym[sym_idx - 
1].GetMangled().GetDemangledName(lldb::eLanguageTypeUnknown).AsCString();
 if (so_path && 
so_path[0])
 {
 
std::string full_so_path (so_path);
@@ -3467,7 +3467,7 @@ ObjectFileMachO::ParseSymtab ()
 
sym[sym_idx].GetMangled().SetValue(const_symbol_name, symbol_name_is_mangled);
 if (is_gsym && 
is_debug)
 {
-const char 
*gsym_name = 
sym[sym_idx].GetMangled().GetName(Mangled::ePreferMangled).GetCString();
+const char 
*gsym_name = sym[sym_idx].GetMangled().GetName(lldb::eLanguageTypeUnknown, 
Mangled::ePreferMangled).GetCString();
 if (gsym_name)
 
N_GSYM_name_to_sym_idx[gsym_name] = sym_idx;
 }
@@ -3541,7 +3541,7 @@ ObjectFileMachO::ParseSymtab ()
 bool found_it = 
false;
 for 
(ValueToSymbolIndexMap::const_iterator pos = range.first; pos != range.second; 
++pos)
 {
-if 
(sym[sym_idx].GetMangled().GetName(Mangled::ePreferMangled) == 
sym[pos->second].GetMangled().GetName(Mangled::ePreferMangled))
+if 
(sym[sym_idx].GetMangled().GetName(lldb::eLanguageTypeUnknown, 
Mangled::ePreferMangled) == 
sym[pos->second].GetMangled().GetName(lldb::eLanguageTypeUnknown, 
Mangled::ePreferMangled))
 {
 
m_nlist_idx_to_sym_idx[nlist_idx] = pos->second;
 // We just 
need the flags from the linker symbol, so put these flags
@@ -3580,7 +3580,7 @@ ObjectFileMachO::ParseSymtab ()
 bool found_it = 
false;
 for 
(ValueToSymbolIndexMap::const_iterator pos = range.first; pos != range.second; 
++pos)
 {
-if 
(sym[sym_idx].GetMangled().GetName(Mangled::ePreferMangled) == 
sym[pos->second].GetMangled().GetName(Mangled::ePreferMangled))
+if 
(sym[sym_idx].GetMangled().GetName(lldb::eLanguageTypeUnknown, 
Mangled::ePreferMangled) == 
sym[pos->second].GetMangled().GetName(lldb::eLanguageTypeUnknown, 
Mangled::ePreferMangled))
 {
 
m_nlist_idx_to_sym_idx[nlist_idx] = pos->second;
 // We just 
need the flags from the linker symbol