date:20151001

Re: [Lldb-commits] [PATCH] D12748: Include platform agnostic in the place of

2015-10-01 Thread Bruce Mitchener via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL248990: Include platform agnostic  in the 
place of  (authored by brucem).

Changed prior to commit:
  http://reviews.llvm.org/D12748?vs=35950&id=36194#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12748

Files:
  lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp

Index: lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
===
--- lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
+++ lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
@@ -9,7 +9,6 @@
 
 // C Includes
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -29,6 +28,7 @@
 #include "lldb/Core/Error.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Host/ConnectionFileDescriptor.h"
+#include "lldb/Host/HostGetOpt.h"
 #include "lldb/Host/HostThread.h"
 #include "lldb/Host/OptionParser.h"
 #include "lldb/Host/Pipe.h"


Index: lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
===
--- lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
+++ lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
@@ -9,7 +9,6 @@
 
 // C Includes
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -29,6 +28,7 @@
 #include "lldb/Core/Error.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Host/ConnectionFileDescriptor.h"
+#include "lldb/Host/HostGetOpt.h"
 #include "lldb/Host/HostThread.h"
 #include "lldb/Host/OptionParser.h"
 #include "lldb/Host/Pipe.h"
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r248990 - Include platform agnostic in the place of

2015-10-01 Thread Bruce Mitchener via lldb-commits

Author: brucem
Date: Thu Oct  1 02:45:58 2015
New Revision: 248990

URL: http://llvm.org/viewvc/llvm-project?rev=248990&view=rev
Log:
Include platform agnostic  in the place of 

Summary: Problem caught on NetBSD with missing getopt_long_only(3).

Change by Kamil Rytarowski 

Reviewers: joerg, brucem

Subscribers: brucem, lldb-commits

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

Modified:
lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp

Modified: lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp?rev=248990&r1=248989&r2=248990&view=diff
==
--- lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp (original)
+++ lldb/trunk/tools/lldb-server/lldb-gdbserver.cpp Thu Oct  1 02:45:58 2015
@@ -9,7 +9,6 @@
 
 // C Includes
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -29,6 +28,7 @@
 #include "lldb/Core/Error.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Host/ConnectionFileDescriptor.h"
+#include "lldb/Host/HostGetOpt.h"
 #include "lldb/Host/HostThread.h"
 #include "lldb/Host/OptionParser.h"
 #include "lldb/Host/Pipe.h"


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

[Lldb-commits] [lldb] r248991 - Use the correct Python lib for each build configuration generated by the Visual Studio CMake generator

2015-10-01 Thread Bruce Mitchener via lldb-commits

Author: brucem
Date: Thu Oct  1 02:47:38 2015
New Revision: 248991

URL: http://llvm.org/viewvc/llvm-project?rev=248991&view=rev
Log:
Use the correct Python lib for each build configuration generated by the Visual 
Studio CMake generator

Summary:
Previously `CMAKE_BUILD_TYPE` was used to determine whether to link in 
`python27.lib` or `python27_d.lib`, unfortunately this only works reliably when 
using a CMake generator that generates a single build configuration (e.g. 
Ninja). The Visual Studio CMake generator generates four build configurations 
at once (`Debug`, `Release`, `RelWithDebInfo`, `MinSizeRel`), so if 
`CMAKE_BUILD_TYPE` is set to `Debug` all four build configurations end up 
linking in `python27_d.lib`, this is clearly undesirable.

To ensure that the correct Python lib is used for each build configuration the 
value of `PYTHON_LIBRARY` is now determined using generator expressions that 
evaluate to either the debug or release Python lib. The values of 
`PYTHON_EXECUTABLE` and `PYTHON_DLL` are now likewise determined using 
generator expressions.

Note that these changes only apply to the Windows build.

Patch by Vadim Macagon. Thanks!

Reviewers: zturner, brucem

Subscribers: zturner, lldb-commits

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

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

Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=248991&r1=248990&r2=248991&view=diff
==
--- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake Thu Oct  1 02:47:38 2015
@@ -48,15 +48,39 @@ if (NOT LLDB_DISABLE_PYTHON)
   if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
 if (NOT "${PYTHON_HOME}" STREQUAL "")
   file(TO_CMAKE_PATH "${PYTHON_HOME}" PYTHON_HOME)
-  if ("${CMAKE_BUILD_TYPE}" STREQUAL "Debug")
-file(TO_CMAKE_PATH "${PYTHON_HOME}/python_d.exe" PYTHON_EXECUTABLE)
-file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/python27_d.lib" PYTHON_LIBRARY)
-file(TO_CMAKE_PATH "${PYTHON_HOME}/python27_d.dll" PYTHON_DLL)
-  else()
-file(TO_CMAKE_PATH "${PYTHON_HOME}/python.exe" PYTHON_EXECUTABLE)
-file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/python27.lib" PYTHON_LIBRARY)
-file(TO_CMAKE_PATH "${PYTHON_HOME}/python27.dll" PYTHON_DLL)
-  endif()
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/python_d.exe" PYTHON_DEBUG_EXE)
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/python27_d.lib" PYTHON_DEBUG_LIB)
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/python27_d.dll" PYTHON_DEBUG_DLL)
+
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/python.exe" PYTHON_RELEASE_EXE)
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/python27.lib" PYTHON_RELEASE_LIB)
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/python27.dll" PYTHON_RELEASE_DLL)
+
+  # Generator expressions are evaluated in the context of each build 
configuration generated
+  # by CMake. Here we use the $:VALUE logical generator 
expression to ensure
+  # that the debug Python library, DLL, and executable are used in the 
Debug build configuration.
+  #
+  # Generator expressions can be difficult to grok at first so here's a 
breakdown of the one
+  # used for PYTHON_LIBRARY:
+  #
+  # 1. $ evaluates to 1 when the Debug configuration is 
being generated,
+  #or 0 in all other cases.
+  # 2. $<$:${PYTHON_DEBUG_LIB}> expands to 
${PYTHON_DEBUG_LIB} when the Debug
+  #configuration is being generated, or nothing (literally) in all 
other cases.
+  # 3. $<$>:${PYTHON_RELEASE_LIB}> expands to 
${PYTHON_RELEASE_LIB} when
+  #any configuration other than Debug is being generated, or nothing 
in all other cases.
+  # 4. The conditionals in 2 & 3 are mutually exclusive.
+  # 5. A logical expression with a conditional that evaluates to 0 yields 
no value at all.
+  #
+  # Due to 4 & 5 it's possible to concatenate 2 & 3 to obtain a single 
value specific to each
+  # build configuration. In this example the value will be 
${PYTHON_DEBUG_LIB} when generating the
+  # Debug configuration, or ${PYTHON_RELEASE_LIB} when generating any 
other configuration.
+  # Note that it's imperative that there is no whitespace between the two 
expressions, otherwise
+  # CMake will insert a semicolon between the two.
+
+  set (PYTHON_EXECUTABLE 
$<$:${PYTHON_DEBUG_EXE}>$<$>:${PYTHON_RELEASE_EXE}>)
+  set (PYTHON_LIBRARY 
$<$:${PYTHON_DEBUG_LIB}>$<$>:${PYTHON_RELEASE_LIB}>)
+  set (PYTHON_DLL 
$<$:${PYTHON_DEBUG_DLL}>$<$>:${PYTHON_RELEASE_DLL}>)
 
   file(TO_CMAKE_PATH "${PYTHON_HOME}/Include" PYTHON_INCLUDE_DIR)
   if (NOT LLDB_RELOCATABLE_PYTHON)


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

Re: [Lldb-commits] [PATCH] D13234: Use the correct Python lib for each build configuration generated by the Visual Studio CMake generator

2015-10-01 Thread Bruce Mitchener via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL248991: Use the correct Python lib for each build 
configuration generated by the… (authored by brucem).

Changed prior to commit:
  http://reviews.llvm.org/D13234?vs=36072&id=36196#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D13234

Files:
  lldb/trunk/cmake/modules/LLDBConfig.cmake

Index: lldb/trunk/cmake/modules/LLDBConfig.cmake
===
--- lldb/trunk/cmake/modules/LLDBConfig.cmake
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake
@@ -48,15 +48,39 @@
   if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
 if (NOT "${PYTHON_HOME}" STREQUAL "")
   file(TO_CMAKE_PATH "${PYTHON_HOME}" PYTHON_HOME)
-  if ("${CMAKE_BUILD_TYPE}" STREQUAL "Debug")
-file(TO_CMAKE_PATH "${PYTHON_HOME}/python_d.exe" PYTHON_EXECUTABLE)
-file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/python27_d.lib" PYTHON_LIBRARY)
-file(TO_CMAKE_PATH "${PYTHON_HOME}/python27_d.dll" PYTHON_DLL)
-  else()
-file(TO_CMAKE_PATH "${PYTHON_HOME}/python.exe" PYTHON_EXECUTABLE)
-file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/python27.lib" PYTHON_LIBRARY)
-file(TO_CMAKE_PATH "${PYTHON_HOME}/python27.dll" PYTHON_DLL)
-  endif()
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/python_d.exe" PYTHON_DEBUG_EXE)
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/python27_d.lib" PYTHON_DEBUG_LIB)
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/python27_d.dll" PYTHON_DEBUG_DLL)
+
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/python.exe" PYTHON_RELEASE_EXE)
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/python27.lib" PYTHON_RELEASE_LIB)
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/python27.dll" PYTHON_RELEASE_DLL)
+
+  # Generator expressions are evaluated in the context of each build 
configuration generated
+  # by CMake. Here we use the $:VALUE logical generator 
expression to ensure
+  # that the debug Python library, DLL, and executable are used in the 
Debug build configuration.
+  #
+  # Generator expressions can be difficult to grok at first so here's a 
breakdown of the one
+  # used for PYTHON_LIBRARY:
+  #
+  # 1. $ evaluates to 1 when the Debug configuration is 
being generated,
+  #or 0 in all other cases.
+  # 2. $<$:${PYTHON_DEBUG_LIB}> expands to 
${PYTHON_DEBUG_LIB} when the Debug
+  #configuration is being generated, or nothing (literally) in all 
other cases.
+  # 3. $<$>:${PYTHON_RELEASE_LIB}> expands to 
${PYTHON_RELEASE_LIB} when
+  #any configuration other than Debug is being generated, or nothing 
in all other cases.
+  # 4. The conditionals in 2 & 3 are mutually exclusive.
+  # 5. A logical expression with a conditional that evaluates to 0 yields 
no value at all.
+  #
+  # Due to 4 & 5 it's possible to concatenate 2 & 3 to obtain a single 
value specific to each
+  # build configuration. In this example the value will be 
${PYTHON_DEBUG_LIB} when generating the
+  # Debug configuration, or ${PYTHON_RELEASE_LIB} when generating any 
other configuration.
+  # Note that it's imperative that there is no whitespace between the two 
expressions, otherwise
+  # CMake will insert a semicolon between the two.
+
+  set (PYTHON_EXECUTABLE 
$<$:${PYTHON_DEBUG_EXE}>$<$>:${PYTHON_RELEASE_EXE}>)
+  set (PYTHON_LIBRARY 
$<$:${PYTHON_DEBUG_LIB}>$<$>:${PYTHON_RELEASE_LIB}>)
+  set (PYTHON_DLL 
$<$:${PYTHON_DEBUG_DLL}>$<$>:${PYTHON_RELEASE_DLL}>)
 
   file(TO_CMAKE_PATH "${PYTHON_HOME}/Include" PYTHON_INCLUDE_DIR)
   if (NOT LLDB_RELOCATABLE_PYTHON)


Index: lldb/trunk/cmake/modules/LLDBConfig.cmake
===
--- lldb/trunk/cmake/modules/LLDBConfig.cmake
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake
@@ -48,15 +48,39 @@
   if ("${CMAKE_SYSTEM_NAME}" STREQUAL "Windows")
 if (NOT "${PYTHON_HOME}" STREQUAL "")
   file(TO_CMAKE_PATH "${PYTHON_HOME}" PYTHON_HOME)
-  if ("${CMAKE_BUILD_TYPE}" STREQUAL "Debug")
-file(TO_CMAKE_PATH "${PYTHON_HOME}/python_d.exe" PYTHON_EXECUTABLE)
-file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/python27_d.lib" PYTHON_LIBRARY)
-file(TO_CMAKE_PATH "${PYTHON_HOME}/python27_d.dll" PYTHON_DLL)
-  else()
-file(TO_CMAKE_PATH "${PYTHON_HOME}/python.exe" PYTHON_EXECUTABLE)
-file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/python27.lib" PYTHON_LIBRARY)
-file(TO_CMAKE_PATH "${PYTHON_HOME}/python27.dll" PYTHON_DLL)
-  endif()
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/python_d.exe" PYTHON_DEBUG_EXE)
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/python27_d.lib" PYTHON_DEBUG_LIB)
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/python27_d.dll" PYTHON_DEBUG_DLL)
+
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/python.exe" PYTHON_RELEASE_EXE)
+  file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/python27.lib" PYTHON_RELEASE_LIB)
+  file(TO_CMAKE_PATH "${PYTHON_HOME}

[Lldb-commits] [lldb] r248992 - Add a Post-Build Event on Windows to copy the correct custom Python DLL to the LLDB binaries dir

2015-10-01 Thread Bruce Mitchener via lldb-commits

Author: brucem
Date: Thu Oct  1 02:55:44 2015
New Revision: 248992

URL: http://llvm.org/viewvc/llvm-project?rev=248992&view=rev
Log:
Add a Post-Build Event on Windows to copy the correct custom Python DLL to the 
LLDB binaries dir

Summary:
After a developer builds LLDB from source on Windows (assuming they've built it 
with Python support enabled), they may be somewhat flustered when it fails to 
launch with a cryptic error.

{F890625}

This happens because Windows can't find python27.dll (or python27_d.dll in case 
LLDB was built in debug mode). Many developers may have previously installed a 
release build of Python 2.7 and will not notice anything is amiss when they run 
a release build of LLDB because Windows will load the python27.dll from one of 
the system directories or `PATH` (rather than the one that the LLDB build 
instructions tell them to build). The issue tends to be more pronounced with 
debug builds of LLDB, since fewer developers probably have python27_d.dll 
sitting in one of the Windows system directories.

To ensure Windows loads the correct custom built Python DLL when launching LLDB 
I've added a post-build event that copies the relevant DLL (based on the LLDB 
build configuration) from `PYTHON_HOME` to the directory in which the LLDB 
executable is generated.

Patch by Vadim Macagon. Thanks!

Reviewers: brucem, zturner

Subscribers: lldb-commits

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

Modified:
lldb/trunk/CMakeLists.txt

Modified: lldb/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=248992&r1=248991&r2=248992&view=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Thu Oct  1 02:55:44 2015
@@ -26,4 +26,17 @@ if (NOT LLDB_DISABLE_PYTHON)
 
 # Ensure we do the python post-build step when building lldb.
 add_dependencies(lldb finish_swig)
+
+# Add a Post-Build Event to copy the custom Python DLL to the lldb 
binaries dir so that Windows can find it when launching
+# lldb.exe or any other executables that were linked with liblldb.
+if (WIN32 AND NOT "${PYTHON_DLL}" STREQUAL "")
+# When using the Visual Studio CMake generator the lldb binaries end 
up in Release/bin, Debug/bin etc.
+file(TO_NATIVE_PATH "${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin" 
LLDB_BIN_DIR)
+file(TO_NATIVE_PATH "${PYTHON_DLL}" PYTHON_DLL_NATIVE_PATH)
+add_custom_command(
+TARGET finish_swig
+POST_BUILD
+COMMAND "${CMAKE_COMMAND}" -E copy ${PYTHON_DLL_NATIVE_PATH} 
${LLDB_BIN_DIR}
+COMMENT "Copying Python DLL to LLDB binaries directory.")
+endif ()
 endif ()


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

Re: [Lldb-commits] [PATCH] D13237: Add a Post-Build Event on Windows to copy the correct custom Python DLL to the LLDB binaries dir

2015-10-01 Thread Bruce Mitchener via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL248992: Add a Post-Build Event on Windows to copy the 
correct custom Python DLL to… (authored by brucem).

Changed prior to commit:
  http://reviews.llvm.org/D13237?vs=35948&id=36197#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D13237

Files:
  lldb/trunk/CMakeLists.txt

Index: lldb/trunk/CMakeLists.txt
===
--- lldb/trunk/CMakeLists.txt
+++ lldb/trunk/CMakeLists.txt
@@ -26,4 +26,17 @@
 
 # Ensure we do the python post-build step when building lldb.
 add_dependencies(lldb finish_swig)
+
+# Add a Post-Build Event to copy the custom Python DLL to the lldb 
binaries dir so that Windows can find it when launching
+# lldb.exe or any other executables that were linked with liblldb.
+if (WIN32 AND NOT "${PYTHON_DLL}" STREQUAL "")
+# When using the Visual Studio CMake generator the lldb binaries end 
up in Release/bin, Debug/bin etc.
+file(TO_NATIVE_PATH "${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin" 
LLDB_BIN_DIR)
+file(TO_NATIVE_PATH "${PYTHON_DLL}" PYTHON_DLL_NATIVE_PATH)
+add_custom_command(
+TARGET finish_swig
+POST_BUILD
+COMMAND "${CMAKE_COMMAND}" -E copy ${PYTHON_DLL_NATIVE_PATH} 
${LLDB_BIN_DIR}
+COMMENT "Copying Python DLL to LLDB binaries directory.")
+endif ()
 endif ()


Index: lldb/trunk/CMakeLists.txt
===
--- lldb/trunk/CMakeLists.txt
+++ lldb/trunk/CMakeLists.txt
@@ -26,4 +26,17 @@
 
 # Ensure we do the python post-build step when building lldb.
 add_dependencies(lldb finish_swig)
+
+# Add a Post-Build Event to copy the custom Python DLL to the lldb binaries dir so that Windows can find it when launching
+# lldb.exe or any other executables that were linked with liblldb.
+if (WIN32 AND NOT "${PYTHON_DLL}" STREQUAL "")
+# When using the Visual Studio CMake generator the lldb binaries end up in Release/bin, Debug/bin etc.
+file(TO_NATIVE_PATH "${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin" LLDB_BIN_DIR)
+file(TO_NATIVE_PATH "${PYTHON_DLL}" PYTHON_DLL_NATIVE_PATH)
+add_custom_command(
+TARGET finish_swig
+POST_BUILD
+COMMAND "${CMAKE_COMMAND}" -E copy ${PYTHON_DLL_NATIVE_PATH} ${LLDB_BIN_DIR}
+COMMENT "Copying Python DLL to LLDB binaries directory.")
+endif ()
 endif ()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D13028: Merge dsym and dwarf test cases

2015-10-01 Thread Ed Maste via lldb-commits

emaste added a comment.

> I'm leaving shortly to travel to EuroBSDCon so probably will not be able to 
> test before Wednesday, but I can investigate and update decorators as 
> appropriate afterwards.


A follow up - the tests look good on FreeBSD after this change. On my branch 
with a few updates to FreeBSD expected failure decorators,

  [1/1] Testing LLDB (parallel execution, with a separate subprocess per test)
  Testing: 399 test suites, 8 threads
  399 out of 399 test suites processed - TestMiFile.py  
 
  Ran 399 test suites (0 failed) (0.00%)
  Ran 322 test cases (0 failed) (0.00%)
  
  Unexpected Successes (1)
  UNEXPECTED SUCCESS: LLDB (suite) :: TestRecursiveInferior.py (FreeBSD feynman 
10.2-STABLE FreeBSD 10.2-STABLE #44 r288174+7644546(stable-10): Thu Sep 24 
14:02:11 EDT 2015 
emaste@feynman:/tank/emaste/obj/tank/emaste/src/git-stable-10/sys/GENERIC amd64 
amd64)
224.52 real   665.99 user   366.72 sys


Repository:
  rL LLVM

http://reviews.llvm.org/D13028



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

Re: [Lldb-commits] [PATCH] D13300: Run tests with dwo symbol files

2015-10-01 Thread Pavel Labath via lldb-commits

labath added a comment.

Only small comments from me.



Comment at: test/dotest_args.py:63
@@ -62,3 +62,3 @@
 group = parser.add_argument_group('Test filtering options')
-group.add_argument('-N', choices=['dwarf', 'dsym'], help="Don't do test 
cases marked with the @dsym decorator by passing 'dsym' as the option arg, or 
don't do test cases marked with the @dwarf decorator by passing 'dwarf' as the 
option arg")
+group.add_argument('-N', choices=['dwarf', 'dwo', 'dsym'], help="Don't do 
test cases marked with the @dsym decorator by passing 'dsym' as the option arg, 
or don't do test cases marked with the @dwarf decorator by passing 'dwarf' as 
the option arg")
 X('-a', "Don't do lldb Python API tests")

This help string sounds like it needs updating.


Comment at: test/functionalities/dead-strip/TestDeadStrip.py:16
@@ -15,2 +15,3 @@
 @expectedFailureWindows("llvm.org/pr24778")
+@expectedFailureDwo # In case of a stripped symbol we put a breakpoint at 
0x0 instead of reporting an error
 @skipIfFreeBSD # The -dead_strip linker option isn't supported on FreeBSD 
versions of ld.

Could you file a bug about this?


http://reviews.llvm.org/D13300



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

[Lldb-commits] [lldb] r248995 - Revert "Fixing a subtle issue on Mac OS X systems with dSYMs..."

2015-10-01 Thread Pavel Labath via lldb-commits

Author: labath
Date: Thu Oct  1 04:03:33 2015
New Revision: 248995

URL: http://llvm.org/viewvc/llvm-project?rev=248995&view=rev
Log:
Revert "Fixing a subtle issue on Mac OS X systems with dSYMs..."

This reverts commit r248985, as it was breaking all remote
expression-evaluating tests (on android at least).

Modified:
lldb/trunk/include/lldb/Host/Symbols.h
lldb/trunk/source/Core/ModuleList.cpp
lldb/trunk/source/Host/common/Symbols.cpp
lldb/trunk/source/Host/macosx/Symbols.cpp
lldb/trunk/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp

Modified: lldb/trunk/include/lldb/Host/Symbols.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/Symbols.h?rev=248995&r1=248994&r2=248995&view=diff
==
--- lldb/trunk/include/lldb/Host/Symbols.h (original)
+++ lldb/trunk/include/lldb/Host/Symbols.h Thu Oct  1 04:03:33 2015
@@ -29,7 +29,7 @@ public:
 // Locating the file should happen only on the local computer or using
 // the current computers global settings.
 //--
-static ModuleSpec
+static FileSpec
 LocateExecutableObjectFile (const ModuleSpec &module_spec);
 
 //--

Modified: lldb/trunk/source/Core/ModuleList.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ModuleList.cpp?rev=248995&r1=248994&r2=248995&view=diff
==
--- lldb/trunk/source/Core/ModuleList.cpp (original)
+++ lldb/trunk/source/Core/ModuleList.cpp Thu Oct  1 04:03:33 2015
@@ -1045,19 +1045,19 @@ ModuleList::GetSharedModule
 
 // Fixup the incoming path in case the path points to a valid file, yet
 // the arch or UUID (if one was passed in) don't match.
-ModuleSpec located_binary_modulespec = Symbols::LocateExecutableObjectFile 
(module_spec);
+FileSpec file_spec = Symbols::LocateExecutableObjectFile (module_spec);
 
 // Don't look for the file if it appears to be the same one we already
 // checked for above...
-if (located_binary_modulespec.GetFileSpec() != module_file_spec)
+if (file_spec != module_file_spec)
 {
-if (!located_binary_modulespec.GetFileSpec().Exists())
+if (!file_spec.Exists())
 {
-located_binary_modulespec.GetFileSpec().GetPath(path, 
sizeof(path));
+file_spec.GetPath(path, sizeof(path));
 if (path[0] == '\0')
 module_file_spec.GetPath(path, sizeof(path));
 // How can this check ever be true? This branch it is false, and 
we haven't modified file_spec.
-if (located_binary_modulespec.GetFileSpec().Exists())
+if (file_spec.Exists())
 {
 std::string uuid_str;
 if (uuid_ptr && uuid_ptr->IsValid())
@@ -1084,8 +1084,9 @@ ModuleList::GetSharedModule
 // Make sure no one else can try and get or create a module while this
 // function is actively working on it by doing an extra lock on the
 // global mutex list.
-ModuleSpec platform_module_spec(located_binary_modulespec);
-platform_module_spec.GetPlatformFileSpec() = 
located_binary_modulespec.GetFileSpec();
+ModuleSpec platform_module_spec(module_spec);
+platform_module_spec.GetFileSpec() = file_spec;
+platform_module_spec.GetPlatformFileSpec() = file_spec;
 ModuleList matching_module_list;
 if (shared_module_list.FindModules (platform_module_spec, 
matching_module_list) > 0)
 {
@@ -1095,7 +1096,7 @@ ModuleList::GetSharedModule
 // then we should make sure the modification time hasn't changed!
 if (platform_module_spec.GetUUIDPtr() == NULL)
 {
-TimeValue 
file_spec_mod_time(located_binary_modulespec.GetFileSpec().GetModificationTime());
+TimeValue file_spec_mod_time(file_spec.GetModificationTime());
 if (file_spec_mod_time.IsValid())
 {
 if (file_spec_mod_time != module_sp->GetModificationTime())
@@ -1124,9 +1125,9 @@ ModuleList::GetSharedModule
 }
 else
 {
-located_binary_modulespec.GetFileSpec().GetPath(path, 
sizeof(path));
+file_spec.GetPath(path, sizeof(path));
 
-if (located_binary_modulespec.GetFileSpec())
+if (file_spec)
 {
 if (arch.IsValid())
 error.SetErrorStringWithFormat("unable to open %s 
architecture in '%s'", arch.GetArchitectureName(), path);

Modified: lldb/trunk/source/Host/common/Symbols.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/common/Symbols.cpp?rev=248995&r1=248994&r2=248995&view=diff
=

Re: [Lldb-commits] [lldb] r248985 - Fixing a subtle issue on Mac OS X systems with dSYMs (possibly

2015-10-01 Thread Pavel Labath via lldb-commits

Hi,

I have reverted this as it was causing many failures on our remote
android buildbots
.
I am hoping I will get a chance to investigate and give you a more
accurate error description by EOD (your morning). Given that the local
tests our working just fine, i suspect this has something to do with
paths.

pl


On 1 October 2015 at 07:09, Zachary Turner via lldb-commits
 wrote:
> Yea.  It's definitely hard to write a normal test case for this.  It's also
> a common problem when dealing with remote debugging scenarios.  It's both
> hard and resource demanding (needing to have just the right Host -> Target
> configuration available) to test that by going through the full debugging
> stack.  But it's often easy to write a test for a specific bug by finding
> the point of failure, and writing a simple unit test that verifies the
> inputs and outputs of a single method.
>
> Many of LLDB's abstractions aren't designed to be able to handle this very
> well (for example, dependency injection is a common technique, but requires
> the functionality to be abstracted correctly to be able to inject mock
> interfaces), but there's no reason they couldn't be changed to be.
>
> On Wed, Sep 30, 2015 at 11:03 PM Jason Molenda  wrote:
>>
>> Thanks for the idea Zachary, I haven't been following that.  I'll look at
>> this tomorrow.  I was trying to imagine how to write a normal test case for
>> this and it'd involve running a binary, deleting the binary off disk, then
>> lldb attach to the process, letting it find a dSYM via spotlight which
>> points to a copy of the binary in another location and there's another copy
>> of the dSYM next to that binary. And I'd want to check that lldb stuck with
>> the original dSYM that it found, instead of picking up the second dSYM
>> sitting next to the binary.  It might be possible to replicate the behavior
>> entirely self-hosted.  But it definitely only works on a mac because of the
>> DebugSymbols private framework calls lldb makes while doing all of this.
>>
>>
>> > On Sep 30, 2015, at 10:58 PM, Zachary Turner  wrote:
>> >
>> > This is a good example of where unit tests are useful.  There's already
>> > a small suite of unit tests but I'm going to start being proactive about
>> > growing it (in part by evangelizing it in response to people's commits ;-).
>> > It's not integrated into the Xcode build, but it would certainly be easy to
>> > do so.  The nice thing about a unit test is that you can set everything up
>> > exactly the way you need it and just call the one native code method you
>> > want to test, and verify the outputs.  You could make up your own
>> > ModuleSpec, you could make a mock implementation of `Symbols` that 
>> > delegates
>> > to the real `Symbols` implementation for everything except the part where 
>> > it
>> > checks if the file exists, and have that method simply return false so it
>> > goes to the fallback path, etc.
>> >
>> > Anyway, just throwing this out there as an option.  This is MacOSX only
>> > code so it's not a huge priority for me to push it strongly, but if you
>> > think it would be useful I'm happy to help you figure out how to run them
>> > and/or write a new one.
>> >
>> > On Wed, Sep 30, 2015 at 10:39 PM Jason Molenda via lldb-commits
>> >  wrote:
>> > Author: jmolenda
>> > Date: Thu Oct  1 00:37:22 2015
>> > New Revision: 248985
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=248985&view=rev
>> > Log:
>> > Fixing a subtle issue on Mac OS X systems with dSYMs (possibly
>> > introduced by r235737 but I didn't look into it too closely).
>> >
>> > A dSYM can have a per-UUID plist in it which tells lldb where
>> > to find an executable binary for the dSYM (DBGSymbolRichExecutable)
>> > - other information can be included in this plist, like how to
>> > remap the source file paths from their build pathnames to their
>> > long-term storage pathnames.
>> >
>> > This per-UUID plist is a unusual; it is used probably exclusively
>> > inside apple with our build system.  It is not created by default
>> > in normal dSYMs.
>> >
>> > The problem was like this:
>> >
>> >   1. lldb wants to find an executable, given only a UUID
>> >  (this happens when lldb is doing cross-host debugging
>> >   and doesn't have a copy of the target system's binaries)
>> >
>> >   2. It eventually calls LocateMacOSXFilesUsingDebugSymbols
>> >  which does a spotlight search for the dSYM on the local
>> >  system, and failing that, tries the DBGShellCommands
>> >  command to find the dSYM.
>> >
>> >   3. It gets a dSYM.  It reads the per-UUID plist in the dSYM.
>> >  The dSYM has a DBGSymbolRichExecutable kv pair pointing to
>> >  the binary on a network filesystem.
>> >
>> >   4. Using the binary on the network filesystem, lldb now goes
>> >  to find the dSYM.
>> >
>> >   5. It starts by looking for a dSYM next to the binary it found.
>> >
>> >   6. lldb is no

[Lldb-commits] [PATCH] D13333: Reduce header inclusion in Expression.

2015-10-01 Thread Bruce Mitchener via lldb-commits

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

http://reviews.llvm.org/D1

Files:
  include/lldb/Expression/ExpressionParser.h
  include/lldb/Expression/ExpressionVariable.h
  include/lldb/Expression/FunctionCaller.h
  include/lldb/Expression/IRInterpreter.h
  include/lldb/Expression/Materializer.h
  include/lldb/Expression/UserExpression.h
  source/Expression/UtilityFunction.cpp
  source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.h
  source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
  source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
  source/Plugins/ExpressionParser/Clang/ClangUserExpression.h

Index: source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
===
--- source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
+++ source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
@@ -32,7 +32,6 @@
 #include "lldb/Core/ClangForward.h"
 #include "lldb/Expression/UserExpression.h"
 #include "lldb/Expression/Materializer.h"
-#include "lldb/Symbol/TaggedASTType.h"
 #include "lldb/Target/ExecutionContext.h"
 
 namespace lldb_private
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.h
@@ -16,8 +16,6 @@
 #include "lldb/Core/Error.h"
 #include "lldb/Expression/ExpressionParser.h"
 
-#include "IRForTarget.h"
-
 #include 
 #include 
 
Index: source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
@@ -14,6 +14,7 @@
 #include "ClangExpressionDeclMap.h"
 #include "ClangModulesDeclVendor.h"
 #include "ClangPersistentVariables.h"
+#include "IRForTarget.h"
 
 #include "lldb/Core/ArchSpec.h"
 #include "lldb/Core/DataBufferHeap.h"
Index: source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.h
===
--- source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.h
+++ source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.h
@@ -12,7 +12,7 @@
 
 #include "clang/Sema/SemaConsumer.h"
 #include "lldb/Core/ClangForward.h"
-#include "lldb/Symbol/TaggedASTType.h"
+#include "lldb/Target/Target.h"
 
 namespace lldb_private {
 
Index: source/Expression/UtilityFunction.cpp
===
--- source/Expression/UtilityFunction.cpp
+++ source/Expression/UtilityFunction.cpp
@@ -26,6 +26,7 @@
 #include "lldb/Expression/IRExecutionUnit.h"
 #include "lldb/Host/Host.h"
 #include "lldb/Target/ExecutionContext.h"
+#include "lldb/Target/Process.h"
 #include "lldb/Target/Target.h"
 
 using namespace lldb_private;
Index: include/lldb/Expression/UserExpression.h
===
--- include/lldb/Expression/UserExpression.h
+++ include/lldb/Expression/UserExpression.h
@@ -16,18 +16,13 @@
 #include 
 #include 
 
-// Other libraries and framework includes
-
-#include "llvm/ADT/ArrayRef.h"
-
 // Project includes
 
 #include "lldb/lldb-forward.h"
 #include "lldb/lldb-private.h"
 #include "lldb/Core/Address.h"
 #include "lldb/Expression/Expression.h"
 #include "lldb/Expression/Materializer.h"
-#include "lldb/Symbol/TaggedASTType.h"
 #include "lldb/Target/ExecutionContext.h"
 
 namespace lldb_private
Index: include/lldb/Expression/Materializer.h
===
--- include/lldb/Expression/Materializer.h
+++ include/lldb/Expression/Materializer.h
@@ -13,8 +13,7 @@
 #include "lldb/lldb-private-types.h"
 #include "lldb/Core/Error.h"
 #include "lldb/Expression/IRMemoryMap.h"
-#include "lldb/Host/Mutex.h"
-#include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Symbol/TaggedASTType.h"
 #include "lldb/Target/StackFrame.h"
 
 #include 
Index: include/lldb/Expression/IRInterpreter.h
===
--- include/lldb/Expression/IRInterpreter.h
+++ include/lldb/Expression/IRInterpreter.h
@@ -13,7 +13,6 @@
 #include "lldb/lldb-public.h"
 #include "lldb/Core/ConstString.h"
 #include "lldb/Core/Stream.h"
-#include "lldb/Symbol/TaggedASTType.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/Pass.h"
 
Index: include/lldb/Expression/FunctionCaller.h
===
--- include/lldb/Expression/FunctionCaller.h
+++ include/lldb/Expression/FunctionCaller.h
@@ -17,19 +17,14 @@
 // Other libraries and framework includes
 // Project includes
 #include "lldb/Core/Address.h"
-#include "lldb/Core/ArchSpec.h"
 #include "lldb/Core/Value.h"
-#include "lldb/Core/ValueObjec

Re: [Lldb-commits] [PATCH] D13323: Use %HOME%/.lldb/module_cache as a default module cache directory

2015-10-01 Thread Tamas Berghammer via lldb-commits

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

LGTM


http://reviews.llvm.org/D13323



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

[Lldb-commits] [lldb] r248998 - Trim the output of mktem in PlatformAndroid::DownloadSymbolFile

2015-10-01 Thread Tamas Berghammer via lldb-commits

Author: tberghammer
Date: Thu Oct  1 04:42:23 2015
New Revision: 248998

URL: http://llvm.org/viewvc/llvm-project?rev=248998&view=rev
Log:
Trim the output of mktem in PlatformAndroid::DownloadSymbolFile

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

Modified:
lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp

Modified: lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp?rev=248998&r1=248997&r2=248998&view=diff
==
--- lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp (original)
+++ lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp Thu Oct  1 
04:42:23 2015
@@ -331,7 +331,7 @@ PlatformAndroid::DownloadSymbolFile (con
 Error error = adb.Shell("mktemp --directory --tmpdir /data/local/tmp", 
5000 /* ms */, &tmpdir);
 if (error.Fail() || tmpdir.empty())
 return Error("Failed to generate temporary directory on the device 
(%s)", error.AsCString());
-tmpdir.erase(tmpdir.size() - 1); // Remove trailing new line
+tmpdir = llvm::StringRef(tmpdir).trim().str();
 
 // Create file remover for the temporary directory created on the device
 std::unique_ptr> 
tmpdir_remover(


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

Re: [Lldb-commits] [PATCH] D13293: Trim the output of mktem in PlatformAndroid::DownloadSymbolFile

2015-10-01 Thread Tamas Berghammer via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL248998: Trim the output of mktem in 
PlatformAndroid::DownloadSymbolFile (authored by tberghammer).

Changed prior to commit:
  http://reviews.llvm.org/D13293?vs=36111&id=36209#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D13293

Files:
  lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp

Index: lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
===
--- lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
+++ lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
@@ -331,7 +331,7 @@
 Error error = adb.Shell("mktemp --directory --tmpdir /data/local/tmp", 
5000 /* ms */, &tmpdir);
 if (error.Fail() || tmpdir.empty())
 return Error("Failed to generate temporary directory on the device 
(%s)", error.AsCString());
-tmpdir.erase(tmpdir.size() - 1); // Remove trailing new line
+tmpdir = llvm::StringRef(tmpdir).trim().str();
 
 // Create file remover for the temporary directory created on the device
 std::unique_ptr> 
tmpdir_remover(


Index: lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
===
--- lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
+++ lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
@@ -331,7 +331,7 @@
 Error error = adb.Shell("mktemp --directory --tmpdir /data/local/tmp", 5000 /* ms */, &tmpdir);
 if (error.Fail() || tmpdir.empty())
 return Error("Failed to generate temporary directory on the device (%s)", error.AsCString());
-tmpdir.erase(tmpdir.size() - 1); // Remove trailing new line
+tmpdir = llvm::StringRef(tmpdir).trim().str();
 
 // Create file remover for the temporary directory created on the device
 std::unique_ptr> tmpdir_remover(
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [lldb] r248985 - Fixing a subtle issue on Mac OS X systems with dSYMs (possibly

2015-10-01 Thread Pavel Labath via lldb-commits

From one of the failing tests:
===
runCmd: expr release_child_flag = 1
output: (volatile int) $0 = 1


Expecting sub string: = 1
Matched

runCmd: print (int)getpgid(0)
runCmd failed!
error: use of undeclared identifier 'getpgid'
error: 1 errors parsing expression
===

here, release_child_flag is in the inferior (and has debug info), and
evaluating an expression with it works.
getpgid is in libc (for which we only have .symtab), and lldb cannot
find it for some reason.

hope that helps,
pl


On 1 October 2015 at 10:09, Pavel Labath  wrote:
> Hi,
>
> I have reverted this as it was causing many failures on our remote
> android buildbots
> .
> I am hoping I will get a chance to investigate and give you a more
> accurate error description by EOD (your morning). Given that the local
> tests our working just fine, i suspect this has something to do with
> paths.
>
> pl
>
>
> On 1 October 2015 at 07:09, Zachary Turner via lldb-commits
>  wrote:
>> Yea.  It's definitely hard to write a normal test case for this.  It's also
>> a common problem when dealing with remote debugging scenarios.  It's both
>> hard and resource demanding (needing to have just the right Host -> Target
>> configuration available) to test that by going through the full debugging
>> stack.  But it's often easy to write a test for a specific bug by finding
>> the point of failure, and writing a simple unit test that verifies the
>> inputs and outputs of a single method.
>>
>> Many of LLDB's abstractions aren't designed to be able to handle this very
>> well (for example, dependency injection is a common technique, but requires
>> the functionality to be abstracted correctly to be able to inject mock
>> interfaces), but there's no reason they couldn't be changed to be.
>>
>> On Wed, Sep 30, 2015 at 11:03 PM Jason Molenda  wrote:
>>>
>>> Thanks for the idea Zachary, I haven't been following that.  I'll look at
>>> this tomorrow.  I was trying to imagine how to write a normal test case for
>>> this and it'd involve running a binary, deleting the binary off disk, then
>>> lldb attach to the process, letting it find a dSYM via spotlight which
>>> points to a copy of the binary in another location and there's another copy
>>> of the dSYM next to that binary. And I'd want to check that lldb stuck with
>>> the original dSYM that it found, instead of picking up the second dSYM
>>> sitting next to the binary.  It might be possible to replicate the behavior
>>> entirely self-hosted.  But it definitely only works on a mac because of the
>>> DebugSymbols private framework calls lldb makes while doing all of this.
>>>
>>>
>>> > On Sep 30, 2015, at 10:58 PM, Zachary Turner  wrote:
>>> >
>>> > This is a good example of where unit tests are useful.  There's already
>>> > a small suite of unit tests but I'm going to start being proactive about
>>> > growing it (in part by evangelizing it in response to people's commits 
>>> > ;-).
>>> > It's not integrated into the Xcode build, but it would certainly be easy 
>>> > to
>>> > do so.  The nice thing about a unit test is that you can set everything up
>>> > exactly the way you need it and just call the one native code method you
>>> > want to test, and verify the outputs.  You could make up your own
>>> > ModuleSpec, you could make a mock implementation of `Symbols` that 
>>> > delegates
>>> > to the real `Symbols` implementation for everything except the part where 
>>> > it
>>> > checks if the file exists, and have that method simply return false so it
>>> > goes to the fallback path, etc.
>>> >
>>> > Anyway, just throwing this out there as an option.  This is MacOSX only
>>> > code so it's not a huge priority for me to push it strongly, but if you
>>> > think it would be useful I'm happy to help you figure out how to run them
>>> > and/or write a new one.
>>> >
>>> > On Wed, Sep 30, 2015 at 10:39 PM Jason Molenda via lldb-commits
>>> >  wrote:
>>> > Author: jmolenda
>>> > Date: Thu Oct  1 00:37:22 2015
>>> > New Revision: 248985
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=248985&view=rev
>>> > Log:
>>> > Fixing a subtle issue on Mac OS X systems with dSYMs (possibly
>>> > introduced by r235737 but I didn't look into it too closely).
>>> >
>>> > A dSYM can have a per-UUID plist in it which tells lldb where
>>> > to find an executable binary for the dSYM (DBGSymbolRichExecutable)
>>> > - other information can be included in this plist, like how to
>>> > remap the source file paths from their build pathnames to their
>>> > long-term storage pathnames.
>>> >
>>> > This per-UUID plist is a unusual; it is used probably exclusively
>>> > inside apple with our build system.  It is not created by default
>>> > in normal dSYMs.
>>> >
>>> > The problem was like this:
>>> >
>>> >   1. lldb wants to find an executable, given only a UUID
>>> >  (this happens when lldb is doing cross-host debugging
>>> >

[Lldb-commits] [PATCH] D13334: Preliminary NetBSD support

2015-10-01 Thread Kamil Rytarowski via lldb-commits

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

This adds platform code without the cmake/gmake glue to the existing 
infrastructure.

The missing and incompatibility ptrace(2) bits (existing in FreeBSD) are under 
active research and development and will be submitted once verified to work.

This code was tested to build and run on NetBSD-current/amd64.

Proper build scripts will be integrated separately as a new commit.

Repository:
  rL LLVM

http://reviews.llvm.org/D13334

Files:
  include/lldb/Host/Config.h
  include/lldb/Host/HostInfo.h
  include/lldb/Host/HostNativeThread.h
  include/lldb/Host/HostNativeThreadForward.h
  include/lldb/Host/netbsd/Config.h
  include/lldb/Host/netbsd/HostInfoNetBSD.h
  include/lldb/Host/netbsd/HostThreadNetBSD.h
  source/Host/netbsd/Host.cpp
  source/Host/netbsd/HostInfoNetBSD.cpp
  source/Host/netbsd/HostThreadNetBSD.cpp
  source/Host/netbsd/ThisThread.cpp
  source/Initialization/SystemInitializerCommon.cpp
  source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp
  source/Plugins/Platform/NetBSD/PlatformNetBSD.h

Index: source/Plugins/Platform/NetBSD/PlatformNetBSD.h
===
--- /dev/null
+++ source/Plugins/Platform/NetBSD/PlatformNetBSD.h
@@ -0,0 +1,182 @@
+//===-- PlatformNetBSD.h ---*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef liblldb_PlatformNetBSD_h_
+#define liblldb_PlatformNetBSD_h_
+
+// C Includes
+// C++ Includes
+// Other libraries and framework includes
+// Project includes
+#include "lldb/Target/Platform.h"
+
+namespace lldb_private {
+namespace platform_netbsd {
+
+class PlatformNetBSD : public Platform
+{
+public:
+
+//
+// Class functions
+//
+static lldb::PlatformSP
+CreateInstance(bool force, const ArchSpec *arch);
+
+static void
+Initialize ();
+
+static void
+Terminate ();
+
+static ConstString
+GetPluginNameStatic (bool is_host);
+
+static const char *
+GetDescriptionStatic (bool is_host);
+
+//
+// Class Methods
+//
+PlatformNetBSD (bool is_host);
+
+virtual
+~PlatformNetBSD();
+
+//
+// lldb_private::PluginInterface functions
+//
+ConstString
+GetPluginName() override
+{
+return GetPluginNameStatic (IsHost());
+}
+
+uint32_t
+GetPluginVersion() override
+{
+return 1;
+}
+
+const char *
+GetDescription () override
+{
+return GetDescriptionStatic(IsHost());
+}
+
+//
+// lldb_private::Platform functions
+//
+bool
+GetModuleSpec(const FileSpec& module_file_spec,
+  const ArchSpec& arch,
+  ModuleSpec &module_spec) override;
+
+Error
+RunShellCommand(const char *command,
+const FileSpec &working_dir,
+int *status_ptr,
+int *signo_ptr,
+std::string *command_output,
+uint32_t timeout_sec) override;
+
+Error
+ResolveExecutable(const ModuleSpec &module_spec,
+  lldb::ModuleSP &module_sp,
+  const FileSpecList *module_search_paths_ptr) override;
+
+size_t
+GetSoftwareBreakpointTrapOpcode(Target &target,
+BreakpointSite *bp_site) override;
+
+bool
+GetRemoteOSVersion () override;
+
+bool
+GetRemoteOSBuildString (std::string &s) override;
+
+bool
+GetRemoteOSKernelDescription (std::string &s) override;
+
+// Remote Platform subclasses need to override this function
+ArchSpec
+GetRemoteSystemArchitecture() override;
+
+bool
+IsConnected () const override;
+
+Error
+ConnectRemote(Args& args) override;
+
+Error
+DisconnectRemote() override;
+
+const char *
+

[Lldb-commits] [PATCH] D13335: [LLDB][MIPS] Skip invalid size watchpoint testcase for MIPS

2015-10-01 Thread Mohit Bhakkad via lldb-commits

mohit.bhakkad created this revision.
mohit.bhakkad added a reviewer: jaydeep.
mohit.bhakkad added a subscriber: lldb-commits.
mohit.bhakkad set the repository for this revision to rL LLVM.

There is no hard constraint on MIPS hardware watches, so skipping this test.

Repository:
  rL LLVM

http://reviews.llvm.org/D13335

Files:
  test/python_api/watchpoint/watchlocation/TestTargetWatchAddress.py

Index: test/python_api/watchpoint/watchlocation/TestTargetWatchAddress.py
===
--- test/python_api/watchpoint/watchlocation/TestTargetWatchAddress.py
+++ test/python_api/watchpoint/watchlocation/TestTargetWatchAddress.py
@@ -87,6 +87,7 @@
 
 @python_api_test
 @expectedFailureAndroid(archs=['arm', 'aarch64']) # Watchpoints not 
supported
+@skipIf(archs=['mips', 'mipsel', 'mips64', 'mips64el']) # No size 
constraint on MIPS for watches
 def test_watch_address_with_invalid_watch_size(self):
 """Exercise SBTarget.WatchAddress() API but pass an invalid 
watch_size."""
 self.build()


Index: test/python_api/watchpoint/watchlocation/TestTargetWatchAddress.py
===
--- test/python_api/watchpoint/watchlocation/TestTargetWatchAddress.py
+++ test/python_api/watchpoint/watchlocation/TestTargetWatchAddress.py
@@ -87,6 +87,7 @@
 
 @python_api_test
 @expectedFailureAndroid(archs=['arm', 'aarch64']) # Watchpoints not supported
+@skipIf(archs=['mips', 'mipsel', 'mips64', 'mips64el']) # No size constraint on MIPS for watches
 def test_watch_address_with_invalid_watch_size(self):
 """Exercise SBTarget.WatchAddress() API but pass an invalid watch_size."""
 self.build()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D13334: Preliminary NetBSD support

2015-10-01 Thread Pavel Labath via lldb-commits

labath added subscribers: emaste, labath.


Comment at: source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp:1
@@ +1,2 @@
+//===-- PlatformNetBSD.cpp -*- C++ -*-===//
+//

This platform code looks like it was copy-pasted from PlatformFreeBSD. Do you 
anticipate making significant changes here?

If not, it might be a good idea to share this code with FreeBSD in some way (in 
fact there is a comment here to make this share code with PlatformPOSIX). 
@emaste, what do you think about this?


Repository:
  rL LLVM

http://reviews.llvm.org/D13334



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

Re: [Lldb-commits] [PATCH] D13334: Preliminary NetBSD support

2015-10-01 Thread Kamil Rytarowski via lldb-commits

krytarowski added a comment.

Primary reason to skip for now build scripts is that this patch takes long to 
be landed.

http://reviews.llvm.org/D12994

I don't want to submit a diff to patches sources...


Repository:
  rL LLVM

http://reviews.llvm.org/D13334



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

Re: [Lldb-commits] [PATCH] D13334: Preliminary NetBSD support

2015-10-01 Thread Kamil Rytarowski via lldb-commits

krytarowski added inline comments.


Comment at: source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp:1
@@ +1,2 @@
+//===-- PlatformNetBSD.cpp -*- C++ -*-===//
+//

labath wrote:
> This platform code looks like it was copy-pasted from PlatformFreeBSD. Do you 
> anticipate making significant changes here?
> 
> If not, it might be a good idea to share this code with FreeBSD in some way 
> (in fact there is a comment here to make this share code with PlatformPOSIX). 
> @emaste, what do you think about this?
Yes... however I have bad experiences (mostly in Gnome) when we drag common 
code for rotted platforms like BSD4.4, BSD/OS and such in a single source tree 
paralyzing sane platform support.


Repository:
  rL LLVM

http://reviews.llvm.org/D13334



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

Re: [Lldb-commits] [PATCH] D13334: Preliminary NetBSD support

2015-10-01 Thread Pavel Labath via lldb-commits

labath added inline comments.

Comment at: source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp:1
@@ +1,2 @@
+//===-- PlatformNetBSD.cpp -*- C++ -*-===//
+//

krytarowski wrote:
> labath wrote:
> > This platform code looks like it was copy-pasted from PlatformFreeBSD. Do 
> > you anticipate making significant changes here?
> > 
> > If not, it might be a good idea to share this code with FreeBSD in some way 
> > (in fact there is a comment here to make this share code with 
> > PlatformPOSIX). @emaste, what do you think about this?
> Yes... however I have bad experiences (mostly in Gnome) when we drag common 
> code for rotted platforms like BSD4.4, BSD/OS and such in a single source 
> tree paralyzing sane platform support.
So which one do you expect to rot first ?

Joke aside, I agree that this could be an issue, but I think if we put some 
thought into the design, we can limit the possible downsides of this approach. 
The other alternative, where we copy everything is not ideal either: we have 
had cases in the past, where we made a change in linux code, and then we needed 
to apply the exact same change in the freebsd version. So there is definitely 
some tradeoff to consider here...

In any case, I'm not trying to stop your changes because of this, but I think 
it's good to open this discussion in the early stages of the implementation... 
I don't know if you're aware but there are plans to move freebsd to the 
client-server model to follow linux, so if you make copies of the code, you may 
find out later that you may need to duplicate that work as well.

Repository:
  rL LLVM

http://reviews.llvm.org/D13334

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

Re: [Lldb-commits] [PATCH] D13334: Preliminary NetBSD support

2015-10-01 Thread Kamil Rytarowski via lldb-commits

krytarowski added inline comments.


Comment at: source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp:1
@@ +1,2 @@
+//===-- PlatformNetBSD.cpp -*- C++ -*-===//
+//

labath wrote:
> krytarowski wrote:
> > labath wrote:
> > > This platform code looks like it was copy-pasted from PlatformFreeBSD. Do 
> > > you anticipate making significant changes here?
> > > 
> > > If not, it might be a good idea to share this code with FreeBSD in some 
> > > way (in fact there is a comment here to make this share code with 
> > > PlatformPOSIX). @emaste, what do you think about this?
> > Yes... however I have bad experiences (mostly in Gnome) when we drag common 
> > code for rotted platforms like BSD4.4, BSD/OS and such in a single source 
> > tree paralyzing sane platform support.
> So which one do you expect to rot first ?
> 
> Joke aside, I agree that this could be an issue, but I think if we put some 
> thought into the design, we can limit the possible downsides of this 
> approach. The other alternative, where we copy everything is not ideal 
> either: we have had cases in the past, where we made a change in linux code, 
> and then we needed to apply the exact same change in the freebsd version. So 
> there is definitely some tradeoff to consider here...
> 
> In any case, I'm not trying to stop your changes because of this, but I think 
> it's good to open this discussion in the early stages of the 
> implementation... I don't know if you're aware but there are plans to move 
> freebsd to the client-server model to follow linux, so if you make copies of 
> the code, you may find out later that you may need to duplicate that work as 
> well.
I'm strongly for this to design and put common BSD code (for modern BSDs) into 
single library or module, limiting Free/Net specific pieces to their 
appropriate modules.

My requirement is to name the common parts as BSD, not FreeBSD. NetBSD isn't a 
variation of FreeBSD (neither e.g. Bitrig, which may come next -- there is 
already an active interest).

I was thinking how to do it, with virtual functions, inheritance, #ifdef 
magic... To make it clear, I don't use nor have FreeBSD to lonely 
design/redesign neither touch its platform support, therefor I request for 
active cooperation from the FreeBSD side.


Repository:
  rL LLVM

http://reviews.llvm.org/D13334



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

[Lldb-commits] [lldb] r249012 - Restrict the scope of a hack in DYLDRendezvous

2015-10-01 Thread Tamas Berghammer via lldb-commits

Author: tberghammer
Date: Thu Oct  1 08:57:54 2015
New Revision: 249012

URL: http://llvm.org/viewvc/llvm-project?rev=249012&view=rev
Log:
Restrict the scope of a hack in DYLDRendezvous

The hack is there to work around an incorrect load address reported
by the android linker on API 21 and 22 devices. This CL restricts the
hack to those android API levels.

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

Modified:
lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h

Modified: lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp?rev=249012&r1=249011&r2=249012&view=diff
==
--- lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp 
(original)
+++ lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp Thu 
Oct  1 08:57:54 2015
@@ -17,6 +17,7 @@
 #include "lldb/Symbol/ObjectFile.h"
 #include "lldb/Symbol/Symbol.h"
 #include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Target/Platform.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/Target.h"
 
@@ -372,6 +373,25 @@ DYLDRendezvous::ReadStringFromMemory(add
 return str;
 }
 
+// Returns true if the load bias reported by the linker is incorrect for the 
given entry. This
+// function is used to handle cases where we want to work around a bug in the 
system linker.
+static bool
+isLoadBiasIncorrect(Target& target, const std::string& file_path)
+{
+// On Android L (API 21, 22) the load address of the "/system/bin/linker" 
isn't filled in
+// correctly.
+uint32_t os_major = 0, os_minor = 0, os_update = 0;
+if (target.GetArchitecture().GetTriple().getEnvironment() == 
llvm::Triple::Android &&
+target.GetPlatform()->GetOSVersion(os_major, os_minor, os_update) &&
+(os_major == 21 || os_major == 22) &&
+(file_path == "/system/bin/linker" || file_path == 
"/system/bin/linker64"))
+{
+return true;
+}
+
+return false;
+}
+
 bool
 DYLDRendezvous::ReadSOEntryFromMemory(lldb::addr_t addr, SOEntry &entry)
 {
@@ -413,11 +433,9 @@ DYLDRendezvous::ReadSOEntryFromMemory(ll
 std::string file_path = ReadStringFromMemory(entry.path_addr);
 entry.file_spec.SetFile(file_path, false);
 
-// On Android L (5.0, 5.1) the load address of the "/system/bin/linker" 
isn't filled in
-// correctly. To get the correct load address we fetch the load address of 
the file from the
-// proc file system.
-if (arch.GetTriple().getEnvironment() == llvm::Triple::Android && 
entry.base_addr == 0 &&
-(file_path == "/system/bin/linker" || file_path == 
"/system/bin/linker64"))
+// If the load bias reported by the linker is incorrect then fetch the 
load address of the file
+// from the proc file system.
+if (isLoadBiasIncorrect(m_process->GetTarget(), file_path))
 {
 lldb::addr_t load_addr = LLDB_INVALID_ADDRESS;
 bool is_loaded = false;

Modified: lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp?rev=249012&r1=249011&r2=249012&view=diff
==
--- lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp (original)
+++ lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp Thu Oct  1 
08:57:54 2015
@@ -362,3 +362,12 @@ PlatformAndroid::DownloadSymbolFile (con
 // Download the symbolfile from the remote device
 return GetFile(symfile_platform_filespec, dst_file_spec);
 }
+
+bool
+PlatformAndroid::GetRemoteOSVersion ()
+{
+m_major_os_version = GetSdkVersion();
+m_minor_os_version = 0;
+m_update_os_version = 0;
+return m_major_os_version != 0;
+}

Modified: lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h?rev=249012&r1=249011&r2=249012&view=diff
==
--- lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h (original)
+++ lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h Thu Oct  1 
08:57:54 2015
@@ -76,7 +76,10 @@ namespace platform_android {
 
 uint32_t
 GetSdkVersion();
-
+
+bool
+GetRemoteOSVersion() override;
+
 Error
 DisconnectRemote () override;
 


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

[Lldb-commits] [lldb] r249014 - Fix Android-SDK detection on API 10 device

2015-10-01 Thread Tamas Berghammer via lldb-commits

Author: tberghammer
Date: Thu Oct  1 08:58:01 2015
New Revision: 249014

URL: http://llvm.org/viewvc/llvm-project?rev=249014&view=rev
Log:
Fix Android-SDK detection on API 10 device

Run the getprop command with AdbClient::Shell instead of
Platform::RunShellCommand because getting the output from getprop
with Platform::RunShellCommand have some (currently unknown) issues.

Modified:
lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp

Modified: lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp?rev=249014&r1=249013&r2=249014&view=diff
==
--- lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp (original)
+++ lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp Thu Oct  1 
08:58:01 2015
@@ -283,23 +283,19 @@ PlatformAndroid::GetSdkVersion()
 if (m_sdk_version != 0)
 return m_sdk_version;
 
-int status = 0;
 std::string version_string;
-Error error = RunShellCommand("getprop ro.build.version.sdk",
-  GetWorkingDirectory(),
-  &status,
-  nullptr,
-  &version_string,
-  1);
-if (error.Fail() || status != 0 || version_string.empty())
+AdbClient adb(m_device_id);
+Error error = adb.Shell("getprop ro.build.version.sdk", 5000 /* ms */, 
&version_string);
+version_string = llvm::StringRef(version_string).trim().str();
+
+if (error.Fail() || version_string.empty())
 {
 Log* log = GetLogIfAllCategoriesSet(LIBLLDB_LOG_PLATFORM);
 if (log)
-log->Printf("Get SDK version failed. (status: %d, error: %s, 
output: %s)",
-status, error.AsCString(), version_string.c_str());
+log->Printf("Get SDK version failed. (error: %s, output: %s)",
+error.AsCString(), version_string.c_str());
 return 0;
 }
-version_string.erase(version_string.size() - 1); // Remove trailing new 
line
 
 m_sdk_version = StringConvert::ToUInt32(version_string.c_str());
 return m_sdk_version;


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

[Lldb-commits] [lldb] r249013 - Fix breakpoint opcode calculation on Linux

2015-10-01 Thread Tamas Berghammer via lldb-commits

Author: tberghammer
Date: Thu Oct  1 08:57:57 2015
New Revision: 249013

URL: http://llvm.org/viewvc/llvm-project?rev=249013&view=rev
Log:
Fix breakpoint opcode calculation on Linux

Change the way we detect if we have to place a thumb breakpoint instead
of an arm breakpoint in the case when no symbol table or mapping symbols
are available. Detect it based on the LSB of the FileAddress instead of
the LSB of the LoadAddress because the LSB of the LoadAddress is already
masked out.

Modified:
lldb/trunk/source/Plugins/Platform/Linux/PlatformLinux.cpp

Modified: lldb/trunk/source/Plugins/Platform/Linux/PlatformLinux.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/Linux/PlatformLinux.cpp?rev=249013&r1=249012&r2=249013&view=diff
==
--- lldb/trunk/source/Plugins/Platform/Linux/PlatformLinux.cpp (original)
+++ lldb/trunk/source/Plugins/Platform/Linux/PlatformLinux.cpp Thu Oct  1 
08:57:57 2015
@@ -575,10 +575,17 @@ PlatformLinux::GetSoftwareBreakpointTrap
 AddressClass addr_class = eAddressClassUnknown;
 
 if (bp_loc_sp)
+{
 addr_class = bp_loc_sp->GetAddress ().GetAddressClass ();
 
-if (addr_class == eAddressClassCodeAlternateISA
-|| (addr_class == eAddressClassUnknown && 
(bp_site->GetLoadAddress() & 1)))
+if (addr_class == eAddressClassUnknown &&
+(bp_loc_sp->GetAddress ().GetFileAddress () & 1))
+{
+addr_class = eAddressClassCodeAlternateISA;
+}
+}
+
+if (addr_class == eAddressClassCodeAlternateISA)
 {
 trap_opcode = g_thumb_breakpoint_opcode;
 trap_opcode_size = sizeof(g_thumb_breakpoint_opcode);


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

Re: [Lldb-commits] [PATCH] D13288: Restrict the scope of a hack in DYLDRendezvous

2015-10-01 Thread Tamas Berghammer via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL249012: Restrict the scope of a hack in DYLDRendezvous 
(authored by tberghammer).

Changed prior to commit:
  http://reviews.llvm.org/D13288?vs=36097&id=36240#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D13288

Files:
  lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
  lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
  lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h

Index: lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h
===
--- lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h
+++ lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h
@@ -76,7 +76,10 @@
 
 uint32_t
 GetSdkVersion();
-
+
+bool
+GetRemoteOSVersion() override;
+
 Error
 DisconnectRemote () override;
 
Index: lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
===
--- lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
+++ lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
@@ -362,3 +362,12 @@
 // Download the symbolfile from the remote device
 return GetFile(symfile_platform_filespec, dst_file_spec);
 }
+
+bool
+PlatformAndroid::GetRemoteOSVersion ()
+{
+m_major_os_version = GetSdkVersion();
+m_minor_os_version = 0;
+m_update_os_version = 0;
+return m_major_os_version != 0;
+}
Index: lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
===
--- lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
+++ lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
@@ -17,6 +17,7 @@
 #include "lldb/Symbol/ObjectFile.h"
 #include "lldb/Symbol/Symbol.h"
 #include "lldb/Symbol/SymbolContext.h"
+#include "lldb/Target/Platform.h"
 #include "lldb/Target/Process.h"
 #include "lldb/Target/Target.h"
 
@@ -372,6 +373,25 @@
 return str;
 }
 
+// Returns true if the load bias reported by the linker is incorrect for the 
given entry. This
+// function is used to handle cases where we want to work around a bug in the 
system linker.
+static bool
+isLoadBiasIncorrect(Target& target, const std::string& file_path)
+{
+// On Android L (API 21, 22) the load address of the "/system/bin/linker" 
isn't filled in
+// correctly.
+uint32_t os_major = 0, os_minor = 0, os_update = 0;
+if (target.GetArchitecture().GetTriple().getEnvironment() == 
llvm::Triple::Android &&
+target.GetPlatform()->GetOSVersion(os_major, os_minor, os_update) &&
+(os_major == 21 || os_major == 22) &&
+(file_path == "/system/bin/linker" || file_path == 
"/system/bin/linker64"))
+{
+return true;
+}
+
+return false;
+}
+
 bool
 DYLDRendezvous::ReadSOEntryFromMemory(lldb::addr_t addr, SOEntry &entry)
 {
@@ -413,11 +433,9 @@
 std::string file_path = ReadStringFromMemory(entry.path_addr);
 entry.file_spec.SetFile(file_path, false);
 
-// On Android L (5.0, 5.1) the load address of the "/system/bin/linker" 
isn't filled in
-// correctly. To get the correct load address we fetch the load address of 
the file from the
-// proc file system.
-if (arch.GetTriple().getEnvironment() == llvm::Triple::Android && 
entry.base_addr == 0 &&
-(file_path == "/system/bin/linker" || file_path == 
"/system/bin/linker64"))
+// If the load bias reported by the linker is incorrect then fetch the 
load address of the file
+// from the proc file system.
+if (isLoadBiasIncorrect(m_process->GetTarget(), file_path))
 {
 lldb::addr_t load_addr = LLDB_INVALID_ADDRESS;
 bool is_loaded = false;


Index: lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h
===
--- lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h
+++ lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.h
@@ -76,7 +76,10 @@
 
 uint32_t
 GetSdkVersion();
-
+
+bool
+GetRemoteOSVersion() override;
+
 Error
 DisconnectRemote () override;
 
Index: lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
===
--- lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
+++ lldb/trunk/source/Plugins/Platform/Android/PlatformAndroid.cpp
@@ -362,3 +362,12 @@
 // Download the symbolfile from the remote device
 return GetFile(symfile_platform_filespec, dst_file_spec);
 }
+
+bool
+PlatformAndroid::GetRemoteOSVersion ()
+{
+m_major_os_version = GetSdkVersion();
+m_minor_os_version = 0;
+m_update_os_version = 0;
+return m_major_os_version != 0;
+}
Index: lldb/trunk/source/Plugins/Dy

Re: [Lldb-commits] [PATCH] D13334: Preliminary NetBSD support

2015-10-01 Thread Pavel Labath via lldb-commits

labath added inline comments.


Comment at: source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp:1
@@ +1,2 @@
+//===-- PlatformNetBSD.cpp -*- C++ -*-===//
+//

krytarowski wrote:
> labath wrote:
> > krytarowski wrote:
> > > labath wrote:
> > > > This platform code looks like it was copy-pasted from PlatformFreeBSD. 
> > > > Do you anticipate making significant changes here?
> > > > 
> > > > If not, it might be a good idea to share this code with FreeBSD in some 
> > > > way (in fact there is a comment here to make this share code with 
> > > > PlatformPOSIX). @emaste, what do you think about this?
> > > Yes... however I have bad experiences (mostly in Gnome) when we drag 
> > > common code for rotted platforms like BSD4.4, BSD/OS and such in a single 
> > > source tree paralyzing sane platform support.
> > So which one do you expect to rot first ?
> > 
> > Joke aside, I agree that this could be an issue, but I think if we put some 
> > thought into the design, we can limit the possible downsides of this 
> > approach. The other alternative, where we copy everything is not ideal 
> > either: we have had cases in the past, where we made a change in linux 
> > code, and then we needed to apply the exact same change in the freebsd 
> > version. So there is definitely some tradeoff to consider here...
> > 
> > In any case, I'm not trying to stop your changes because of this, but I 
> > think it's good to open this discussion in the early stages of the 
> > implementation... I don't know if you're aware but there are plans to move 
> > freebsd to the client-server model to follow linux, so if you make copies 
> > of the code, you may find out later that you may need to duplicate that 
> > work as well.
> I'm strongly for this to design and put common BSD code (for modern BSDs) 
> into single library or module, limiting Free/Net specific pieces to their 
> appropriate modules.
> 
> My requirement is to name the common parts as BSD, not FreeBSD. NetBSD isn't 
> a variation of FreeBSD (neither e.g. Bitrig, which may come next -- there is 
> already an active interest).
> 
> I was thinking how to do it, with virtual functions, inheritance, #ifdef 
> magic... To make it clear, I don't use nor have FreeBSD to lonely 
> design/redesign neither touch its platform support, therefor I request for 
> active cooperation from the FreeBSD side.
>I'm strongly for this to design and put common BSD code (for modern BSDs) into 
>single library or module, limiting Free/Net specific pieces to their 
>appropriate modules.

>My requirement is to name the common parts as BSD, not FreeBSD. NetBSD isn't a 
>variation of FreeBSD (neither e.g. Bitrig, which may come next -- there is 
>already an active interest).

Sounds reasonable to me.

> I was thinking how to do it, with virtual functions, inheritance, #ifdef 
> magic...
LLDB is a cross-platform tool, we can already remotely debug linux from windows 
and mac machines, etc. It would be great if this would eventually work for BSD 
platforms as well. For this, we need both freebsd and netbsd code in a single 
client binary, so #ifdefs are ruled out (at least in client code). But I think 
inheritance is perfect for this particular case of PlatformNetBSD -- just move 
the code to PlatformBSD and have Free/NetBSD inherit from that.

> To make it clear, I don't use nor have FreeBSD to lonely design/redesign 
> neither touch its platform support, therefor I request for active cooperation 
> from the FreeBSD side.
Let's see what FreeBSD has to say to this. :)


Repository:
  rL LLVM

http://reviews.llvm.org/D13334



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

[Lldb-commits] [lldb] r249020 - [LLDB][MIPS] Fix gp register value for o32 applications on 64-bit target

2015-10-01 Thread Sagar Thakur via lldb-commits

Author: slthakur
Date: Thu Oct  1 10:05:31 2015
New Revision: 249020

URL: http://llvm.org/viewvc/llvm-project?rev=249020&view=rev
Log:
[LLDB][MIPS] Fix gp register value for o32 applications on 64-bit target

GP registers for o32 applications were always giving zero value because 
SetType() on the RegisterValue was causing the accessor functions to pickup the 
value from m_scalar of RegisterValue which is zero.
In this patch byte size and byte order of register value is set at the time of 
setting the value of the register.


Modified:
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp

lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp

Modified: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp?rev=249020&r1=249019&r2=249020&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp Thu Oct  1 
10:05:31 2015
@@ -2206,6 +2206,8 @@ ObjectFileELF::ParseSymbols (Symtab *sym
 mangled.SetDemangledName( ConstString((demangled_name + 
suffix).str()) );
 }
 
+printf("Symbol: name=%s, Type:%d value=%08lx\n", symbol_name, 
symbol_type, symbol.st_value);
+
 Symbol dc_symbol(
 i + start_id,   // ID is the original symbol table index.
 mangled,

Modified: 
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp?rev=249020&r1=249019&r2=249020&view=diff
==
--- 
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp 
(original)
+++ 
lldb/trunk/source/Plugins/Process/Linux/NativeRegisterContextLinux_mips64.cpp 
Thu Oct  1 10:05:31 2015
@@ -623,13 +623,6 @@ NativeRegisterContextLinux_mips64::ReadR
 else
 {
 error = ReadRegisterRaw(reg, reg_value);
-if (error.Success())
-{
-// If our return byte size was greater than the return value reg 
size, then
-// use the type specified by reg_info rather than the uint64_t 
default
-if (reg_value.GetByteSize() > reg_info->byte_size)
-reg_value.SetType(reg_info);
-}
 }
 
 return error;
@@ -1387,7 +1380,7 @@ NativeRegisterContextLinux_mips64::DoRea
 {
 lldb_private::ArchSpec arch;
 if (m_thread.GetProcess()->GetArchitecture(arch))
-value.SetBytes((void *)(((unsigned char *)(®s)) + offset), 8, 
arch.GetByteOrder());
+value.SetBytes((void *)(((unsigned char *)®s) + offset + 4 * 
(arch.GetMachine() == llvm::Triple::mips)), arch.GetAddressByteSize(), 
arch.GetByteOrder());
 else
 error.SetErrorString("failed to get architecture");
 }


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

Re: [Lldb-commits] [lldb] r249020 - [LLDB][MIPS] Fix gp register value for o32 applications on 64-bit target

2015-10-01 Thread Pavel Labath via lldb-commits

On 1 October 2015 at 16:05, Sagar Thakur via lldb-commits
 wrote:
> +printf("Symbol: name=%s, Type:%d value=%08lx\n", symbol_name, 
> symbol_type, symbol.st_value);
> +

You seem to have left a debugging statement in. :)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r249021 - Romove accidentially added statement in r249020

2015-10-01 Thread Sagar Thakur via lldb-commits

Author: slthakur
Date: Thu Oct  1 10:15:42 2015
New Revision: 249021

URL: http://llvm.org/viewvc/llvm-project?rev=249021&view=rev
Log:
Romove accidentially added statement in r249020

Modified:
lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp

Modified: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp?rev=249021&r1=249020&r2=249021&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp Thu Oct  1 
10:15:42 2015
@@ -2206,8 +2206,6 @@ ObjectFileELF::ParseSymbols (Symtab *sym
 mangled.SetDemangledName( ConstString((demangled_name + 
suffix).str()) );
 }
 
-printf("Symbol: name=%s, Type:%d value=%08lx\n", symbol_name, 
symbol_type, symbol.st_value);
-
 Symbol dc_symbol(
 i + start_id,   // ID is the original symbol table index.
 mangled,


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

Re: [Lldb-commits] [PATCH] D13334: Preliminary NetBSD support

2015-10-01 Thread Kamil Rytarowski via lldb-commits

krytarowski added inline comments.


Comment at: source/Plugins/Platform/NetBSD/PlatformNetBSD.cpp:1
@@ +1,2 @@
+//===-- PlatformNetBSD.cpp -*- C++ -*-===//
+//

labath wrote:
> krytarowski wrote:
> > labath wrote:
> > > krytarowski wrote:
> > > > labath wrote:
> > > > > This platform code looks like it was copy-pasted from 
> > > > > PlatformFreeBSD. Do you anticipate making significant changes here?
> > > > > 
> > > > > If not, it might be a good idea to share this code with FreeBSD in 
> > > > > some way (in fact there is a comment here to make this share code 
> > > > > with PlatformPOSIX). @emaste, what do you think about this?
> > > > Yes... however I have bad experiences (mostly in Gnome) when we drag 
> > > > common code for rotted platforms like BSD4.4, BSD/OS and such in a 
> > > > single source tree paralyzing sane platform support.
> > > So which one do you expect to rot first ?
> > > 
> > > Joke aside, I agree that this could be an issue, but I think if we put 
> > > some thought into the design, we can limit the possible downsides of this 
> > > approach. The other alternative, where we copy everything is not ideal 
> > > either: we have had cases in the past, where we made a change in linux 
> > > code, and then we needed to apply the exact same change in the freebsd 
> > > version. So there is definitely some tradeoff to consider here...
> > > 
> > > In any case, I'm not trying to stop your changes because of this, but I 
> > > think it's good to open this discussion in the early stages of the 
> > > implementation... I don't know if you're aware but there are plans to 
> > > move freebsd to the client-server model to follow linux, so if you make 
> > > copies of the code, you may find out later that you may need to duplicate 
> > > that work as well.
> > I'm strongly for this to design and put common BSD code (for modern BSDs) 
> > into single library or module, limiting Free/Net specific pieces to their 
> > appropriate modules.
> > 
> > My requirement is to name the common parts as BSD, not FreeBSD. NetBSD 
> > isn't a variation of FreeBSD (neither e.g. Bitrig, which may come next -- 
> > there is already an active interest).
> > 
> > I was thinking how to do it, with virtual functions, inheritance, #ifdef 
> > magic... To make it clear, I don't use nor have FreeBSD to lonely 
> > design/redesign neither touch its platform support, therefor I request for 
> > active cooperation from the FreeBSD side.
> >I'm strongly for this to design and put common BSD code (for modern BSDs) 
> >into single library or module, limiting Free/Net specific pieces to their 
> >appropriate modules.
> 
> >My requirement is to name the common parts as BSD, not FreeBSD. NetBSD isn't 
> >a variation of FreeBSD (neither e.g. Bitrig, which may come next -- there is 
> >already an active interest).
> 
> Sounds reasonable to me.
> 
> > I was thinking how to do it, with virtual functions, inheritance, #ifdef 
> > magic...
> LLDB is a cross-platform tool, we can already remotely debug linux from 
> windows and mac machines, etc. It would be great if this would eventually 
> work for BSD platforms as well. For this, we need both freebsd and netbsd 
> code in a single client binary, so #ifdefs are ruled out (at least in client 
> code). But I think inheritance is perfect for this particular case of 
> PlatformNetBSD -- just move the code to PlatformBSD and have Free/NetBSD 
> inherit from that.
> 
> > To make it clear, I don't use nor have FreeBSD to lonely design/redesign 
> > neither touch its platform support, therefor I request for active 
> > cooperation from the FreeBSD side.
> Let's see what FreeBSD has to say to this. :)
> LLDB is a cross-platform tool, we can already remotely debug linux from 
> windows and mac machines, etc. It would be great if this would eventually 
> work for BSD platforms as well.

Sounds great!

> Let's see what FreeBSD has to say to this. :)

I opened the offer from my site. The code is already there. I'm waiting for the 
feedback.


Repository:
  rL LLVM

http://reviews.llvm.org/D13334



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

[Lldb-commits] [PATCH] D13350: [lldb] Fix evaluation of global variables

2015-10-01 Thread Eugene Leviant via lldb-commits

evgeny777 created this revision.
evgeny777 added reviewers: clayborg, paulherman.
evgeny777 added subscribers: lldb-commits, KLapshin.

Current revision contains bug, related to evaluation of global variables. 
Imagine you have the following code

```
int _g = 1;
int func(void) {
int _g = 2;
return _g; // BP here and evaluate ::_g
}
```
evaluation of ::_g will return 2, while the correct value is 1

Another example:


```
namespace test {
int test_var = 1;
}

int test_var = 2;
int func(void) {
 using namespace test;
 return ::test_var;  // BP here and try to evaluate ::test_var
}

```
Evaluation will return error (multiple candidates), while correct behaviour is 
to return '2'

http://reviews.llvm.org/D13350

Files:
  clang/include/clang/AST/DeclBase.h
  clang/lib/Sema/SemaLookup.cpp
  lldb/include/lldb/Symbol/ClangASTContext.h
  lldb/include/lldb/Symbol/CompilerDeclContext.h
  lldb/include/lldb/Symbol/TypeSystem.h
  lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
  lldb/source/Symbol/ClangASTContext.cpp
  lldb/source/Symbol/CompilerDeclContext.cpp

Index: lldb/source/Symbol/CompilerDeclContext.cpp
===
--- lldb/source/Symbol/CompilerDeclContext.cpp
+++ lldb/source/Symbol/CompilerDeclContext.cpp
@@ -15,12 +15,13 @@
 using namespace lldb_private;
 
 std::vector
-CompilerDeclContext::FindDeclByName (ConstString name)
+CompilerDeclContext::FindDeclByName (ConstString name, const clang::DeclContext* lookupCtx)
 {
 std::vector found_decls;
 if (IsValid())
 {
-std::vector found_opaque_decls = m_type_system->DeclContextFindDeclByName(m_opaque_decl_ctx, name);
+std::vector found_opaque_decls =
+m_type_system->DeclContextFindDeclByNameEx(m_opaque_decl_ctx, name, (void*)lookupCtx);
 for (void *opaque_decl : found_opaque_decls)
 found_decls.push_back(CompilerDecl(m_type_system, opaque_decl));
 }
Index: lldb/source/Symbol/ClangASTContext.cpp
===
--- lldb/source/Symbol/ClangASTContext.cpp
+++ lldb/source/Symbol/ClangASTContext.cpp
@@ -8975,9 +8975,24 @@
 // CompilerDeclContext functions
 //--
 
+static inline bool
+NamedDeclDoesQualify (NamedDecl* nd, const DeclContext* lookupCtx)
+{
+if(lookupCtx == nullptr || lookupCtx->shouldUseQualifiedLookup() == false)
+return true;
+return nd->getLexicalDeclContext()->getDeclKind() == lookupCtx->getDeclKind();
+}
+
 std::vector
 ClangASTContext::DeclContextFindDeclByName(void *opaque_decl_ctx, ConstString name)
 {
+return DeclContextFindDeclByNameEx(opaque_decl_ctx, name, nullptr);
+}
+
+std::vector
+ClangASTContext::DeclContextFindDeclByNameEx (void *opaque_decl_ctx, ConstString name, void* extra)
+{
+const DeclContext* lookupCtx = (const DeclContext*)(extra);
 std::vector found_decls;
 if (opaque_decl_ctx)
 {
@@ -9011,16 +9026,24 @@
 if (clang::NamedDecl *nd = llvm::dyn_cast(target))
 {
 IdentifierInfo *ii = nd->getIdentifier();
-if (ii != nullptr && ii->getName().equals(name.AsCString(nullptr)))
+if (ii != nullptr &&
+ii->getName().equals(name.AsCString(nullptr)) &&
+NamedDeclDoesQualify(nd, lookupCtx))
+{
 found_decls.push_back(nd);
+}
 }
 }
 }
 else if (clang::NamedDecl *nd = llvm::dyn_cast(child))
 {
 IdentifierInfo *ii = nd->getIdentifier();
-if (ii != nullptr && ii->getName().equals(name.AsCString(nullptr)))
+if (ii != nullptr &&
+ii->getName().equals(name.AsCString(nullptr)) &&
+NamedDeclDoesQualify(nd, lookupCtx))
+{
 found_decls.push_back(nd);
+}
 }
 }
 }
Index: lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
===
--- lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
+++ lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
@@ -1366,7 +1366,8 @@
 vars->GetVariableAtIndex(i)->GetDecl();
 
 // Search for declarations matching the name
-std::vector found_decls = compiler_decl_context.FindDeclByName(name);
+std::vector found_decls =
+compiler_decl_context.Fi

Re: [Lldb-commits] [PATCH] D13350: [lldb] Fix evaluation of global variables

2015-10-01 Thread Pavel Labath via lldb-commits

labath added a subscriber: labath.
labath added a comment.

Could you please put the examples you cite above into the test suite?


http://reviews.llvm.org/D13350



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

Re: [Lldb-commits] [lldb] r249020 - [LLDB][MIPS] Fix gp register value for o32 applications on 64-bit target

2015-10-01 Thread Zachary Turner via lldb-commits

Would be great if you had a test for this (if it simply fixes an existing
broken test, then you should mention that in the patch summary so you don't
get these emails from me in the future :))

On Thu, Oct 1, 2015 at 8:10 AM Pavel Labath via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> On 1 October 2015 at 16:05, Sagar Thakur via lldb-commits
>  wrote:
> > +printf("Symbol: name=%s, Type:%d value=%08lx\n", symbol_name,
> symbol_type, symbol.st_value);
> > +
>
> You seem to have left a debugging statement in. :)
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D13350: [lldb] Fix evaluation of qualified global variables

2015-10-01 Thread Zachary Turner via lldb-commits

zturner added a subscriber: zturner.
zturner added a comment.

In http://reviews.llvm.org/D13350#257676, @labath wrote:

> Could you please put the examples you cite above into the test suite?


Agreed, please make a test for this.


http://reviews.llvm.org/D13350



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

[Lldb-commits] [lldb] r249027 - Made Target hold a map of languages to TypeSystems, and added some accessors.

2015-10-01 Thread Sean Callanan via lldb-commits

Author: spyffe
Date: Thu Oct  1 11:28:02 2015
New Revision: 249027

URL: http://llvm.org/viewvc/llvm-project?rev=249027&view=rev
Log:
Made Target hold a map of languages to TypeSystems, and added some accessors.
Also added some target-level search functions so that persistent variables and
symbols can be searched for without hand-iterating across the map of
TypeSystems.

Modified:
lldb/trunk/include/lldb/Target/Target.h
lldb/trunk/source/Commands/CommandObjectMemory.cpp
lldb/trunk/source/Core/ValueObject.cpp
lldb/trunk/source/Expression/UserExpression.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
lldb/trunk/source/Target/ABI.cpp
lldb/trunk/source/Target/Target.cpp

Modified: lldb/trunk/include/lldb/Target/Target.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Target.h?rev=249027&r1=249026&r2=249027&view=diff
==
--- lldb/trunk/include/lldb/Target/Target.h (original)
+++ lldb/trunk/include/lldb/Target/Target.h Thu Oct  1 11:28:02 2015
@@ -1231,6 +1231,9 @@ public:
 TypeSystem *
 GetScratchTypeSystemForLanguage (lldb::LanguageType language, bool 
create_on_demand = true);
 
+PersistentExpressionState *
+GetPersistentExpressionStateForLanguage (lldb::LanguageType language);
+
 // Creates a UserExpression for the given language, the rest of the 
parameters have the
 // same meaning as for the UserExpression constructor.
 // Returns a new-ed object which the caller owns.
@@ -1322,6 +1325,9 @@ public:
 lldb::ExpressionVariableSP
 GetPersistentVariable(const ConstString &name);
 
+lldb::addr_t
+GetPersistentSymbol(const ConstString &name);
+
 //--
 // Target Stop Hooks
 //--
@@ -1499,6 +1505,9 @@ public:
 GetSearchFilterForModuleAndCUList (const FileSpecList *containingModules, 
const FileSpecList *containingSourceFiles);
 
 protected:
+ClangASTContext *
+GetScratchClangASTContextImpl();
+
 //--
 // Member variables.
 //--
@@ -1519,7 +1528,10 @@ protected:
 lldb::ProcessSP m_process_sp;
 lldb::SearchFilterSP  m_search_filter_sp;
 PathMappingList m_image_search_paths;
-lldb::ClangASTContextUP m_scratch_ast_context_ap;
+
+typedef std::map TypeSystemMap;
+TypeSystemMap m_scratch_type_system_map;
+
 lldb::ClangASTSourceUP m_scratch_ast_source_ap;
 lldb::ClangASTImporterUP m_ast_importer_ap;
 lldb::ClangModulesDeclVendorUP m_clang_modules_decl_vendor_ap;

Modified: lldb/trunk/source/Commands/CommandObjectMemory.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectMemory.cpp?rev=249027&r1=249026&r2=249027&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectMemory.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectMemory.cpp Thu Oct  1 11:28:02 2015
@@ -530,10 +530,14 @@ protected:
 
 if (type_list.GetSize() == 0 && lookup_type_name.GetCString() && 
*lookup_type_name.GetCString() == '$')
 {
-clang::TypeDecl *tdecl = 
llvm::cast(target->GetScratchTypeSystemForLanguage(lldb::eLanguageTypeC)->GetPersistentExpressionState())->GetPersistentType(ConstString(lookup_type_name));
-if (tdecl)
+if (ClangPersistentVariables *persistent_vars = 
llvm::dyn_cast_or_null(target->GetPersistentExpressionStateForLanguage(lldb::eLanguageTypeC)))
 {
-
clang_ast_type.SetCompilerType(ClangASTContext::GetASTContext(&tdecl->getASTContext()),(const
 lldb::opaque_compiler_type_t)tdecl->getTypeForDecl());
+clang::TypeDecl *tdecl = 
persistent_vars->GetPersistentType(ConstString(lookup_type_name));
+
+if (tdecl)
+{
+
clang_ast_type.SetCompilerType(ClangASTContext::GetASTContext(&tdecl->getASTContext()),(const
 lldb::opaque_compiler_type_t)tdecl->getTypeForDecl());
+}
 }
 }
 

Modified: lldb/trunk/source/Core/ValueObject.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ValueObject.cpp?rev=249027&r1=249026&r2=249027&view=diff
==
--- lldb/trunk/source/Core/ValueObject.cpp (orig

Re: [Lldb-commits] [lldb] r249013 - Fix breakpoint opcode calculation on Linux

2015-10-01 Thread Zachary Turner via lldb-commits

Seems like it should be possible to write a test for this.

On Thu, Oct 1, 2015 at 6:59 AM Tamas Berghammer via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: tberghammer
> Date: Thu Oct  1 08:57:57 2015
> New Revision: 249013
>
> URL: http://llvm.org/viewvc/llvm-project?rev=249013&view=rev
> Log:
> Fix breakpoint opcode calculation on Linux
>
> Change the way we detect if we have to place a thumb breakpoint instead
> of an arm breakpoint in the case when no symbol table or mapping symbols
> are available. Detect it based on the LSB of the FileAddress instead of
> the LSB of the LoadAddress because the LSB of the LoadAddress is already
> masked out.
>
> Modified:
> lldb/trunk/source/Plugins/Platform/Linux/PlatformLinux.cpp
>
> Modified: lldb/trunk/source/Plugins/Platform/Linux/PlatformLinux.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Platform/Linux/PlatformLinux.cpp?rev=249013&r1=249012&r2=249013&view=diff
>
> ==
> --- lldb/trunk/source/Plugins/Platform/Linux/PlatformLinux.cpp (original)
> +++ lldb/trunk/source/Plugins/Platform/Linux/PlatformLinux.cpp Thu Oct  1
> 08:57:57 2015
> @@ -575,10 +575,17 @@ PlatformLinux::GetSoftwareBreakpointTrap
>  AddressClass addr_class = eAddressClassUnknown;
>
>  if (bp_loc_sp)
> +{
>  addr_class = bp_loc_sp->GetAddress ().GetAddressClass ();
>
> -if (addr_class == eAddressClassCodeAlternateISA
> -|| (addr_class == eAddressClassUnknown &&
> (bp_site->GetLoadAddress() & 1)))
> +if (addr_class == eAddressClassUnknown &&
> +(bp_loc_sp->GetAddress ().GetFileAddress () & 1))
> +{
> +addr_class = eAddressClassCodeAlternateISA;
> +}
> +}
> +
> +if (addr_class == eAddressClassCodeAlternateISA)
>  {
>  trap_opcode = g_thumb_breakpoint_opcode;
>  trap_opcode_size = sizeof(g_thumb_breakpoint_opcode);
>
>
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D13350: [lldb] Fix evaluation of qualified global variables

2015-10-01 Thread Siva Chandra via lldb-commits

sivachandra added a subscriber: sivachandra.
sivachandra added a comment.

Also, this patch has changes in clang. There should be a clang reviewer I think 
[unless I am unaware something here.]


http://reviews.llvm.org/D13350



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

Re: [Lldb-commits] [PATCH] D13350: [lldb] Fix evaluation of qualified global variables

2015-10-01 Thread Zachary Turner via lldb-commits

zturner added a comment.

Good point.  The two patches should actually be separate, and you will need a 
separate set of tests for the clang patch.


http://reviews.llvm.org/D13350



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

Re: [Lldb-commits] [PATCH] D13350: [lldb] Fix evaluation of qualified global variables

2015-10-01 Thread Eugene Leviant via lldb-commits

evgeny777 added a comment.

Thanks for your comments. I will certainly add the test cases to lldb. I was 
just curious if this is correct way of fixing the issue. Besides test case what 
else has to be done? Separate review for changes in clang linked to this review?


http://reviews.llvm.org/D13350



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

[Lldb-commits] [lldb] r249039 - Removed a mutex guard that I accidentally pasted in from other code.

2015-10-01 Thread Sean Callanan via lldb-commits

Author: spyffe
Date: Thu Oct  1 12:48:25 2015
New Revision: 249039

URL: http://llvm.org/viewvc/llvm-project?rev=249039&view=rev
Log:
Removed a mutex guard that I accidentally pasted in from other code.
It was causing deadlocks when stepping out.

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

Modified: lldb/trunk/source/Target/Target.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Target.cpp?rev=249039&r1=249038&r2=249039&view=diff
==
--- lldb/trunk/source/Target/Target.cpp (original)
+++ lldb/trunk/source/Target/Target.cpp Thu Oct  1 12:48:25 2015
@@ -1892,8 +1892,6 @@ Target::ImageSearchPathsChanged
 TypeSystem *
 Target::GetScratchTypeSystemForLanguage (lldb::LanguageType language, bool 
create_on_demand)
 {
-Mutex::Locker locker (m_mutex);
-
 if (language == eLanguageTypeMipsAssembler // GNU AS and LLVM use it for 
all assembly code
 || language == eLanguageTypeUnknown) {
 language = eLanguageTypeC;


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

Re: [Lldb-commits] [PATCH] D13323: Use %HOME%/.lldb/module_cache as a default module cache directory

2015-10-01 Thread Oleksiy Vyalov via lldb-commits

ovyalov closed this revision.
ovyalov added a comment.

Users:

  ovyalov (Author)

http://reviews.llvm.org/rL249040


http://reviews.llvm.org/D13323



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

Re: [Lldb-commits] [PATCH] D13350: [lldb] Fix evaluation of qualified global variables

2015-10-01 Thread Siva Chandra via lldb-commits

sivachandra added a comment.

I suppose you should first post a separate self contained clang patch to the 
clang list. After landing it in clang, you should post an LLDB specific patch 
here.

About its correctness, I cannot comment on the clang changes. Commenting on the 
LLDB changes are probably meaningful after the clang change lands.


http://reviews.llvm.org/D13350



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

[Lldb-commits] [lldb] r249040 - Use %HOME%/.lldb/module_cache as a default module cache directory.

2015-10-01 Thread Oleksiy Vyalov via lldb-commits

Author: ovyalov
Date: Thu Oct  1 12:48:57 2015
New Revision: 249040

URL: http://llvm.org/viewvc/llvm-project?rev=249040&view=rev
Log:
Use %HOME%/.lldb/module_cache as a default module cache directory.

http://reviews.llvm.org/D13323


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

Modified: lldb/trunk/source/Target/Platform.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Target/Platform.cpp?rev=249040&r1=249039&r2=249040&view=diff
==
--- lldb/trunk/source/Target/Platform.cpp (original)
+++ lldb/trunk/source/Target/Platform.cpp Thu Oct  1 12:48:57 2015
@@ -39,9 +39,11 @@
 #include "lldb/Target/UnixSignals.h"
 #include "lldb/Utility/Utils.h"
 #include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Path.h"
 
 #include "Utility/ModuleCache.h"
 
+
 // Define these constants from POSIX mman.h rather than include the file
 // so that they will be correct even when compiled on Linux.
 #define MAP_PRIVATE 2
@@ -99,13 +101,17 @@ PlatformProperties::PlatformProperties (
 m_collection_sp->Initialize (g_properties);
 
 auto module_cache_dir = GetModuleCacheDirectory ();
-if (!module_cache_dir)
-{
-if (!HostInfo::GetLLDBPath (ePathTypeGlobalLLDBTempSystemDir, 
module_cache_dir))
-module_cache_dir = FileSpec ("/tmp/lldb", false);
-module_cache_dir.AppendPathComponent ("module_cache");
-SetModuleCacheDirectory (module_cache_dir);
-}
+if (module_cache_dir)
+return;
+
+llvm::SmallString<64> user_home_dir;
+if (!llvm::sys::path::home_directory (user_home_dir))
+return;
+
+module_cache_dir = FileSpec (user_home_dir.c_str(), false);
+module_cache_dir.AppendPathComponent (".lldb");
+module_cache_dir.AppendPathComponent ("module_cache");
+SetModuleCacheDirectory (module_cache_dir);
 }
 
 bool
@@ -1847,7 +1853,8 @@ Platform::GetCachedSharedModule (const M
  bool *did_create_ptr)
 {
 if (IsHost() ||
-!GetGlobalPlatformProperties ()->GetUseModuleCache ())
+!GetGlobalPlatformProperties ()->GetUseModuleCache () ||
+!GetGlobalPlatformProperties ()->GetModuleCacheDirectory ())
 return false;
 
 Log *log = GetLogIfAnyCategoriesSet (LIBLLDB_LOG_PLATFORM);


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

Re: [Lldb-commits] [lldb] r248934 - Now persistent expression data no longer lives with the Target, but rather with

2015-10-01 Thread Ryan Brown via lldb-commits

Shouldn't Target::GetPersistentVariable take a language parameter instead
of assuming clang?

On Wed, Sep 30, 2015 at 12:59 PM Sean Callanan via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: spyffe
> Date: Wed Sep 30 14:57:57 2015
> New Revision: 248934
>
> URL: http://llvm.org/viewvc/llvm-project?rev=248934&view=rev
> Log:
> Now persistent expression data no longer lives with the Target, but rather
> with
> the corresponding TypeSystem.  This makes sense because what kind of data
> there
> is -- and how it can be looked up -- depends on the language.
>
> Functionality that is common to all type systems is factored out into
> PersistentExpressionState.
>
> Modified:
> lldb/trunk/include/lldb/Expression/ExpressionVariable.h
> lldb/trunk/include/lldb/Symbol/ClangASTContext.h
> lldb/trunk/include/lldb/Symbol/TypeSystem.h
> lldb/trunk/include/lldb/Target/Target.h
> lldb/trunk/include/lldb/lldb-forward.h
> lldb/trunk/source/API/SBFrame.cpp
> lldb/trunk/source/Commands/CommandObjectMemory.cpp
> lldb/trunk/source/Core/ValueObject.cpp
> lldb/trunk/source/Expression/ExpressionSourceCode.cpp
> lldb/trunk/source/Expression/ExpressionVariable.cpp
> lldb/trunk/source/Expression/Materializer.cpp
> lldb/trunk/source/Expression/UserExpression.cpp
>
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
>
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
>
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
>
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.cpp
>
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.h
>
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
> lldb/trunk/source/Symbol/ClangASTContext.cpp
> lldb/trunk/source/Target/ABI.cpp
> lldb/trunk/source/Target/Target.cpp
>
> Modified: lldb/trunk/include/lldb/Expression/ExpressionVariable.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/ExpressionVariable.h?rev=248934&r1=248933&r2=248934&view=diff
>
> ==
> --- lldb/trunk/include/lldb/Expression/ExpressionVariable.h (original)
> +++ lldb/trunk/include/lldb/Expression/ExpressionVariable.h Wed Sep 30
> 14:57:57 2015
> @@ -265,6 +265,36 @@ private:
>  std::vector  m_variables;
>  };
>
> +class PersistentExpressionState : public ExpressionVariableList {
> +public:
> +
> //--
> +// See TypeSystem.h for how to add subclasses to this.
> +
> //--
> +enum LLVMCastKind {
> +eKindClang,
> +eKindSwift,
> +eKindGo,
> +kNumKinds
> +};
> +
> +LLVMCastKind getKind() const { return m_kind; }
> +
> +PersistentExpressionState(LLVMCastKind kind) :
> +m_kind(kind)
> +{
> +}
> +
> +virtual ~PersistentExpressionState ();
> +
> +virtual ConstString
> +GetNextPersistentVariableName () = 0;
> +
> +virtual void
> +RemovePersistentVariable (lldb::ExpressionVariableSP variable) = 0;
> +private:
> +LLVMCastKind m_kind;
> +};
> +
>  }
>
>  #endif /* liblldb_ExpressionVariable_h_ */
>
> Modified: lldb/trunk/include/lldb/Symbol/ClangASTContext.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/ClangASTContext.h?rev=248934&r1=248933&r2=248934&view=diff
>
> ==
> --- lldb/trunk/include/lldb/Symbol/ClangASTContext.h (original)
> +++ lldb/trunk/include/lldb/Symbol/ClangASTContext.h Wed Sep 30 14:57:57
> 2015
> @@ -20,6 +20,8 @@
>  #include 
>
>  // Other libraries and framework includes
> +#include "ClangPersistentVariables.h"
> +
>  #include "llvm/ADT/SmallVector.h"
>  #include "clang/AST/ASTContext.h"
>  #include "clang/AST/TemplateBase.h"
> @@ -1188,8 +1190,12 @@ public:
>
>  UtilityFunction *
>  GetUtilityFunction(const char *text, const char *name) override;
> +
> +PersistentExpressionState *
> +GetPersistentExpressionState() override;
>  private:
>  lldb::TargetWP m_target_wp;
> +lldb::ClangPersistentVariablesUP m_persistent_variables;  ///<
> These are the persistent variables associated with this process for the
> expression parser.
>  };
>
>  } // namespace lldb_private
>
> Modified: lldb/trunk/include/lldb/Symbol/TypeSystem.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/TypeSystem.h?rev=248934&r1=248933&r2=248934&view=diff
>
> ==
> --- lldb/trunk/include/lldb/Symbol/TypeSystem.h (original)
> +++ lldb/trunk/include/lldb/Symbol/TypeSystem.h Wed Sep 30 14:57:57 2015
> @@ -504,6 +504,12 @@ public:
>  return nullptr;
>  }
>
> +virtual Per

Re: [Lldb-commits] [lldb] r248934 - Now persistent expression data no longer lives with the Target, but rather with

2015-10-01 Thread Ryan Brown via lldb-commits

Oh, now I see the search in 249027.
But how does this work with multiple type systems?
Target no longer manages persistent variable names so won't each type
system generate conflicting names?
e.g.
(lldb) expr -l c -- 1
$1 = 1
(lldb) expr -l go -- 2
$1 = 2
(lldb) expr -l go -- $1

Which $1 do you get?


On Thu, Oct 1, 2015 at 10:59 AM Ryan Brown  wrote:

> Shouldn't Target::GetPersistentVariable take a language parameter instead
> of assuming clang?
>
> On Wed, Sep 30, 2015 at 12:59 PM Sean Callanan via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: spyffe
>> Date: Wed Sep 30 14:57:57 2015
>> New Revision: 248934
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=248934&view=rev
>> Log:
>> Now persistent expression data no longer lives with the Target, but
>> rather with
>> the corresponding TypeSystem.  This makes sense because what kind of data
>> there
>> is -- and how it can be looked up -- depends on the language.
>>
>> Functionality that is common to all type systems is factored out into
>> PersistentExpressionState.
>>
>> Modified:
>> lldb/trunk/include/lldb/Expression/ExpressionVariable.h
>> lldb/trunk/include/lldb/Symbol/ClangASTContext.h
>> lldb/trunk/include/lldb/Symbol/TypeSystem.h
>> lldb/trunk/include/lldb/Target/Target.h
>> lldb/trunk/include/lldb/lldb-forward.h
>> lldb/trunk/source/API/SBFrame.cpp
>> lldb/trunk/source/Commands/CommandObjectMemory.cpp
>> lldb/trunk/source/Core/ValueObject.cpp
>> lldb/trunk/source/Expression/ExpressionSourceCode.cpp
>> lldb/trunk/source/Expression/ExpressionVariable.cpp
>> lldb/trunk/source/Expression/Materializer.cpp
>> lldb/trunk/source/Expression/UserExpression.cpp
>>
>> lldb/trunk/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
>>
>> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
>>
>> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
>>
>> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.cpp
>>
>> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.h
>>
>> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
>> lldb/trunk/source/Symbol/ClangASTContext.cpp
>> lldb/trunk/source/Target/ABI.cpp
>> lldb/trunk/source/Target/Target.cpp
>>
>> Modified: lldb/trunk/include/lldb/Expression/ExpressionVariable.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/ExpressionVariable.h?rev=248934&r1=248933&r2=248934&view=diff
>>
>> ==
>> --- lldb/trunk/include/lldb/Expression/ExpressionVariable.h (original)
>> +++ lldb/trunk/include/lldb/Expression/ExpressionVariable.h Wed Sep 30
>> 14:57:57 2015
>> @@ -265,6 +265,36 @@ private:
>>  std::vector  m_variables;
>>  };
>>
>> +class PersistentExpressionState : public ExpressionVariableList {
>> +public:
>> +
>> //--
>> +// See TypeSystem.h for how to add subclasses to this.
>> +
>> //--
>> +enum LLVMCastKind {
>> +eKindClang,
>> +eKindSwift,
>> +eKindGo,
>> +kNumKinds
>> +};
>> +
>> +LLVMCastKind getKind() const { return m_kind; }
>> +
>> +PersistentExpressionState(LLVMCastKind kind) :
>> +m_kind(kind)
>> +{
>> +}
>> +
>> +virtual ~PersistentExpressionState ();
>> +
>> +virtual ConstString
>> +GetNextPersistentVariableName () = 0;
>> +
>> +virtual void
>> +RemovePersistentVariable (lldb::ExpressionVariableSP variable) = 0;
>> +private:
>> +LLVMCastKind m_kind;
>> +};
>> +
>>  }
>>
>>  #endif /* liblldb_ExpressionVariable_h_ */
>>
>> Modified: lldb/trunk/include/lldb/Symbol/ClangASTContext.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/ClangASTContext.h?rev=248934&r1=248933&r2=248934&view=diff
>>
>> ==
>> --- lldb/trunk/include/lldb/Symbol/ClangASTContext.h (original)
>> +++ lldb/trunk/include/lldb/Symbol/ClangASTContext.h Wed Sep 30 14:57:57
>> 2015
>> @@ -20,6 +20,8 @@
>>  #include 
>>
>>  // Other libraries and framework includes
>> +#include "ClangPersistentVariables.h"
>> +
>>  #include "llvm/ADT/SmallVector.h"
>>  #include "clang/AST/ASTContext.h"
>>  #include "clang/AST/TemplateBase.h"
>> @@ -1188,8 +1190,12 @@ public:
>>
>>  UtilityFunction *
>>  GetUtilityFunction(const char *text, const char *name) override;
>> +
>> +PersistentExpressionState *
>> +GetPersistentExpressionState() override;
>>  private:
>>  lldb::TargetWP m_target_wp;
>> +lldb::ClangPersistentVariablesUP m_persistent_variables;  ///<
>> These are the persistent variables associated with this process for the
>> expression parser.
>>  };
>>
>>  } // namespace lldb_private
>>
>

[Lldb-commits] [lldb] r249047 - Add a 'type lookup' command. This command is meant to look up type information by name in a language-specific way.

2015-10-01 Thread Enrico Granata via lldb-commits

Author: enrico
Date: Thu Oct  1 13:16:18 2015
New Revision: 249047

URL: http://llvm.org/viewvc/llvm-project?rev=249047&view=rev
Log:
Add a 'type lookup' command. This command is meant to look up type information 
by name in a language-specific way.

Currently, it only supports Objective-C - C++ types can be looked up through 
debug info via 'image lookup -t', whereas ObjC types via this command are 
looked up by runtime introspection

This behavior is in line with type lookup's behavior in Xcode 7, but I am 
definitely open to feedback as to what makes the most sense here


Modified:
lldb/trunk/include/lldb/Target/Language.h
lldb/trunk/source/Commands/CommandObjectType.cpp
lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp
lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.h
lldb/trunk/source/Target/Language.cpp

Modified: lldb/trunk/include/lldb/Target/Language.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Language.h?rev=249047&r1=249046&r2=249047&view=diff
==
--- lldb/trunk/include/lldb/Target/Language.h (original)
+++ lldb/trunk/include/lldb/Target/Language.h Thu Oct  1 13:16:18 2015
@@ -13,6 +13,8 @@
 // C Includes
 // C++ Includes
 #include 
+#include 
+#include 
 #include 
 
 // Other libraries and framework includes
@@ -29,6 +31,42 @@ class Language :
 public PluginInterface
 {
 public:
+
+class TypeScavenger
+{
+public:
+class Result
+{
+public:
+virtual bool
+IsValid () = 0;
+
+virtual bool
+DumpToStream (Stream& stream,
+  bool print_help_if_available) = 0;
+
+virtual ~Result() = default;
+};
+
+typedef std::set> ResultSet;
+
+virtual ~TypeScavenger () = default;
+
+size_t
+Find (ExecutionContextScope *exe_scope,
+  const char *key,
+  ResultSet &results,
+  bool append = true);
+
+protected:
+TypeScavenger () = default;
+
+virtual bool
+Find_Impl (ExecutionContextScope *exe_scope,
+   const char *key,
+   ResultSet &results) = 0;
+};
+
 ~Language() override;
 
 static Language*
@@ -65,6 +103,9 @@ public:
 virtual lldb_private::formatters::StringPrinter::EscapingHelper
 GetStringPrinterEscapingHelper 
(lldb_private::formatters::StringPrinter::GetPrintableElementType);
 
+virtual std::unique_ptr
+GetTypeScavenger ();
+
 // These are accessors for general information about the Languages lldb 
knows about:
 
 static lldb::LanguageType
@@ -91,7 +132,6 @@ public:
 
 static bool
 LanguageIsPascal (lldb::LanguageType language);
-
 
 protected:
 //--

Modified: lldb/trunk/source/Commands/CommandObjectType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectType.cpp?rev=249047&r1=249046&r2=249047&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectType.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectType.cpp Thu Oct  1 13:16:18 2015
@@ -4558,6 +4558,218 @@ CommandObjectTypeFilterAdd::CommandOptio
 { 0, false, NULL, 0, 0, NULL, NULL, 0, eArgTypeNone, NULL }
 };
 
+//--
+// "type lookup"
+//--
+class CommandObjectTypeLookup : public CommandObjectRaw
+{
+protected:
+
+class CommandOptions : public OptionGroup
+{
+public:
+
+CommandOptions () :
+OptionGroup(),
+m_show_help(false),
+m_language(eLanguageTypeUnknown)
+{}
+
+virtual
+~CommandOptions () {}
+
+virtual uint32_t
+GetNumDefinitions ()
+{
+return 3;
+}
+
+virtual const OptionDefinition*
+GetDefinitions ()
+{
+return g_option_table;
+}
+
+virtual Error
+SetOptionValue (CommandInterpreter &interpreter,
+uint32_t option_idx,
+const char *option_value)
+{
+Error error;
+
+const int short_option = g_option_table[option_idx].short_option;
+
+switch (short_option)
+{
+case 'h':
+m_show_help = true;
+break;
+
+case 'l':
+m_language = 
Language::GetLanguageTypeFromString(option_value);
+break;
+
+default:
+

Re: [Lldb-commits] [lldb] r248934 - Now persistent expression data no longer lives with the Target, but rather with

2015-10-01 Thread Enrico Granata via lldb-commits

The way I understand this from talking with Sean about it is that the 
persistent variables for each type system will need to generate non-conflicting 
names

In your example,

(lldb) expr -l c — 1
$1 = 1
(lldb) expr -l go — 2
$G1 = 2
(lldb) expr -l go — $1
Identifier ‘$1’ not recognized (or whatever equivalent error Go would produce, 
unless you had somehow gotten Go and Clang to interop with each other in a 
smart way)

But that is simply my understanding

> On Oct 1, 2015, at 11:15 AM, Ryan Brown via lldb-commits 
>  wrote:
> 
> Oh, now I see the search in 249027.
> But how does this work with multiple type systems?
> Target no longer manages persistent variable names so won't each type system 
> generate conflicting names? 
> e.g.
> (lldb) expr -l c -- 1
> $1 = 1
> (lldb) expr -l go -- 2
> $1 = 2
> (lldb) expr -l go -- $1
> 
> Which $1 do you get?
> 
> 
> On Thu, Oct 1, 2015 at 10:59 AM Ryan Brown  > wrote:
> Shouldn't Target::GetPersistentVariable take a language parameter instead of 
> assuming clang?
> 
> On Wed, Sep 30, 2015 at 12:59 PM Sean Callanan via lldb-commits 
> mailto:lldb-commits@lists.llvm.org>> wrote:
> Author: spyffe
> Date: Wed Sep 30 14:57:57 2015
> New Revision: 248934
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=248934&view=rev 
> 
> Log:
> Now persistent expression data no longer lives with the Target, but rather 
> with
> the corresponding TypeSystem.  This makes sense because what kind of data 
> there
> is -- and how it can be looked up -- depends on the language.
> 
> Functionality that is common to all type systems is factored out into
> PersistentExpressionState.
> 
> Modified:
> lldb/trunk/include/lldb/Expression/ExpressionVariable.h
> lldb/trunk/include/lldb/Symbol/ClangASTContext.h
> lldb/trunk/include/lldb/Symbol/TypeSystem.h
> lldb/trunk/include/lldb/Target/Target.h
> lldb/trunk/include/lldb/lldb-forward.h
> lldb/trunk/source/API/SBFrame.cpp
> lldb/trunk/source/Commands/CommandObjectMemory.cpp
> lldb/trunk/source/Core/ValueObject.cpp
> lldb/trunk/source/Expression/ExpressionSourceCode.cpp
> lldb/trunk/source/Expression/ExpressionVariable.cpp
> lldb/trunk/source/Expression/Materializer.cpp
> lldb/trunk/source/Expression/UserExpression.cpp
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp
> 
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
> 
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.cpp
> 
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.h
> lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
> lldb/trunk/source/Symbol/ClangASTContext.cpp
> lldb/trunk/source/Target/ABI.cpp
> lldb/trunk/source/Target/Target.cpp
> 
> Modified: lldb/trunk/include/lldb/Expression/ExpressionVariable.h
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/ExpressionVariable.h?rev=248934&r1=248933&r2=248934&view=diff
>  
> 
> ==
> --- lldb/trunk/include/lldb/Expression/ExpressionVariable.h (original)
> +++ lldb/trunk/include/lldb/Expression/ExpressionVariable.h Wed Sep 30 
> 14:57:57 2015
> @@ -265,6 +265,36 @@ private:
>  std::vector  m_variables;
>  };
> 
> +class PersistentExpressionState : public ExpressionVariableList {
> +public:
> +//--
> +// See TypeSystem.h for how to add subclasses to this.
> +//--
> +enum LLVMCastKind {
> +eKindClang,
> +eKindSwift,
> +eKindGo,
> +kNumKinds
> +};
> +
> +LLVMCastKind getKind() const { return m_kind; }
> +
> +PersistentExpressionState(LLVMCastKind kind) :
> +m_kind(kind)
> +{
> +}
> +
> +virtual ~PersistentExpressionState ();
> +
> +virtual ConstString
> +GetNextPersistentVariableName () = 0;
> +
> +virtual void
> +RemovePersistentVariable (lldb::ExpressionVariableSP variable) = 0;
> +private:
> +LLVMCastKind m_kind;
> +};
> +
>  }
> 
>  #endif /* liblldb_ExpressionVariable_h_ */
> 
> Modified: lldb/trunk/include/lldb/Symbol/ClangASTContext.h
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/ClangASTContext.h?rev=248934&r1=248933&r2=248934&view=diff
>  
> 
> ==
> --- lldb/trunk/in

Re: [Lldb-commits] [PATCH] D12968: Fix for lldb-mi crash in Listener code if -exec-abort MI command was invoked without getting process stopped

2015-10-01 Thread Kirill Lapshin via lldb-commits

KLapshin added a comment.

@labath,

Regarding how to reproduce - this problem looks remote target specific only - 
in my case gdb-remote modules involved.


Repository:
  rL LLVM

http://reviews.llvm.org/D12968



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

[Lldb-commits] [lldb] r249055 - Fix Android build after r249047.

2015-10-01 Thread Oleksiy Vyalov via lldb-commits

Author: ovyalov
Date: Thu Oct  1 14:08:00 2015
New Revision: 249055

URL: http://llvm.org/viewvc/llvm-project?rev=249055&view=rev
Log:
Fix Android build after r249047.


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

Modified: lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp?rev=249055&r1=249054&r2=249055&view=diff
==
--- lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp (original)
+++ lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp Thu Oct  1 
14:08:00 2015
@@ -739,7 +739,7 @@ ObjCLanguage::GetTypeScavenger ()
 return result;
 }
 
-friend class ObjCLanguage;
+friend class lldb_private::ObjCLanguage;
 };
 
 return std::unique_ptr(new ObjCTypeScavenger());


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

Re: [Lldb-commits] [lldb] r249047 - Add a 'type lookup' command. This command is meant to look up type information by name in a language-specific way.

2015-10-01 Thread Zachary Turner via lldb-commits

Hi Enrico,

Could you add some tests for this?  python API tests and appropriate
methods added to SBTarget would be ideal.

On Thu, Oct 1, 2015 at 11:17 AM Enrico Granata via lldb-commits <
lldb-commits@lists.llvm.org> wrote:

> Author: enrico
> Date: Thu Oct  1 13:16:18 2015
> New Revision: 249047
>
> URL: http://llvm.org/viewvc/llvm-project?rev=249047&view=rev
> Log:
> Add a 'type lookup' command. This command is meant to look up type
> information by name in a language-specific way.
>
> Currently, it only supports Objective-C - C++ types can be looked up
> through debug info via 'image lookup -t', whereas ObjC types via this
> command are looked up by runtime introspection
>
> This behavior is in line with type lookup's behavior in Xcode 7, but I am
> definitely open to feedback as to what makes the most sense here
>
>
> Modified:
> lldb/trunk/include/lldb/Target/Language.h
> lldb/trunk/source/Commands/CommandObjectType.cpp
> lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp
> lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.h
> lldb/trunk/source/Target/Language.cpp
>
> Modified: lldb/trunk/include/lldb/Target/Language.h
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Language.h?rev=249047&r1=249046&r2=249047&view=diff
>
> ==
> --- lldb/trunk/include/lldb/Target/Language.h (original)
> +++ lldb/trunk/include/lldb/Target/Language.h Thu Oct  1 13:16:18 2015
> @@ -13,6 +13,8 @@
>  // C Includes
>  // C++ Includes
>  #include 
> +#include 
> +#include 
>  #include 
>
>  // Other libraries and framework includes
> @@ -29,6 +31,42 @@ class Language :
>  public PluginInterface
>  {
>  public:
> +
> +class TypeScavenger
> +{
> +public:
> +class Result
> +{
> +public:
> +virtual bool
> +IsValid () = 0;
> +
> +virtual bool
> +DumpToStream (Stream& stream,
> +  bool print_help_if_available) = 0;
> +
> +virtual ~Result() = default;
> +};
> +
> +typedef std::set> ResultSet;
> +
> +virtual ~TypeScavenger () = default;
> +
> +size_t
> +Find (ExecutionContextScope *exe_scope,
> +  const char *key,
> +  ResultSet &results,
> +  bool append = true);
> +
> +protected:
> +TypeScavenger () = default;
> +
> +virtual bool
> +Find_Impl (ExecutionContextScope *exe_scope,
> +   const char *key,
> +   ResultSet &results) = 0;
> +};
> +
>  ~Language() override;
>
>  static Language*
> @@ -65,6 +103,9 @@ public:
>  virtual lldb_private::formatters::StringPrinter::EscapingHelper
>  GetStringPrinterEscapingHelper
> (lldb_private::formatters::StringPrinter::GetPrintableElementType);
>
> +virtual std::unique_ptr
> +GetTypeScavenger ();
> +
>  // These are accessors for general information about the Languages
> lldb knows about:
>
>  static lldb::LanguageType
> @@ -91,7 +132,6 @@ public:
>
>  static bool
>  LanguageIsPascal (lldb::LanguageType language);
> -
>
>  protected:
>  //--
>
> Modified: lldb/trunk/source/Commands/CommandObjectType.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectType.cpp?rev=249047&r1=249046&r2=249047&view=diff
>
> ==
> --- lldb/trunk/source/Commands/CommandObjectType.cpp (original)
> +++ lldb/trunk/source/Commands/CommandObjectType.cpp Thu Oct  1 13:16:18
> 2015
> @@ -4558,6 +4558,218 @@ CommandObjectTypeFilterAdd::CommandOptio
>  { 0, false, NULL, 0, 0, NULL, NULL, 0, eArgTypeNone, NULL }
>  };
>
> +//--
> +// "type lookup"
> +//--
> +class CommandObjectTypeLookup : public CommandObjectRaw
> +{
> +protected:
> +
> +class CommandOptions : public OptionGroup
> +{
> +public:
> +
> +CommandOptions () :
> +OptionGroup(),
> +m_show_help(false),
> +m_language(eLanguageTypeUnknown)
> +{}
> +
> +virtual
> +~CommandOptions () {}
> +
> +virtual uint32_t
> +GetNumDefinitions ()
> +{
> +return 3;
> +}
> +
> +virtual const OptionDefinition*
> +GetDefinitions ()
> +{
> +return g_option_table;
> +}
> +
> +virtual Error
> +SetOptionValue (CommandInterpreter &interpreter,
> +uint32_t option_idx,
> +const char *option_value)
> +{
> +Error error;
> +
> +const int short_option =
> g_option_table[option_idx].short_option;
> +
> +

Re: [Lldb-commits] [lldb] r248985 - Fixing a subtle issue on Mac OS X systems with dSYMs (possibly

2015-10-01 Thread Jason Molenda via lldb-commits

Thanks Pavel.  I'll read through the code and try to figure out what's 
happening here.

J

> On Oct 1, 2015, at 3:15 AM, Pavel Labath  wrote:
> 
> From one of the failing tests:
> ===
> runCmd: expr release_child_flag = 1
> output: (volatile int) $0 = 1
> 
> 
> Expecting sub string: = 1
> Matched
> 
> runCmd: print (int)getpgid(0)
> runCmd failed!
> error: use of undeclared identifier 'getpgid'
> error: 1 errors parsing expression
> ===
> 
> here, release_child_flag is in the inferior (and has debug info), and
> evaluating an expression with it works.
> getpgid is in libc (for which we only have .symtab), and lldb cannot
> find it for some reason.
> 
> hope that helps,
> pl
> 
> 
> On 1 October 2015 at 10:09, Pavel Labath  wrote:
>> Hi,
>> 
>> I have reverted this as it was causing many failures on our remote
>> android buildbots
>> .
>> I am hoping I will get a chance to investigate and give you a more
>> accurate error description by EOD (your morning). Given that the local
>> tests our working just fine, i suspect this has something to do with
>> paths.
>> 
>> pl
>> 
>> 
>> On 1 October 2015 at 07:09, Zachary Turner via lldb-commits
>>  wrote:
>>> Yea.  It's definitely hard to write a normal test case for this.  It's also
>>> a common problem when dealing with remote debugging scenarios.  It's both
>>> hard and resource demanding (needing to have just the right Host -> Target
>>> configuration available) to test that by going through the full debugging
>>> stack.  But it's often easy to write a test for a specific bug by finding
>>> the point of failure, and writing a simple unit test that verifies the
>>> inputs and outputs of a single method.
>>> 
>>> Many of LLDB's abstractions aren't designed to be able to handle this very
>>> well (for example, dependency injection is a common technique, but requires
>>> the functionality to be abstracted correctly to be able to inject mock
>>> interfaces), but there's no reason they couldn't be changed to be.
>>> 
>>> On Wed, Sep 30, 2015 at 11:03 PM Jason Molenda  wrote:
 
 Thanks for the idea Zachary, I haven't been following that.  I'll look at
 this tomorrow.  I was trying to imagine how to write a normal test case for
 this and it'd involve running a binary, deleting the binary off disk, then
 lldb attach to the process, letting it find a dSYM via spotlight which
 points to a copy of the binary in another location and there's another copy
 of the dSYM next to that binary. And I'd want to check that lldb stuck with
 the original dSYM that it found, instead of picking up the second dSYM
 sitting next to the binary.  It might be possible to replicate the behavior
 entirely self-hosted.  But it definitely only works on a mac because of the
 DebugSymbols private framework calls lldb makes while doing all of this.
 
 
> On Sep 30, 2015, at 10:58 PM, Zachary Turner  wrote:
> 
> This is a good example of where unit tests are useful.  There's already
> a small suite of unit tests but I'm going to start being proactive about
> growing it (in part by evangelizing it in response to people's commits 
> ;-).
> It's not integrated into the Xcode build, but it would certainly be easy 
> to
> do so.  The nice thing about a unit test is that you can set everything up
> exactly the way you need it and just call the one native code method you
> want to test, and verify the outputs.  You could make up your own
> ModuleSpec, you could make a mock implementation of `Symbols` that 
> delegates
> to the real `Symbols` implementation for everything except the part where 
> it
> checks if the file exists, and have that method simply return false so it
> goes to the fallback path, etc.
> 
> Anyway, just throwing this out there as an option.  This is MacOSX only
> code so it's not a huge priority for me to push it strongly, but if you
> think it would be useful I'm happy to help you figure out how to run them
> and/or write a new one.
> 
> On Wed, Sep 30, 2015 at 10:39 PM Jason Molenda via lldb-commits
>  wrote:
> Author: jmolenda
> Date: Thu Oct  1 00:37:22 2015
> New Revision: 248985
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=248985&view=rev
> Log:
> Fixing a subtle issue on Mac OS X systems with dSYMs (possibly
> introduced by r235737 but I didn't look into it too closely).
> 
> A dSYM can have a per-UUID plist in it which tells lldb where
> to find an executable binary for the dSYM (DBGSymbolRichExecutable)
> - other information can be included in this plist, like how to
> remap the source file paths from their build pathnames to their
> long-term storage pathnames.
> 
> This per-UUID plist is a unusual; it is used probably exclusively
> inside apple wit

Re: [Lldb-commits] [lldb] r249047 - Add a 'type lookup' command. This command is meant to look up type information by name in a language-specific way.

2015-10-01 Thread Enrico Granata via lldb-commits


> On Oct 1, 2015, at 12:49 PM, Zachary Turner  wrote:
> 
> Hi Enrico,
> 
> Could you add some tests for this?

Sure. I am still churning through a thing or two before declaring victory, but 
I can add tests as I make progress

>  python API tests and appropriate methods added to SBTarget

There currently is no SB API component to this. It is a purely command-line 
facility.
If you feel it would be useful to have SB API for this, it will need to be 
designed (e.g. “type lookup” is allowed to transact in things that are not 
strictly speaking compiler types - we have no API way to represent this kind of 
concept)

> would be ideal.
> 
> On Thu, Oct 1, 2015 at 11:17 AM Enrico Granata via lldb-commits 
> mailto:lldb-commits@lists.llvm.org>> wrote:
> Author: enrico
> Date: Thu Oct  1 13:16:18 2015
> New Revision: 249047
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=249047&view=rev 
> 
> Log:
> Add a 'type lookup' command. This command is meant to look up type 
> information by name in a language-specific way.
> 
> Currently, it only supports Objective-C - C++ types can be looked up through 
> debug info via 'image lookup -t', whereas ObjC types via this command are 
> looked up by runtime introspection
> 
> This behavior is in line with type lookup's behavior in Xcode 7, but I am 
> definitely open to feedback as to what makes the most sense here
> 
> 
> Modified:
> lldb/trunk/include/lldb/Target/Language.h
> lldb/trunk/source/Commands/CommandObjectType.cpp
> lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp
> lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.h
> lldb/trunk/source/Target/Language.cpp
> 
> Modified: lldb/trunk/include/lldb/Target/Language.h
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Language.h?rev=249047&r1=249046&r2=249047&view=diff
>  
> 
> ==
> --- lldb/trunk/include/lldb/Target/Language.h (original)
> +++ lldb/trunk/include/lldb/Target/Language.h Thu Oct  1 13:16:18 2015
> @@ -13,6 +13,8 @@
>  // C Includes
>  // C++ Includes
>  #include 
> +#include 
> +#include 
>  #include 
> 
>  // Other libraries and framework includes
> @@ -29,6 +31,42 @@ class Language :
>  public PluginInterface
>  {
>  public:
> +
> +class TypeScavenger
> +{
> +public:
> +class Result
> +{
> +public:
> +virtual bool
> +IsValid () = 0;
> +
> +virtual bool
> +DumpToStream (Stream& stream,
> +  bool print_help_if_available) = 0;
> +
> +virtual ~Result() = default;
> +};
> +
> +typedef std::set> ResultSet;
> +
> +virtual ~TypeScavenger () = default;
> +
> +size_t
> +Find (ExecutionContextScope *exe_scope,
> +  const char *key,
> +  ResultSet &results,
> +  bool append = true);
> +
> +protected:
> +TypeScavenger () = default;
> +
> +virtual bool
> +Find_Impl (ExecutionContextScope *exe_scope,
> +   const char *key,
> +   ResultSet &results) = 0;
> +};
> +
>  ~Language() override;
> 
>  static Language*
> @@ -65,6 +103,9 @@ public:
>  virtual lldb_private::formatters::StringPrinter::EscapingHelper
>  GetStringPrinterEscapingHelper 
> (lldb_private::formatters::StringPrinter::GetPrintableElementType);
> 
> +virtual std::unique_ptr
> +GetTypeScavenger ();
> +
>  // These are accessors for general information about the Languages lldb 
> knows about:
> 
>  static lldb::LanguageType
> @@ -91,7 +132,6 @@ public:
> 
>  static bool
>  LanguageIsPascal (lldb::LanguageType language);
> -
> 
>  protected:
>  //--
> 
> Modified: lldb/trunk/source/Commands/CommandObjectType.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectType.cpp?rev=249047&r1=249046&r2=249047&view=diff
>  
> 
> ==
> --- lldb/trunk/source/Commands/CommandObjectType.cpp (original)
> +++ lldb/trunk/source/Commands/CommandObjectType.cpp Thu Oct  1 13:16:18 2015
> @@ -4558,6 +4558,218 @@ CommandObjectTypeFilterAdd::CommandOptio
>  { 0, false, NULL, 0, 0, NULL, NULL, 0, eArgTypeNone, NULL }
>  };
> 
> +//--
> +// "type lookup"
> +//--
> +class CommandObjectTypeLookup : public CommandObjectRaw
> +{
> +protected:
> +
> +

[Lldb-commits] [PATCH] D13362: Enhance test runner timeout logic to detect successful completion of spawned process when stdout/stderr are shared to still-existing child processes

2015-10-01 Thread Todd Fiala via lldb-commits

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

This makes one of the internal process_control tests go green.  It covers the 
case where spawned process P1 itself spawns a child process C1, shared 
stdout/stderr file handles with C1, and then P1 terminates.

Prior to this change, we would end up timing out rather than detecting the 
immediate termination of P1 because we would wait for the stdout/stderr file 
handles to wrap up.

Now we wait on a condition variable that is set via a thread parked on 
subprocess.Popen.wait() and another on subprocess.Popen.communicate().  This 
allows us to catch the scenario above.  There's an additional thread (for the 
thread parked on wait()).  Both the wait() and the communicate() threads wait 
efficiently, so this should be minimal cost. 

http://reviews.llvm.org/D13362

Files:
  test/test_runner/lib/process_control.py
  test/test_runner/test/inferior.py
  test/test_runner/test/process_control_tests.py

Index: test/test_runner/test/process_control_tests.py
===
--- test/test_runner/test/process_control_tests.py
+++ test/test_runner/test/process_control_tests.py
@@ -14,7 +14,6 @@
 
 # System imports.
 import os
-import platform
 import unittest
 import sys
 import threading
@@ -27,9 +26,11 @@
 
 
 class TestInferiorDriver(process_control.ProcessDriver):
-def __init__(self, soft_terminate_timeout=None):
+def __init__(self, soft_terminate_timeout=5.0):
+# override the default
 super(TestInferiorDriver, self).__init__(
 soft_terminate_timeout=soft_terminate_timeout)
+
 self.started_event = threading.Event()
 self.started_event.clear()
 
@@ -105,10 +106,13 @@
 def test_run_completes_with_code(self):
 """Test that running completes and gets expected stdout/stderr."""
 driver = TestInferiorDriver()
-driver.run_command(self.inferior_command(options="-r10"))
+expected_returncode = 10
+driver.run_command(self.inferior_command(options="-r{}".format(
+expected_returncode)))
 self.assertTrue(
 driver.completed_event.wait(5), "process failed to complete")
-self.assertEqual(driver.returncode, 10, "return code does not match")
+self.assertIsNotNone(driver.returncode)
+self.assertEqual(driver.returncode, expected_returncode)
 
 
 class ProcessControlTimeoutTests(ProcessControlTests):
@@ -204,27 +208,30 @@
 """
 driver = TestInferiorDriver()
 
+timeout_seconds = 5
+return_code = 3
 # Create the inferior (I1), and instruct it to create a child (C1)
 # that shares the stdout/stderr handles with the inferior.
 # C1 will then loop forever.
 driver.run_command_with_timeout(
 self.inferior_command(
-options="--launch-child-share-handles --return-code 3"),
-"5s",
+options="--launch-child-share-handles --return-code {}".format(
+return_code)),
+"{}s".format(timeout_seconds),
 False)
 
 # We should complete without a timetout.  I1 should end
 # immediately after launching C1.
 self.assertTrue(
-driver.completed_event.wait(5),
+driver.completed_event.wait(timeout_seconds),
 "process failed to complete")
 
 # Ensure we didn't receive a timeout.
-self.assertTrue(
+self.assertFalse(
 driver.was_timeout, "inferior should have completed normally")
 
 self.assertEqual(
-driver.returncode, 3,
+driver.returncode, return_code,
 "expected inferior process to end with expected returncode")
 
 
Index: test/test_runner/test/inferior.py
===
--- test/test_runner/test/inferior.py
+++ test/test_runner/test/inferior.py
@@ -140,4 +140,6 @@
 return options.return_code
 
 if __name__ == "__main__":
-sys.exit(main(sys.argv[1:]))
+RETURN_CODE = main(sys.argv[1:])
+print "returning {}".format(RETURN_CODE)
+sys.exit(RETURN_CODE)
Index: test/test_runner/lib/process_control.py
===
--- test/test_runner/lib/process_control.py
+++ test/test_runner/lib/process_control.py
@@ -13,6 +13,7 @@
 """
 
 # System imports
+import datetime
 import os
 import re
 import signal
@@ -21,31 +22,40 @@
 import threading
 
 
-class CommunicatorThread(threading.Thread):
-"""Provides a thread class that communicates with a subprocess."""
-def __init__(self, process, event, output_file):
-super(CommunicatorThread, self).__init__()
+class CallAndNotifyThread(threading.Thread):
+"""Provides a thread class that calls a method, then notifies.
+
+Implements a thread that sits on a synchronous call, then notif

Re: [Lldb-commits] [lldb] r249047 - Add a 'type lookup' command. This command is meant to look up type information by name in a language-specific way.

2015-10-01 Thread Zachary Turner via lldb-commits

I see there's SBType, does this represent something different?  I was
thinking you could make a method like

SBType *
SBTarget::LookupType(const char* type_name, eLanguage lang);

Even if it didn't support every possible usage of the "type lookup"
command, it would be a start.

At one point on the list it was discussed whether tests which use runCmd
and then matching the output should be separated from the rest of the test
suite, so there's a more clearly enforced distinction about which tests use
the command API and which tests use the python API.  At least Jim thought
that was a good idea and supported the move, but nobody else really chimed
in.  If you agree, maybe you could be the first?  :)  Something like
lldb/test/commands/type-lookup.  Eventually the goal would just be to have
3 top level directories,

lldb
|__test
|__commands
|__python-api
|__unit-tests

With the existing sub-trees divided up accordingly between the 3.   (This
is all assuming of course that making the SBTarget::LookupType method I
suggested earlier doesn't work for some reason)

On Thu, Oct 1, 2015 at 1:01 PM Enrico Granata  wrote:

> On Oct 1, 2015, at 12:49 PM, Zachary Turner  wrote:
>
> Hi Enrico,
>
> Could you add some tests for this?
>
>
> Sure. I am still churning through a thing or two before declaring victory,
> but I can add tests as I make progress
>
>  python API tests and appropriate methods added to SBTarget
>
>
> There currently is no SB API component to this. It is a purely
> command-line facility.
> If you feel it would be useful to have SB API for this, it will need to be
> designed (e.g. “type lookup” is allowed to transact in things that are not
> strictly speaking compiler types - we have no API way to represent this
> kind of concept)
>
> would be ideal.
>
> On Thu, Oct 1, 2015 at 11:17 AM Enrico Granata via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>> Author: enrico
>> Date: Thu Oct  1 13:16:18 2015
>> New Revision: 249047
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=249047&view=rev
>> Log:
>> Add a 'type lookup' command. This command is meant to look up type
>> information by name in a language-specific way.
>>
>> Currently, it only supports Objective-C - C++ types can be looked up
>> through debug info via 'image lookup -t', whereas ObjC types via this
>> command are looked up by runtime introspection
>>
>> This behavior is in line with type lookup's behavior in Xcode 7, but I am
>> definitely open to feedback as to what makes the most sense here
>>
>>
>> Modified:
>> lldb/trunk/include/lldb/Target/Language.h
>> lldb/trunk/source/Commands/CommandObjectType.cpp
>> lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp
>> lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.h
>> lldb/trunk/source/Target/Language.cpp
>>
>> Modified: lldb/trunk/include/lldb/Target/Language.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Target/Language.h?rev=249047&r1=249046&r2=249047&view=diff
>>
>> ==
>> --- lldb/trunk/include/lldb/Target/Language.h (original)
>> +++ lldb/trunk/include/lldb/Target/Language.h Thu Oct  1 13:16:18 2015
>> @@ -13,6 +13,8 @@
>>  // C Includes
>>  // C++ Includes
>>  #include 
>> +#include 
>> +#include 
>>  #include 
>>
>>  // Other libraries and framework includes
>> @@ -29,6 +31,42 @@ class Language :
>>  public PluginInterface
>>  {
>>  public:
>> +
>> +class TypeScavenger
>> +{
>> +public:
>> +class Result
>> +{
>> +public:
>> +virtual bool
>> +IsValid () = 0;
>> +
>> +virtual bool
>> +DumpToStream (Stream& stream,
>> +  bool print_help_if_available) = 0;
>> +
>> +virtual ~Result() = default;
>> +};
>> +
>> +typedef std::set> ResultSet;
>> +
>> +virtual ~TypeScavenger () = default;
>> +
>> +size_t
>> +Find (ExecutionContextScope *exe_scope,
>> +  const char *key,
>> +  ResultSet &results,
>> +  bool append = true);
>> +
>> +protected:
>> +TypeScavenger () = default;
>> +
>> +virtual bool
>> +Find_Impl (ExecutionContextScope *exe_scope,
>> +   const char *key,
>> +   ResultSet &results) = 0;
>> +};
>> +
>>  ~Language() override;
>>
>>  static Language*
>> @@ -65,6 +103,9 @@ public:
>>  virtual lldb_private::formatters::StringPrinter::EscapingHelper
>>  GetStringPrinterEscapingHelper
>> (lldb_private::formatters::StringPrinter::GetPrintableElementType);
>>
>> +virtual std::unique_ptr
>> +GetTypeScavenger ();
>> +
>>  // These are accessors for general information about the Languages
>> lldb knows about:
>>
>>  static lldb::LanguageType
>> @@ -91,7 +132,6 @@ public:
>>
>>  static bool
>>  LanguageIsPascal (lldb::LanguageType language);
>> -
>>
>>  pro

Re: [Lldb-commits] [PATCH] D13268: Simple readline functionality for interactive python on linux.

2015-10-01 Thread Ryan Brown via lldb-commits

ribrdb updated this revision to Diff 36295.
ribrdb marked an inline comment as done.
ribrdb added a comment.

Updated comments.


Repository:
  rL LLVM

http://reviews.llvm.org/D13268

Files:
  scripts/Python/modules/readline/CMakeLists.txt
  scripts/Python/modules/readline/readline.cpp

Index: scripts/Python/modules/readline/readline.cpp
===
--- scripts/Python/modules/readline/readline.cpp
+++ scripts/Python/modules/readline/readline.cpp
@@ -1,10 +1,12 @@
 #include 
 #include "Python.h"
+#include 
 
-// Python readline module intentionally built to not implement the
-// readline module interface. This is meant to work around llvm
-// pr18841 to avoid seg faults in the stock Python readline.so linked
-// against GNU readline.
+// Simple implementation of the Python readline module using libedit.
+// Currently it only installs a PyOS_ReadlineFunctionPointer, without
+// implementing any of the readline module methods. This is meant to
+// work around LLVM pr18841 to avoid seg faults in the stock Python
+// readline.so linked against GNU readline.
 
 static struct PyMethodDef moduleMethods[] =
 {
@@ -13,11 +15,36 @@
 
 PyDoc_STRVAR(
 moduleDocumentation,
-"Stub module meant to effectively disable readline support.");
+"Stub module meant to avoid linking GNU readline.");
+
+static char*
+simple_readline(FILE *stdin, FILE *stdout, char *prompt)
+{
+rl_instream = stdin;
+rl_outstream = stdout;
+char* line = readline(prompt);
+if (!line)
+{
+char* ret = (char*)PyMem_Malloc(1);
+if (ret != NULL)
+*ret = '\0';
+return ret;
+}
+if (*line)
+add_history(line);
+int n = strlen(line);
+char* ret = (char*)PyMem_Malloc(n + 2);
+strncpy(ret, line, n);
+free(line);
+ret[n] = '\n';
+ret[n+1] = '\0';
+return ret;
+}
 
 PyMODINIT_FUNC
 initreadline(void)
 {
+PyOS_ReadlineFunctionPointer = simple_readline;
 Py_InitModule4(
 "readline",
 moduleMethods,
Index: scripts/Python/modules/readline/CMakeLists.txt
===
--- scripts/Python/modules/readline/CMakeLists.txt
+++ scripts/Python/modules/readline/CMakeLists.txt
@@ -7,7 +7,7 @@
 include_directories(${PYTHON_INCLUDE_DIR})
 add_library(readline SHARED readline.cpp)
 
-target_link_libraries(readline ${PYTHON_LIBRARY})
+target_link_libraries(readline ${PYTHON_LIBRARY} edit)
 
 # FIXME: the LIBRARY_OUTPUT_PATH seems to be ignored - this is not a
 # functional issue for the build dir, though, since the shared lib dir


Index: scripts/Python/modules/readline/readline.cpp
===
--- scripts/Python/modules/readline/readline.cpp
+++ scripts/Python/modules/readline/readline.cpp
@@ -1,10 +1,12 @@
 #include 
 #include "Python.h"
+#include 
 
-// Python readline module intentionally built to not implement the
-// readline module interface. This is meant to work around llvm
-// pr18841 to avoid seg faults in the stock Python readline.so linked
-// against GNU readline.
+// Simple implementation of the Python readline module using libedit.
+// Currently it only installs a PyOS_ReadlineFunctionPointer, without
+// implementing any of the readline module methods. This is meant to
+// work around LLVM pr18841 to avoid seg faults in the stock Python
+// readline.so linked against GNU readline.
 
 static struct PyMethodDef moduleMethods[] =
 {
@@ -13,11 +15,36 @@
 
 PyDoc_STRVAR(
 moduleDocumentation,
-"Stub module meant to effectively disable readline support.");
+"Stub module meant to avoid linking GNU readline.");
+
+static char*
+simple_readline(FILE *stdin, FILE *stdout, char *prompt)
+{
+rl_instream = stdin;
+rl_outstream = stdout;
+char* line = readline(prompt);
+if (!line)
+{
+char* ret = (char*)PyMem_Malloc(1);
+if (ret != NULL)
+*ret = '\0';
+return ret;
+}
+if (*line)
+add_history(line);
+int n = strlen(line);
+char* ret = (char*)PyMem_Malloc(n + 2);
+strncpy(ret, line, n);
+free(line);
+ret[n] = '\n';
+ret[n+1] = '\0';
+return ret;
+}
 
 PyMODINIT_FUNC
 initreadline(void)
 {
+PyOS_ReadlineFunctionPointer = simple_readline;
 Py_InitModule4(
 "readline",
 moduleMethods,
Index: scripts/Python/modules/readline/CMakeLists.txt
===
--- scripts/Python/modules/readline/CMakeLists.txt
+++ scripts/Python/modules/readline/CMakeLists.txt
@@ -7,7 +7,7 @@
 include_directories(${PYTHON_INCLUDE_DIR})
 add_library(readline SHARED readline.cpp)
 
-target_link_libraries(readline ${PYTHON_LIBRARY})
+target_link_libraries(readline ${PYTHON_LIBRARY} edit)
 
 # FIXME: the LIBRARY_OUTPUT_PATH seems to be ignored - this is not a
 # functional issue for the build dir, though, since the shared lib dir

[Lldb-commits] [lldb] r249072 - [lldb-mi] Add support for StopAtEntry in MI via "-exec-run --start".

2015-10-01 Thread Dawn Perchik via lldb-commits

Author: dperchik
Date: Thu Oct  1 16:15:43 2015
New Revision: 249072

URL: http://llvm.org/viewvc/llvm-project?rev=249072&view=rev
Log:
[lldb-mi] Add support for StopAtEntry in MI via "-exec-run --start".

This patch adds a --start option to the lldb-mi -exec-run command for
getting process stopped at entry point after launch.  It is equivelent
to the -s option in the lldb command line interpreter:
process launch -s
and is therefore not supported on all hosts and/or targets.  To check
if the --start option is supported, see if the corresponding feature
"exec-run-start-option" is in the list of options reported by the lldb-mi
"-list-features" command.

Patch from engineer.develo...@gmail.com (Kirill Lapshin)
Reviewed by: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12977

Modified:
lldb/trunk/test/tools/lldb-mi/control/TestMiExec.py
lldb/trunk/tools/lldb-mi/MICmdCmdExec.cpp
lldb/trunk/tools/lldb-mi/MICmdCmdExec.h
lldb/trunk/tools/lldb-mi/MICmdCmdSupportList.cpp

Modified: lldb/trunk/test/tools/lldb-mi/control/TestMiExec.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/test/tools/lldb-mi/control/TestMiExec.py?rev=249072&r1=249071&r2=249072&view=diff
==
--- lldb/trunk/test/tools/lldb-mi/control/TestMiExec.py (original)
+++ lldb/trunk/test/tools/lldb-mi/control/TestMiExec.py Thu Oct  1 16:15:43 2015
@@ -13,6 +13,26 @@ class MiExecTestCase(lldbmi_testcase.MiT
 @lldbmi_test
 @skipIfWindows #llvm.org/pr24452: Get lldb-mi tests working on Windows
 @skipIfFreeBSD # llvm.org/pr22411: Failure presumably due to known thread 
races
+@expectedFailureLinux # llvm.org/pr25000: lldb-mi does not receive 
broadcasted notification from Core/Process about process stopped
+def test_lldbmi_exec_run(self):
+"""Test that 'lldb-mi --interpreter' can stop at entry."""
+
+self.spawnLldbMi(args = None)
+
+# Load executable
+self.runCmd("-file-exec-and-symbols %s" % self.myexe)
+self.expect("\^done")
+
+# Test that program is stopped at entry
+self.runCmd("-exec-run --start")
+self.expect("\^running")
+
self.expect("\*stopped,reason=\"signal-received\",signal-name=\"SIGSTOP\",signal-meaning=\"Stop\",.*?thread-id=\"1\",stopped-threads=\"all\"")
+# Test that lldb-mi is ready to execute next commands
+self.expect(self.child_prompt, exactly = True)
+
+@lldbmi_test
+@skipIfWindows #llvm.org/pr24452: Get lldb-mi tests working on Windows
+@skipIfFreeBSD # llvm.org/pr22411: Failure presumably due to known thread 
races
 @expectedFailureAll("llvm.org/pr23139", oslist=["linux"], compiler="gcc", 
compiler_version=[">=","4.9"], archs=["i386"])
 def test_lldbmi_exec_abort(self):
 """Test that 'lldb-mi --interpreter' works for -exec-abort."""

Modified: lldb/trunk/tools/lldb-mi/MICmdCmdExec.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-mi/MICmdCmdExec.cpp?rev=249072&r1=249071&r2=249072&view=diff
==
--- lldb/trunk/tools/lldb-mi/MICmdCmdExec.cpp (original)
+++ lldb/trunk/tools/lldb-mi/MICmdCmdExec.cpp Thu Oct  1 16:15:43 2015
@@ -48,6 +48,7 @@
 // Throws:  None.
 //--
 CMICmdCmdExecRun::CMICmdCmdExecRun()
+: m_constStrArgStart("start")
 {
 // Command factory matches this name with that received from the stdin 
stream
 m_strMiCmd = "exec-run";
@@ -68,6 +69,23 @@ CMICmdCmdExecRun::~CMICmdCmdExecRun()
 }
 
 //++ 

+// Details: The invoker requires this function. It parses the command line 
options'
+//  arguments to extract values for each of those arguments.
+// Type:Overridden.
+// Args:None.
+// Return:  MIstatus::success - Functional succeeded.
+//  MIstatus::failure - Functional failed.
+// Throws:  None.
+//--
+bool
+CMICmdCmdExecRun::ParseArgs()
+{
+m_setCmdArgs.Add(
+new CMICmdArgValOptionLong(m_constStrArgStart, false, true, 
CMICmdArgValListBase::eArgValType_OptionLong, 0));
+return ParseValidateCmdOptions();
+}
+
+//++ 

 // Details: The invoker requires this function. The command does work in this 
function.
 //  The command is likely to communicate with the LLDB SBDebugger in 
here.
 // Type:Overridden.
@@ -84,6 +102,14 @@ CMICmdCmdExecRun::Execute()
 lldb::SBStream errMsg;
 lldb::SBLaunchInfo launchInfo = rSessionInfo.GetTarget().GetLaunchInfo();
 launchInfo.SetListener(rSessionInfo.GetListener());
+
+// Run to first instruction or main() requested?
+CMICMDBASE_GETOPTION(pArgStart, OptionLong, m_constStrArgStart);
+if (pArgStart->GetFound())
+{
+launchInfo.SetLaunchFlags(launchInfo.GetLaunchFlags() | 
lldb::eLa

Re: [Lldb-commits] [PATCH] D12977: LLDB MI addition for getting process stopped at first instruction right after launch via -exec-run

2015-10-01 Thread Phabricator via lldb-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL249072: [lldb-mi] Add support for StopAtEntry in MI via 
"-exec-run --start". (authored by dperchik).

Changed prior to commit:
  http://reviews.llvm.org/D12977?vs=36128&id=36298#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D12977

Files:
  lldb/trunk/test/tools/lldb-mi/control/TestMiExec.py
  lldb/trunk/tools/lldb-mi/MICmdCmdExec.cpp
  lldb/trunk/tools/lldb-mi/MICmdCmdExec.h
  lldb/trunk/tools/lldb-mi/MICmdCmdSupportList.cpp

Index: lldb/trunk/test/tools/lldb-mi/control/TestMiExec.py
===
--- lldb/trunk/test/tools/lldb-mi/control/TestMiExec.py
+++ lldb/trunk/test/tools/lldb-mi/control/TestMiExec.py
@@ -13,6 +13,26 @@
 @lldbmi_test
 @skipIfWindows #llvm.org/pr24452: Get lldb-mi tests working on Windows
 @skipIfFreeBSD # llvm.org/pr22411: Failure presumably due to known thread races
+@expectedFailureLinux # llvm.org/pr25000: lldb-mi does not receive broadcasted notification from Core/Process about process stopped
+def test_lldbmi_exec_run(self):
+"""Test that 'lldb-mi --interpreter' can stop at entry."""
+
+self.spawnLldbMi(args = None)
+
+# Load executable
+self.runCmd("-file-exec-and-symbols %s" % self.myexe)
+self.expect("\^done")
+
+# Test that program is stopped at entry
+self.runCmd("-exec-run --start")
+self.expect("\^running")
+self.expect("\*stopped,reason=\"signal-received\",signal-name=\"SIGSTOP\",signal-meaning=\"Stop\",.*?thread-id=\"1\",stopped-threads=\"all\"")
+# Test that lldb-mi is ready to execute next commands
+self.expect(self.child_prompt, exactly = True)
+
+@lldbmi_test
+@skipIfWindows #llvm.org/pr24452: Get lldb-mi tests working on Windows
+@skipIfFreeBSD # llvm.org/pr22411: Failure presumably due to known thread races
 @expectedFailureAll("llvm.org/pr23139", oslist=["linux"], compiler="gcc", compiler_version=[">=","4.9"], archs=["i386"])
 def test_lldbmi_exec_abort(self):
 """Test that 'lldb-mi --interpreter' works for -exec-abort."""
Index: lldb/trunk/tools/lldb-mi/MICmdCmdSupportList.cpp
===
--- lldb/trunk/tools/lldb-mi/MICmdCmdSupportList.cpp
+++ lldb/trunk/tools/lldb-mi/MICmdCmdSupportList.cpp
@@ -71,8 +71,13 @@
 bool
 CMICmdCmdSupportListFeatures::Acknowledge()
 {
-const CMICmnMIValueConst miValueConst("data-read-memory-bytes");
-const CMICmnMIValueList miValueList(miValueConst);
+// Declare supported features here
+const CMICmnMIValueConst miValueConst1("data-read-memory-bytes");
+const CMICmnMIValueConst miValueConst2("exec-run-start-option");
+// Some features may depend on host and/or target, decide what to add below
+CMICmnMIValueList miValueList(true);
+miValueList.Add(miValueConst1);
+miValueList.Add(miValueConst2);
 const CMICmnMIValueResult miValueResult("features", miValueList);
 const CMICmnMIResultRecord miRecordResult(m_cmdData.strMiCmdToken, CMICmnMIResultRecord::eResultClass_Done, miValueResult);
 m_miResultRecord = miRecordResult;
Index: lldb/trunk/tools/lldb-mi/MICmdCmdExec.h
===
--- lldb/trunk/tools/lldb-mi/MICmdCmdExec.h
+++ lldb/trunk/tools/lldb-mi/MICmdCmdExec.h
@@ -55,11 +55,13 @@
 // From CMICmdInvoker::ICmd
 bool Execute() override;
 bool Acknowledge() override;
+bool ParseArgs() override;
 // From CMICmnBase
 /* dtor */ ~CMICmdCmdExecRun() override;
 
 // Attributes:
   private:
+const CMIUtilString m_constStrArgStart; // StopAtEntry - run to first instruction or main() if specified
 lldb::SBCommandReturnObject m_lldbResult;
 };
 
Index: lldb/trunk/tools/lldb-mi/MICmdCmdExec.cpp
===
--- lldb/trunk/tools/lldb-mi/MICmdCmdExec.cpp
+++ lldb/trunk/tools/lldb-mi/MICmdCmdExec.cpp
@@ -48,6 +48,7 @@
 // Throws:  None.
 //--
 CMICmdCmdExecRun::CMICmdCmdExecRun()
+: m_constStrArgStart("start")
 {
 // Command factory matches this name with that received from the stdin stream
 m_strMiCmd = "exec-run";
@@ -68,6 +69,23 @@
 }
 
 //++ 
+// Details: The invoker requires this function. It parses the command line options'
+//  arguments to extract values for each of those arguments.
+// Type:Overridden.
+// Args:None.
+// Return:  MIstatus::success - Functional succeeded.
+//  MIstatus::failure - Functional failed.
+// Throws:  None.
+//--
+bool
+CMICmdCmdExecRun::ParseArgs()
+{
+m_setCmdArgs.Add(
+new CMICmdArgValOptionLong(m_constStrArgStart, false, true, CMICmdArgValListBase::eArgValType_OptionLong, 0));
+return ParseValidateCmdOptions();
+}
+
+//++ ---

Re: [Lldb-commits] [lldb] r249047 - Add a 'type lookup' command. This command is meant to look up type information by name in a language-specific way.

2015-10-01 Thread Enrico Granata via lldb-commits

> On Oct 1, 2015, at 1:15 PM, Zachary Turner  wrote:
> 
> I see there's SBType, does this represent something different?

Yes, it represents types.
Type lookup does not necessarily always deal with types.
For instance, imagine a language that has function declarations such that

function foo(int x, int y) returns int

and

function bar(int x, int y) returns int

represents two different declarations - but they have the same type

function (int, int) returns int

We want type lookup to be able to maintain that distinction, such that one 
could say

(lldb) type lookup -l newlanguage — foo
function foo(int x, int y) returns int

vs.

(lldb) type lookup -l newlanguage — bar
function bar(int x, int y) returns int

Other similar cases are languages where a runtime introspection mechanism does 
not expose fully-baked types, but still provides useful introspection 
information that one could show the user. Those are useful things for type 
lookup to do, and forcing the results to be CompilerTypes would lose us that 
ability. We would need something like SBTypeOrDecl, or an opaque 
SBTypeLookupResult.

>   I was thinking you could make a method like 
> 
> SBType *
> SBTarget::LookupType(const char* type_name, eLanguage lang);
> 
> Even if it didn't support every possible usage of the "type lookup" command, 
> it would be a start.

I would like to avoid having a command that does the right thing always, and an 
API that does somewhat a good thing sometimes. Note that I don’t say this to 
oppose the notion of an API for “type lookup”, but only to oppose the notion of 
an API that returns a list of types, when the output of “type lookup” is not 
necessarily always just types.

An API is a reasonable thing to ask for - I can’t promise I’ll have one done 
today or tomorrow, especially because I have given no thought to how to design 
one, but now that you mention it, it is in my queue of improvements for this 
functionality.

> 
> At one point on the list it was discussed whether tests which use runCmd and 
> then matching the output should be separated from the rest of the test suite, 
> so there's a more clearly enforced distinction about which tests use the 
> command API and which tests use the python API.  At least Jim thought that 
> was a good idea and supported the move, but nobody else really chimed in.  If 
> you agree, maybe you could be the first?  :)  Something like 
> lldb/test/commands/type-lookup.  Eventually the goal would just be to have 3 
> top level directories, 
> 
> lldb
> |__test
> |__commands
> |__python-api
> |__unit-tests

I have historically been putting this kind of things in “test/functionalities”. 
I am not sure that - as a matter of convention - we have command-line only 
tests in “functionalities” though.
Is there any objection to a refactor as-you-touch-things approach here? i.e. if 
I add a test for the command-line side, it goes in test/functionalities/* - but 
if at a later time I add SB API for type lookup, then the test for that goes in 
test/python-api/*
It seems a reasonable way forward to me - unless I am missing something

> 
> With the existing sub-trees divided up accordingly between the 3.   (This is 
> all assuming of course that making the SBTarget::LookupType method I 
> suggested earlier doesn't work for some reason)
> 
> On Thu, Oct 1, 2015 at 1:01 PM Enrico Granata  > wrote:
>> On Oct 1, 2015, at 12:49 PM, Zachary Turner > > wrote:
>> 
>> Hi Enrico,
>> 
>> Could you add some tests for this?
> 
> Sure. I am still churning through a thing or two before declaring victory, 
> but I can add tests as I make progress
> 
>>  python API tests and appropriate methods added to SBTarget
> 
> There currently is no SB API component to this. It is a purely command-line 
> facility.
> If you feel it would be useful to have SB API for this, it will need to be 
> designed (e.g. “type lookup” is allowed to transact in things that are not 
> strictly speaking compiler types - we have no API way to represent this kind 
> of concept)
> 
>> would be ideal.
>> 
>> On Thu, Oct 1, 2015 at 11:17 AM Enrico Granata via lldb-commits 
>> mailto:lldb-commits@lists.llvm.org>> wrote:
>> Author: enrico
>> Date: Thu Oct  1 13:16:18 2015
>> New Revision: 249047
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=249047&view=rev 
>> 
>> Log:
>> Add a 'type lookup' command. This command is meant to look up type 
>> information by name in a language-specific way.
>> 
>> Currently, it only supports Objective-C - C++ types can be looked up through 
>> debug info via 'image lookup -t', whereas ObjC types via this command are 
>> looked up by runtime introspection
>> 
>> This behavior is in line with type lookup's behavior in Xcode 7, but I am 
>> definitely open to feedback as to what makes the most sense here
>> 
>> 
>> Modified:
>> lldb/trunk/include/lldb/Target/Language.h
>> lld

Re: [Lldb-commits] [PATCH] D13334: Preliminary NetBSD support

2015-10-01 Thread Joerg Sonnenberger via lldb-commits

On Thu, Oct 01, 2015 at 10:41:46AM +, Pavel Labath via lldb-commits wrote:
> This platform code looks like it was copy-pasted from PlatformFreeBSD.
> Do you anticipate making significant changes here?
> 
> If not, it might be a good idea to share this code with FreeBSD in some
> way (in fact there is a comment here to make this share code with
> PlatformPOSIX). @emaste, what do you think about this?

I was talking about this with Ed and some of the other FreeBSD folks
when I started my own efforts on LLDB for NetBSD. I think the best
approach is to start with the patch as is and slowly refactoring from
that. IMO it is better here to have a basic working state first.

The other point we agreed on is that the FreeBSD code and the Linux code
can often be more shared to, so there is a lot of room for improvements
in any direction. I'd prefer to avoid the classic "the enemy of good"
situations here.

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

Re: [Lldb-commits] [PATCH] D13058: LLDB-MI: Bug when evaluating strings containing characters from non-ascii range

2015-10-01 Thread via lldb-commits

On Sat, Sep 26, 2015 at 08:13:48AM +, Jason Molenda wrote:
> NB: Greg is out for the next nine days, Enrico for the next five days.

Is Enrico back now?  OK to commit this if he accepts?

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

Re: [Lldb-commits] [PATCH] D13058: LLDB-MI: Bug when evaluating strings containing characters from non-ascii range

2015-10-01 Thread Enrico Granata via lldb-commits

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

Sorry, I didn't realize you were still waiting on me to land this patch.

I have a few extra comments before this is ready to land.



Comment at: include/lldb/API/SBTypeSummary.h:125
@@ +124,3 @@
+
+bool DoesPrintValue(const lldb::SBValue &value) const;
+

Can you please change this to

bool
DoesPrintValue (lldb::SBValue value);

There is no need to pass the SBValue by reference since you're not actually 
altering it - and since SBValue wraps a (glorified) pointer to a ValueObject 
you're not really copying much data over. I don't see the need to classify the 
function as const (only IsValid() seems to be marked thusly in that file), and 
definitely no need for the SBValue to be a const


Comment at: source/API/SBTypeSummary.cpp:289
@@ -286,1 +288,3 @@
 
+bool
+SBTypeSummary::DoesPrintValue(const lldb::SBValue &value) const

Of course change this in the C++ file as well


Comment at: tools/lldb-mi/MICmnLLDBUtilSBValue.cpp:372
@@ +371,3 @@
+CMIUtilString
+CMICmnLLDBUtilSBValue::GetValueSummary() const
+{

I might be missing something, but how is this going to work when an SBValue has 
a value but no summary (something as simple as int x = 1;)?

GetSummary() is free to return NULL, and I only see you fetching the value here 
when there is a summary. Your logic should be more like

GetSummary()
if (!summary || summary && DoesPrintValue())
 append value

A very long-term goal of mine is for all of this logic to exist in the 
ValueObjectPrinter and clients to simply be able to ask it to print a 
ValueObject according to some specification of theirs, in the middle of an 
existing stream. But that is way beyond the scope of your patch, so if you just 
clean up the logic here to do the right thing for values without summaries, I 
am happy.


http://reviews.llvm.org/D13058



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

Re: [Lldb-commits] [lldb] r249047 - Add a 'type lookup' command. This command is meant to look up type information by name in a language-specific way.

2015-10-01 Thread Zachary Turner via lldb-commits

I agree that refactor-as-you-touch-things is definitely the way to go, but
if we're going to end up having a test/commands for all the command line
tests, then we might as well start it sooner rather than later.  On the
other hand, if we dont' all agree that that's the best path forward, then I
guess test/functionalities would be the place for it to go now, and we
could continue that discussion on the other thread.  The original therad is
here  if
you want to chime in.

On Thu, Oct 1, 2015 at 2:17 PM Enrico Granata  wrote:

> On Oct 1, 2015, at 1:15 PM, Zachary Turner  wrote:
>
> I see there's SBType, does this represent something different?
>
>
> Yes, it represents types.
> Type lookup does not necessarily always deal with types.
> For instance, imagine a language that has function declarations such that
>
> function foo(int x, int y) returns int
>
> and
>
> function bar(int x, int y) returns int
>
> represents two different declarations - but they have the same type
>
> function (int, int) returns int
>
> We want type lookup to be able to maintain that distinction, such that one
> could say
>
> (lldb) type lookup -l newlanguage — foo
> *function foo(int x, int y) returns int*
>
> vs.
>
> (lldb) type lookup -l newlanguage — bar
> *function bar(int x, int y) returns int*
>
> Other similar cases are languages where a runtime introspection mechanism
> does not expose fully-baked types, but still provides useful introspection
> information that one could show the user. Those are useful things for type
> lookup to do, and forcing the results to be CompilerType*s* would lose us
> that ability. We would need something like SBTypeOrDecl, or an opaque
> SBTypeLookupResult.
>
>   I was thinking you could make a method like
>
> SBType *
> SBTarget::LookupType(const char* type_name, eLanguage lang);
>
> Even if it didn't support every possible usage of the "type lookup"
> command, it would be a start.
>
>
> I would like to avoid having a command that does the right thing always,
> and an API that does somewhat a good thing sometimes. Note that I don’t say
> this to oppose the notion of an API for “type lookup”, but only to oppose
> the notion of an API that returns a list of types, when the output of “type
> lookup” is not necessarily always just types.
>
> An API is a reasonable thing to ask for - I can’t promise I’ll have one
> done today or tomorrow, especially because I have given no thought to how
> to design one, but now that you mention it, it is in my queue of
> improvements for this functionality.
>
>
> At one point on the list it was discussed whether tests which use runCmd
> and then matching the output should be separated from the rest of the test
> suite, so there's a more clearly enforced distinction about which tests use
> the command API and which tests use the python API.  At least Jim thought
> that was a good idea and supported the move, but nobody else really chimed
> in.  If you agree, maybe you could be the first?  :)  Something like
> lldb/test/commands/type-lookup.  Eventually the goal would just be to have
> 3 top level directories,
>
> lldb
> |__test
> |__commands
> |__python-api
> |__unit-tests
>
>
> I have historically been putting this kind of things in
> “test/functionalities”. I am not sure that - as a matter of convention - we
> have command-line only tests in “functionalities” though.
> Is there any objection to a refactor as-you-touch-things approach here?
> i.e. if I add a test for the command-line side, it goes in
> test/functionalities/* - but if at a later time I add SB API for type
> lookup, then the test for that goes in test/python-api/*
> It seems a reasonable way forward to me - unless I am missing something
>
>
> With the existing sub-trees divided up accordingly between the 3.   (This
> is all assuming of course that making the SBTarget::LookupType method I
> suggested earlier doesn't work for some reason)
>
> On Thu, Oct 1, 2015 at 1:01 PM Enrico Granata  wrote:
>
>> On Oct 1, 2015, at 12:49 PM, Zachary Turner  wrote:
>>
>> Hi Enrico,
>>
>> Could you add some tests for this?
>>
>>
>> Sure. I am still churning through a thing or two before declaring
>> victory, but I can add tests as I make progress
>>
>>  python API tests and appropriate methods added to SBTarget
>>
>>
>> There currently is no SB API component to this. It is a purely
>> command-line facility.
>> If you feel it would be useful to have SB API for this, it will need to
>> be designed (e.g. “type lookup” is allowed to transact in things that are
>> not strictly speaking compiler types - we have no API way to represent this
>> kind of concept)
>>
>> would be ideal.
>>
>> On Thu, Oct 1, 2015 at 11:17 AM Enrico Granata via lldb-commits <
>> lldb-commits@lists.llvm.org> wrote:
>>
>>> Author: enrico
>>> Date: Thu Oct  1 13:16:18 2015
>>> New Revision: 249047
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=249047&view=rev
>>> Log:

Re: [Lldb-commits] [PATCH] D13350: [lldb] Fix evaluation of qualified global variables

2015-10-01 Thread Dawn Perchik via lldb-commits

dawn added a subscriber: dawn.
dawn added a comment.

This patch fixes bugs:

- https://llvm.org/bugs/show_bug.cgi?id=24994 (::val gets NS::val inside NS 
since r247746)
- https://llvm.org/bugs/show_bug.cgi?id=24995 (shadowed var gets ambiguity 
since r247836)

See inline comments.  Mostly had concerns about indentation - please always run 
patches through clang-format (both clang and lldb have their own config file in 
the root dir).



Comment at: clang/include/clang/AST/DeclBase.h:1769
@@ +1768,3 @@
+  return old_value;
+  }
+

Indenting in clang is 2 spaces.


Comment at: lldb/include/lldb/Symbol/CompilerDeclContext.h:17
@@ -16,2 +16,3 @@
 #include "lldb/Core/ConstString.h"
+#include "clang/AST/DeclBase.h"
 

clang includes should precede lldb ones.


Comment at: lldb/include/lldb/Symbol/TypeSystem.h:121
@@ -120,1 +120,3 @@
 
+// extra is language dependant
+virtual std::vector

I don't understand this comment - please clarify?  Also, please start comments 
with capital letters.


Comment at: lldb/include/lldb/Symbol/TypeSystem.h:123
@@ +122,3 @@
+virtual std::vector
+DeclContextFindDeclByNameEx (void *opaque_decl_ctx, ConstString name, 
void* extra)
+{

It would be cleaner to have a default argument instead of this second overload. 
 What are the guidelines on using default arguments in lldb?  I've seen them 
both used and not used.


Comment at: 
lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:1370
@@ -1370,1 +1369,3 @@
+std::vector found_decls =
+compiler_decl_context.FindDeclByName(name, 
context.m_decl_context);
 

Looks like indentation was accidentally changed here?


Comment at: lldb/source/Symbol/ClangASTContext.cpp:8984
@@ +8983,3 @@
+return nd->getLexicalDeclContext()->getDeclKind() == 
lookupCtx->getDeclKind();
+}
+

Please run patch through clang-format to fix indentation issues.


http://reviews.llvm.org/D13350



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

Re: [Lldb-commits] [PATCH] D13350: [lldb] Fix evaluation of qualified global variables

2015-10-01 Thread Dawn Perchik via lldb-commits

dawn added a comment.

Was this patch run on the entire set of lldb tests?  Were there any regressions?


http://reviews.llvm.org/D13350



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

Re: [Lldb-commits] [PATCH] D13268: Simple readline functionality for interactive python on linux.

2015-10-01 Thread Todd Fiala via lldb-commits

tfiala added a comment.

Ooo neat, I'll have a look!  Might take me 24 hours.


Repository:
  rL LLVM

http://reviews.llvm.org/D13268



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

Re: [Lldb-commits] [PATCH] D13268: Simple readline functionality for interactive python on linux.

2015-10-01 Thread Todd Fiala via lldb-commits

tfiala added a comment.

It might need to be conditionalized for libedit support if the CMakeLists 
doesn't already cover that.  I think we had it set up to allow conditional lldb 
building without libedit support.


Repository:
  rL LLVM

http://reviews.llvm.org/D13268



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

Re: [Lldb-commits] [PATCH] D13362: Enhance test runner timeout logic to detect successful completion of spawned process when stdout/stderr are shared to still-existing child processes

2015-10-01 Thread Todd Fiala via lldb-commits

tfiala added a comment.

Hmm, I'm getting a few more tests to time out now with this change:

TIMEOUT: LLDB (suite) :: TestCallStopAndContinue.py (Linux rad 
3.13.0-57-generic #95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
TIMEOUT: LLDB (suite) :: TestCommandScript.py (Linux rad 3.13.0-57-generic 
#95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
TIMEOUT: LLDB (suite) :: TestFrames.py (Linux rad 3.13.0-57-generic #95-Ubuntu 
SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
TIMEOUT: LLDB (suite) :: TestInlineStepping.py (Linux rad 3.13.0-57-generic 
#95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
TIMEOUT: LLDB (suite) :: TestReturnValue.py (Linux rad 3.13.0-57-generic 
#95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
TIMEOUT: LLDB (suite) :: TestStepNoDebug.py (Linux rad 3.13.0-57-generic 
#95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
TIMEOUT: LLDB (suite) :: TestThreadAPI.py (Linux rad 3.13.0-57-generic 
#95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
TIMEOUT: LLDB (suite) :: TestThreadJump.py (Linux rad 3.13.0-57-generic 
#95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
TIMEOUT: LLDB (suite) :: TestThreadStepping.py (Linux rad 3.13.0-57-generic 
#95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)
TIMEOUT: LLDB (suite) :: TestValueMD5Crash.py (Linux rad 3.13.0-57-generic 
#95-Ubuntu SMP Fri Jun 19 09:28:15 UTC 2015 x86_64 x86_64)

I'll need to drill into that.


http://reviews.llvm.org/D13362



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

[Lldb-commits] [lldb] r249095 - Eliminated redundant "constructors" for ClangExpressionVariable.

2015-10-01 Thread Sean Callanan via lldb-commits

Author: spyffe
Date: Thu Oct  1 18:07:06 2015
New Revision: 249095

URL: http://llvm.org/viewvc/llvm-project?rev=249095&view=rev
Log:
Eliminated redundant "constructors" for ClangExpressionVariable.

   


   
The ClangExpressionVariable::CreateVariableInList functions looked cute, but

   
caused more confusion than they solved.  I removed them, and instead made sure  

   
that there are adequate facilities for easily adding newly-constructed  

   
ExpressionVariables to lists.  

I also made some of the constructors that are common be generic, so that it's
possible to construct expression variables from generic places (like the ABI and
ValueObject) without having to know the specifics about the class.

Modified:
lldb/trunk/include/lldb/Expression/ExpressionVariable.h
lldb/trunk/source/Core/ValueObject.cpp
lldb/trunk/source/Expression/Materializer.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionVariable.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangExpressionVariable.h

lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangPersistentVariables.h
lldb/trunk/source/Target/ABI.cpp

Modified: lldb/trunk/include/lldb/Expression/ExpressionVariable.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/ExpressionVariable.h?rev=249095&r1=249094&r2=249095&view=diff
==
--- lldb/trunk/include/lldb/Expression/ExpressionVariable.h (original)
+++ lldb/trunk/include/lldb/Expression/ExpressionVariable.h Thu Oct  1 18:07:06 
2015
@@ -184,6 +184,14 @@ public:
 m_variables.push_back(var_sp);
 return m_variables.size() - 1;
 }
+
+lldb::ExpressionVariableSP
+AddNewlyConstructedVariable (ExpressionVariable *var)
+{
+lldb::ExpressionVariableSP var_sp(var);
+m_variables.push_back(var_sp);
+return m_variables.back();
+}
 
 bool
 ContainsVariable (const lldb::ExpressionVariableSP &var_sp)
@@ -283,6 +291,16 @@ public:
 m_kind(kind)
 {
 }
+
+virtual lldb::ExpressionVariableSP
+CreatePersistentVariable (const lldb::ValueObjectSP &valobj_sp) = 0;
+
+virtual lldb::ExpressionVariableSP
+CreatePersistentVariable (ExecutionContextScope *exe_scope,
+  const ConstString &name,
+  const CompilerType &type,
+  lldb::ByteOrder byte_order,
+  uint32_t addr_byte_size) = 0;
 
 virtual ~PersistentExpressionState ();
 

Modified: lldb/trunk/source/Core/ValueObject.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ValueObject.cpp?rev=249095&r1=249094&r2=249095&view=diff
==
--- lldb/trunk/source/Core/ValueObject.cpp (original)
+++ lldb/trunk/source/Core/ValueObject.cpp Thu Oct  1 18:07:06 2015
@@ -4284,13 +4284,11 @@ ValueObject::Persist ()
 
 ConstString name(persistent_state->GetNextPersistentVariableName());
 
-ExpressionVariableSP clang_var_sp(new 
ClangExpressionVariable(target_sp.get(), GetValue(), name));
-if (clang_var_sp)
-{
-clang_var_sp->m_live_sp = clang_var_sp->m_frozen_sp;
-clang_var_sp->m_flags |= ClangExpressionVariable::EVIsProgramReference;
-persistent_state->AddVariable(clang_var_sp);
-}
+ValueObjectSP const_result_sp = ValueObjectConstResult::Create 
(target_sp.get(), GetValue(), name);
+
+ExpressionVariableSP clang_var_sp = 
persistent_state->CreatePersistentVariable(const_result_sp);
+clang_var_sp->m_live_sp = clang_var_sp->m_frozen_sp;
+clang_var_sp->m_flags |= ExpressionVariable::EVIsProgramReference;
 
 return clang_var_sp->GetValueObject();
 }

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

Re: [Lldb-commits] [PATCH] D13334: Preliminary NetBSD support

2015-10-01 Thread Kamil Rytarowski via lldb-commits

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01.10.2015 23:20, Joerg Sonnenberger via lldb-commits wrote:
> On Thu, Oct 01, 2015 at 10:41:46AM +, Pavel Labath via
> lldb-commits wrote:
>> This platform code looks like it was copy-pasted from
>> PlatformFreeBSD. Do you anticipate making significant changes
>> here?
>> 
>> If not, it might be a good idea to share this code with FreeBSD
>> in some way (in fact there is a comment here to make this share
>> code with PlatformPOSIX). @emaste, what do you think about this?
> 
> I was talking about this with Ed and some of the other FreeBSD
> folks when I started my own efforts on LLDB for NetBSD. I think the
> best approach is to start with the patch as is and slowly
> refactoring from that.

I'm for it. Having in sources real-world reference will ease the
refactoring either way.

> IMO it is better here to have a basic working state first.

I've passed my current limits of the size of locally maintainable patch.

For the reference, I have more code locally still in progress of
active research (once I got to ~10k lines of git diff of the support
patch...).

Please help me to make the NetBSD support dept partially canceled.

> The other point we agreed on is that the FreeBSD code and the Linux
> code can often be more shared to, so there is a lot of room for
> improvements in any direction.

Yes, true. Integrating NetBSD will clearly help to spot these points.

> I'd prefer to avoid the classic "the enemy of good" situations
> here.
> 

Yes, please! Better incomplete support in the source trees then once
almost complete but rotting in a local patch...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWDb0eAAoJEEuzCOmwLnZs4YAP/1x9RW31pG6H6v9a9Z4GBEgG
FZy+EM5TMWp1LFBlqyxZuboLAp00E+KMHr9oM78zbrQbhng3Lf0K62nZBJKD3Zx7
Az56XBPreqdwUxMJsydD7tKXhDKldCm+1XR/8RE1xaPoG1l6qn0v6pQZek96P1RB
UJ9XCHB+w33IskbfkjK2zoIyA/KFOL4pGxHVtwdINxbeVMo8e7az2PVHspEd5IQe
vBDDlUNZU6x2xGlf9B09taUW+RcpRMrH/8OUagmqBei+v68hDaaL40GoCfMaOl1m
qV+6j0SbP4UEt9VN8gTgWkR1s4jb6PlX0eG5ktGr6cEQA3vO8kh4YmKQOJo6tF3w
y43DnQgwJBXRnNVQ60xWH+XNyBBtV6dl67DBWx1aFOORo9bseXW+KrGpjoLagQru
ZIKgIC1bt2R9wn+8vmYtp2cWac2YZHJZiT6jwWmLm796+Kb8tibnceHacPeoYFSx
LJy608GFTdUh/Zqje2J5SgL23w/Iti2ZZ6cUd1T/XpMnN8uzIH0EFXz80HVuEwvw
314PbVSYUKoOpQBLqigvOGk2SMTQm3gC5MUIX9JZBaDw2xTOyx/p9jxi2dtxPX73
Sr9WC9xKYpftDjff94MEqXqd1aSst4i5h0dCY9RcY+qFiSTYcq8jymfpTcrF44fx
UA+78iMc8QP+UOrx+hur
=Eogw
-END PGP SIGNATURE-
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D13362: Enhance test runner timeout logic to detect successful completion of spawned process when stdout/stderr are shared to still-existing child processes

2015-10-01 Thread Todd Fiala via lldb-commits

tfiala added a comment.

On OS X the only timeout I'm getting is:

TIMEOUT: LLDB (suite) :: TestValueObjectRecursion.py (Darwin 
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:45 
PDT 2015; root:xnu-3247.10.11~1/DEVELOPMENT_X86_64 x86_64 i386)


http://reviews.llvm.org/D13362



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

Re: [Lldb-commits] [PATCH] D13362: Enhance test runner timeout logic to detect successful completion of spawned process when stdout/stderr are shared to still-existing child processes

2015-10-01 Thread Todd Fiala via lldb-commits

tfiala added a comment.

The OS X one seems to be related to load (not terribly surprising).  I'm seeing 
timeouts as I crank up the --threads.  But I don't think that's the whole 
story.   On the Linux side, I've been cranking down the threads and I'm still 
seeing it.

In light of the more fundamental issue I just filed here:
https://llvm.org/bugs/show_bug.cgi?id=25019

I'm going to address that piece first (upstream) before I take this part on 
here.  That part needs to be straightened out first.  The then I'll come back 
here.


http://reviews.llvm.org/D13362



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

[Lldb-commits] [lldb] r249117 - Teach 'type lookup' to pull types from clang modules; also add a test case

2015-10-01 Thread Enrico Granata via lldb-commits

Author: enrico
Date: Thu Oct  1 20:23:11 2015
New Revision: 249117

URL: http://llvm.org/viewvc/llvm-project?rev=249117&view=rev
Log:
Teach 'type lookup' to pull types from clang modules; also add a test case


Added:
lldb/trunk/test/functionalities/type_lookup/
lldb/trunk/test/functionalities/type_lookup/Makefile
lldb/trunk/test/functionalities/type_lookup/TestTypeLookup.py
lldb/trunk/test/functionalities/type_lookup/main.m
Modified:
lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp

Modified: lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp?rev=249117&r1=249116&r2=249117&view=diff
==
--- lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp (original)
+++ lldb/trunk/source/Plugins/Language/ObjC/ObjCLanguage.cpp Thu Oct  1 
20:23:11 2015
@@ -708,34 +708,57 @@ ObjCLanguage::GetTypeScavenger ()
 {
 bool result = false;
 
-Process* process = exe_scope->CalculateProcess().get();
-if (process)
+Target* target = exe_scope->CalculateTarget().get();
+if (target)
 {
-const bool create_on_demand = false;
-auto objc_runtime = 
process->GetObjCLanguageRuntime(create_on_demand);
-if (objc_runtime)
+if (auto clang_modules_decl_vendor = 
target->GetClangModulesDeclVendor())
 {
-auto decl_vendor = objc_runtime->GetDeclVendor();
-if (decl_vendor)
+std::vector  decls;
+ConstString key_cs(key);
+
+if (clang_modules_decl_vendor->FindDecls(key_cs, false, 
UINT32_MAX, decls) > 0 &&
+decls.size() > 0)
 {
-std::vector decls;
-ConstString name(key);
-decl_vendor->FindDecls(name, true, UINT32_MAX, decls);
-for (auto decl : decls)
+CompilerType module_type = 
ClangASTContext::GetTypeForDecl(decls.front());
+result = true;
+std::unique_ptr 
result(new ObjCScavengerResult(module_type));
+results.insert(std::move(result));
+}
+}
+}
+
+if (!result)
+{
+Process* process = exe_scope->CalculateProcess().get();
+if (process)
+{
+const bool create_on_demand = false;
+auto objc_runtime = 
process->GetObjCLanguageRuntime(create_on_demand);
+if (objc_runtime)
+{
+auto decl_vendor = objc_runtime->GetDeclVendor();
+if (decl_vendor)
 {
-if (decl)
+std::vector decls;
+ConstString name(key);
+decl_vendor->FindDecls(name, true, UINT32_MAX, 
decls);
+for (auto decl : decls)
 {
-if (CompilerType candidate = 
ClangASTContext::GetTypeForDecl(decl))
+if (decl)
 {
-result = true;
-
std::unique_ptr result(new 
ObjCScavengerResult(candidate));
-results.insert(std::move(result));
+if (CompilerType candidate = 
ClangASTContext::GetTypeForDecl(decl))
+{
+result = true;
+
std::unique_ptr result(new 
ObjCScavengerResult(candidate));
+results.insert(std::move(result));
+}
 }
 }
 }
 }
 }
 }
+
 return result;
 }
 

Added: lldb/trunk/test/functionalities/type_lookup/Makefile
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/test/functionalities/type_lookup/Makefile?rev=249117&view=auto
==
--- lldb/trunk/test/functionalities/type_lookup/Makefile (added)
+++ lldb/trunk/test/functionalities/type_lookup/Makefile Thu Oct  1 20:23:11 
2015
@@ -0,0 +1,9 @@
+LEVEL = ../../make
+
+OBJC_SOURCES := main.m
+
+CFLAGS_EXTRAS += -w
+
+include $(LEVEL)/Makefile.rules
+
+LDFLAGS += -framework Foundation

Added: lldb/trunk/test/functionalities/type_lookup/TestType

73 matches

Mail list logo