Re: [Lldb-commits] [lldb] r326756 - Upstreaming avx512 register support in debugserver. These changes

2018-03-05 Thread Davide Italiano via lldb-commits
Thank you so much Jason!

On Mon, Mar 5, 2018 at 4:27 PM, Jason Molenda via lldb-commits
 wrote:
> Author: jmolenda
> Date: Mon Mar  5 16:27:41 2018
> New Revision: 326756
>
> URL: http://llvm.org/viewvc/llvm-project?rev=326756&view=rev
> Log:
> Upstreaming avx512 register support in debugserver.  These changes
> were originally written by Chris Bieneman, they've undergone a
> number of changes since then.
>
> Also including the debugserver bridgeos support, another arm
> environment that runs Darwin akin to ios.  These codepaths are
> activated when running in a bridgeos environment which we're not
> set up to test today.
>
> There's additional (small) lldb changes to handle bridgeos binaries
> that still need to be merged up.
>
> Tested on a darwin system with avx512 hardware and without.
>
> 
>
> Added:
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/TestZMMRegister.py
> Modified:
> lldb/trunk/include/lldb/Core/RegisterValue.h
> lldb/trunk/packages/Python/lldbsuite/test/decorators.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/TestYMMRegister.py
> 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/main.c
> lldb/trunk/tools/debugserver/source/DNBDefs.h
> lldb/trunk/tools/debugserver/source/MacOSX/MachProcess.mm
> lldb/trunk/tools/debugserver/source/MacOSX/i386/DNBArchImplI386.cpp
> lldb/trunk/tools/debugserver/source/MacOSX/i386/DNBArchImplI386.h
> lldb/trunk/tools/debugserver/source/MacOSX/i386/MachRegisterStatesI386.h
> lldb/trunk/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp
> lldb/trunk/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.h
> 
> lldb/trunk/tools/debugserver/source/MacOSX/x86_64/MachRegisterStatesX86_64.h
> lldb/trunk/tools/debugserver/source/RNBRemote.cpp
>
> Modified: lldb/trunk/include/lldb/Core/RegisterValue.h
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/RegisterValue.h?rev=326756&r1=326755&r2=326756&view=diff
> ==
> --- lldb/trunk/include/lldb/Core/RegisterValue.h (original)
> +++ lldb/trunk/include/lldb/Core/RegisterValue.h Mon Mar  5 16:27:41 2018
> @@ -35,7 +35,7 @@ namespace lldb_private {
>
>  class RegisterValue {
>  public:
> -  enum { kMaxRegisterByteSize = 32u };
> +  enum { kMaxRegisterByteSize = 64u };
>
>enum Type {
>  eTypeInvalid,
>
> Modified: lldb/trunk/packages/Python/lldbsuite/test/decorators.py
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/decorators.py?rev=326756&r1=326755&r2=326756&view=diff
> ==
> --- lldb/trunk/packages/Python/lldbsuite/test/decorators.py (original)
> +++ lldb/trunk/packages/Python/lldbsuite/test/decorators.py Mon Mar  5 
> 16:27:41 2018
> @@ -10,6 +10,7 @@ import platform
>  import re
>  import sys
>  import tempfile
> +import subprocess
>
>  # Third-party modules
>  import six
> @@ -741,3 +742,20 @@ def skipIfXmlSupportMissing(func):
>  fail_value = True # More likely to notice if something goes wrong
>  have_xml = xml.GetValueForKey("value").GetBooleanValue(fail_value)
>  return unittest2.skipIf(not have_xml, "requires xml support")(func)
> +
> +# Call sysctl on darwin to see if a specified hardware feature is available 
> on this machine.
> +def skipUnlessFeature(feature):
> +def is_feature_enabled(self):
> +if platform.system() == 'Darwin':
> +try:
> +DEVNULL = open(os.devnull, 'w')
> +output = subprocess.check_output(["/usr/sbin/sysctl", 
> feature], stderr=DEVNULL)
> +# If 'feature: 1' was output, then this feature is available 
> and
> +# the test should not be skipped.
> +if re.match('%s: 1\s*' % feature, output):
> +return None
> +else:
> +return "%s is not supported on this system." % feature
> +except subprocess.CalledProcessError:
> +return "%s is not supported on this system." % feature
> +return skipTestIfFn(is_feature_enabled)
>
> Modified: 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/TestYMMRegister.py
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/TestYMMRegister.py?rev=326756&r1=326755&r2=326756&view=diff
> ==
> --- 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/TestYMMRegister.py
>  (original)
> +++ 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/TestYMMRegister.py
>  Mon Mar  5 16:27:41 2018
> @@ -21,8 +21,9 @@ class TestYMMRegister(TestBase):
>  @skipIfiOSSimulator
> 

[Lldb-commits] [lldb] r326756 - Upstreaming avx512 register support in debugserver. These changes

2018-03-05 Thread Jason Molenda via lldb-commits
Author: jmolenda
Date: Mon Mar  5 16:27:41 2018
New Revision: 326756

URL: http://llvm.org/viewvc/llvm-project?rev=326756&view=rev
Log:
Upstreaming avx512 register support in debugserver.  These changes
were originally written by Chris Bieneman, they've undergone a
number of changes since then.

Also including the debugserver bridgeos support, another arm
environment that runs Darwin akin to ios.  These codepaths are
activated when running in a bridgeos environment which we're not
set up to test today.

There's additional (small) lldb changes to handle bridgeos binaries
that still need to be merged up.

Tested on a darwin system with avx512 hardware and without.

 

Added:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/TestZMMRegister.py
Modified:
lldb/trunk/include/lldb/Core/RegisterValue.h
lldb/trunk/packages/Python/lldbsuite/test/decorators.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/TestYMMRegister.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/main.c
lldb/trunk/tools/debugserver/source/DNBDefs.h
lldb/trunk/tools/debugserver/source/MacOSX/MachProcess.mm
lldb/trunk/tools/debugserver/source/MacOSX/i386/DNBArchImplI386.cpp
lldb/trunk/tools/debugserver/source/MacOSX/i386/DNBArchImplI386.h
lldb/trunk/tools/debugserver/source/MacOSX/i386/MachRegisterStatesI386.h
lldb/trunk/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.cpp
lldb/trunk/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.h
lldb/trunk/tools/debugserver/source/MacOSX/x86_64/MachRegisterStatesX86_64.h
lldb/trunk/tools/debugserver/source/RNBRemote.cpp

Modified: lldb/trunk/include/lldb/Core/RegisterValue.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/RegisterValue.h?rev=326756&r1=326755&r2=326756&view=diff
==
--- lldb/trunk/include/lldb/Core/RegisterValue.h (original)
+++ lldb/trunk/include/lldb/Core/RegisterValue.h Mon Mar  5 16:27:41 2018
@@ -35,7 +35,7 @@ namespace lldb_private {
 
 class RegisterValue {
 public:
-  enum { kMaxRegisterByteSize = 32u };
+  enum { kMaxRegisterByteSize = 64u };
 
   enum Type {
 eTypeInvalid,

Modified: lldb/trunk/packages/Python/lldbsuite/test/decorators.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/decorators.py?rev=326756&r1=326755&r2=326756&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/decorators.py (original)
+++ lldb/trunk/packages/Python/lldbsuite/test/decorators.py Mon Mar  5 16:27:41 
2018
@@ -10,6 +10,7 @@ import platform
 import re
 import sys
 import tempfile
+import subprocess
 
 # Third-party modules
 import six
@@ -741,3 +742,20 @@ def skipIfXmlSupportMissing(func):
 fail_value = True # More likely to notice if something goes wrong
 have_xml = xml.GetValueForKey("value").GetBooleanValue(fail_value)
 return unittest2.skipIf(not have_xml, "requires xml support")(func)
+
+# Call sysctl on darwin to see if a specified hardware feature is available on 
this machine.
+def skipUnlessFeature(feature):
+def is_feature_enabled(self):
+if platform.system() == 'Darwin':
+try:
+DEVNULL = open(os.devnull, 'w')
+output = subprocess.check_output(["/usr/sbin/sysctl", 
feature], stderr=DEVNULL)
+# If 'feature: 1' was output, then this feature is available 
and
+# the test should not be skipped.
+if re.match('%s: 1\s*' % feature, output):
+return None
+else:
+return "%s is not supported on this system." % feature
+except subprocess.CalledProcessError:
+return "%s is not supported on this system." % feature
+return skipTestIfFn(is_feature_enabled)

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/TestYMMRegister.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/TestYMMRegister.py?rev=326756&r1=326755&r2=326756&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/TestYMMRegister.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/register/intel_avx/TestYMMRegister.py
 Mon Mar  5 16:27:41 2018
@@ -21,8 +21,9 @@ class TestYMMRegister(TestBase):
 @skipIfiOSSimulator
 @skipIfTargetAndroid()
 @skipIf(archs=no_match(['i386', 'x86_64']))
+@expectedFailureAll(oslist=["linux"], bugnumber="rdar://30523153")
 def test(self):
-self.build()
+self.build(dictionary={"CFLAGS_EXTRAS": "-march=haswell"})
 self.setTearDownCleanup()
 
 ex

[Lldb-commits] [lldb] r326754 - LLDBStandalone.cmake: set path to llvm-lit inside of llvm build dir

2018-03-05 Thread Adrian Prantl via lldb-commits
Author: adrian
Date: Mon Mar  5 15:57:46 2018
New Revision: 326754

URL: http://llvm.org/viewvc/llvm-project?rev=326754&view=rev
Log:
LLDBStandalone.cmake: set path to llvm-lit inside of llvm build dir

Modified:
lldb/trunk/cmake/modules/LLDBStandalone.cmake

Modified: lldb/trunk/cmake/modules/LLDBStandalone.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBStandalone.cmake?rev=326754&r1=326753&r2=326754&view=diff
==
--- lldb/trunk/cmake/modules/LLDBStandalone.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBStandalone.cmake Mon Mar  5 15:57:46 2018
@@ -58,6 +58,7 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
   set(LLVM_DIR ${LLVM_OBJ_ROOT}/cmake/modules/CMakeFiles CACHE PATH "Path to 
LLVM build tree CMake files")
   set(LLVM_BINARY_DIR ${LLVM_OBJ_ROOT} CACHE PATH "Path to LLVM build tree")
   set(LLVM_MAIN_SRC_DIR ${MAIN_SRC_DIR} CACHE PATH "Path to LLVM source tree")
+  set(LLVM_EXTERNAL_LIT ${LLVM_TOOLS_BINARY_DIR}/llvm-lit CACHE PATH "Path to 
llvm-lit")
 
   find_program(LLVM_TABLEGEN_EXE "llvm-tblgen" ${LLVM_TOOLS_BINARY_DIR}
 NO_DEFAULT_PATH)


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


[Lldb-commits] [lldb] r326743 - Fix the install location of LLDBWrapPython.cpp when building

2018-03-05 Thread Adrian Prantl via lldb-commits
Author: adrian
Date: Mon Mar  5 13:08:42 2018
New Revision: 326743

URL: http://llvm.org/viewvc/llvm-project?rev=326743&view=rev
Log:
Fix the install location of LLDBWrapPython.cpp when building
LLDB.framework to point to the build directory where it is expected by
the top-level CMakeLists.txt.

This should be a no-op in any other configurations.

rdar://problem/38005302

Modified:
lldb/trunk/scripts/CMakeLists.txt

Modified: lldb/trunk/scripts/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/CMakeLists.txt?rev=326743&r1=326742&r2=326743&view=diff
==
--- lldb/trunk/scripts/CMakeLists.txt (original)
+++ lldb/trunk/scripts/CMakeLists.txt Mon Mar  5 13:08:42 2018
@@ -30,6 +30,8 @@ if(LLDB_BUILD_FRAMEWORK)
 ${LLDB_FRAMEWORK_INSTALL_DIR}/${LLDB_FRAMEWORK_RESOURCE_DIR})
 endif()
 
+get_filename_component(CFGBLDDIR ${LLDB_WRAP_PYTHON} DIRECTORY)
+
 find_package(SWIG REQUIRED)
 add_custom_command(
   OUTPUT ${LLDB_WRAP_PYTHON}
@@ -43,7 +45,7 @@ add_custom_command(
   ${framework_arg}
   --srcRoot=${LLDB_SOURCE_DIR}
   --targetDir=${LLDB_PYTHON_TARGET_DIR}
-  --cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}
+  --cfgBldDir=${CFGBLDDIR}
   --prefix=${CMAKE_BINARY_DIR}
   --swigExecutable=${SWIG_EXECUTABLE}
   VERBATIM


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


[Lldb-commits] [lldb] r326739 - [test] Skip pexpect-based lldb-mi tests on Darwin

2018-03-05 Thread Vedant Kumar via lldb-commits
Author: vedantk
Date: Mon Mar  5 12:16:52 2018
New Revision: 326739

URL: http://llvm.org/viewvc/llvm-project?rev=326739&view=rev
Log:
[test] Skip pexpect-based lldb-mi tests on Darwin

These tests fail with a relatively frequently on Darwin machines with
errors such as:

  File ".../lldb/third_party/Python/module/pexpect-2.4/pexpect.py", line 1444, 
in expect_loop
raise EOF(str(e) + '\n' + str(self))
EOF: End Of File (EOF) in read_nonblocking(). Empty string style platform.

The unpredictable failures make these tests noisy.

rdar://37046976

Modified:
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/TestMiExit.py
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/TestMiGdbSetShow.py
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/data/TestMiData.py

lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/signal/TestMiSignal.py

Modified: lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/TestMiExit.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/TestMiExit.py?rev=326739&r1=326738&r2=326739&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/TestMiExit.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/TestMiExit.py Mon 
Mar  5 12:16:52 2018
@@ -17,6 +17,7 @@ class MiExitTestCase(lldbmi_testcase.MiT
 @expectedFailureAll(
 oslist=["windows"],
 bugnumber="llvm.org/pr22274: need a pexpect replacement for windows")
+@skipIfDarwin   # pexpect is known to be unreliable on Darwin
 @skipIfFreeBSD  # llvm.org/pr22411: Failure presumably due to known thread 
races
 @skipIfRemote   # We do not currently support remote debugging via the MI.
 def test_lldbmi_gdb_exit(self):
@@ -44,6 +45,7 @@ class MiExitTestCase(lldbmi_testcase.MiT
 @expectedFailureAll(
 oslist=["windows"],
 bugnumber="llvm.org/pr22274: need a pexpect replacement for windows")
+@skipIfDarwin   # pexpect is known to be unreliable on Darwin
 @skipIfFreeBSD  # llvm.org/pr22411: Failure presumably due to known thread 
races
 @skipIfRemote   # We do not currently support remote debugging via the MI.
 def test_lldbmi_quit(self):
@@ -70,6 +72,7 @@ class MiExitTestCase(lldbmi_testcase.MiT
 @expectedFailureAll(
 oslist=["windows"],
 bugnumber="llvm.org/pr22274: need a pexpect replacement for windows")
+@skipIfDarwin   # pexpect is known to be unreliable on Darwin
 @skipIfFreeBSD  # llvm.org/pr22411: Failure presumably due to known thread 
races
 @skipIfRemote   # We do not currently support remote debugging via the MI.
 def test_lldbmi_q(self):

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/TestMiGdbSetShow.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/TestMiGdbSetShow.py?rev=326739&r1=326738&r2=326739&view=diff
==
--- lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/TestMiGdbSetShow.py 
(original)
+++ lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-mi/TestMiGdbSetShow.py 
Mon Mar  5 12:16:52 2018
@@ -19,6 +19,7 @@ class MiGdbSetShowTestCase(lldbmi_testca
 @expectedFailureAll(
 oslist=["windows"],
 bugnumber="llvm.org/pr22274: need a pexpect replacement for windows")
+@skipIfDarwin   # pexpect is known to be unreliable on Darwin
 @skipIfFreeBSD  # llvm.org/pr22411: Failure presumably due to known thread 
races
 @skipIfRemote   # We do not currently support remote debugging via the MI.
 def test_lldbmi_gdb_set_target_async_default(self):
@@ -41,6 +42,7 @@ class MiGdbSetShowTestCase(lldbmi_testca
 @expectedFailureAll(
 oslist=["windows"],
 bugnumber="llvm.org/pr22274: need a pexpect replacement for windows")
+@skipIfDarwin   # pexpect is known to be unreliable on Darwin
 @skipIfFreeBSD  # llvm.org/pr22411: Failure presumably due to known thread 
races
 @expectedFlakeyLinux("llvm.org/pr26028")  # Fails in ~1% of cases
 @skipIfRemote   # We do not currently support remote debugging via the MI.
@@ -74,6 +76,7 @@ class MiGdbSetShowTestCase(lldbmi_testca
 oslist=["windows"],
 bugnumber="llvm.org/pr22274: need a pexpect replacement for windows")
 @skipIfFreeBSD  # llvm.org/pr22411: Failure presumably due to known thread 
races
+@skipIfDarwin   # pexpect is known to be unreliable on Darwin
 @expectedFailureAll(
 oslist=["linux"],
 bugnumber="Failing in ~11/600 dosep runs (build 3120-3122)")
@@ -103,6 +106,7 @@ class MiGdbSetShowTestCase(lldbmi_testca
 @expectedFailureAll(
 oslist=["windows"],
 bugnumber="llvm.org/pr22274: need a pexpect replacement for windows")
+@skipIfDarwin   # pexpect is known to be unreliable on Darwin
 @skipIfFreeBSD  # llv

[Lldb-commits] [lldb] r326727 - Including for std::bind

2018-03-05 Thread Raphael Isemann via lldb-commits
Author: teemperor
Date: Mon Mar  5 09:54:23 2018
New Revision: 326727

URL: http://llvm.org/viewvc/llvm-project?rev=326727&view=rev
Log:
Including  for std::bind

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

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/backtrace_all/ParallelTask.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/backtrace_all/ParallelTask.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/backtrace_all/ParallelTask.cpp?rev=326727&r1=326726&r2=326727&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/backtrace_all/ParallelTask.cpp
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/backtrace_all/ParallelTask.cpp
 Mon Mar  5 09:54:23 2018
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 


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


[Lldb-commits] [PATCH] D44015: Fix std unique pointer not printing.

2018-03-05 Thread Alexandre Yukio Yamashita via Phabricator via lldb-commits
alexandreyy updated this revision to Diff 137022.
alexandreyy added a comment.

Fix std unique pointer not printing


https://reviews.llvm.org/D44015

Files:
  source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp


Index: source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
===
--- source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
+++ source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
@@ -43,6 +43,8 @@
   ValueObjectSP m_ptr_obj;
   ValueObjectSP m_obj_obj;
   ValueObjectSP m_del_obj;
+
+  ValueObjectSP GetTuple();
 };
 
 } // end of anonymous namespace
@@ -53,17 +55,34 @@
   Update();
 }
 
-bool LibStdcppUniquePtrSyntheticFrontEnd::Update() {
+ValueObjectSP LibStdcppUniquePtrSyntheticFrontEnd::GetTuple() {
   ValueObjectSP valobj_backend_sp = m_backend.GetSP();
+
   if (!valobj_backend_sp)
-return false;
+return NULL;
 
   ValueObjectSP valobj_sp = valobj_backend_sp->GetNonSyntheticValue();
   if (!valobj_sp)
-return false;
+return NULL;
 
-  ValueObjectSP tuple_sp =
+  ValueObjectSP obj_child_sp =
   valobj_sp->GetChildMemberWithName(ConstString("_M_t"), true);
+
+  ValueObjectSP obj_subchild_sp =
+  obj_child_sp->GetChildMemberWithName(ConstString("_M_t"), true);
+
+  // if there is a _M_t subchild, the tuple is found in
+  // the obj_subchild_sp (for libstdc++ 6.0.23).
+  if (obj_subchild_sp) {
+return obj_subchild_sp;
+  } else {
+return obj_child_sp;
+  }
+}
+
+bool LibStdcppUniquePtrSyntheticFrontEnd::Update() {
+  ValueObjectSP tuple_sp = GetTuple();
+
   if (!tuple_sp)
 return false;
 


Index: source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
===
--- source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
+++ source/Plugins/Language/CPlusPlus/LibStdcppUniquePointer.cpp
@@ -43,6 +43,8 @@
   ValueObjectSP m_ptr_obj;
   ValueObjectSP m_obj_obj;
   ValueObjectSP m_del_obj;
+
+  ValueObjectSP GetTuple();
 };
 
 } // end of anonymous namespace
@@ -53,17 +55,34 @@
   Update();
 }
 
-bool LibStdcppUniquePtrSyntheticFrontEnd::Update() {
+ValueObjectSP LibStdcppUniquePtrSyntheticFrontEnd::GetTuple() {
   ValueObjectSP valobj_backend_sp = m_backend.GetSP();
+
   if (!valobj_backend_sp)
-return false;
+return NULL;
 
   ValueObjectSP valobj_sp = valobj_backend_sp->GetNonSyntheticValue();
   if (!valobj_sp)
-return false;
+return NULL;
 
-  ValueObjectSP tuple_sp =
+  ValueObjectSP obj_child_sp =
   valobj_sp->GetChildMemberWithName(ConstString("_M_t"), true);
+
+  ValueObjectSP obj_subchild_sp =
+  obj_child_sp->GetChildMemberWithName(ConstString("_M_t"), true);
+
+  // if there is a _M_t subchild, the tuple is found in
+  // the obj_subchild_sp (for libstdc++ 6.0.23).
+  if (obj_subchild_sp) {
+return obj_subchild_sp;
+  } else {
+return obj_child_sp;
+  }
+}
+
+bool LibStdcppUniquePtrSyntheticFrontEnd::Update() {
+  ValueObjectSP tuple_sp = GetTuple();
+
   if (!tuple_sp)
 return false;
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D44074: ObjectFileMachO: split CreateSections mega-function into more manageable chunks

2018-03-05 Thread Davide Italiano via Phabricator via lldb-commits
davide added a comment.

Fair, I don't have a strong opinion on whether this should be in an header or 
not. Probably Greg is right though, if this is not used anywhere else, we could 
make it somehow private.
Thanks!


https://reviews.llvm.org/D44074



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


[Lldb-commits] [PATCH] D44056: [lldb] Fix "code unreachable" warning in HostThreadPosix::Cancel

2018-03-05 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

Yes we want to avoid ever using this function. It only leads to bad things 
happening.


https://reviews.llvm.org/D44056



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


[Lldb-commits] [PATCH] D44074: ObjectFileMachO: split CreateSections mega-function into more manageable chunks

2018-03-05 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added inline comments.



Comment at: source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h:202
+  UnifiedList(UnifiedList) {}
+  };
+  void ProcessDysymtabCommand(const llvm::MachO::load_command &load_cmd,

Because it is only used in internal functions... I doesn't have to move, just a 
suggestion. All this code used to be in the section parsing functions.


https://reviews.llvm.org/D44074



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


[Lldb-commits] [PATCH] D44074: ObjectFileMachO: split CreateSections mega-function into more manageable chunks

2018-03-05 Thread Davide Italiano via Phabricator via lldb-commits
davide accepted this revision.
davide added a comment.

LGTM




Comment at: source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h:191-202
+  struct SegmentParsingContext {
+const EncryptedFileRanges EncryptedRanges;
+lldb_private::SectionList &UnifiedList;
+uint32_t NextSegmentIdx = 0;
+uint32_t NextSectionIdx = 0;
+bool FileAddressesChanged = false;
+

clayborg wrote:
> Forward declare this and remove from header file?
Why?


https://reviews.llvm.org/D44074



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


[Lldb-commits] [PATCH] D44074: ObjectFileMachO: split CreateSections mega-function into more manageable chunks

2018-03-05 Thread Greg Clayton via Phabricator via lldb-commits
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.

Looks fine. Would just move stuff from header into .cpp file for the 
SegmentParsingContext class. I'll leave that up to you.




Comment at: source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h:191-202
+  struct SegmentParsingContext {
+const EncryptedFileRanges EncryptedRanges;
+lldb_private::SectionList &UnifiedList;
+uint32_t NextSegmentIdx = 0;
+uint32_t NextSectionIdx = 0;
+bool FileAddressesChanged = false;
+

Forward declare this and remove from header file?


https://reviews.llvm.org/D44074



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


[Lldb-commits] [PATCH] D42955: Make Module::GetSectionList output consistent

2018-03-05 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

In https://reviews.llvm.org/D42955#1026296, @labath wrote:

> In https://reviews.llvm.org/D42955#1026216, @clayborg wrote:
>
> > AS for the ELF example where only debug info is around, it might not be 
> > running into issues if it doesn't contain a symbol table. If it does 
> > contain a symbol table, hopefully it is using the unified section table, 
> > otherwise if might have symbol's whose addresses have sections from the 
> > stripped ELF file and it might not have the section contents that it needs 
> > to back it. In that case we might fail to disassemble the symbol's code.
>
>
> I made a trivial experiment:
>
>   g++ a.cc
>   objcopy a.out --only-keep-debug a.sym #a.sym contains a symtab
>   strip a.out # a.out does not contain a symtab
>   (lldb) target create "a.out"
>   Current executable set to 'a.out' (x86_64).
>   (lldb) b main
>   Breakpoint 1: no locations (pending).
>   WARNING:  Unable to resolve breakpoint to any actual locations.
>   (lldb) target symbols add a.sym
>   symbol file '/tmp/X/a.sym' has been added to '/tmp/X/a.out'
>   1 location added to breakpoint 1
>   #symbol resolution seems fine
>   (lldb) disassemble -n main
>   a.out`main:
>   a.out[0x69b] <+0>:  pushq  %rbp
>   a.out[0x69c] <+1>:  movq   %rsp, %rbp
>   a.out[0x69f] <+4>:  callq  0x690 ; foo()
>   a.out[0x6a4] <+9>:  addl   $0x2a, %eax
>   a.out[0x6a7] <+12>: popq   %rbp
>   a.out[0x6a8] <+13>: retq
>   # so does disassembling
>
>
> The part that is not clear to me is, if the dsym object file should absorb 
> the sections from the main object file, then what is the purpose of the 
> "unified section list" in the module? I can see why we need a unified list, 
> and I think it's a good idea, but having an ObjectFile containing the merged 
> list seems to defeat it. From a separation of concerns POV, it would be much 
> clearer if each ObjectFile contained only it's own sections, and then some 
> other entity (Module) held the combined data(sections) of the individual 
> object files. Then, most clients should operate on the unified view of the 
> module, but if anyone ever had a reason, he could always look directly at a 
> specific ObjectFile, and see what's contained there.


The issue is the object file must create symbols that uses the section from the 
unified section list. The easiest way to accomplish that was to have the object 
file just use the right section and not have to worry about any other code 
having to know anything about the relationship between a debuig info file and 
the main executable file.

> Among other things, this could be very useful for lldb-server. lldb-server 
> needs only lightweight access to the data in the object file -- it does not 
> need the Module class and everything it pulls in (SymbolVendor, SymbolFile, 
> ...). If we could make the ObjectFile class completely standalone, we can 
> avoid pulling all this stuff in and make the code more modular. It would also 
> help with the migration to llvm's Object parsing library, as it knows nothing 
> about unified sections. If we had a standalone ObjectFile implementation, 
> then it would be easy to swap it out for llvm's and still keep the "section 
> unification" code intact as it would be in a different layer.
> 
> So, could this be a direction we can move in? I can put this patch on ice and 
> try to make the ObjectFileMachO standalone instead. I don't think it should 
> be that hard, given that this is how things already work for elf. I'm hoping 
> it will be a matter of changing some consumers to use 
> module->GetSectionList() instead of objfile->GetSectionList()...

Again, we need any objects coming out of the ObjectFile to have the correct 
sections. Not sure how we would accomplish that with a solution where the dSYM 
file uses it own useless sections.


https://reviews.llvm.org/D42955



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


[Lldb-commits] [lldb] r326687 - [test] Add dotest wrapper

2018-03-05 Thread Jonas Devlieghere via lldb-commits
Author: jdevlieghere
Date: Mon Mar  5 02:03:44 2018
New Revision: 326687

URL: http://llvm.org/viewvc/llvm-project?rev=326687&view=rev
Log:
[test] Add dotest wrapper

This adds a wrapper around dotest, similar to llvm-lit in llvm. The
wrapper is created in the binary directory, next to LLDB and allows you
to invoke dotest without having to pass any of the configuration
arguments yourself. I think this could also be useful for re-running a
particular test case when it fails, as an alternative to "Command
Invoked".

The motivation for this is that I'd like to replace the driver part of
dotest with lit. As a first step, I'd like to have lit invoke dotest,
which would just run the complete test suite, completely identical to
what the CMake target does today. Once this is in place, we can have lit
run dotest for the different test directories, and ultimately once per
python file. Along the way we can strip out driver functionality from
dotest where appropriate.

https://reviews.llvm.org/D44002

Added:
lldb/trunk/test/llvm-dotest.in   (with props)
Modified:
lldb/trunk/test/CMakeLists.txt

Modified: lldb/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/test/CMakeLists.txt?rev=326687&r1=326686&r2=326687&view=diff
==
--- lldb/trunk/test/CMakeLists.txt (original)
+++ lldb/trunk/test/CMakeLists.txt Mon Mar  5 02:03:44 2018
@@ -25,7 +25,7 @@ endif()
 if(TARGET lldb-server)
   list(APPEND LLDB_TEST_DEPS lldb-server)
 endif()
-  
+
 if(TARGET debugserver)
   if(NOT CMAKE_HOST_APPLE OR LLDB_CODESIGN_IDENTITY)
 list(APPEND LLDB_TEST_DEPS debugserver)
@@ -78,7 +78,7 @@ set(LLDB_TEST_COMMON_ARGS
 if ( CMAKE_SYSTEM_NAME MATCHES "Windows" )
   # All tests are currently flaky on Windows, so rerun them all once when they 
fail.
   set(LLDB_TEST_COMMON_ARGS ${LLDB_TEST_COMMON_ARGS} --rerun-all-issues)
-  
+
   set(LLDB_TEST_DEBUG_TEST_CRASHES
 0
 CACHE BOOL "(Windows only) Enables debugging of tests in the test suite by 
showing the crash dialog when lldb crashes")
@@ -129,6 +129,21 @@ add_python_test_target(check-lldb
   "Testing LLDB (parallel execution, with a separate subprocess per test)"
   )
 
+# Generate a wrapper for dotest.py in the bin directory.
+string (REPLACE ";" " " LLDB_DOTEST_ARGS_STR  "${LLDB_DOTEST_ARGS}")
+# We need this to substitute variables.
+configure_file(
+  llvm-dotest.in
+  ${CMAKE_CURRENT_BINARY_DIR}/llvm-dotest.configured
+  )
+# We need this to expand the generator expressions.
+file(GENERATE
+  OUTPUT
+  $/llvm-dotest
+  INPUT
+  ${CMAKE_CURRENT_BINARY_DIR}/llvm-dotest.configured
+  )
+
 # If we're building with an in-tree clang, then list clang as a dependency
 # to run tests.
 if (TARGET clang)

Added: lldb/trunk/test/llvm-dotest.in
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/test/llvm-dotest.in?rev=326687&view=auto
==
--- lldb/trunk/test/llvm-dotest.in (added)
+++ lldb/trunk/test/llvm-dotest.in Mon Mar  5 02:03:44 2018
@@ -0,0 +1,14 @@
+#!/usr/bin/env python
+import sys
+import os
+
+dotest_path = '@LLDB_SOURCE_DIR@/test/dotest.py'
+dotest_args = '@LLDB_DOTEST_ARGS_STR@'
+
+if __name__ == '__main__':
+# FIXME: It would be nice if we can mimic the approach taken by llvm-lit
+# and pass a python configuration straight to dotest, rather than going
+# through the operating system.
+command = '{} -q {} {}'.format(dotest_path, dotest_args, ' '.join(
+sys.argv[1:]))
+os.system(command)

Propchange: lldb/trunk/test/llvm-dotest.in
--
svn:executable = *


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