Re: [Lldb-commits] [PATCH] D24124: [LLDB][MIPS] Fix register read/write for 32 bit big endian system

[Nitesh Jain via lldb-commits]

nitesh.jain retitled this revision from "[LLDB][MIPS] Fix register read/write 
for big endian" to "[LLDB][MIPS] Fix register read/write for 32 bit big endian 
system".
nitesh.jain updated the summary for this revision.
nitesh.jain updated this revision to Diff 71360.

https://reviews.llvm.org/D24124

Files:
  include/lldb/Core/DataExtractor.h
  source/Core/DataExtractor.cpp
  source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
  source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp

Index: source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
===
--- source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
+++ source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
@@ -1936,8 +1936,17 @@
 
   // Build the reginfos response.
   StreamGDBRemote response;
-
-  RegisterValue reg_value(reg_bytes, reg_size, process_arch.GetByteOrder());
+  uint64_t dst_value;
+  RegisterValue reg_value;
+  lldb::ByteOrder byte_order = lldb::eByteOrderInvalid;
+  // The host will always send data in target byte order
+  // Hence source byte order will be same as destination byte order
+  m_debugged_process_sp->GetByteOrder(byte_order);
+  
+  DataExtractor::CopyByteOrderedData(reg_bytes, reg_size,
+ byte_order, &dst_value,
+ sizeof(dst_value), byte_order);
+  reg_value.SetUInt(dst_value, reg_size);
   Error error = reg_context_sp->WriteRegister(reg_info, reg_value);
   if (error.Fail()) {
 if (log)
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp
@@ -169,7 +169,7 @@
 
   if (error.Success())
 // First cast to an unsigned of the same size to avoid sign extension.
-value.SetUInt64(static_cast(data));
+value.SetUInt(static_cast(data), size);
 
   if (log)
 log->Printf("NativeRegisterContextLinux::%s() reg %s: 0x%lx", __FUNCTION__,
Index: source/Core/DataExtractor.cpp
===
--- source/Core/DataExtractor.cpp
+++ source/Core/DataExtractor.cpp
@@ -938,6 +938,87 @@
   return 0;
 }
 
+lldb::offset_t DataExtractor::CopyByteOrderedData(void *src_void_ptr,
+  offset_t src_len,
+  ByteOrder src_byte_order,
+  void *dst_void_ptr,
+  offset_t dst_len,
+  ByteOrder dst_byte_order) {
+
+  // Validate the source and destination info
+  assert(dst_void_ptr != nullptr || src_void_ptr != nullptr);
+  assert(dst_len > 0 || src_len > 0);
+  assert(src_len <= dst_len);
+  assert(dst_byte_order == eByteOrderBig || dst_byte_order == eByteOrderLittle);
+  assert(src_byte_order == eByteOrderBig || src_byte_order == eByteOrderLittle);
+
+  // Validate that only a word- or register-sized dst is byte swapped
+  assert(dst_byte_order == src_byte_order || dst_len == 1 || dst_len == 2 ||
+ dst_len == 4 || dst_len == 8 || dst_len == 10 || dst_len == 16 ||
+ dst_len == 32);
+
+  uint8_t* dst = (uint8_t*)dst_void_ptr;
+  const uint8_t* src = (const uint8_t *)src_void_ptr;
+  if (src) {
+if (dst_len >= src_len) {
+  // We are copying the entire value from src into dst.
+  // Calculate how many, if any, zeroes we need for the most
+  // significant bytes if "dst_len" is greater than "src_len"...
+  const size_t num_zeroes = dst_len - src_len;
+  if (dst_byte_order == eByteOrderBig) {
+// Big endian, so we lead with zeroes...
+if (num_zeroes > 0)
+  ::memset(dst, 0, num_zeroes);
+// Then either copy or swap the rest
+if (src_byte_order == eByteOrderBig) {
+  ::memcpy(dst + num_zeroes, src, src_len);
+} else {
+  for (uint32_t i = 0; i < src_len; ++i)
+dst[i + num_zeroes] = src[src_len - 1 - i];
+}
+  } else {
+// Little endian destination, so we lead the value bytes
+if (src_byte_order == eByteOrderBig) {
+  for (uint32_t i = 0; i < src_len; ++i)
+dst[i] = src[src_len - 1 - i];
+} else {
+  ::memcpy(dst, src, src_len);
+}
+// And zero the rest...
+if (num_zeroes > 0)
+  ::memset(dst + src_len, 0, num_zeroes);
+  }
+  return src_len;
+} else {
+  // We are only copying some of the value from src into dst..
+
+  if (dst_byte_order == eByteOrderBig) {
+// Big endian dst
+if (src_byte_order == eByteOrderBig) {
+  // Big endian dst, with big endian src
+  ::memcpy(dst, src + (src_len - 

[Lldb-commits] [lldb] r281594 - Try to fix windows build after rL281569

[Tamas Berghammer via lldb-commits]

Author: tberghammer
Date: Thu Sep 15 03:47:59 2016
New Revision: 281594

URL: http://llvm.org/viewvc/llvm-project?rev=281594&view=rev
Log:
Try to fix windows build after rL281569

Modified:
lldb/trunk/include/lldb/Breakpoint/BreakpointOptions.h
lldb/trunk/include/lldb/Breakpoint/BreakpointResolver.h

Modified: lldb/trunk/include/lldb/Breakpoint/BreakpointOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Breakpoint/BreakpointOptions.h?rev=281594&r1=281593&r2=281594&view=diff
==
--- lldb/trunk/include/lldb/Breakpoint/BreakpointOptions.h (original)
+++ lldb/trunk/include/lldb/Breakpoint/BreakpointOptions.h Thu Sep 15 03:47:59 
2016
@@ -61,7 +61,7 @@ public:
 static const char
 *g_option_names[static_cast(OptionNames::LastOptionName)];
 
-static const char *GetKey(enum OptionNames enum_value) {
+static const char *GetKey(OptionNames enum_value) {
   return g_option_names[static_cast(enum_value)];
 }
   };

Modified: lldb/trunk/include/lldb/Breakpoint/BreakpointResolver.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Breakpoint/BreakpointResolver.h?rev=281594&r1=281593&r2=281594&view=diff
==
--- lldb/trunk/include/lldb/Breakpoint/BreakpointResolver.h (original)
+++ lldb/trunk/include/lldb/Breakpoint/BreakpointResolver.h Thu Sep 15 03:47:59 
2016
@@ -222,7 +222,7 @@ protected:
   *g_option_names[static_cast(OptionNames::LastOptionName)];
 
 public:
-  static const char *GetKey(enum OptionNames enum_value) {
+  static const char *GetKey(OptionNames enum_value) {
 return g_option_names[static_cast(enum_value)];
   }
 


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

[Lldb-commits] [lldb] r281595 - Add support for DW_AT_ranges_base attribute

[Tamas Berghammer via lldb-commits]

Author: tberghammer
Date: Thu Sep 15 03:53:33 2016
New Revision: 281595

URL: http://llvm.org/viewvc/llvm-project?rev=281595&view=rev
Log:
Add support for DW_AT_ranges_base attribute

It is a new attribute emitted by clang as a GNU extension and will
be part of Dwarf5. The purpose of the attribute is to specify a compile
unit level base value for all DW_AT_ranges to reduce the number of
relocations have to be done by the linker.

Fixes (at least partially): https://llvm.org/pr28826

Differential revision: https://reviews.llvm.org/D24514

Modified:

lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py

lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/decls.h

lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/file1.cpp

lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/file2.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py?rev=281595&r1=281594&r2=281595&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
 Thu Sep 15 03:53:33 2016
@@ -38,3 +38,46 @@ class SymbolContextTwoFilesTestCase(Test
 symbol_address, lldb.eSymbolContextFunction)
 self.assertEqual(symbol_name,
  sc_by_address.GetFunction().GetName())
+
+@add_test_categories(['pyapi'])
+def test_ranges_in_multiple_compile_unit(self):
+"""This test verifies that we correctly handle the case when multiple
+compile unit contains DW_AT_ranges and DW_AT_ranges_base attributes."""
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+source1 = "file1.cpp"
+line1 = line_number(source1, '// Break1')
+breakpoint1 = target.BreakpointCreateByLocation(source1, line1)
+self.assertIsNotNone(breakpoint1)
+self.assertTrue(breakpoint1.IsValid())
+
+source2 = "file2.cpp"
+line2 = line_number(source2, '// Break2')
+breakpoint2 = target.BreakpointCreateByLocation(source2, line2)
+self.assertIsNotNone(breakpoint2)
+self.assertTrue(breakpoint2.IsValid())
+
+process = target.LaunchSimple(None, None, os.getcwd())
+self.assertIsNotNone(process, PROCESS_IS_VALID)
+
+threads = lldbutil.get_threads_stopped_at_breakpoint(
+process, breakpoint2)
+self.assertEqual(len(threads), 1)
+frame = threads[0].GetFrameAtIndex(0)
+value = frame.FindVariable("x")
+self.assertTrue(value.IsValid())
+
+process.Continue()
+
+threads = lldbutil.get_threads_stopped_at_breakpoint(
+process, breakpoint1)
+self.assertEqual(len(threads), 1)
+frame = threads[0].GetFrameAtIndex(0)
+value = frame.FindVariable("x")
+self.assertTrue(value.IsValid())
+
+process.Continue()

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/decls.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/decls.h?rev=281595&r1=281594&r2=281595&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/decls.h
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/decls.h
 Thu Sep 15 03:53:33 2016
@@ -1,11 +1,11 @@
-struct struct1
-{
-static void
-f();
+struct struct1 {
+  ~struct1();
+  static void f();
 };
 
-struct struct2
-{
-static void
-f();
+struct struct2 {
+  ~struct2();
+  static void f();
 };
+
+int g();

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/file1.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/file1.cpp?rev=281595&r1=281594&r2=281595&view=diff

Re: [Lldb-commits] [PATCH] D24514: Add support for DW_AT_ranges_base attribute

[Tamas Berghammer via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL281595: Add support for DW_AT_ranges_base attribute 
(authored by tberghammer).

Changed prior to commit:
  https://reviews.llvm.org/D24514?vs=71316&id=71484#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24514

Files:
  
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
  
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/decls.h
  
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/file1.cpp
  
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/file2.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFCompileUnit.h
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp
  lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h
  lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

Index: lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/file1.cpp
===
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/file1.cpp
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/file1.cpp
@@ -1,13 +1,21 @@
 #include "decls.h"
 
-void
-struct1::f()
-{
+int g() {
+  return 1;
 }
 
-int main()
-{
-struct1::f();
-struct2::f();
-return 0;
+struct1::~struct1() {
+  int x = g(); // Break1
+}
+
+void struct1::f() {}
+
+int main() {
+  struct1::f();
+  struct2::f();
+
+  struct1 s1;
+  struct2 s2;
+
+  return 0;
 }
Index: lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/decls.h
===
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/decls.h
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/decls.h
@@ -1,11 +1,11 @@
-struct struct1
-{
-static void
-f();
+struct struct1 {
+  ~struct1();
+  static void f();
 };
 
-struct struct2
-{
-static void
-f();
+struct struct2 {
+  ~struct2();
+  static void f();
 };
+
+int g();
Index: lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
@@ -38,3 +38,46 @@
 symbol_address, lldb.eSymbolContextFunction)
 self.assertEqual(symbol_name,
  sc_by_address.GetFunction().GetName())
+
+@add_test_categories(['pyapi'])
+def test_ranges_in_multiple_compile_unit(self):
+"""This test verifies that we correctly handle the case when multiple
+compile unit contains DW_AT_ranges and DW_AT_ranges_base attributes."""
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+
+target = self.dbg.CreateTarget(exe)
+self.assertTrue(target, VALID_TARGET)
+
+source1 = "file1.cpp"
+line1 = line_number(source1, '// Break1')
+breakpoint1 = target.BreakpointCreateByLocation(source1, line1)
+self.assertIsNotNone(breakpoint1)
+self.assertTrue(breakpoint1.IsValid())
+
+source2 = "file2.cpp"
+line2 = line_number(source2, '// Break2')
+breakpoint2 = target.BreakpointCreateByLocation(source2, line2)
+self.assertIsNotNone(breakpoint2)
+self.assertTrue(breakpoint2.IsValid())
+
+process = target.LaunchSimple(None, None, os.getcwd())
+self.assertIsNotNone(process, PROCESS_IS_VALID)
+
+threads = lldbutil.get_threads_stopped_at_breakpoint(
+process, breakpoint2)
+self.assertEqual(len(threads), 1)
+frame = threads[0].GetFrameAtIndex(0)
+value = frame.FindVariable("x")
+self.assertTrue(value.IsValid())
+
+process.Continue()
+
+threads = lldbutil.get_threads_stopped_at_breakpoint(
+process, breakpoint1)
+self.assertEqual(len(threads), 1)
+frame = threads[0].GetFrameAtIndex(0)
+value = frame.FindVariable("x")
+self.assertTrue(value.IsValid())
+
+process.Continue()
Index: lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/file2.cpp
===
--- lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/file2.cpp
+++ lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/file2.cpp
@@ -1,6 +1,7 @@
 #include "decls.h"
 
-void
-struct2::f

Re: [Lldb-commits] [PATCH] D24124: [LLDB][MIPS] Fix register read/write for 32 bit big endian system

[Nitesh Jain via lldb-commits]

nitesh.jain added inline comments.


Comment at: 
source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:1940
@@ +1939,3 @@
+  uint64_t dst_value;
+  RegisterValue reg_value;
+  lldb::ByteOrder byte_order = lldb::eByteOrderInvalid;

The GetAsUint64 work well on 32 bit little endian system since 32 bit data  is 
copy at lower address in SetBytes which is valid for little endian but not on 
32 bit big endian system.  The Goal is to GetAsUint64 work for 32 bit big 
endian data type. We can do following change inorder to make it work for 
RegisterValue type eTypeBytes

uint64_t
RegisterValue::GetAsUInt64 (uint64_t fail_value, bool *success_ptr) const
{
if (success_ptr)
*success_ptr = true;
switch (m_type)
{
...
...
...
case eTypeBytes:
{
switch (buffer.length)
{
default:break;
case 1:
case 2:
case 4:
case 8: return *(const uint64_t *)buffer.bytes;
}
}
break;
}
if (success_ptr)
*success_ptr = false;
return fail_value;
}

We can modify the case for buffer.length = 4/2/1 

switch (buffer.length) {
  case 1:  return *(const uint8_t *)buffer.bytes;
  case 2:  return *(const uint16_t *)buffer.bytes;
  case 4:  return *(const uint32_t *)buffer.bytes;

...
...
...
   }



https://reviews.llvm.org/D24124



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

Re: [Lldb-commits] [PATCH] D24124: [LLDB][MIPS] Fix register read/write for 32 bit big endian system

[Nitesh Jain via lldb-commits]

nitesh.jain marked 2 inline comments as done.
nitesh.jain added a comment.

https://reviews.llvm.org/D24124



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

Re: [Lldb-commits] [PATCH] D24124: [LLDB][MIPS] Fix register read/write for 32 bit big endian system

[Nitesh Jain via lldb-commits]

nitesh.jain added a comment.

Will submit separate patch for Floating point register read/write and ptrace 
changes.


https://reviews.llvm.org/D24124



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

[Lldb-commits] [PATCH] D24603: [LLDB][MIPS] fix Floating point register read/write for big endian

[Nitesh Jain via lldb-commits]

nitesh.jain created this revision.
nitesh.jain added reviewers: clayborg, labath, jaydeep.
nitesh.jain added subscribers: bhushan, slthakur, lldb-commits.
Herald added a subscriber: sdardis.

This patch add fix for reading and writing floating point register based on 
SR.FR bit. 

https://reviews.llvm.org/D24603

Files:
  source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
  source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.h

Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.h
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.h
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.h
@@ -76,11 +76,16 @@
   static bool IsMSAAvailable();
 
 protected:
-  Error DoReadRegisterValue(uint32_t offset, const char *reg_name,
-uint32_t size, RegisterValue &value) override;
+  Error Read_SR_Config(uint32_t offset, const char *reg_name, uint32_t size,
+   RegisterValue &value);
 
-  Error DoWriteRegisterValue(uint32_t offset, const char *reg_name,
- const RegisterValue &value) override;
+  uint32_t GetPtraceOffset(uint32_t reg_index,
+   const RegisterInfo *const reg_info);
+
+  Error ReadRegisterRaw(uint32_t reg_index, RegisterValue &value) override;
+
+  Error WriteRegisterRaw(uint32_t reg_index,
+ const RegisterValue &value) override;
 
   Error DoReadWatchPointRegisterValue(lldb::tid_t tid, void *watch_readback);
 
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
@@ -28,9 +28,16 @@
 #include "lldb/Host/HostInfo.h"
 #include "lldb/lldb-enumerations.h"
 #include "lldb/lldb-private-enumerations.h"
+
 #define NT_MIPS_MSA 0x600
 #define CONFIG5_FRE (1 << 8)
 #define SR_FR (1 << 26)
+#define FPR_BASE 32
+#define PC 64
+#define CAUSE 65
+#define BADVADDR 66
+#define MMHI 67
+#define MMLO 68
 #define NUM_REGISTERS 32
 
 #include 
@@ -466,21 +473,23 @@
   }
 
   if (IsFPR(reg_index) || IsMSA(reg_index)) {
-uint8_t *dst;
-uint64_t *src;
+uint8_t *dst = nullptr;
+uint64_t *src = nullptr;
+uint8_t byte_size = reg_info->byte_size;
 
 // Initialise the FP and MSA buffers by reading all co-processor 1 registers
 ReadCP1();
 
 if (IsFPR(reg_index)) {
   assert(reg_info->byte_offset < sizeof(UserArea));
   dst = (uint8_t *)&m_fpr + reg_info->byte_offset - (sizeof(m_gpr));
+  byte_size = IsFR0() ? 4 : 8;
 } else {
   assert(reg_info->byte_offset < sizeof(UserArea));
   dst = (uint8_t *)&m_msa + reg_info->byte_offset -
 (sizeof(m_gpr) + sizeof(m_fpr));
 }
-switch (reg_info->byte_size) {
+switch (byte_size) {
 case 4:
   *(uint32_t *)dst = reg_value.GetAsUInt32();
   break;
@@ -611,11 +620,12 @@
 Error NativeRegisterContextLinux_mips64::ReadCP1() {
   Error error;
 
-  uint8_t *src, *dst;
+  uint8_t *src = nullptr;
+  uint8_t *dst = nullptr;
 
   lldb::ByteOrder byte_order = GetByteOrder();
 
-  uint32_t IsBigEndian = (byte_order == lldb::eByteOrderBig);
+  bool IsBigEndian = (byte_order == lldb::eByteOrderBig);
 
   if (IsMSAAvailable()) {
 error = NativeRegisterContextLinux::ReadRegisterSet(
@@ -637,11 +647,18 @@
 
   // TODO: Add support for FRE
   if (IsFR0()) {
-src = (uint8_t *)&m_fpr + 4 + (IsBigEndian * 4);
-dst = (uint8_t *)&m_fpr + 8 + (IsBigEndian * 4);
+src = (uint8_t *)&m_fpr + (!IsBigEndian) * 4;
+dst = (uint8_t *)&m_fpr + 8;
 for (int i = 0; i < (NUM_REGISTERS / 2); i++) {
   // copy odd single from top of neighbouring even double
+  // In case of little endian, 32 bit LSB store even FP register
+  // and 32 bit MSB store odd FP register
+  // vice-versa for big-endian
   *(uint32_t *)dst = *(uint32_t *)src;
+
+  if (IsBigEndian)
+// Copy 32 bit MSB to 32 bit LSB
+*(uint32_t *)src = *(uint32_t *)(src + 4);
   src = src + 16;
   dst = dst + 16;
 }
@@ -653,18 +670,23 @@
 Error NativeRegisterContextLinux_mips64::WriteCP1() {
   Error error;
 
-  uint8_t *src, *dst;
+  uint8_t *src = nullptr;
+  uint8_t *dst = nullptr;
 
   lldb::ByteOrder byte_order = GetByteOrder();
 
-  uint32_t IsBigEndian = (byte_order == lldb::eByteOrderBig);
+  bool IsBigEndian = (byte_order == lldb::eByteOrderBig);
 
   // TODO: Add support for FRE
   if (IsFR0()) {
-src = (uint8_t *)&m_fpr + 8 + (IsBigEndian * 4);
-dst = (uint8_t *)&m_fpr + 4 + (IsBigEndian * 4);
+dst = (uint8_t *)&m_fpr + (!IsBigEndian) * 4;
+src = dst + 8 - (!IsBigEndian) * 4;
 for (int i = 0; i < (NUM_REGISTERS / 2); i++) {
   // copy odd single to top of neighbouring even double
+  if (IsB

[Lldb-commits] [lldb] r281601 - Fix TestSymbolContextTwoFiles on Android after rL281595

[Tamas Berghammer via lldb-commits]

Author: tberghammer
Date: Thu Sep 15 05:49:55 2016
New Revision: 281601

URL: http://llvm.org/viewvc/llvm-project?rev=281601&view=rev
Log:
Fix TestSymbolContextTwoFiles on Android after rL281595

Modified:

lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py?rev=281601&r1=281600&r2=281601&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py
 Thu Sep 15 05:49:55 2016
@@ -61,7 +61,7 @@ class SymbolContextTwoFilesTestCase(Test
 self.assertIsNotNone(breakpoint2)
 self.assertTrue(breakpoint2.IsValid())
 
-process = target.LaunchSimple(None, None, os.getcwd())
+process = target.LaunchSimple(None, None, 
self.get_process_working_directory())
 self.assertIsNotNone(process, PROCESS_IS_VALID)
 
 threads = lldbutil.get_threads_stopped_at_breakpoint(


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

Re: [Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

[Pavel Labath via lldb-commits]

labath added a comment.

The biggest feature I see missing here is the ability to run tests remotely. 
Remote debugging is the most important use case for our team, and now we have a 
number of (experimental) bots running the remote test suite. We want to make 
sure we can debug correctly when the host and target have different 
architectures, operating systems, pointer sizes, etc.

Some of the implications of this are:

- we need to be able to fully specify the toolchain used to compile the target 
executables (specifically, we should not assume the host compiler)
- this includes the need to pass funny compiler switches based on the target 
(some android targets can only run `-pie` executables, some cannot run `-pie` 
executables at all).
- the test suite needs to know how to connect to the remote target (mostly it's 
just executing three commands: `platform select XXX`, `platform connect` and 
`platform settings --working-dir YYY`), but it can get a bit more complicated 
in some cases (if we need to install shared libraries along with the main 
executable, if it involves the test executable writing something to a file, 
etc.)
- we need to be careful about strong cmake integration. The same lldb binary is 
capable of debugging all kinds of targets. We should not require a fresh cmake 
build to run the test suite against multiple targets. If we need to switch 
cmake options (`LLDB_TEST_COMPILER`, `LLDB_TEST_ARCH`, `LLDB_TEST_URL` or 
similar) and it does not trigger a rebuild then it's usable, but slightly 
inpractical. For us, it would be best to be able a fire off a remote test with 
a single command (like we can do now).

I am not against this going in without the remote feature in the first version, 
but I think we should think hardly about it, as I think it could impact a 
number of design decisions.



Comment at: lit/Expr/TestCallStdStringFunction.test:4
@@ +3,3 @@
+
+# XFAIL: compiler-icc
+# -> llvm.org/pr14437

I don't think anyone has tested lldb with icc in the past few years. We can 
avoid adding those xfails to the new tests.


https://reviews.llvm.org/D24591



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

Re: [Lldb-commits] [PATCH] D24603: [LLDB][MIPS] fix Floating point register read/write for big endian

[Pavel Labath via lldb-commits]

labath added inline comments.


Comment at: 
source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp:1183
@@ +1182,3 @@
+  case dwarf_config5_mips64:
+return reg_info->byte_offset;
+  case dwarf_cause_mips:

Why do we need to do this remapping? Couldn't we structure the register infos 
in a way that reg_info->byte_offset is exactly the offset that ptrace expects?

Or are you saying that ptrace does not accept register offsets, but some random 
register numbers instead? (I cannot tell, as the comment above is confusing.)


Comment at: 
source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp:1222
@@ +1221,3 @@
+  if (reg_info->invalidate_regs)
+assert(false && "In MIPS, reg_info->invalidate_regs is unhandled");
+

This seems like a pretty complicated way to write 
`assert(!reg_info->invalidate_regs);`


https://reviews.llvm.org/D24603



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

Re: [Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

[Pavel Labath via lldb-commits]

labath added a comment.

Btw, I will be in the bay area from 3rd to 7th of October. Maybe we could sit 
down and talk the design and requirements through in person? I've been hoping 
to speak to some of you in person anyway, and this could be a good first topic 
on the agenda...


https://reviews.llvm.org/D24591



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

[Lldb-commits] [lldb] r281606 - Reformat x86_64 register infos defines table

[Dimitar Vlahovski via lldb-commits]

Author: dvlahovski
Date: Thu Sep 15 07:58:27 2016
New Revision: 281606

URL: http://llvm.org/viewvc/llvm-project?rev=281606&view=rev
Log:
Reformat x86_64 register infos defines table

Fix the table format of the register defines after clang-format.
Added guards to prevent future reformatting again from clang-format.

Modified:
lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_x86_64.h

Modified: lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_x86_64.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_x86_64.h?rev=281606&r1=281605&r2=281606&view=diff
==
--- lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_x86_64.h (original)
+++ lldb/trunk/source/Plugins/Process/Utility/RegisterInfos_x86_64.h Thu Sep 15 
07:58:27 2016
@@ -196,57 +196,34 @@
 RegisterContextPOSIX_x86::g_invalidate_##reg64, NULL, 0
\
   }
 
+// clang-format off
 static RegisterInfo g_register_infos_x86_64[] = {
-// General purpose registers.   EH_Frame,   DWARF,
-// Generic,Process Plugin
-DEFINE_GPR(rax, nullptr, dwarf_rax_x86_64, dwarf_rax_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(rbx, nullptr, dwarf_rbx_x86_64, dwarf_rbx_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(rcx, "arg4", dwarf_rcx_x86_64, dwarf_rcx_x86_64,
-   LLDB_REGNUM_GENERIC_ARG4, LLDB_INVALID_REGNUM),
-DEFINE_GPR(rdx, "arg3", dwarf_rdx_x86_64, dwarf_rdx_x86_64,
-   LLDB_REGNUM_GENERIC_ARG3, LLDB_INVALID_REGNUM),
-DEFINE_GPR(rdi, "arg1", dwarf_rdi_x86_64, dwarf_rdi_x86_64,
-   LLDB_REGNUM_GENERIC_ARG1, LLDB_INVALID_REGNUM),
-DEFINE_GPR(rsi, "arg2", dwarf_rsi_x86_64, dwarf_rsi_x86_64,
-   LLDB_REGNUM_GENERIC_ARG2, LLDB_INVALID_REGNUM),
-DEFINE_GPR(rbp, "fp", dwarf_rbp_x86_64, dwarf_rbp_x86_64,
-   LLDB_REGNUM_GENERIC_FP, LLDB_INVALID_REGNUM),
-DEFINE_GPR(rsp, "sp", dwarf_rsp_x86_64, dwarf_rsp_x86_64,
-   LLDB_REGNUM_GENERIC_SP, LLDB_INVALID_REGNUM),
-DEFINE_GPR(r8, "arg5", dwarf_r8_x86_64, dwarf_r8_x86_64,
-   LLDB_REGNUM_GENERIC_ARG5, LLDB_INVALID_REGNUM),
-DEFINE_GPR(r9, "arg6", dwarf_r9_x86_64, dwarf_r9_x86_64,
-   LLDB_REGNUM_GENERIC_ARG6, LLDB_INVALID_REGNUM),
-DEFINE_GPR(r10, nullptr, dwarf_r10_x86_64, dwarf_r10_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(r11, nullptr, dwarf_r11_x86_64, dwarf_r11_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(r12, nullptr, dwarf_r12_x86_64, dwarf_r12_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(r13, nullptr, dwarf_r13_x86_64, dwarf_r13_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(r14, nullptr, dwarf_r14_x86_64, dwarf_r14_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(r15, nullptr, dwarf_r15_x86_64, dwarf_r15_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(rip, "pc", dwarf_rip_x86_64, dwarf_rip_x86_64,
-   LLDB_REGNUM_GENERIC_PC, LLDB_INVALID_REGNUM),
-DEFINE_GPR(rflags, "flags", dwarf_rflags_x86_64, dwarf_rflags_x86_64,
-   LLDB_REGNUM_GENERIC_FLAGS, LLDB_INVALID_REGNUM),
-DEFINE_GPR(cs, nullptr, dwarf_cs_x86_64, dwarf_cs_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(fs, nullptr, dwarf_fs_x86_64, dwarf_fs_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(gs, nullptr, dwarf_gs_x86_64, dwarf_gs_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(ss, nullptr, dwarf_ss_x86_64, dwarf_ss_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(ds, nullptr, dwarf_ds_x86_64, dwarf_ds_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
-DEFINE_GPR(es, nullptr, dwarf_es_x86_64, dwarf_es_x86_64,
-   LLDB_INVALID_REGNUM, LLDB_INVALID_REGNUM),
+// General purpose registers EH_Frame  DWARF 
Generic Process Plugin
+//  ===  ==  
=   
+DEFINE_GPR(rax,nullptr,  dwarf_rax_x86_64, dwarf_rax_x86_64, 
LLDB_INVALID_REGNUM,LLDB_INVALID_REGNUM),
+DEFINE_GPR(rbx,nullptr,  dwarf_rbx_x86_64, dwarf_rbx_x86_64, 
LLDB_INVALID_REGNUM,LLDB_INVALID_REGNUM),
+DEFINE_GPR(rcx,"arg4",   dwarf_rcx_x86_64, dwarf_rcx_x86_64, 
LLDB_REGNUM_GENERIC_ARG4,   LLDB_INVALID_REGNUM),
+DEFINE_GPR(rdx,"arg3",   dwarf_rdx_x86_64, dwarf_rdx_x86_64, 
LLDB_REGNUM_GENERIC_ARG3,   LLDB_INVALID_REGNUM),
+DEFINE_GPR(rdi,"arg1",

Re: [Lldb-commits] [PATCH] D24603: [LLDB][MIPS] fix Floating point register read/write for big endian

[Nitesh Jain via lldb-commits]

nitesh.jain added inline comments.


Comment at: 
source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp:1183
@@ +1182,3 @@
+  case dwarf_config5_mips64:
+return reg_info->byte_offset;
+  case dwarf_cause_mips:

labath wrote:
> Why do we need to do this remapping? Couldn't we structure the register infos 
> in a way that reg_info->byte_offset is exactly the offset that ptrace expects?
> 
> Or are you saying that ptrace does not accept register offsets, but some 
> random register numbers instead? (I cannot tell, as the comment above is 
> confusing.)
In case of MIPS, ptrace request PTRACE_PEEKUSER/PTRACE_POKEUSER accept register 
number as an offset.  We used reg_info->byte_offset to find register value in 
the struct GPR_linux_mips. The struct GPR_linux_mips  is same for 32 and 64 bit 
since ptrace always return 64 bit value irrespective of Arch (32 and 64) . 
Hence we can't modify reg_info->byte_offset to match exactly the offset that 
ptrace expects.


https://reviews.llvm.org/D24603



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

Re: [Lldb-commits] [PATCH] D24610: LLDB Arm Watchpoints: Use single hardware watchpoint slot to watch multiple bytes where possible

[Pavel Labath via lldb-commits]

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

I have some doubts about the validity of this patch. We should make sure those 
are cleared before putting this in.



Comment at: 
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_size/TestWatchpointSizes.py:43
@@ -42,2 +42,3 @@
 """Test to selectively watch different bytes in a 8-byte array."""
-self.run_watchpoint_size_test('byteArray', 8, '1')
+if self.getArchitecture() in ['arm']:
+self.run_watchpoint_size_test('byteArray', 8, '1', 1)

It's not clear to me why you need to modify the existing test for this change. 
You are adding functionality, so all existing tests should pass as-is (which 
will also validate that your change did not introduce regressions).


Comment at: 
packages/Python/lldbsuite/test/functionalities/watchpoint/watchpoint_size/TestWatchpointSizes.py:154
@@ +153,3 @@
+# Continue after hitting watchpoint twice (Read/Write)
+if slots != 0:
+self.runCmd("process continue")

It looks like this test will test something completely different on arm than on 
other architectures. You would probably be better off writing a new test for 
this.


Comment at: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp:556
@@ +555,3 @@
+uint32_t current_size = GetWatchpointSize(wp_index);
+if ((current_size == 4) || (current_size == 2 && watch_mask <= 2) ||
+(current_size == 1 && watch_mask == 1))

The logic here is extremely convoluted. Doesn't this code basically boil down 
to:
```
current_size = m_hwp_regs[wp_index].control & 1 ? GetWatchpointSize(wp_index) : 
0;
new_size = llvm::NextPowerOf2(std::max(current_size, watch_mask));
// update the control value, write the debug registers...
```

Also `watch_mask` should probably be renamed to `watch_size`, as it doesn't 
appear to be a mask.


Comment at: source/Plugins/Process/Linux/NativeRegisterContextLinux_arm.cpp:602
@@ -612,3 +601,3 @@
 
 bool NativeRegisterContextLinux_arm::ClearHardwareWatchpoint(
 uint32_t wp_index) {

This looks a bit worrying.
What will happen after the following sequence of events:
- client tells us to set a watchpoint at 0x1000
- we set the watchpoint
- client tells us to set a watchpoint at 0x1001
- we extend the previous watchpoint to watch this address as well
- client tells us to delete the watchpoint at 0x1000
- ???

Will we remain watching the address 0x1001? I don't see how will you be able to 
do that without maintaining a some info about the original watchpoints the 
client requested (and I have not seen that code). Please add a test for this.


https://reviews.llvm.org/D24610



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

Re: [Lldb-commits] [PATCH] D24603: [LLDB][MIPS] fix Floating point register read/write for big endian

[Nitesh Jain via lldb-commits]

nitesh.jain updated this revision to Diff 71505.
nitesh.jain added a comment.

Updated diff as per suggestion.


https://reviews.llvm.org/D24603

Files:
  source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
  source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.h

Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.h
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.h
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.h
@@ -76,11 +76,16 @@
   static bool IsMSAAvailable();
 
 protected:
-  Error DoReadRegisterValue(uint32_t offset, const char *reg_name,
-uint32_t size, RegisterValue &value) override;
+  Error Read_SR_Config(uint32_t offset, const char *reg_name, uint32_t size,
+   RegisterValue &value);
 
-  Error DoWriteRegisterValue(uint32_t offset, const char *reg_name,
- const RegisterValue &value) override;
+  uint32_t GetPtraceOffset(uint32_t reg_index,
+   const RegisterInfo *const reg_info);
+
+  Error ReadRegisterRaw(uint32_t reg_index, RegisterValue &value) override;
+
+  Error WriteRegisterRaw(uint32_t reg_index,
+ const RegisterValue &value) override;
 
   Error DoReadWatchPointRegisterValue(lldb::tid_t tid, void *watch_readback);
 
Index: source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
===
--- source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
+++ source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
@@ -28,9 +28,16 @@
 #include "lldb/Host/HostInfo.h"
 #include "lldb/lldb-enumerations.h"
 #include "lldb/lldb-private-enumerations.h"
+
 #define NT_MIPS_MSA 0x600
 #define CONFIG5_FRE (1 << 8)
 #define SR_FR (1 << 26)
+#define FPR_BASE 32
+#define PC 64
+#define CAUSE 65
+#define BADVADDR 66
+#define MMHI 67
+#define MMLO 68
 #define NUM_REGISTERS 32
 
 #include 
@@ -466,21 +473,23 @@
   }
 
   if (IsFPR(reg_index) || IsMSA(reg_index)) {
-uint8_t *dst;
-uint64_t *src;
+uint8_t *dst = nullptr;
+uint64_t *src = nullptr;
+uint8_t byte_size = reg_info->byte_size;
 
 // Initialise the FP and MSA buffers by reading all co-processor 1 registers
 ReadCP1();
 
 if (IsFPR(reg_index)) {
   assert(reg_info->byte_offset < sizeof(UserArea));
   dst = (uint8_t *)&m_fpr + reg_info->byte_offset - (sizeof(m_gpr));
+  byte_size = IsFR0() ? 4 : 8;
 } else {
   assert(reg_info->byte_offset < sizeof(UserArea));
   dst = (uint8_t *)&m_msa + reg_info->byte_offset -
 (sizeof(m_gpr) + sizeof(m_fpr));
 }
-switch (reg_info->byte_size) {
+switch (byte_size) {
 case 4:
   *(uint32_t *)dst = reg_value.GetAsUInt32();
   break;
@@ -611,11 +620,12 @@
 Error NativeRegisterContextLinux_mips64::ReadCP1() {
   Error error;
 
-  uint8_t *src, *dst;
+  uint8_t *src = nullptr;
+  uint8_t *dst = nullptr;
 
   lldb::ByteOrder byte_order = GetByteOrder();
 
-  uint32_t IsBigEndian = (byte_order == lldb::eByteOrderBig);
+  bool IsBigEndian = (byte_order == lldb::eByteOrderBig);
 
   if (IsMSAAvailable()) {
 error = NativeRegisterContextLinux::ReadRegisterSet(
@@ -637,11 +647,18 @@
 
   // TODO: Add support for FRE
   if (IsFR0()) {
-src = (uint8_t *)&m_fpr + 4 + (IsBigEndian * 4);
-dst = (uint8_t *)&m_fpr + 8 + (IsBigEndian * 4);
+src = (uint8_t *)&m_fpr + (!IsBigEndian) * 4;
+dst = (uint8_t *)&m_fpr + 8;
 for (int i = 0; i < (NUM_REGISTERS / 2); i++) {
   // copy odd single from top of neighbouring even double
+  // In case of little endian, 32 bit LSB store even FP register
+  // and 32 bit MSB store odd FP register
+  // vice-versa for big-endian
   *(uint32_t *)dst = *(uint32_t *)src;
+
+  if (IsBigEndian)
+// Copy 32 bit MSB to 32 bit LSB
+*(uint32_t *)src = *(uint32_t *)(src + 4);
   src = src + 16;
   dst = dst + 16;
 }
@@ -653,18 +670,23 @@
 Error NativeRegisterContextLinux_mips64::WriteCP1() {
   Error error;
 
-  uint8_t *src, *dst;
+  uint8_t *src = nullptr;
+  uint8_t *dst = nullptr;
 
   lldb::ByteOrder byte_order = GetByteOrder();
 
-  uint32_t IsBigEndian = (byte_order == lldb::eByteOrderBig);
+  bool IsBigEndian = (byte_order == lldb::eByteOrderBig);
 
   // TODO: Add support for FRE
   if (IsFR0()) {
-src = (uint8_t *)&m_fpr + 8 + (IsBigEndian * 4);
-dst = (uint8_t *)&m_fpr + 4 + (IsBigEndian * 4);
+dst = (uint8_t *)&m_fpr + (!IsBigEndian) * 4;
+src = dst + 8 - (!IsBigEndian) * 4;
 for (int i = 0; i < (NUM_REGISTERS / 2); i++) {
   // copy odd single to top of neighbouring even double
+  if (IsBigEndian)
+// Copy 32 bit LSB to 32 bit MSB
+*(uint32_t *)(dst + 4) = *(uint32_t *)dst;
+
   *(uint32_t *)dst = *(uint32_t *)src;
   src = src + 

Re: [Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

[Zachary Turner via lldb-commits]

On Wed, Sep 14, 2016 at 11:43 PM Jason Molenda  wrote:

> If we want to add a testsuite runner which takes a source file, a place to
> put a breakpoint, the name of a variable to examine, and it runs through
> those in SB API, I'm all in favor.  I don't know if that's going to add a
> lot of test coverage to lldb, but I have no problem with such a thing.
>
> My goal isn't to make test case writing hard.  My goal is to make the
> testsuite a benefit to the project, instead of a boat anchor.
>
> My non-goal is what testsuite harness is used to run the SB API tests -
> whether it's lit or whatever, I don't care.
>

It sounds like your goal is also "tests have to use the SB API and no other
API", which if so I think that's counterproductive.   More productive, IMO,
would be being open to any alternative that addresses the concerns you have
with command-line tests.  There are more than 2 ways to skin a cat, so to
speak.

Aside from that, it sounds like we have the same goal -- make the test
suite a benefit to the project rather than a boat anchor.  I guess we
differ on what constitutes a benefit and a boat anchor.  TBH I think the
current test suite is a boat anchor due to its numerous stability issues
and the barrier to entry for writing new tests.  lit wins by leaps and
bounds in both of these areas.  If there were something else that were even
better, then I'd be all for using it (although then we'd have to question
why LLVM doesn't also use it).  But the fact is -- as a test
infrastructure, lit is better.



On Wed, Sep 14, 2016 at 11:19 PM Jason Molenda  wrote:

> It's great to make writing tests easier.  We'd all love to have more tests.
>
> If "writing tests easier" is "command line output scraping", that's only
> hurting the project in the long term.  I'm telling you this from years of
> experience on a project where we did exactly this.  It's great to have
> examples where we're testing that "p 5" prints 5.  That's awesome and I'm
> sure it won't break.  But that's not more than a tiny fraction of what you
> need to test in a debugger.


At least 2 different brainstorm ideas have been proposed that would make
lit tests not rely on "command line output scraping".  A command line is
just a particular form of an API.  The SB API is another form of an API.
There are infinite numbers of ways to design an API, these aren't the only
2 APIs in the world.  One could easily imagine an "API" that was itself a
single LLDB command and which you could pass some kind of argument to it
that resolved to an SB API call.  Sean gave an example earlier.

(lldb) script lldb.frame.FindVariable("argc").GetValue()
'1'
(lldb) script lldb.process.GetNumThreads()
1
(lldb) script lldb.process.GetThreadAtIndex(0).GetThreadID()
3514809

Assuming your test ran against this output, is this a "command line
scraping" test or an "SB API" test?  Seems to be both, which is why I keep
saying that it's unproductive to talk about SB API tests and command line
scraping tests as the entire universe of options.

But even the above is not the only possibility.  You could directly map
every single SB API call to an LLDB command-line independent of the normal
command line UI.  One-to-one mapping

(lldb) object lldb.frame.variables["argc"].value
'1'
(lldb) object lldb.process.threads.count
1
(lldb) object lldb.process.threads[0].id
3514809

Is this really any different than the script example above?

So I would request that we stop talking about "command line scraping
tests".  Let's focus on the actual issue, which is "tests that are hard to
maintain: bad.  Tests that are easy to maintain: good"
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D24603: [LLDB][MIPS] fix Floating point register read/write for big endian

[Nitesh Jain via lldb-commits]

nitesh.jain marked an inline comment as done.
nitesh.jain added a comment.

https://reviews.llvm.org/D24603



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

Re: [Lldb-commits] [PATCH] D24603: [LLDB][MIPS] fix Floating point register read/write for big endian

[Pavel Labath via lldb-commits]

labath added inline comments.


Comment at: 
source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp:1161
@@ +1160,3 @@
+  // In case of MIPS, the PTRACE_PEEKUSER/PTRACE_POKEUSER
+  // take register number has an offset
+  // Apart from GPR registers , the offset for other registers are

Ok I think I understand this now.
`s/has/as/`



Comment at: 
source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp:1183
@@ +1182,3 @@
+  case dwarf_config5_mips64:
+return reg_info->byte_offset;
+  case dwarf_cause_mips:

nitesh.jain wrote:
> labath wrote:
> > Why do we need to do this remapping? Couldn't we structure the register 
> > infos in a way that reg_info->byte_offset is exactly the offset that ptrace 
> > expects?
> > 
> > Or are you saying that ptrace does not accept register offsets, but some 
> > random register numbers instead? (I cannot tell, as the comment above is 
> > confusing.)
> In case of MIPS, ptrace request PTRACE_PEEKUSER/PTRACE_POKEUSER accept 
> register number as an offset.  We used reg_info->byte_offset to find register 
> value in the struct GPR_linux_mips. The struct GPR_linux_mips  is same for 32 
> and 64 bit since ptrace always return 64 bit value irrespective of Arch (32 
> and 64) . Hence we can't modify reg_info->byte_offset to match exactly the 
> offset that ptrace expects.
Ok, I see what you mean. byte_offset is out in that case.
However, I am wondering if we couldn't tweak one of the existing numbering 
schemes to fit that one. For example, the LLDB numbering scheme is completely 
arbitrary, and under our control, so what if we just reordered that a bit to 
match what ptrace expects? I feel that we have enough numbering schemes 
already, so it should be possible to find one that works without introducing a 
new one.

This is not that bad, as the "scheme" is confined to the single file, but still 
you have to admit that this function looks very odd: sometimes you return a 
register index, sometimes a register offset and sometimes a completely made up 
number...


Comment at: 
source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp:1207
@@ +1206,3 @@
+
+  if ((reg_index == dwarf_sr_mips) || (strcmp(reg_info->name, "config5") == 0))
+return Read_SR_Config(offset, reg_info->name, reg_info->byte_size, value);

Isn't it possible to match the "config5" register by one of the numbering 
schemes, instead of by name?


https://reviews.llvm.org/D24603



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

Re: [Lldb-commits] [PATCH] D24124: [LLDB][MIPS] Fix register read/write for 32 bit big endian system

[Greg Clayton via lldb-commits]

clayborg added a comment.

A few things about a the RegisterContext class in case it would change and 
thing that you are submitting here. The entire register context defines a 
buffer of bytes that can contain all register values. Each RegisterInfo 
contains the offset for the value of this register in this buffer. This buffer 
is said to have a specific byte order (big, little, etc). When a register is 
read, it should place its bytes into the RegisterContext's buffer of bytes and 
mark itself as being valid in the register context. Some platforms read 
multiple registers at a time (they don't have a "read one register value", they 
just have "read all GPR registers") and lets say you are reading one GPR, and 
this causes all GPR values to be read, then all bytes from all GPR values will 
be copied into the register context data buffer and all GPRs should be marked 
as valid. So to get a RegisterValue for a 32 bit register, we normally will 
just ask the RegisterInfo for the offset of the register, and then extract the 
bytes from the buffer using a DataExtractor object. If you have a 64 bit 
register whose value also contains a 32 bit pseudo register (like rax contains 
eax on x86), then you should have a RegisterInfo defined for "rax" that says 
its offset is N, and for a big endian system, you would say that the register 
offset for "eax" is N + 4. Extracting the value simply becomes extracting the 
bytes from the buffer without the need for any tricks. After reading all of 
this, do you still believe you have the right fix in here? It doesn't seem like 
you ever should need to use DataExtractor::CopyByteOrderedData???



Comment at: source/Core/DataExtractor.cpp:949-958
@@ +948,12 @@
+  // Validate the source and destination info
+  assert(dst_void_ptr != nullptr || src_void_ptr != nullptr);
+  assert(dst_len > 0 || src_len > 0);
+  assert(src_len <= dst_len);
+  assert(dst_byte_order == eByteOrderBig || dst_byte_order == 
eByteOrderLittle);
+  assert(src_byte_order == eByteOrderBig || src_byte_order == 
eByteOrderLittle);
+
+  // Validate that only a word- or register-sized dst is byte swapped
+  assert(dst_byte_order == src_byte_order || dst_len == 1 || dst_len == 2 ||
+ dst_len == 4 || dst_len == 8 || dst_len == 10 || dst_len == 16 ||
+ dst_len == 32);
+

change all assert calls to lldbassert so they don't crash  running program and 
add if statements that return if any of the assertion fails. We can't just 
crash when we are unhappy with function input. I know llvm and clang do this, 
but it has caused way too many crashes for LLDB.


Comment at: source/Core/DataExtractor.cpp:1024-1026
@@ -942,5 +1023,5 @@
 lldb::offset_t
 DataExtractor::CopyByteOrderedData(offset_t src_offset, offset_t src_len,
void *dst_void_ptr, offset_t dst_len,
ByteOrder dst_byte_order) const {
   // Validate the source info

Should probably have this call the above new function so we don't duplicate 
functionality.


https://reviews.llvm.org/D24124



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

[Lldb-commits] [lldb] r281639 - added LLDB_PYTHON_TESTSUITE_ARCH Xcode variable

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Thu Sep 15 13:28:03 2016
New Revision: 281639

URL: http://llvm.org/viewvc/llvm-project?rev=281639&view=rev
Log:
added LLDB_PYTHON_TESTSUITE_ARCH Xcode variable

This Xcode build variable defaults to x86_64.  It can be set to i386
to cause the lldb-python-test-suite target run the tests in the
specified architecture.

This flag is being added for the zorg build script so that Green Dragon
can run the test suite against both x86_64 and i386 macOS targets.

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

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=281639&r1=281638&r2=281639&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Thu Sep 15 13:28:03 2016
@@ -6420,11 +6420,11 @@
 /* Begin PBXLegacyTarget section */
2387551E1C24974600CCE8C3 /* lldb-python-test-suite */ = {
isa = PBXLegacyTarget;
-   buildArgumentsString = "-u $(SRCROOT)/test/dotest.py 
--apple-sdk $(PLATFORM_NAME) 
--executable=$(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/lldb -C 
$(LLDB_PYTHON_TESTSUITE_CC) --session-file-format fm --results-formatter 
lldbsuite.test_event.formatter.xunit.XunitFormatter --results-file 
$(BUILD_DIR)/test-results.xml --rerun-all-issues --env TERM=vt100 
-O--xpass=ignore";
+   buildArgumentsString = "-u $(SRCROOT)/test/dotest.py 
--apple-sdk $(PLATFORM_NAME) 
--executable=$(BUILD_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)/lldb -C 
$(LLDB_PYTHON_TESTSUITE_CC) --arch $(LLDB_PYTHON_TESTSUITE_ARCH) 
--session-file-format fm --results-formatter 
lldbsuite.test_event.formatter.xunit.XunitFormatter --results-file 
$(BUILD_DIR)/test-results.xml --rerun-all-issues --env TERM=vt100 
-O--xpass=ignore";
buildConfigurationList = 238755241C24974600CCE8C3 /* 
Build configuration list for PBXLegacyTarget "lldb-python-test-suite" */;
buildPhases = (
);
-   buildToolPath = python;
+   buildToolPath = /usr/bin/python;
buildWorkingDirectory = "$(BUILD_DIR)";
dependencies = (
);
@@ -8033,6 +8033,7 @@
);
GCC_WARN_ABOUT_RETURN_TYPE = YES_ERROR;
GCC_WARN_UNINITIALIZED_AUTOS = YES_AGGRESSIVE;
+   LLDB_PYTHON_TESTSUITE_ARCH = x86_64;
LLDB_PYTHON_TESTSUITE_CC = 
"$(LLVM_BUILD_DIR)/x86_64/bin/clang";
MTL_ENABLE_DEBUG_INFO = YES;
OTHER_CFLAGS = "";
@@ -8062,6 +8063,7 @@
);
GCC_WARN_ABOUT_RETURN_TYPE = YES_ERROR;
GCC_WARN_UNINITIALIZED_AUTOS = YES_AGGRESSIVE;
+   LLDB_PYTHON_TESTSUITE_ARCH = x86_64;
LLDB_PYTHON_TESTSUITE_CC = 
"$(LLVM_BUILD_DIR)/x86_64/bin/clang";
MTL_ENABLE_DEBUG_INFO = YES;
OTHER_CFLAGS = "";
@@ -8083,6 +8085,7 @@
GCC_C_LANGUAGE_STANDARD = gnu99;
GCC_WARN_ABOUT_RETURN_TYPE = YES_ERROR;
GCC_WARN_UNINITIALIZED_AUTOS = YES_AGGRESSIVE;
+   LLDB_PYTHON_TESTSUITE_ARCH = x86_64;
LLDB_PYTHON_TESTSUITE_CC = 
"$(LLVM_BUILD_DIR)/x86_64/bin/clang";
MTL_ENABLE_DEBUG_INFO = NO;
OTHER_CFLAGS = "";
@@ -8104,6 +8107,7 @@
GCC_C_LANGUAGE_STANDARD = gnu99;
GCC_WARN_ABOUT_RETURN_TYPE = YES_ERROR;
GCC_WARN_UNINITIALIZED_AUTOS = YES_AGGRESSIVE;
+   LLDB_PYTHON_TESTSUITE_ARCH = x86_64;
LLDB_PYTHON_TESTSUITE_CC = 
"$(LLVM_BUILD_DIR)/x86_64/bin/clang";
MTL_ENABLE_DEBUG_INFO = NO;
OTHER_CFLAGS = "";


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

Re: [Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

[Zachary Turner via lldb-commits]

lldb-commits to bcc, lldb-dev to cc.

> The biggest feature I see missing here is the ability to run tests
remotely. Remote debugging is the most important use case for our team, and
now we have a number of (experimental) bots running the remote test suite.
We want to make sure we can debug correctly when the host and target have
different architectures

That is a good point.  I thought about this a little bit and I believe I
have a solution to most of the issues you would face when running a remote
test suite, but perhaps it would be better to take that to a different
thread on lldb-dev rather than on this commit.  So I'm taking lldb-commits
off of this thread and adding lldb-dev.   Responses inline.

On Thu, Sep 15, 2016 at 4:02 AM Pavel Labath  wrote:



>  - the test suite needs to know how to connect to the remote target
> (mostly it's just executing three commands: `platform select XXX`,
> `platform connect` and `platform settings --working-dir YYY`), but it can
> get a bit more complicated in some cases (if we need to install shared
> libraries along with the main executable, if it involves the test
> executable writing something to a file, etc.)

This seems like the easiest of the problems to solve, so I'm mentioning it
first.  I can imagine a couple of command line options to the lldb
executable itself that allow one to configure remote debugging from the
command line.  Then, we could provide one CMake target for each remote
platform.  check-lldb-remote-android, check-lldb-remote-fizzbuzz,
whatever.  And you could configure all of these at CMake time with one
command.  Like cmake -DLLDB_TEST_REMOTE_TARGETS=android,fizzbuzz,etc.
Internally, each target's CMake logic could configure some appropriate
variables that would be picked up by lit so that the lit substitution for
running lldb would supply the appropriate command line to configure the
remote target.

 - this includes the need to pass funny compiler switches based on the
target (some android targets can only run `-pie` executables, some cannot
run `-pie` executables at all).
 This should be handled the same way as above.  Configuring the lit
substitutions for the compiler invocation can depend on which cmake target
you're running lit through.  ninja check-lldb-remote-android could define
one set of lit substitutions, and another target could define another.  Is
this sufficient?  Is it easy to define a mapping between the set of all
remote targets and the set of all command line flag combinations?

- we need to be able to fully specify the toolchain used to compile the
> target executables (specifically, we should not assume the host compiler)
>
Will you want a single run of the test suite to use multiple compilers, or
can we assume there is only 1 compiler for a given cmake output directory?
I think we can assume the latter since even now we only have 1 cmake
variable `LLDB_TEST_COMPILER`, but let me know if this is a wrong assumption


>
> - we need to be careful about strong cmake integration. The same lldb
> binary is capable of debugging all kinds of targets. We should not require
> a fresh cmake build to run the test suite against multiple targets. If we
> need to switch cmake options (`LLDB_TEST_COMPILER`, `LLDB_TEST_ARCH`,
> `LLDB_TEST_URL` or similar) and it does not trigger a rebuild then it's
> usable, but slightly inpractical. For us, it would be best to be able a
> fire off a remote test with a single command (like we can do now).
>
See first response.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r281642 - Convert ArchSpec::ParseMachOCPUDashSubtypeTriple to use StringRef.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Thu Sep 15 13:41:48 2016
New Revision: 281642

URL: http://llvm.org/viewvc/llvm-project?rev=281642&view=rev
Log:
Convert ArchSpec::ParseMachOCPUDashSubtypeTriple to use StringRef.

This makes the code easier to grok, and since this is a very low
level function it also is very helpful to have this take a StringRef
since it means anyone higher up the chain who has a StringRef would
have to first convert it to a null-terminated string.  This way it
can work equally well with StringRefs or const char*'s, which will
enable the conversion of higher up functions to StringRef.

Tested on Windows, Linux, and OSX and saw no regressions.

Modified:
lldb/trunk/include/lldb/Core/ArchSpec.h
lldb/trunk/source/Core/ArchSpec.cpp
lldb/trunk/unittests/Core/ArchSpecTest.cpp

Modified: lldb/trunk/include/lldb/Core/ArchSpec.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/ArchSpec.h?rev=281642&r1=281641&r2=281642&view=diff
==
--- lldb/trunk/include/lldb/Core/ArchSpec.h (original)
+++ lldb/trunk/include/lldb/Core/ArchSpec.h Thu Sep 15 13:41:48 2016
@@ -625,7 +625,7 @@ protected:
 //--
 bool operator<(const ArchSpec &lhs, const ArchSpec &rhs);
 
-bool ParseMachCPUDashSubtypeTriple(const char *triple_cstr, ArchSpec &arch);
+bool ParseMachCPUDashSubtypeTriple(llvm::StringRef triple_str, ArchSpec &arch);
 
 } // namespace lldb_private
 

Modified: lldb/trunk/source/Core/ArchSpec.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ArchSpec.cpp?rev=281642&r1=281641&r2=281642&view=diff
==
--- lldb/trunk/source/Core/ArchSpec.cpp (original)
+++ lldb/trunk/source/Core/ArchSpec.cpp Thu Sep 15 13:41:48 2016
@@ -821,51 +821,48 @@ bool ArchSpec::SetTriple(const llvm::Tri
   return IsValid();
 }
 
-bool lldb_private::ParseMachCPUDashSubtypeTriple(const char *triple_cstr,
- ArchSpec &arch) {
+bool lldb_private::ParseMachCPUDashSubtypeTriple(llvm::StringRef triple_str, 
ArchSpec &arch) {
   // Accept "12-10" or "12.10" as cpu type/subtype
-  if (isdigit(triple_cstr[0])) {
-char *end = nullptr;
-errno = 0;
-uint32_t cpu = (uint32_t)::strtoul(triple_cstr, &end, 0);
-if (errno == 0 && cpu != 0 && end && ((*end == '-') || (*end == '.'))) {
-  errno = 0;
-  uint32_t sub = (uint32_t)::strtoul(end + 1, &end, 0);
-  if (errno == 0 && end &&
-  ((*end == '-') || (*end == '.') || (*end == '\0'))) {
-if (arch.SetArchitecture(eArchTypeMachO, cpu, sub)) {
-  if (*end == '-') {
-llvm::StringRef vendor_os(end + 1);
-size_t dash_pos = vendor_os.find('-');
-if (dash_pos != llvm::StringRef::npos) {
-  llvm::StringRef vendor_str(vendor_os.substr(0, dash_pos));
-  arch.GetTriple().setVendorName(vendor_str);
-  const size_t vendor_start_pos = dash_pos + 1;
-  dash_pos = vendor_os.find('-', vendor_start_pos);
-  if (dash_pos == llvm::StringRef::npos) {
-if (vendor_start_pos < vendor_os.size())
-  arch.GetTriple().setOSName(
-  vendor_os.substr(vendor_start_pos));
-  } else {
-arch.GetTriple().setOSName(vendor_os.substr(
-vendor_start_pos, dash_pos - vendor_start_pos));
-  }
-}
-  }
-  return true;
-}
-  }
-}
+  if (triple_str.empty())
+return false;
+
+  size_t pos = triple_str.find_first_of("-.");
+  if (pos == llvm::StringRef::npos)
+return false;
+
+  llvm::StringRef cpu_str = triple_str.substr(0, pos);
+  llvm::StringRef remainder = triple_str.substr(pos + 1);
+  if (cpu_str.empty() || remainder.empty())
+return false;
+
+  llvm::StringRef sub_str;
+  llvm::StringRef vendor;
+  llvm::StringRef os;
+  std::tie(sub_str, remainder) = remainder.split('-');
+  std::tie(vendor, os) = remainder.split('-');
+
+  uint32_t cpu = 0;
+  uint32_t sub = 0;
+  if (cpu_str.getAsInteger(10, cpu) || sub_str.getAsInteger(10, sub))
+return false;
+
+  if (!arch.SetArchitecture(eArchTypeMachO, cpu, sub))
+return false;
+  if (!vendor.empty() && !os.empty()) {
+arch.GetTriple().setVendorName(vendor);
+arch.GetTriple().setOSName(os);
   }
-  return false;
+
+  return true;
 }
 
 bool ArchSpec::SetTriple(const char *triple_cstr) {
   if (triple_cstr && triple_cstr[0]) {
-if (ParseMachCPUDashSubtypeTriple(triple_cstr, *this))
+llvm::StringRef triple_stref(triple_cstr);
+
+if (ParseMachCPUDashSubtypeTriple(triple_stref, *this))
   return true;
 
-llvm::StringRef triple_stref(triple_cstr);
 if (triple_stref.startswith(LLDB_ARCH_DEFAULT)) {
   // Special case for the current host default architectures...

Re: [Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

[Chris Bieneman via lldb-commits]

beanz updated this revision to Diff 71537.
beanz added a comment.

- Removed the XFAIL for icc
- Added support for LLDB_TEST__COMPILER options

Assuming there are no objections, since the patch has been approved by two 
reviewers I'll commit it this afternoon.

Thanks,
-Chris


https://reviews.llvm.org/D24591

Files:
  lit/CMakeLists.txt
  lit/Expr/Inputs/anonymous-struct.cpp
  lit/Expr/Inputs/call-function.cpp
  lit/Expr/TestCallStdStringFunction.test
  lit/Expr/TestCallStopAndContinue.test
  lit/Expr/TestCallUserAnonTypedef.test
  lit/Expr/TestCallUserDefinedFunction.test
  lit/Expr/lit.local.cfg
  lit/Unit/lit.cfg
  lit/Unit/lit.site.cfg.in
  lit/lit.cfg
  lit/lit.site.cfg.in

Index: lit/lit.site.cfg.in
===
--- lit/lit.site.cfg.in
+++ lit/lit.site.cfg.in
@@ -8,6 +8,22 @@
 config.lldb_obj_root = "@LLDB_BINARY_DIR@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.python_executable = "@PYTHON_EXECUTABLE@"
+config.cc = "@CMAKE_C_COMPILER@"
+config.cxx = "@CMAKE_CXX_COMPILER@"
+
+test_c_compiler = "@LLDB_TEST_C_COMPILER@"
+test_cxx_compiler = "@LLDB_TEST_CXX_COMPILER@"
+test_clang = "@LLDB_TEST_CLANG@".lower()
+test_clang = test_clang == "on" or test_clang == "true" or test_clang == "1"
+
+if len(test_c_compiler) > 0:
+  config.cc = test_c_compiler
+if len(test_c_compiler) > 0:
+  config.cxx = test_cxx_compiler
+
+if test_clang:
+  config.cc = 'clang'
+  config.cxx = 'clang++'
 
 # Support substitution of the tools and libs dirs with user parameters. This is
 # used when we can't determine the tool dir at configuration time.
Index: lit/lit.cfg
===
--- lit/lit.cfg
+++ lit/lit.cfg
@@ -112,17 +112,80 @@
 lit_config.load_config(config, site_cfg)
 raise SystemExit
 
+# Register substitutions
+config.substitutions.append(('%python', config.python_executable))
+
+debugserver = lit.util.which('debugserver', llvm_tools_dir)
+lldb = lit.util.which('lldb', llvm_tools_dir)
+
+if not os.path.exists(config.cc):
+config.cc = lit.util.which(config.cc, llvm_tools_dir)
+
+if not os.path.exists(config.cxx):
+config.cxx = lit.util.which(config.cxx, llvm_tools_dir)
+
+if platform.system() in ['Darwin']:
+try:
+out = lit.util.capture(['xcrun', '--show-sdk-path']).strip()
+res = 0
+except OSError:
+res = -1
+if res == 0 and out:
+sdk_path = out
+lit_config.note('using SDKROOT: %r' % sdk_path)
+config.cc += " -isysroot %s" % sdk_path
+config.cxx += " -isysroot %s" % sdk_path
+
+config.substitutions.append(('%cc', config.cc))
+config.substitutions.append(('%cxx', config.cxx))
+
+config.substitutions.append(('%lldb', lldb))
+config.substitutions.append(('%debugserver', debugserver))
+
+for pattern in [r"\bFileCheck\b",
+r"\| \bnot\b"]:
+tool_match = re.match(r"^(\\)?((\| )?)\W+b([0-9A-Za-z-_]+)\\b\W*$",
+  pattern)
+tool_pipe = tool_match.group(2)
+tool_name = tool_match.group(4)
+tool_path = lit.util.which(tool_name, config.llvm_tools_dir)
+if not tool_path:
+# Warn, but still provide a substitution.
+lit_config.note(
+'Did not find ' + tool_name + ' in ' + config.llvm_tools_dir)
+config.substitutions.append((pattern, tool_pipe + tool_path))
+
 # Shell execution
 if platform.system() not in ['Windows'] or lit_config.getBashPath() != '':
 config.available_features.add('shell')
 
 # Running on Darwin OS
 if platform.system() in ['Darwin']:
+config.available_features.add('darwin')
 config.available_features.add('system-linker-mach-o')
 
 # Running on ELF based *nix
 if platform.system() in ['FreeBSD', 'Linux']:
 config.available_features.add('system-linker-elf')
+if platform.system() in ['FreeBSD']:
+config.available_features.add('freebsd')
+else:
+config.available_features.add('linux')
+
+if platform.system() in ['Windows']:
+config.available_features.add('windows')
+
+if re.match(r'^arm(hf.*-linux)|(.*-linux-gnuabihf)', config.target_triple):
+config.available_features.add("armhf-linux")
+
+if re.match(r'icc', config.cc):
+config.available_features.add("compiler-icc")
+elif re.match(r'clang', config.cc):
+config.available_features.add("compiler-clang")
+elif re.match(r'gcc', config.cc):
+config.available_features.add("compiler-gcc")
+elif re.match(r'cl', config.cc):
+config.available_features.add("compiler-msvc")
 
 # llvm-config knows whether it is compiled with asserts (and)
 # whether we are operating in release/debug mode.
Index: lit/Unit/lit.site.cfg.in
===
--- lit/Unit/lit.site.cfg.in
+++ lit/Unit/lit.site.cfg.in
@@ -1,5 +1,6 @@
 @LIT_SITE_CFG_IN_HEADER@
 
+config.test_exec_root = "@LLVM_BINARY_DIR@" 
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_t

Re: [Lldb-commits] [PATCH] D24610: LLDB Arm Watchpoints: Use single hardware watchpoint slot to watch multiple bytes where possible

[Greg Clayton via lldb-commits]

clayborg requested changes to this revision.
clayborg added a comment.

Great fix. Just fix the testing so that it isn't ARM specific. There shouldn't 
be any:

  if self.getArchitecture() in ['arm']:
do arm stuff
  else:
do non arm stuff

Also we will need to be able to test the set watch at 0x1000, then at 0x1001 by 
sharing, clear 0x1000 make sure 0x1001 still works, etc.


https://reviews.llvm.org/D24610



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

[Lldb-commits] [lldb] r281651 - [LIT] First pass of LLDB LIT support

[Chris Bieneman via lldb-commits]

Author: cbieneman
Date: Thu Sep 15 15:13:55 2016
New Revision: 281651

URL: http://llvm.org/viewvc/llvm-project?rev=281651&view=rev
Log:
[LIT] First pass of LLDB LIT support

Summary:
This patch supplies basic infrastructure for LLDB to use LIT, and ports a few 
basic test cases from the LLDB test suite into LIT.

With this patch the LLDB lit system is not capable or intended to fully replace 
the existing LLDB test suite, but this first patch enables people to write lit 
tests for LLDB.

The lit substitution for %cc and %cxx default to the host compiler unless the 
CMake option LLDB_TEST_CLANG is On, in which case the in-tree clang will be 
used.

The target check-lldb-lit will run all lit tests including the lit-based 
executor for the unit tests. Alternatively there is a target generated for each 
subdirectory under the lit directory, so check-lldb-unit and check-lldb-expr 
will run just the tests under their respective directories.

The ported tests are not removed from the existing suite, and should not be 
until such a time when the lit runner is mature and in use by bots and 
workflows.

Reviewers: zturner, labath, jingham, tfiala

Subscribers: beanz, mgorny, lldb-commits

Differential Revision: https://reviews.llvm.org/D24591

Added:
lldb/trunk/lit/Expr/
lldb/trunk/lit/Expr/Inputs/
lldb/trunk/lit/Expr/Inputs/anonymous-struct.cpp
lldb/trunk/lit/Expr/Inputs/call-function.cpp
lldb/trunk/lit/Expr/TestCallStdStringFunction.test
lldb/trunk/lit/Expr/TestCallStopAndContinue.test
lldb/trunk/lit/Expr/TestCallUserAnonTypedef.test
lldb/trunk/lit/Expr/TestCallUserDefinedFunction.test
lldb/trunk/lit/Expr/lit.local.cfg
Modified:
lldb/trunk/lit/CMakeLists.txt
lldb/trunk/lit/Unit/lit.cfg
lldb/trunk/lit/Unit/lit.site.cfg.in
lldb/trunk/lit/lit.cfg
lldb/trunk/lit/lit.site.cfg.in

Modified: lldb/trunk/lit/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/CMakeLists.txt?rev=281651&r1=281650&r2=281651&view=diff
==
--- lldb/trunk/lit/CMakeLists.txt (original)
+++ lldb/trunk/lit/CMakeLists.txt Thu Sep 15 15:13:55 2016
@@ -11,6 +11,10 @@ else()
   set(ENABLE_SHARED 0)
 endif(BUILD_SHARED_LIBS)
 
+option(LLDB_TEST_CLANG "Use in-tree clang when testing lldb" Off)
+set(LLDB_TEST_C_COMPILER "" CACHE STRING "C compiler to use when testing LLDB")
+set(LLDB_TEST_CXX_COMPILER "" CACHE STRING "C++ compiler to use when testing 
LLDB")
+
 configure_lit_site_cfg(
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
   ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg)
@@ -20,17 +24,36 @@ configure_lit_site_cfg(
   )
 
 set(LLDB_TEST_DEPS
+  FileCheck
+  debugserver
   LLDBUnitTests
+  lldb
+  lldb-server
+  not
   )
+
+if(LLDB_TEST_CLANG)
+  if(LLDB_TEST_C_COMPILER OR LLDB_TEST_CXX_COMPILER)
+message(SEND_ERROR "Cannot override LLDB_TEST__COMPILER and set 
LLDB_TEST_CLANG.")
+  endif()
+  list(APPEND LLDB_TEST_DEPS clang)
+endif()
+
 set(LLDB_TEST_PARAMS
   lldb_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
   )
 
-add_lit_testsuite(check-lldb-unit "Running lldb unit test suite"
+add_lit_testsuite(check-lldb-lit "Running lldb lit test suite"
   ${CMAKE_CURRENT_BINARY_DIR}
   PARAMS lldb_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
lldb_unit_site_config=${CMAKE_CURRENT_BINARY_DIR}/Unit/lit.site.cfg
   DEPENDS ${LLDB_TEST_DEPS}
   )
 
-set_target_properties(check-lldb-unit PROPERTIES FOLDER "LLDB tests")
+set_target_properties(check-lldb-lit PROPERTIES FOLDER "LLDB tests")
+
+add_lit_testsuites(LLDB ${CMAKE_CURRENT_SOURCE_DIR}
+  PARAMS lldb_site_config=${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
+ lldb_unit_site_config=${CMAKE_CURRENT_BINARY_DIR}/Unit/lit.site.cfg
+  DEPENDS ${LLDB_TEST_DEPS}
+  )

Added: lldb/trunk/lit/Expr/Inputs/anonymous-struct.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Expr/Inputs/anonymous-struct.cpp?rev=281651&view=auto
==
--- lldb/trunk/lit/Expr/Inputs/anonymous-struct.cpp (added)
+++ lldb/trunk/lit/Expr/Inputs/anonymous-struct.cpp Thu Sep 15 15:13:55 2016
@@ -0,0 +1,26 @@
+#include 
+
+typedef struct {
+float f;
+int i;
+} my_untagged_struct;
+
+double multiply(my_untagged_struct *s)
+{
+return s->f * s->i;
+}
+
+double multiply(my_untagged_struct *s, int x)
+{
+return multiply(s) * x;
+}
+
+int main(int argc, char **argv)
+{
+my_untagged_struct s = {
+.f = (float)argc,
+.i = argc,
+};
+// lldb testsuite break
+return !(multiply(&s, argc) == pow(argc, 3));
+}

Added: lldb/trunk/lit/Expr/Inputs/call-function.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/Expr/Inputs/call-function.cpp?rev=281651&view=auto
==
--- lldb/trunk/lit/Expr/Inputs/call-function.cpp (added)
+++ lldb/trunk/lit/Expr/Inputs/call-function.cpp Thu S

Re: [Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

[Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL281651: [LIT] First pass of LLDB LIT support (authored by 
cbieneman).

Changed prior to commit:
  https://reviews.llvm.org/D24591?vs=71537&id=71546#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24591

Files:
  lldb/trunk/lit/CMakeLists.txt
  lldb/trunk/lit/Expr/Inputs/anonymous-struct.cpp
  lldb/trunk/lit/Expr/Inputs/call-function.cpp
  lldb/trunk/lit/Expr/TestCallStdStringFunction.test
  lldb/trunk/lit/Expr/TestCallStopAndContinue.test
  lldb/trunk/lit/Expr/TestCallUserAnonTypedef.test
  lldb/trunk/lit/Expr/TestCallUserDefinedFunction.test
  lldb/trunk/lit/Expr/lit.local.cfg
  lldb/trunk/lit/Unit/lit.cfg
  lldb/trunk/lit/Unit/lit.site.cfg.in
  lldb/trunk/lit/lit.cfg
  lldb/trunk/lit/lit.site.cfg.in

Index: lldb/trunk/lit/lit.cfg
===
--- lldb/trunk/lit/lit.cfg
+++ lldb/trunk/lit/lit.cfg
@@ -112,17 +112,80 @@
 lit_config.load_config(config, site_cfg)
 raise SystemExit
 
+# Register substitutions
+config.substitutions.append(('%python', config.python_executable))
+
+debugserver = lit.util.which('debugserver', llvm_tools_dir)
+lldb = lit.util.which('lldb', llvm_tools_dir)
+
+if not os.path.exists(config.cc):
+config.cc = lit.util.which(config.cc, llvm_tools_dir)
+
+if not os.path.exists(config.cxx):
+config.cxx = lit.util.which(config.cxx, llvm_tools_dir)
+
+if platform.system() in ['Darwin']:
+try:
+out = lit.util.capture(['xcrun', '--show-sdk-path']).strip()
+res = 0
+except OSError:
+res = -1
+if res == 0 and out:
+sdk_path = out
+lit_config.note('using SDKROOT: %r' % sdk_path)
+config.cc += " -isysroot %s" % sdk_path
+config.cxx += " -isysroot %s" % sdk_path
+
+config.substitutions.append(('%cc', config.cc))
+config.substitutions.append(('%cxx', config.cxx))
+
+config.substitutions.append(('%lldb', lldb))
+config.substitutions.append(('%debugserver', debugserver))
+
+for pattern in [r"\bFileCheck\b",
+r"\| \bnot\b"]:
+tool_match = re.match(r"^(\\)?((\| )?)\W+b([0-9A-Za-z-_]+)\\b\W*$",
+  pattern)
+tool_pipe = tool_match.group(2)
+tool_name = tool_match.group(4)
+tool_path = lit.util.which(tool_name, config.llvm_tools_dir)
+if not tool_path:
+# Warn, but still provide a substitution.
+lit_config.note(
+'Did not find ' + tool_name + ' in ' + config.llvm_tools_dir)
+config.substitutions.append((pattern, tool_pipe + tool_path))
+
 # Shell execution
 if platform.system() not in ['Windows'] or lit_config.getBashPath() != '':
 config.available_features.add('shell')
 
 # Running on Darwin OS
 if platform.system() in ['Darwin']:
+config.available_features.add('darwin')
 config.available_features.add('system-linker-mach-o')
 
 # Running on ELF based *nix
 if platform.system() in ['FreeBSD', 'Linux']:
 config.available_features.add('system-linker-elf')
+if platform.system() in ['FreeBSD']:
+config.available_features.add('freebsd')
+else:
+config.available_features.add('linux')
+
+if platform.system() in ['Windows']:
+config.available_features.add('windows')
+
+if re.match(r'^arm(hf.*-linux)|(.*-linux-gnuabihf)', config.target_triple):
+config.available_features.add("armhf-linux")
+
+if re.match(r'icc', config.cc):
+config.available_features.add("compiler-icc")
+elif re.match(r'clang', config.cc):
+config.available_features.add("compiler-clang")
+elif re.match(r'gcc', config.cc):
+config.available_features.add("compiler-gcc")
+elif re.match(r'cl', config.cc):
+config.available_features.add("compiler-msvc")
 
 # llvm-config knows whether it is compiled with asserts (and)
 # whether we are operating in release/debug mode.
Index: lldb/trunk/lit/Unit/lit.site.cfg.in
===
--- lldb/trunk/lit/Unit/lit.site.cfg.in
+++ lldb/trunk/lit/Unit/lit.site.cfg.in
@@ -1,5 +1,6 @@
 @LIT_SITE_CFG_IN_HEADER@
 
+config.test_exec_root = "@LLVM_BINARY_DIR@" 
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
Index: lldb/trunk/lit/Unit/lit.cfg
===
--- lldb/trunk/lit/Unit/lit.cfg
+++ lldb/trunk/lit/Unit/lit.cfg
@@ -6,6 +6,19 @@
 
 import lit.formats
 
+# Check that the object root is known.
+if config.test_exec_root is None:
+# Otherwise, we haven't loaded the site specific configuration (the user is
+# probably trying to run on a test file directly, and either the site
+# configuration hasn't been created by the build system, or we are in an
+# out-of-tree build situation).
+
+# Check for 'llvm_unit_site_config' user parameter, and use that if available.
+site_cfg = lit_config.params.get('lldb_unit_site_config', None

[Lldb-commits] [lldb] r281652 - Fixing bot failures

[Chris Bieneman via lldb-commits]

Author: cbieneman
Date: Thu Sep 15 15:23:31 2016
New Revision: 281652

URL: http://llvm.org/viewvc/llvm-project?rev=281652&view=rev
Log:
Fixing bot failures

Need to only add debugserver as a test dependency on Darwin.

Modified:
lldb/trunk/lit/CMakeLists.txt

Modified: lldb/trunk/lit/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/CMakeLists.txt?rev=281652&r1=281651&r2=281652&view=diff
==
--- lldb/trunk/lit/CMakeLists.txt (original)
+++ lldb/trunk/lit/CMakeLists.txt Thu Sep 15 15:23:31 2016
@@ -25,12 +25,14 @@ configure_lit_site_cfg(
 
 set(LLDB_TEST_DEPS
   FileCheck
-  debugserver
   LLDBUnitTests
   lldb
   lldb-server
   not
   )
+if(APPLE)
+  list(APPEND LLDB_TEST_DEPS debugserver)
+endif()
 
 if(LLDB_TEST_CLANG)
   if(LLDB_TEST_C_COMPILER OR LLDB_TEST_CXX_COMPILER)


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

[Lldb-commits] [PATCH] D24629: Allow for tests to be disabled at runtime

[Francis Ricci via lldb-commits]

fjricci created this revision.
fjricci added reviewers: zturner, labath, tfiala.
fjricci added subscribers: lldb-commits, sas.

The current implementation of the test suite allows the user to run
a certain subset of tests using '-p', but does not allow the inverse,
where a user wants to run all but some number of known failing tests.
Implement this functionality.

https://reviews.llvm.org/D24629

Files:
  packages/Python/lldbsuite/test/configuration.py
  packages/Python/lldbsuite/test/dotest.py
  packages/Python/lldbsuite/test/dotest_args.py
  packages/Python/lldbsuite/test/test_result.py

Index: packages/Python/lldbsuite/test/test_result.py
===
--- packages/Python/lldbsuite/test/test_result.py
+++ packages/Python/lldbsuite/test/test_result.py
@@ -18,6 +18,8 @@
 # Third-party modules
 import unittest2
 
+from unittest2.util import strclass
+
 # LLDB Modules
 from . import configuration
 from lldbsuite.test_event.event_builder import EventBuilder
@@ -124,10 +126,23 @@
 test,
 test._testMethodName).__func__.__unittest_skip_why__ = "test case does not fall in any category of interest for this run"
 
+def checkExclusion(self, exclusion_list, name):
+if exclusion_list:
+import re
+for item in exclusion_list:
+if re.search(item, name):
+return True
+return False
+
 def startTest(self, test):
 if configuration.shouldSkipBecauseOfCategories(
 self.getCategoriesForTest(test)):
 self.hardMarkAsSkipped(test)
+if self.checkExclusion(
+configuration.skip_methods,
+test._testMethodName):
+self.hardMarkAsSkipped(test)
+
 configuration.setCrashInfoHook(
 "%s at %s" %
 (str(test), inspect.getfile(
@@ -145,6 +160,15 @@
 EventBuilder.event_for_start(test))
 
 def addSuccess(self, test):
+if self.checkExclusion(
+configuration.xfail_files,
+strclass(
+test.__class__)) or self.checkExclusion(
+configuration.xfail_methods,
+test._testMethodName):
+self.addUnexpectedSuccess(test, None)
+return
+
 super(LLDBTestResult, self).addSuccess(test)
 if configuration.parsable:
 self.stream.write(
@@ -214,6 +238,15 @@
 test, err))
 
 def addFailure(self, test, err):
+if self.checkExclusion(
+configuration.xfail_files,
+strclass(
+test.__class__)) or self.checkExclusion(
+configuration.xfail_methods,
+test._testMethodName):
+self.addExpectedFailure(test, err, None)
+return
+
 configuration.sdir_has_content = True
 super(LLDBTestResult, self).addFailure(test, err)
 method = getattr(test, "markFailure", None)
Index: packages/Python/lldbsuite/test/dotest_args.py
===
--- packages/Python/lldbsuite/test/dotest_args.py
+++ packages/Python/lldbsuite/test/dotest_args.py
@@ -96,6 +96,9 @@
 '-p',
 metavar='pattern',
 help='Specify a regexp filename pattern for inclusion in the test suite')
+group.add_argument('--excluded', metavar='exclusion-file', help=textwrap.dedent(
+'''Specify a file for tests to exclude. File should contain lists of regular expressions for test files or methods,
+with each list under a matching header (xfail files, xfail methods, skip files, skip methods)'''))
 group.add_argument(
 '-G',
 '--category',
Index: packages/Python/lldbsuite/test/dotest.py
===
--- packages/Python/lldbsuite/test/dotest.py
+++ packages/Python/lldbsuite/test/dotest.py
@@ -202,6 +202,48 @@
 sys.exit(0)
 
 
+def parseExclusion(exclusion_file):
+"""Parse an exclusion file, of the following format, where
+   'skip files', 'skip methods', 'xfail files', and 'xfail methods'
+   are the possible list heading values:
+
+   skip files
+   
+   
+
+   xfail methods
+   
+"""
+excl_type = None
+case_type = None
+
+with open(exclusion_file) as f:
+for line in f:
+if not excl_type:
+[excl_type, case_type] = line.split()
+continue
+
+line = line.strip()
+if not line:
+excl_type = None
+elif excl_type == 'skip' and case_type == 'files':
+if not configuration.skip_files:
+configuration.skip_files = []
+configuration.skip_files.append(line)
+elif excl_type == 'skip' and case_type == 'methods':
+if not configuration.skip

Re: [Lldb-commits] [PATCH] D24629: Allow for tests to be disabled at runtime

[Zachary Turner via lldb-commits]

zturner added a comment.

If a set of tests is failing, wouldn't you just want to xfail them?


https://reviews.llvm.org/D24629



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

Re: [Lldb-commits] [PATCH] D24629: Allow for tests to be disabled at runtime

[Francis Ricci via lldb-commits]

fjricci added a comment.

The issue is that you can only commit a patch to xfail a test that fails when 
you run the test suite on master with no local changes.

The problem is that if you run into test failures on other branches or in 
unconventional configurations, there is no good way to disable failing tests, 
other than carrying local patches to xfail the tests which fail. Carrying these 
sorts of local patches is tedious, prone to breakages, and requires many manual 
changes whenever test suite sources changes.

I'm particular, we run into this with ds2, since it fails some tests passed by 
lldb-server (and passes some tests xfail-ed by lldb-server).

I also find that I fail different tests on master (with lldb-server) between 
Ubuntu and CentOS, for example, and I'm not sure that it makes sense to xfail 
in those cases.


https://reviews.llvm.org/D24629



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

[Lldb-commits] [lldb] r281662 - Allow ArchSpec to take a StringRef.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Thu Sep 15 16:32:57 2016
New Revision: 281662

URL: http://llvm.org/viewvc/llvm-project?rev=281662&view=rev
Log:
Allow ArchSpec to take a StringRef.

Modified:
lldb/trunk/include/lldb/Core/ArchSpec.h
lldb/trunk/source/Core/ArchSpec.cpp
lldb/trunk/unittests/Core/ArchSpecTest.cpp

Modified: lldb/trunk/include/lldb/Core/ArchSpec.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/ArchSpec.h?rev=281662&r1=281661&r2=281662&view=diff
==
--- lldb/trunk/include/lldb/Core/ArchSpec.h (original)
+++ lldb/trunk/include/lldb/Core/ArchSpec.h Thu Sep 15 16:32:57 2016
@@ -257,7 +257,9 @@ public:
   //--
   explicit ArchSpec(const llvm::Triple &triple);
   explicit ArchSpec(const char *triple_cstr);
-  explicit ArchSpec(const char *triple_cstr, Platform *platform);
+  explicit ArchSpec(llvm::StringRef triple_str);
+  ArchSpec(const char *triple_cstr, Platform *platform);
+  ArchSpec(llvm::StringRef triple_str, Platform *platform);
   //--
   /// Constructor over architecture name.
   ///
@@ -505,8 +507,10 @@ public:
   //--
   bool SetTriple(const llvm::Triple &triple);
 
-  bool SetTriple(const char *triple_cstr);
+  bool SetTriple(llvm::StringRef triple_str);
+  bool SetTriple(llvm::StringRef triple_str, Platform *platform);
 
+  bool SetTriple(const char *triple_cstr);
   bool SetTriple(const char *triple_cstr, Platform *platform);
 
   //--
@@ -596,13 +600,13 @@ protected:
   bool IsEqualTo(const ArchSpec &rhs, bool exact_match) const;
 
   llvm::Triple m_triple;
-  Core m_core;
-  lldb::ByteOrder m_byte_order;
+  Core m_core = kCore_invalid;
+  lldb::ByteOrder m_byte_order = lldb::eByteOrderInvalid;
 
   // Additional arch flags which we cannot get from triple and core
   // For MIPS these are application specific extensions like
   // micromips, mips16 etc.
-  uint32_t m_flags;
+  uint32_t m_flags = 0;
 
   ConstString m_distribution_id;
 

Modified: lldb/trunk/source/Core/ArchSpec.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ArchSpec.cpp?rev=281662&r1=281661&r2=281662&view=diff
==
--- lldb/trunk/source/Core/ArchSpec.cpp (original)
+++ lldb/trunk/source/Core/ArchSpec.cpp Thu Sep 15 16:32:57 2016
@@ -555,33 +555,27 @@ FindArchDefinitionEntry(const ArchDefini
 
//===--===//
 // Constructors and destructors.
 
-ArchSpec::ArchSpec()
-: m_triple(), m_core(kCore_invalid), m_byte_order(eByteOrderInvalid),
-  m_flags(0), m_distribution_id() {}
-
-ArchSpec::ArchSpec(const char *triple_cstr, Platform *platform)
-: m_triple(), m_core(kCore_invalid), m_byte_order(eByteOrderInvalid),
-  m_flags(0), m_distribution_id() {
+ArchSpec::ArchSpec() {}
+
+ArchSpec::ArchSpec(const char *triple_cstr, Platform *platform) {
   if (triple_cstr)
 SetTriple(triple_cstr, platform);
 }
 
-ArchSpec::ArchSpec(const char *triple_cstr)
-: m_triple(), m_core(kCore_invalid), m_byte_order(eByteOrderInvalid),
-  m_flags(0), m_distribution_id() {
+ArchSpec::ArchSpec(llvm::StringRef triple_str, Platform *platform) {
+  SetTriple(triple_str, platform);
+}
+
+ArchSpec::ArchSpec(const char *triple_cstr) {
   if (triple_cstr)
 SetTriple(triple_cstr);
 }
 
-ArchSpec::ArchSpec(const llvm::Triple &triple)
-: m_triple(), m_core(kCore_invalid), m_byte_order(eByteOrderInvalid),
-  m_flags(0), m_distribution_id() {
-  SetTriple(triple);
-}
+ArchSpec::ArchSpec(llvm::StringRef triple_str) { SetTriple(triple_str); }
+
+ArchSpec::ArchSpec(const llvm::Triple &triple) { SetTriple(triple); }
 
-ArchSpec::ArchSpec(ArchitectureType arch_type, uint32_t cpu, uint32_t subtype)
-: m_triple(), m_core(kCore_invalid), m_byte_order(eByteOrderInvalid),
-  m_flags(0), m_distribution_id() {
+ArchSpec::ArchSpec(ArchitectureType arch_type, uint32_t cpu, uint32_t subtype) 
{
   SetArchitecture(arch_type, cpu, subtype);
 }
 
@@ -857,99 +851,104 @@ bool lldb_private::ParseMachCPUDashSubty
 }
 
 bool ArchSpec::SetTriple(const char *triple_cstr) {
-  if (triple_cstr && triple_cstr[0]) {
-llvm::StringRef triple_stref(triple_cstr);
+  llvm::StringRef str(triple_cstr ? triple_cstr : "");
+  return SetTriple(str);
+}
 
-if (ParseMachCPUDashSubtypeTriple(triple_stref, *this))
-  return true;
+bool ArchSpec::SetTriple(const char *triple_cstr, Platform *platform) {
+  llvm::StringRef str(triple_cstr ? triple_cstr : "");
+  return SetTriple(str, platform);
+}
 
-if (triple_stref.startswith(LLDB_ARCH_DEFAULT)) {
-  // Special case for the current host default architectures...
-  if (trip

[Lldb-commits] [lldb] r281661 - [cmake] Don't depend on lldb-server unless it's built.

[Zachary Turner via lldb-commits]

Author: zturner
Date: Thu Sep 15 16:32:51 2016
New Revision: 281661

URL: http://llvm.org/viewvc/llvm-project?rev=281661&view=rev
Log:
[cmake] Don't depend on lldb-server unless it's built.

Modified:
lldb/trunk/lit/CMakeLists.txt

Modified: lldb/trunk/lit/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/CMakeLists.txt?rev=281661&r1=281660&r2=281661&view=diff
==
--- lldb/trunk/lit/CMakeLists.txt (original)
+++ lldb/trunk/lit/CMakeLists.txt Thu Sep 15 16:32:51 2016
@@ -27,9 +27,14 @@ set(LLDB_TEST_DEPS
   FileCheck
   LLDBUnitTests
   lldb
-  lldb-server
   not
   )
+  
+# lldb-server is not built on every platform.
+if (TARGET lldb-server)
+  list(APPEND LLDB_TEST_DEPS lldb-server)
+endif()
+  
 if(APPLE)
   list(APPEND LLDB_TEST_DEPS debugserver)
 endif()


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

[Lldb-commits] [lldb] r281690 - First tests for serializing breakpoints.

[Jim Ingham via lldb-commits]

Author: jingham
Date: Thu Sep 15 20:41:27 2016
New Revision: 281690

URL: http://llvm.org/viewvc/llvm-project?rev=281690&view=rev
Log:
First tests for serializing breakpoints.

Plus a few bug fixes I found along the way.

Added:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/serialize/

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/serialize/Makefile

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/serialize/TestBreakpointSerialization.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/serialize/main.c
Modified:
lldb/trunk/include/lldb/API/SBBreakpoint.h
lldb/trunk/scripts/interface/SBBreakpoint.i
lldb/trunk/source/API/SBBreakpoint.cpp
lldb/trunk/source/Breakpoint/BreakpointResolverFileRegex.cpp
lldb/trunk/source/Core/SearchFilter.cpp

Modified: lldb/trunk/include/lldb/API/SBBreakpoint.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBBreakpoint.h?rev=281690&r1=281689&r2=281690&view=diff
==
--- lldb/trunk/include/lldb/API/SBBreakpoint.h (original)
+++ lldb/trunk/include/lldb/API/SBBreakpoint.h Thu Sep 15 20:41:27 2016
@@ -104,6 +104,8 @@ public:
 
   bool GetDescription(lldb::SBStream &description);
 
+  bool GetDescription(lldb::SBStream &description, bool include_locations);
+
   static bool EventIsBreakpointEvent(const lldb::SBEvent &event);
 
   static lldb::BreakpointEventType
@@ -152,6 +154,8 @@ public:
 
   SBBreakpoint GetBreakpointAtIndex(size_t idx);
 
+  SBBreakpoint  FindBreakpointByID(lldb::break_id_t);
+
   void Append(const SBBreakpoint &sb_file);
 
   bool AppendIfUnique(const SBBreakpoint &sb_file);

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/serialize/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/serialize/Makefile?rev=281690&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/serialize/Makefile
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/serialize/Makefile
 Thu Sep 15 20:41:27 2016
@@ -0,0 +1,5 @@
+LEVEL = ../../../make
+
+C_SOURCES := main.c
+
+include $(LEVEL)/Makefile.rules

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/serialize/TestBreakpointSerialization.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/serialize/TestBreakpointSerialization.py?rev=281690&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/serialize/TestBreakpointSerialization.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/serialize/TestBreakpointSerialization.py
 Thu Sep 15 20:41:27 2016
@@ -0,0 +1,147 @@
+"""
+Test breakpoint ignore count features.
+"""
+
+from __future__ import print_function
+
+
+import os
+import time
+import re
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class BreakpointSerialization(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@add_test_categories(['pyapi'])
+def test_resolvers(self):
+"""Use Python APIs to test that we serialize resolvers."""
+self.build()
+self.setup_targets_and_cleanup()
+self.do_check_resolvers()
+
+def not_test_filters(self):
+"""Use Python APIs to test that we serialize search filters 
correctly."""
+self.build()
+self.setup_targets_and_cleanup()
+self.check_filters()
+
+def not_test_options(self):
+"""Use Python APIs to test that we serialize breakpoint options 
correctly."""
+self.build()
+self.setup_targets_and_cleanup()
+self.check_filters()
+
+def not_test_complex(self):
+"""Use Python APIs to test that we serialize complex breakpoints 
correctly."""
+self.build()
+self.setup_targets_and_cleanup()
+self.check_filters()
+
+def setup_targets_and_cleanup(self):
+def cleanup ():
+#self.RemoveTempFile(self.bkpts_file_path)
+
+if self.orig_target.IsValid():
+self.dbg.DeleteTarget(self.orig_target)
+self.dbg.DeleteTarget(self.copy_target)
+
+self.addTearDownHook(cleanup)
+#self.RemoveTempFile(self.bkpts_file_path)
+
+exe = os.path.join(os.getcwd(), "a.out")
+
+# Create a targets we are making breakpoint in and copying to:
+self.orig_target = self.dbg.CreateTarget(exe)
+self.assertTrue(self.orig_target, VALID_TARGET)
+
+self.copy_target = self.dbg.CreateTarget(exe)
+self

Re: [Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

[Jason Molenda via lldb-commits]

> On Sep 15, 2016, at 8:02 AM, Zachary Turner  wrote:
> 
> 
> It sounds like your goal is also "tests have to use the SB API and no other 
> API", which if so I think that's counterproductive.   More productive, IMO, 
> would be being open to any alternative that addresses the concerns you have 
> with command-line tests.  There are more than 2 ways to skin a cat, so to 
> speak.

Thinking about this a bit, another approach would be to do lit tests on top of 
lldb-mi.  MI is a structured format for the debugger and a UI to communicate 
back and forth with a simple text markup language (it would be JSON if it were 
being done today, but it was added to gdb eighteen years ago, so it's not).  
The commands correspond to the commands a debugger user would think to use -- 
no need to understand the structure of how lldb is implemented, like with the 
SB API.  The format is a little unusual for a human to type, but back when we 
supported gdb at Apple we worked in MI all the time (it was used to communicate 
between Xcode, our IDE, and gdb) by hand when testing and it was fine. 
"-exec-run" instead of run, that kind of thing.  I think there are four dozens 
different commands.

lldb-mi itself uses SB API.  And the concerns about hardcoding command line UI 
don't apply, it's a key-value format intended for computers, no one is going to 
add an extra space character to anything -- the most it changes is that new 
key-value pairs are added to responses.


I agree there are many acceptable ways to write lit tests that don't involve 
lldb command line scraping, and I'm all in favor of using lit with tests that 
don't do that.  Of course the patch we're discussing has lit test examples that 
contradict our own policy on writing tests.  Once lit is supported in lldb, are 
we going to reject any testsuite additions that depend on the text output from 
the command line lldb?  If we're all on the same page here, then I have no 
reservations.

Just to say out loud the future I can easily see:  We add lit, then we have 
people helpfully write a few dozen tests in lit that depend on the command line 
debugger output.  Those patches have to be rejected.  

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

Re: [Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

[Zachary Turner via lldb-commits]

One thing I wonder about. It seems like everyone is mostly on the same page
about command line output .

What about input? Would anyone have objections to a test which ran a few
commands to get the debugger into a particular state before doing something
to verify the output? Let's assume I'm waving my hands about this last step
but that it doesn't involve scraping the output of a debugger command

Maybe this will never even be an issue, but I just want to make sure
everyone is on the same page and that the objections are:

a) specific to command OUTPUT, not input (i.e. it's ok to have a test run
"break set -n main")
b) specific to *non trivial* output (checking that "p 5" displays 5 is ok)
c) specific to the the output of the *user* command line interface, so that
some hypothetical other command line interface (which again I'm being hand
wavy about) would not be subject to the same objections.


On Thu, Sep 15, 2016 at 7:28 PM Jason Molenda  wrote:

>
> > On Sep 15, 2016, at 8:02 AM, Zachary Turner  wrote:
> >
> >
> > It sounds like your goal is also "tests have to use the SB API and no
> other API", which if so I think that's counterproductive.   More
> productive, IMO, would be being open to any alternative that addresses the
> concerns you have with command-line tests.  There are more than 2 ways to
> skin a cat, so to speak.
>
> Thinking about this a bit, another approach would be to do lit tests on
> top of lldb-mi.  MI is a structured format for the debugger and a UI to
> communicate back and forth with a simple text markup language (it would be
> JSON if it were being done today, but it was added to gdb eighteen years
> ago, so it's not).  The commands correspond to the commands a debugger user
> would think to use -- no need to understand the structure of how lldb is
> implemented, like with the SB API.  The format is a little unusual for a
> human to type, but back when we supported gdb at Apple we worked in MI all
> the time (it was used to communicate between Xcode, our IDE, and gdb) by
> hand when testing and it was fine. "-exec-run" instead of run, that kind of
> thing.  I think there are four dozens different commands.
>
> lldb-mi itself uses SB API.  And the concerns about hardcoding command
> line UI don't apply, it's a key-value format intended for computers, no one
> is going to add an extra space character to anything -- the most it changes
> is that new key-value pairs are added to responses.
>
>
> I agree there are many acceptable ways to write lit tests that don't
> involve lldb command line scraping, and I'm all in favor of using lit with
> tests that don't do that.  Of course the patch we're discussing has lit
> test examples that contradict our own policy on writing tests.  Once lit is
> supported in lldb, are we going to reject any testsuite additions that
> depend on the text output from the command line lldb?  If we're all on the
> same page here, then I have no reservations.
>
> Just to say out loud the future I can easily see:  We add lit, then we
> have people helpfully write a few dozen tests in lit that depend on the
> command line debugger output.  Those patches have to be rejected.
>
> J
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r281696 - add availability check to DarwinLog event tests

[Todd Fiala via lldb-commits]

Author: tfiala
Date: Thu Sep 15 22:07:14 2016
New Revision: 281696

URL: http://llvm.org/viewvc/llvm-project?rev=281696&view=rev
Log:
add availability check to DarwinLog event tests

The pexpect-based tests properly checked for the stub reporting
DarwinLog support.  The event-based ones did not.  This is fixed
here.  Swift CI bots are not currently building debugserver on
macOS, so they don't have the DarwinLog support even when they
pass the macOS 10.12 check.

Modified:
lldb/trunk/packages/Python/lldbsuite/test/darwin_log.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/darwin_log.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/darwin_log.py?rev=281696&r1=281695&r2=281696&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/darwin_log.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/darwin_log.py Thu Sep 15 22:07:14 
2016
@@ -325,6 +325,11 @@ class DarwinLogEventBasedTestBase(lldbte
 self.runCmd("settings set target.process.extra-startup-command "
 "QSetLogging:bitmask=LOG_DARWIN_LOG;")
 
+def darwin_log_available(self):
+match = self.match("plugin structured-data darwin-log status",
+   patterns=[r"Availability: ([\S]+)"])
+return match is not None and (match.group(1) == "available")
+
 def do_test(self, enable_options, settings_commands=None,
 run_enable_after_breakpoint=False, max_entry_count=None):
 """Runs the test inferior, returning collected events.
@@ -401,6 +406,14 @@ class DarwinLogEventBasedTestBase(lldbte
 # And our one and only breakpoint should have been hit.
 self.assertEquals(breakpoint.GetHitCount(), 1)
 
+# Check if DarwinLog is available.  This check cannot be done
+# until after the process has started, as the feature availability
+# comes through the stub.  The stub isn't running until
+# the target process is running.  So this is really the earliest
+# we can check.
+if not self.darwin_log_available():
+self.skipTest("DarwinLog not available")
+
 # Now setup the structured data listener.
 #
 # Grab the broadcaster for the process.  We'll be attaching our


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