[Lldb-commits] [lldb] r309664 - Expose process instance info via SB API

2017-08-01 Thread Vadim Macagon via lldb-commits
Author: enlight
Date: Tue Aug  1 00:34:26 2017
New Revision: 309664

URL: http://llvm.org/viewvc/llvm-project?rev=309664&view=rev
Log:
Expose process instance info via SB API

Summary:
Implement SBProcessInfo to wrap lldb_private::ProcessInstanceInfo,
and add SBProcess::GetProcessInfo() to retrieve info like parent ID,
group ID, user ID etc. from a live process.

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

Added:
lldb/trunk/include/lldb/API/SBProcessInfo.h

lldb/trunk/packages/Python/lldbsuite/test/python_api/default-constructor/sb_process_info.py
lldb/trunk/scripts/interface/SBProcessInfo.i
lldb/trunk/source/API/SBProcessInfo.cpp
Modified:
lldb/trunk/include/lldb/API/LLDB.h
lldb/trunk/include/lldb/API/SBDefines.h
lldb/trunk/include/lldb/API/SBFileSpec.h
lldb/trunk/include/lldb/API/SBProcess.h

lldb/trunk/packages/Python/lldbsuite/test/python_api/default-constructor/TestDefaultConstructorForAPIObjects.py

lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
lldb/trunk/scripts/interface/SBProcess.i
lldb/trunk/scripts/lldb.swig
lldb/trunk/source/API/CMakeLists.txt
lldb/trunk/source/API/SBProcess.cpp

Modified: lldb/trunk/include/lldb/API/LLDB.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/LLDB.h?rev=309664&r1=309663&r2=309664&view=diff
==
--- lldb/trunk/include/lldb/API/LLDB.h (original)
+++ lldb/trunk/include/lldb/API/LLDB.h Tue Aug  1 00:34:26 2017
@@ -49,6 +49,7 @@
 #include "lldb/API/SBModuleSpec.h"
 #include "lldb/API/SBPlatform.h"
 #include "lldb/API/SBProcess.h"
+#include "lldb/API/SBProcessInfo.h"
 #include "lldb/API/SBQueue.h"
 #include "lldb/API/SBQueueItem.h"
 #include "lldb/API/SBSection.h"

Modified: lldb/trunk/include/lldb/API/SBDefines.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBDefines.h?rev=309664&r1=309663&r2=309664&view=diff
==
--- lldb/trunk/include/lldb/API/SBDefines.h (original)
+++ lldb/trunk/include/lldb/API/SBDefines.h Tue Aug  1 00:34:26 2017
@@ -65,6 +65,7 @@ class LLDB_API SBModule;
 class LLDB_API SBModuleSpec;
 class LLDB_API SBModuleSpecList;
 class LLDB_API SBProcess;
+class LLDB_API SBProcessInfo;
 class LLDB_API SBQueue;
 class LLDB_API SBQueueItem;
 class LLDB_API SBSection;

Modified: lldb/trunk/include/lldb/API/SBFileSpec.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBFileSpec.h?rev=309664&r1=309663&r2=309664&view=diff
==
--- lldb/trunk/include/lldb/API/SBFileSpec.h (original)
+++ lldb/trunk/include/lldb/API/SBFileSpec.h Tue Aug  1 00:34:26 2017
@@ -65,6 +65,7 @@ private:
   friend class SBModuleSpec;
   friend class SBPlatform;
   friend class SBProcess;
+  friend class SBProcessInfo;
   friend class SBSourceManager;
   friend class SBThread;
   friend class SBTarget;

Modified: lldb/trunk/include/lldb/API/SBProcess.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBProcess.h?rev=309664&r1=309663&r2=309664&view=diff
==
--- lldb/trunk/include/lldb/API/SBProcess.h (original)
+++ lldb/trunk/include/lldb/API/SBProcess.h Tue Aug  1 00:34:26 2017
@@ -12,6 +12,7 @@
 
 #include "lldb/API/SBDefines.h"
 #include "lldb/API/SBError.h"
+#include "lldb/API/SBProcessInfo.h"
 #include "lldb/API/SBQueue.h"
 #include "lldb/API/SBTarget.h"
 #include 
@@ -380,6 +381,15 @@ public:
   //--
   lldb::SBMemoryRegionInfoList GetMemoryRegions();
 
+  //--
+  /// Return information about the process.
+  ///
+  /// Valid process info will only be returned when the process is
+  /// alive, use SBProcessInfo::IsValid() to check returned info is
+  /// valid.
+  //--
+  lldb::SBProcessInfo GetProcessInfo();
+
 protected:
   friend class SBAddress;
   friend class SBBreakpoint;

Added: lldb/trunk/include/lldb/API/SBProcessInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBProcessInfo.h?rev=309664&view=auto
==
--- lldb/trunk/include/lldb/API/SBProcessInfo.h (added)
+++ lldb/trunk/include/lldb/API/SBProcessInfo.h Tue Aug  1 00:34:26 2017
@@ -0,0 +1,64 @@
+//===-- SBProcessInfo.h -*- C++ 
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLDB_SBProces

[Lldb-commits] [lldb] r309803 - Fix ProcessAPITestCase.test_get_process_info

2017-08-02 Thread Vadim Macagon via lldb-commits
Author: enlight
Date: Wed Aug  2 03:12:12 2017
New Revision: 309803

URL: http://llvm.org/viewvc/llvm-project?rev=309803&view=rev
Log:
Fix ProcessAPITestCase.test_get_process_info

Modified:

lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py?rev=309803&r1=309802&r2=309803&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py 
(original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/python_api/process/TestProcessAPI.py 
Wed Aug  2 03:12:12 2017
@@ -328,7 +328,6 @@ class ProcessAPITestCase(TestBase):
 
 @add_test_categories(['pyapi'])
 @no_debug_info_test
-@expectedFailureAll() # broken bots
 def test_get_process_info(self):
 """Test SBProcess::GetProcessInfo() API with a locally launched 
process."""
 self.build()
@@ -350,7 +349,7 @@ class ProcessAPITestCase(TestBase):
 if not error.Success():
 self.fail("Failed to launch process")
 
-# Verify all process info can be retrieved successfully
+# Verify basic process info can be retrieved successfully
 process_info = process.GetProcessInfo()
 self.assertTrue(process_info.IsValid())
 file_spec = process_info.GetExecutableFile()
@@ -363,29 +362,42 @@ class ProcessAPITestCase(TestBase):
 process_info.GetProcessID(), lldb.LLDB_INVALID_PROCESS_ID,
 "Process ID is valid")
 
-if self.getPlatform() != 'windows':
-self.assertTrue(process_info.UserIDIsValid())
+# Additional process info varies by platform, so just check that
+# whatever info was retrieved is consistent and nothing blows up.
+if process_info.UserIDIsValid():
 self.assertNotEqual(
 process_info.GetUserID(), lldb.UINT32_MAX,
 "Process user ID is valid")
-self.assertTrue(process_info.GroupIDIsValid())
+else:
+self.assertEqual(
+process_info.GetUserID(), lldb.UINT32_MAX,
+"Process user ID is invalid")
+
+if process_info.GroupIDIsValid():
 self.assertNotEqual(
 process_info.GetGroupID(), lldb.UINT32_MAX,
 "Process group ID is valid")
-self.assertTrue(process_info.EffectiveUserIDIsValid())
+else:
+self.assertEqual(
+process_info.GetGroupID(), lldb.UINT32_MAX,
+"Process group ID is invalid")
+
+if process_info.EffectiveUserIDIsValid():
 self.assertNotEqual(
 process_info.GetEffectiveUserID(), lldb.UINT32_MAX,
 "Process effective user ID is valid")
-self.assertTrue(process_info.EffectiveGroupIDIsValid())
+else:
+self.assertEqual(
+process_info.GetEffectiveUserID(), lldb.UINT32_MAX,
+"Process effective user ID is invalid")
+
+if process_info.EffectiveGroupIDIsValid():
 self.assertNotEqual(
 process_info.GetEffectiveGroupID(), lldb.UINT32_MAX,
 "Process effective group ID is valid")
-self.assertNotEqual(
-process_info.GetParentProcessID(), 
lldb.LLDB_INVALID_PROCESS_ID,
-"Parent process ID is valid"
-)
+else:
+self.assertEqual(
+process_info.GetEffectiveGroupID(), lldb.UINT32_MAX,
+"Process effective group ID is invalid")
 
-# Verify that a dead process doesn't yield stale process info
-process.Kill()
-process_info = process.GetProcessInfo()
-self.assertFalse(process_info.IsValid())
+process_info.GetParentProcessID()


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


[Lldb-commits] [lldb] r310452 - Expose active and available platform lists via SBDebugger API

2017-08-09 Thread Vadim Macagon via lldb-commits
Author: enlight
Date: Wed Aug  9 02:20:40 2017
New Revision: 310452

URL: http://llvm.org/viewvc/llvm-project?rev=310452&view=rev
Log:
Expose active and available platform lists via SBDebugger API

Summary:
The available platform list was previously only accessible via the
`platform list` command, this patch makes it possible to access that
list via the SBDebugger API. The active platform list has likewise
been exposed via the SBDebugger API.

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

Added:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py
Modified:
lldb/trunk/include/lldb/API/SBDebugger.h
lldb/trunk/include/lldb/API/SBStructuredData.h

lldb/trunk/packages/Python/lldbsuite/test/python_api/default-constructor/sb_debugger.py
lldb/trunk/scripts/interface/SBDebugger.i
lldb/trunk/source/API/SBDebugger.cpp

Modified: lldb/trunk/include/lldb/API/SBDebugger.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBDebugger.h?rev=310452&r1=310451&r2=310452&view=diff
==
--- lldb/trunk/include/lldb/API/SBDebugger.h (original)
+++ lldb/trunk/include/lldb/API/SBDebugger.h Wed Aug  9 02:20:40 2017
@@ -132,6 +132,25 @@ public:
 
   void SetSelectedPlatform(lldb::SBPlatform &platform);
 
+  /// Get the number of currently active platforms.
+  uint32_t GetNumPlatforms();
+
+  /// Get one of the currently active platforms.
+  lldb::SBPlatform GetPlatformAtIndex(uint32_t idx);
+
+  /// Get the number of available platforms.
+  ///
+  /// The return value should match the number of entries output by the
+  /// "platform list" command.
+  uint32_t GetNumAvailablePlatforms();
+
+  /// Get the name and description of one of the available platforms.
+  ///
+  /// @param[in] idx
+  /// Zero-based index of the platform for which info should be retrieved,
+  /// must be less than the value returned by GetNumAvailablePlatforms().
+  lldb::SBStructuredData GetAvailablePlatformInfoAtIndex(uint32_t idx);
+
   lldb::SBSourceManager GetSourceManager();
 
   // REMOVE: just for a quick fix, need to expose platforms through

Modified: lldb/trunk/include/lldb/API/SBStructuredData.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBStructuredData.h?rev=310452&r1=310451&r2=310452&view=diff
==
--- lldb/trunk/include/lldb/API/SBStructuredData.h (original)
+++ lldb/trunk/include/lldb/API/SBStructuredData.h Wed Aug  9 02:20:40 2017
@@ -98,6 +98,7 @@ public:
 
 protected:
   friend class SBTraceOptions;
+  friend class SBDebugger;
 
   StructuredDataImplUP m_impl_up;
 };

Added: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py?rev=310452&view=auto
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py
 (added)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py
 Wed Aug  9 02:20:40 2017
@@ -0,0 +1,70 @@
+"""
+Test the lldb platform Python API.
+"""
+
+from __future__ import print_function
+
+
+import os
+import time
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class PlatformPythonTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@add_test_categories(['pyapi'])
+@no_debug_info_test
+def test_platform_list(self):
+"""Test SBDebugger::GetNumPlatforms() & GetPlatformAtIndex() API"""
+# Verify there's only the host platform present by default.
+self.assertEqual(self.dbg.GetNumPlatforms(), 1)
+host_platform = self.dbg.GetPlatformAtIndex(0)
+self.assertTrue(host_platform.IsValid() and
+host_platform.GetName() == 'host',
+'Only the host platform is available')
+# Select another platform and verify that the platform is added to
+# the platform list.
+platform_idx = self.dbg.GetNumAvailablePlatforms() - 1
+if platform_idx < 1:
+self.fail('No platforms other than host are available')
+platform_data = self.dbg.GetAvailablePlatformInfoAtIndex(platform_idx)
+platform_name = 
platform_data.GetValueForKey('name').GetStringValue(100)
+self.assertNotEqual(platform_name, 'host')
+self.dbg.SetCurrentPlatform(platform_name)
+selected_platform = self.dbg.GetSelectedPlatform()
+self.assertTrue(selected_platform.IsValid())
+self.assertEqual(selected_platform.GetName(), platform_name)
+self.assertEqual(self.dbg.GetNumPlatforms(), 2)
+platform = self.dbg.G

[Lldb-commits] [lldb] r310488 - Fix PlatformPythonTestCase.test_platform_list for the build bots

2017-08-09 Thread Vadim Macagon via lldb-commits
Author: enlight
Date: Wed Aug  9 08:49:15 2017
New Revision: 310488

URL: http://llvm.org/viewvc/llvm-project?rev=310488&view=rev
Log:
Fix PlatformPythonTestCase.test_platform_list for the build bots

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py?rev=310488&r1=310487&r2=310488&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/platform/TestPlatformPython.py
 Wed Aug  9 08:49:15 2017
@@ -21,12 +21,13 @@ class PlatformPythonTestCase(TestBase):
 @no_debug_info_test
 def test_platform_list(self):
 """Test SBDebugger::GetNumPlatforms() & GetPlatformAtIndex() API"""
-# Verify there's only the host platform present by default.
-self.assertEqual(self.dbg.GetNumPlatforms(), 1)
+# Verify the host platform is present by default.
+initial_num_platforms = self.dbg.GetNumPlatforms()
+self.assertGreater(initial_num_platforms, 0)
 host_platform = self.dbg.GetPlatformAtIndex(0)
 self.assertTrue(host_platform.IsValid() and
 host_platform.GetName() == 'host',
-'Only the host platform is available')
+'The host platform is present')
 # Select another platform and verify that the platform is added to
 # the platform list.
 platform_idx = self.dbg.GetNumAvailablePlatforms() - 1
@@ -39,9 +40,14 @@ class PlatformPythonTestCase(TestBase):
 selected_platform = self.dbg.GetSelectedPlatform()
 self.assertTrue(selected_platform.IsValid())
 self.assertEqual(selected_platform.GetName(), platform_name)
-self.assertEqual(self.dbg.GetNumPlatforms(), 2)
-platform = self.dbg.GetPlatformAtIndex(1)
-self.assertEqual(platform.GetName(), platform_name)
+self.assertEqual(self.dbg.GetNumPlatforms(), initial_num_platforms + 1)
+platform_found = False
+for platform_idx in range(self.dbg.GetNumPlatforms()):
+platform = self.dbg.GetPlatformAtIndex(platform_idx)
+if platform.GetName() == platform_name:
+platform_found = True
+break
+self.assertTrue(platform_found)
 
 @add_test_categories(['pyapi'])
 @no_debug_info_test


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


[Lldb-commits] [PATCH] D25486: Fix lookup path for lldb-mi

2016-10-11 Thread Vadim Macagon via lldb-commits
enlight added a comment.

In https://reviews.llvm.org/D25486#567722, @zturner wrote:

> Heh.  It just occurred to me that this is probably the reason why all of the 
> `lldb-mi` tests fail on Windows.  Because `.exe` is not appended.  I'm not 
> ready to turn that on and deal with all the failures just yet, but for now 
> can you please add a `#TODO` right above this that says `"Append .exe on 
> Windows"`


Yep, I had to fix this locally just the other day, but all the tests still fail 
:)


https://reviews.llvm.org/D25486



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


[Lldb-commits] [lldb] r284100 - Fix Python binding generation build step on Windows

2016-10-12 Thread Vadim Macagon via lldb-commits
Author: enlight
Date: Wed Oct 12 23:07:22 2016
New Revision: 284100

URL: http://llvm.org/viewvc/llvm-project?rev=284100&view=rev
Log:
Fix Python binding generation build step on Windows

Summary:
If Python is installed to a location that contains spaces
(e.g. "C:\Program Files\Python3") then the build fails while attempting
to run the modify-python-lldb.py script because the path to the Python
executable is not double-quoted before being passed to the shell. The
fix consists of letting Python handle the formatting of the command
line, since subprocess.Popen() is perfectly capable of handling paths
containing spaces if it's given the command and arguments as a list
instead of a single pre-formatted string.

Reviewers: zturner, clayborg

Subscribers: lldb-commits

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

Modified:
lldb/trunk/scripts/Python/prepare_binding_Python.py

Modified: lldb/trunk/scripts/Python/prepare_binding_Python.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/prepare_binding_Python.py?rev=284100&r1=284099&r2=284100&view=diff
==
--- lldb/trunk/scripts/Python/prepare_binding_Python.py (original)
+++ lldb/trunk/scripts/Python/prepare_binding_Python.py Wed Oct 12 23:07:22 2016
@@ -264,8 +264,9 @@ def run_python_script(script_and_args):
 @param script_and_args the python script to execute, along with
 the command line arguments to pass to it.
 """
-command_line = "%s %s" % (sys.executable, script_and_args)
-process = subprocess.Popen(command_line, shell=True)
+command = [sys.executable] + script_and_args
+command_line = " ".join(command)
+process = subprocess.Popen(command, shell=False)
 script_stdout, script_stderr = process.communicate()
 return_code = process.returncode
 if return_code != 0:
@@ -294,8 +295,7 @@ def do_modify_python_lldb(options, confi
 logging.error("failed to find python script: '%s'", script_path)
 sys.exit(-11)
 
-script_invocation = "%s %s" % (script_path, config_build_dir)
-run_python_script(script_invocation)
+run_python_script([script_path, config_build_dir])
 
 
 def get_python_module_path(options):


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


[Lldb-commits] [PATCH] D25592: [LLDB-MI] Minor cleanup of CMICmnLLDBUtilSBValue class

2016-10-13 Thread Vadim Macagon via lldb-commits
enlight created this revision.
enlight added reviewers: ki.stfu, abidh.
enlight added a subscriber: LLDB.
enlight set the repository for this revision to rL LLVM.

Placeholder c-strings don't need to be instance variables.


Repository:
  rL LLVM

https://reviews.llvm.org/D25592

Files:
  tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
  tools/lldb-mi/MICmnLLDBUtilSBValue.h

Index: tools/lldb-mi/MICmnLLDBUtilSBValue.h
===
--- tools/lldb-mi/MICmnLLDBUtilSBValue.h
+++ tools/lldb-mi/MICmnLLDBUtilSBValue.h
@@ -70,8 +70,6 @@
   // Attributes:
 private:
   lldb::SBValue &m_rValue;
-  const char *m_pUnkwn;
-  const char *m_pComposite;
   bool m_bValidSBValue; // True = SBValue is a valid object, false = not valid.
   bool m_bHandleCharType;  // True = Yes return text molding to char type, false
// = just return data.
Index: tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
===
--- tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
+++ tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
@@ -18,6 +18,9 @@
 #include "MICmnMIValueTuple.h"
 #include "MIUtilString.h"
 
+static const char *kUnknownValue = "??";
+static const char *kCompositeValuePlaceholder = "{...}";
+
 //++
 //
 // Details: CMICmnLLDBUtilSBValue constructor.
@@ -32,8 +35,8 @@
 CMICmnLLDBUtilSBValue::CMICmnLLDBUtilSBValue(
 const lldb::SBValue &vrValue, const bool vbHandleCharType /* = false */,
 const bool vbHandleArrayType /* = true */)
-: m_rValue(const_cast(vrValue)), m_pUnkwn("??"),
-  m_pComposite("{...}"), m_bHandleCharType(vbHandleCharType),
+: m_rValue(const_cast(vrValue)),
+  m_bHandleCharType(vbHandleCharType),
   m_bHandleArrayType(vbHandleArrayType) {
   m_bValidSBValue = m_rValue.IsValid();
 }
@@ -80,7 +83,7 @@
 CMIUtilString CMICmnLLDBUtilSBValue::GetValue(
 const bool vbExpandAggregates /* = false */) const {
   if (!m_bValidSBValue)
-return m_pUnkwn;
+return kUnknownValue;
 
   CMICmnLLDBDebugSessionInfo &rSessionInfo(
   CMICmnLLDBDebugSessionInfo::Instance());
@@ -98,7 +101,7 @@
 return value;
 
   if (!vbExpandAggregates && !bPrintExpandAggregates)
-return m_pComposite;
+return kCompositeValuePlaceholder;
 
   bool bPrintAggregateFieldNames = false;
   bPrintAggregateFieldNames =
@@ -110,7 +113,7 @@
   CMICmnMIValueTuple miValueTuple;
   const bool bOk = GetCompositeValue(bPrintAggregateFieldNames, miValueTuple);
   if (!bOk)
-return m_pUnkwn;
+return kUnknownValue;
 
   value = miValueTuple.GetString();
   return value;
@@ -131,11 +134,11 @@
CMIUtilString &vwrValue) const {
   const MIuint nChildren = m_rValue.GetNumChildren();
   if (nChildren == 0) {
-vwrValue = GetValueSummary(!m_bHandleCharType && IsCharType(), m_pUnkwn);
+vwrValue = GetValueSummary(!m_bHandleCharType && IsCharType(), kUnknownValue);
 return MIstatus::success;
   } else if (IsPointerType()) {
 vwrValue =
-GetValueSummary(!m_bHandleCharType && IsPointeeCharType(), m_pUnkwn);
+GetValueSummary(!m_bHandleCharType && IsPointeeCharType(), kUnknownValue);
 return MIstatus::success;
   } else if (IsArrayType()) {
 CMICmnLLDBDebugSessionInfo &rSessionInfo(
@@ -187,13 +190,13 @@
 miValueTuple, vnDepth + 1);
   if (!bOk)
 // Can't obtain composite type
-value = m_pUnkwn;
+value = kUnknownValue;
   else
 // OK. Value is composite and was successfully got
 value = miValueTuple.GetString();
 } else {
   // Need to get value from composite type, but vnMaxDepth is reached
-  value = m_pComposite;
+  value = kCompositeValuePlaceholder;
 }
 const bool bNoQuotes = true;
 const CMICmnMIValueConst miValueConst(value, bNoQuotes);
@@ -404,7 +407,7 @@
 const MIuint64 nReadBytes =
 process.ReadMemory(addr, &ch, sizeof(ch), error);
 if (error.Fail() || nReadBytes != sizeof(ch))
-  return m_pUnkwn;
+  return kUnknownValue;
 else if (ch == 0)
   break;
 result.append(
@@ -425,7 +428,7 @@
 //--
 bool CMICmnLLDBUtilSBValue::IsNameUnknown() const {
   const CMIUtilString name(GetName());
-  return (name == m_pUnkwn);
+  return (name == kUnknownValue);
 }
 
 //++
@@ -438,7 +441,7 @@
 //--
 bool CMICmnLLDBUtilSBValue::IsValueUnknown() const {
   const CMIUtilString value(GetValue());
-  return (value == m_pUnkwn);
+  return (value == kUnknownValue);
 }
 
 //++
@@ -451,7 +454,7 @@
 //--
 CMIUtilString CMICmnLLDBUtilSBValue::GetTypeName() const {
   const char *pName = m_bValidSBValue ? m_rValue.GetTypeName() : nullptr;
-  const CMIUtilString text((pName != nullptr) ? pName : m_pUnkwn);
+  const CMIUtilString text((pName != nullptr) ? pName : kUnknownValue);
 
   return text;
 }
@@ -466,7 +469,7 @@

[Lldb-commits] [PATCH] D25592: [LLDB-MI] Minor cleanup of CMICmnLLDBUtilSBValue class

2016-10-13 Thread Vadim Macagon via lldb-commits
enlight added inline comments.



Comment at: tools/lldb-mi/MICmnLLDBUtilSBValue.cpp:21-22
 
+static const char *kUnknownValue = "??";
+static const char *kCompositeValuePlaceholder = "{...}";
+

ki.stfu wrote:
> use unnamed namespace here
I would like to use an anonymous namespace but the [[ 
http://llvm.org/docs/CodingStandards.html#anonymous-namespaces | LLVM coding 
standards ]] say

> make anonymous namespaces as small as possible, and only use them for class 
> declarations

I don't really buy their reasoning, but we are supposed to be following their 
style now aren't we?

kUnresolvedValue/kUnresolvedCompositeValue does sound better, I'll rename them.


Repository:
  rL LLVM

https://reviews.llvm.org/D25592



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


[Lldb-commits] [PATCH] D25592: [LLDB-MI] Minor cleanup of CMICmnLLDBUtilSBValue class

2016-10-14 Thread Vadim Macagon via lldb-commits
enlight updated this revision to Diff 74622.
enlight added a comment.

Renamed placeholder c-strings.


Repository:
  rL LLVM

https://reviews.llvm.org/D25592

Files:
  tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
  tools/lldb-mi/MICmnLLDBUtilSBValue.h

Index: tools/lldb-mi/MICmnLLDBUtilSBValue.h
===
--- tools/lldb-mi/MICmnLLDBUtilSBValue.h
+++ tools/lldb-mi/MICmnLLDBUtilSBValue.h
@@ -70,8 +70,6 @@
   // Attributes:
 private:
   lldb::SBValue &m_rValue;
-  const char *m_pUnkwn;
-  const char *m_pComposite;
   bool m_bValidSBValue; // True = SBValue is a valid object, false = not valid.
   bool m_bHandleCharType;  // True = Yes return text molding to char type, false
// = just return data.
Index: tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
===
--- tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
+++ tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
@@ -18,6 +18,9 @@
 #include "MICmnMIValueTuple.h"
 #include "MIUtilString.h"
 
+static const char *kUnresolvedValue = "??";
+static const char *kUnresolvedCompositeValue = "{...}";
+
 //++
 //
 // Details: CMICmnLLDBUtilSBValue constructor.
@@ -32,8 +35,8 @@
 CMICmnLLDBUtilSBValue::CMICmnLLDBUtilSBValue(
 const lldb::SBValue &vrValue, const bool vbHandleCharType /* = false */,
 const bool vbHandleArrayType /* = true */)
-: m_rValue(const_cast(vrValue)), m_pUnkwn("??"),
-  m_pComposite("{...}"), m_bHandleCharType(vbHandleCharType),
+: m_rValue(const_cast(vrValue)),
+  m_bHandleCharType(vbHandleCharType),
   m_bHandleArrayType(vbHandleArrayType) {
   m_bValidSBValue = m_rValue.IsValid();
 }
@@ -80,7 +83,7 @@
 CMIUtilString CMICmnLLDBUtilSBValue::GetValue(
 const bool vbExpandAggregates /* = false */) const {
   if (!m_bValidSBValue)
-return m_pUnkwn;
+return kUnresolvedValue;
 
   CMICmnLLDBDebugSessionInfo &rSessionInfo(
   CMICmnLLDBDebugSessionInfo::Instance());
@@ -98,7 +101,7 @@
 return value;
 
   if (!vbExpandAggregates && !bPrintExpandAggregates)
-return m_pComposite;
+return kUnresolvedCompositeValue;
 
   bool bPrintAggregateFieldNames = false;
   bPrintAggregateFieldNames =
@@ -110,7 +113,7 @@
   CMICmnMIValueTuple miValueTuple;
   const bool bOk = GetCompositeValue(bPrintAggregateFieldNames, miValueTuple);
   if (!bOk)
-return m_pUnkwn;
+return kUnresolvedValue;
 
   value = miValueTuple.GetString();
   return value;
@@ -131,11 +134,11 @@
CMIUtilString &vwrValue) const {
   const MIuint nChildren = m_rValue.GetNumChildren();
   if (nChildren == 0) {
-vwrValue = GetValueSummary(!m_bHandleCharType && IsCharType(), m_pUnkwn);
+vwrValue = GetValueSummary(!m_bHandleCharType && IsCharType(), kUnresolvedValue);
 return MIstatus::success;
   } else if (IsPointerType()) {
 vwrValue =
-GetValueSummary(!m_bHandleCharType && IsPointeeCharType(), m_pUnkwn);
+GetValueSummary(!m_bHandleCharType && IsPointeeCharType(), kUnresolvedValue);
 return MIstatus::success;
   } else if (IsArrayType()) {
 CMICmnLLDBDebugSessionInfo &rSessionInfo(
@@ -187,13 +190,13 @@
 miValueTuple, vnDepth + 1);
   if (!bOk)
 // Can't obtain composite type
-value = m_pUnkwn;
+value = kUnresolvedValue;
   else
 // OK. Value is composite and was successfully got
 value = miValueTuple.GetString();
 } else {
   // Need to get value from composite type, but vnMaxDepth is reached
-  value = m_pComposite;
+  value = kUnresolvedCompositeValue;
 }
 const bool bNoQuotes = true;
 const CMICmnMIValueConst miValueConst(value, bNoQuotes);
@@ -404,7 +407,7 @@
 const MIuint64 nReadBytes =
 process.ReadMemory(addr, &ch, sizeof(ch), error);
 if (error.Fail() || nReadBytes != sizeof(ch))
-  return m_pUnkwn;
+  return kUnresolvedValue;
 else if (ch == 0)
   break;
 result.append(
@@ -425,7 +428,7 @@
 //--
 bool CMICmnLLDBUtilSBValue::IsNameUnknown() const {
   const CMIUtilString name(GetName());
-  return (name == m_pUnkwn);
+  return (name == kUnresolvedValue);
 }
 
 //++
@@ -438,7 +441,7 @@
 //--
 bool CMICmnLLDBUtilSBValue::IsValueUnknown() const {
   const CMIUtilString value(GetValue());
-  return (value == m_pUnkwn);
+  return (value == kUnresolvedValue);
 }
 
 //++
@@ -451,7 +454,7 @@
 //--
 CMIUtilString CMICmnLLDBUtilSBValue::GetTypeName() const {
   const char *pName = m_bValidSBValue ? m_rValue.GetTypeName() : nullptr;
-  const CMIUtilString text((pName != nullptr) ? pName : m_pUnkwn);
+  const CMIUtilString text((pName != nullptr) ? pName : kUnresolvedValue);
 
   return text;
 }
@@ -466,7 +469,7 @@
 //--
 CMIUtilString CMICmnLLDBUtilSBValue::GetTypeNameDisplay() const {
   const char *pName

[Lldb-commits] [PATCH] D25592: [LLDB-MI] Minor cleanup of CMICmnLLDBUtilSBValue class

2016-10-14 Thread Vadim Macagon via lldb-commits
enlight updated this revision to Diff 74628.
enlight marked an inline comment as done.
enlight added a comment.

Rename `kUnresolvedValue` back to `kUknownValue`.


Repository:
  rL LLVM

https://reviews.llvm.org/D25592

Files:
  tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
  tools/lldb-mi/MICmnLLDBUtilSBValue.h

Index: tools/lldb-mi/MICmnLLDBUtilSBValue.h
===
--- tools/lldb-mi/MICmnLLDBUtilSBValue.h
+++ tools/lldb-mi/MICmnLLDBUtilSBValue.h
@@ -70,8 +70,6 @@
   // Attributes:
 private:
   lldb::SBValue &m_rValue;
-  const char *m_pUnkwn;
-  const char *m_pComposite;
   bool m_bValidSBValue; // True = SBValue is a valid object, false = not valid.
   bool m_bHandleCharType;  // True = Yes return text molding to char type, false
// = just return data.
Index: tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
===
--- tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
+++ tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
@@ -18,6 +18,9 @@
 #include "MICmnMIValueTuple.h"
 #include "MIUtilString.h"
 
+static const char *kUnknownValue = "??";
+static const char *kUnresolvedCompositeValue = "{...}";
+
 //++
 //
 // Details: CMICmnLLDBUtilSBValue constructor.
@@ -32,8 +35,8 @@
 CMICmnLLDBUtilSBValue::CMICmnLLDBUtilSBValue(
 const lldb::SBValue &vrValue, const bool vbHandleCharType /* = false */,
 const bool vbHandleArrayType /* = true */)
-: m_rValue(const_cast(vrValue)), m_pUnkwn("??"),
-  m_pComposite("{...}"), m_bHandleCharType(vbHandleCharType),
+: m_rValue(const_cast(vrValue)),
+  m_bHandleCharType(vbHandleCharType),
   m_bHandleArrayType(vbHandleArrayType) {
   m_bValidSBValue = m_rValue.IsValid();
 }
@@ -80,7 +83,7 @@
 CMIUtilString CMICmnLLDBUtilSBValue::GetValue(
 const bool vbExpandAggregates /* = false */) const {
   if (!m_bValidSBValue)
-return m_pUnkwn;
+return kUnknownValue;
 
   CMICmnLLDBDebugSessionInfo &rSessionInfo(
   CMICmnLLDBDebugSessionInfo::Instance());
@@ -98,7 +101,7 @@
 return value;
 
   if (!vbExpandAggregates && !bPrintExpandAggregates)
-return m_pComposite;
+return kUnresolvedCompositeValue;
 
   bool bPrintAggregateFieldNames = false;
   bPrintAggregateFieldNames =
@@ -110,7 +113,7 @@
   CMICmnMIValueTuple miValueTuple;
   const bool bOk = GetCompositeValue(bPrintAggregateFieldNames, miValueTuple);
   if (!bOk)
-return m_pUnkwn;
+return kUnknownValue;
 
   value = miValueTuple.GetString();
   return value;
@@ -131,11 +134,11 @@
CMIUtilString &vwrValue) const {
   const MIuint nChildren = m_rValue.GetNumChildren();
   if (nChildren == 0) {
-vwrValue = GetValueSummary(!m_bHandleCharType && IsCharType(), m_pUnkwn);
+vwrValue = GetValueSummary(!m_bHandleCharType && IsCharType(), kUnknownValue);
 return MIstatus::success;
   } else if (IsPointerType()) {
 vwrValue =
-GetValueSummary(!m_bHandleCharType && IsPointeeCharType(), m_pUnkwn);
+GetValueSummary(!m_bHandleCharType && IsPointeeCharType(), kUnknownValue);
 return MIstatus::success;
   } else if (IsArrayType()) {
 CMICmnLLDBDebugSessionInfo &rSessionInfo(
@@ -187,13 +190,13 @@
 miValueTuple, vnDepth + 1);
   if (!bOk)
 // Can't obtain composite type
-value = m_pUnkwn;
+value = kUnknownValue;
   else
 // OK. Value is composite and was successfully got
 value = miValueTuple.GetString();
 } else {
   // Need to get value from composite type, but vnMaxDepth is reached
-  value = m_pComposite;
+  value = kUnresolvedCompositeValue;
 }
 const bool bNoQuotes = true;
 const CMICmnMIValueConst miValueConst(value, bNoQuotes);
@@ -404,7 +407,7 @@
 const MIuint64 nReadBytes =
 process.ReadMemory(addr, &ch, sizeof(ch), error);
 if (error.Fail() || nReadBytes != sizeof(ch))
-  return m_pUnkwn;
+  return kUnknownValue;
 else if (ch == 0)
   break;
 result.append(
@@ -425,7 +428,7 @@
 //--
 bool CMICmnLLDBUtilSBValue::IsNameUnknown() const {
   const CMIUtilString name(GetName());
-  return (name == m_pUnkwn);
+  return (name == kUnknownValue);
 }
 
 //++
@@ -438,7 +441,7 @@
 //--
 bool CMICmnLLDBUtilSBValue::IsValueUnknown() const {
   const CMIUtilString value(GetValue());
-  return (value == m_pUnkwn);
+  return (value == kUnknownValue);
 }
 
 //++
@@ -451,7 +454,7 @@
 //--
 CMIUtilString CMICmnLLDBUtilSBValue::GetTypeName() const {
   const char *pName = m_bValidSBValue ? m_rValue.GetTypeName() : nullptr;
-  const CMIUtilString text((pName != nullptr) ? pName : m_pUnkwn);
+  const CMIUtilString text((pName != nullptr) ? pName : kUnknownValue);
 
   return text;
 }
@@ -466,7 +469,7 @@
 //--
 CMIUtilString CMICmnLLDBUtilSBValue::GetTypeNameDisplay

[Lldb-commits] [PATCH] D25592: [LLDB-MI] Minor cleanup of CMICmnLLDBUtilSBValue class

2016-10-14 Thread Vadim Macagon via lldb-commits
enlight marked an inline comment as done.
enlight added inline comments.



Comment at: tools/lldb-mi/MICmnLLDBUtilSBValue.cpp:116
   if (!bOk)
-return m_pUnkwn;
+return kUnresolvedValue;
 

ki.stfu wrote:
> After couple of minutes I see the lack of logic there: the value is still 
> composite but we return kUnresolvedValue instead of kUnresolvedCompositeValue.
> 
> I think we have to rename kUnresolvedValue back to kUnknownValue.
Yep, good point, I've renamed it back.


Repository:
  rL LLVM

https://reviews.llvm.org/D25592



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


[Lldb-commits] [lldb] r284231 - [LLDB-MI] Minor cleanup of CMICmnLLDBUtilSBValue class

2016-10-14 Thread Vadim Macagon via lldb-commits
Author: enlight
Date: Fri Oct 14 07:58:02 2016
New Revision: 284231

URL: http://llvm.org/viewvc/llvm-project?rev=284231&view=rev
Log:
[LLDB-MI] Minor cleanup of CMICmnLLDBUtilSBValue class

Summary:
Placeholder c-strings don't need to be instance variables.

Reviewers: ki.stfu, abidh

Subscribers: lldb-commits

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

Modified:
lldb/trunk/tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
lldb/trunk/tools/lldb-mi/MICmnLLDBUtilSBValue.h

Modified: lldb/trunk/tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-mi/MICmnLLDBUtilSBValue.cpp?rev=284231&r1=284230&r2=284231&view=diff
==
--- lldb/trunk/tools/lldb-mi/MICmnLLDBUtilSBValue.cpp (original)
+++ lldb/trunk/tools/lldb-mi/MICmnLLDBUtilSBValue.cpp Fri Oct 14 07:58:02 2016
@@ -18,6 +18,9 @@
 #include "MICmnMIValueTuple.h"
 #include "MIUtilString.h"
 
+static const char *kUnknownValue = "??";
+static const char *kUnresolvedCompositeValue = "{...}";
+
 //++
 
//
 // Details: CMICmnLLDBUtilSBValue constructor.
@@ -32,8 +35,8 @@
 CMICmnLLDBUtilSBValue::CMICmnLLDBUtilSBValue(
 const lldb::SBValue &vrValue, const bool vbHandleCharType /* = false */,
 const bool vbHandleArrayType /* = true */)
-: m_rValue(const_cast(vrValue)), m_pUnkwn("??"),
-  m_pComposite("{...}"), m_bHandleCharType(vbHandleCharType),
+: m_rValue(const_cast(vrValue)),
+  m_bHandleCharType(vbHandleCharType),
   m_bHandleArrayType(vbHandleArrayType) {
   m_bValidSBValue = m_rValue.IsValid();
 }
@@ -80,7 +83,7 @@ CMIUtilString CMICmnLLDBUtilSBValue::Get
 CMIUtilString CMICmnLLDBUtilSBValue::GetValue(
 const bool vbExpandAggregates /* = false */) const {
   if (!m_bValidSBValue)
-return m_pUnkwn;
+return kUnknownValue;
 
   CMICmnLLDBDebugSessionInfo &rSessionInfo(
   CMICmnLLDBDebugSessionInfo::Instance());
@@ -98,7 +101,7 @@ CMIUtilString CMICmnLLDBUtilSBValue::Get
 return value;
 
   if (!vbExpandAggregates && !bPrintExpandAggregates)
-return m_pComposite;
+return kUnresolvedCompositeValue;
 
   bool bPrintAggregateFieldNames = false;
   bPrintAggregateFieldNames =
@@ -110,7 +113,7 @@ CMIUtilString CMICmnLLDBUtilSBValue::Get
   CMICmnMIValueTuple miValueTuple;
   const bool bOk = GetCompositeValue(bPrintAggregateFieldNames, miValueTuple);
   if (!bOk)
-return m_pUnkwn;
+return kUnknownValue;
 
   value = miValueTuple.GetString();
   return value;
@@ -131,11 +134,11 @@ bool CMICmnLLDBUtilSBValue::GetSimpleVal
CMIUtilString &vwrValue) const {
   const MIuint nChildren = m_rValue.GetNumChildren();
   if (nChildren == 0) {
-vwrValue = GetValueSummary(!m_bHandleCharType && IsCharType(), m_pUnkwn);
+vwrValue = GetValueSummary(!m_bHandleCharType && IsCharType(), 
kUnknownValue);
 return MIstatus::success;
   } else if (IsPointerType()) {
 vwrValue =
-GetValueSummary(!m_bHandleCharType && IsPointeeCharType(), m_pUnkwn);
+GetValueSummary(!m_bHandleCharType && IsPointeeCharType(), 
kUnknownValue);
 return MIstatus::success;
   } else if (IsArrayType()) {
 CMICmnLLDBDebugSessionInfo &rSessionInfo(
@@ -187,13 +190,13 @@ bool CMICmnLLDBUtilSBValue::GetComposite
 miValueTuple, vnDepth + 1);
   if (!bOk)
 // Can't obtain composite type
-value = m_pUnkwn;
+value = kUnknownValue;
   else
 // OK. Value is composite and was successfully got
 value = miValueTuple.GetString();
 } else {
   // Need to get value from composite type, but vnMaxDepth is reached
-  value = m_pComposite;
+  value = kUnresolvedCompositeValue;
 }
 const bool bNoQuotes = true;
 const CMICmnMIValueConst miValueConst(value, bNoQuotes);
@@ -404,7 +407,7 @@ CMICmnLLDBUtilSBValue::ReadCStringFromHo
 const MIuint64 nReadBytes =
 process.ReadMemory(addr, &ch, sizeof(ch), error);
 if (error.Fail() || nReadBytes != sizeof(ch))
-  return m_pUnkwn;
+  return kUnknownValue;
 else if (ch == 0)
   break;
 result.append(
@@ -425,7 +428,7 @@ CMICmnLLDBUtilSBValue::ReadCStringFromHo
 //--
 bool CMICmnLLDBUtilSBValue::IsNameUnknown() const {
   const CMIUtilString name(GetName());
-  return (name == m_pUnkwn);
+  return (name == kUnknownValue);
 }
 
 //++
@@ -438,7 +441,7 @@ bool CMICmnLLDBUtilSBValue::IsNameUnknow
 //--
 bool CMICmnLLDBUtilSBValue::IsValueUnknown() const {
   const CMIUtilString value(GetValue());
-  return (value == m_pUnkwn);
+  return (value == kUnknownValue);
 }
 
 //++
@@ -451,7 +454,7 @@ bool CMICmnLLDBUtilSBValue::IsValueUnkno
 //--
 CMIUtilString CMICmnLLDBUtilSBValue::GetTypeName() const {
   const char *pName = m_bValidSBValue ? m_rValue.GetTypeName() : nullptr;
-  const CMIUt

[Lldb-commits] [PATCH] D25592: [LLDB-MI] Minor cleanup of CMICmnLLDBUtilSBValue class

2016-10-14 Thread Vadim Macagon via lldb-commits
This revision was automatically updated to reflect the committed changes.
enlight marked an inline comment as done.
Closed by commit rL284231: [LLDB-MI] Minor cleanup of CMICmnLLDBUtilSBValue 
class (authored by enlight).

Changed prior to commit:
  https://reviews.llvm.org/D25592?vs=74628&id=74667#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D25592

Files:
  lldb/trunk/tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
  lldb/trunk/tools/lldb-mi/MICmnLLDBUtilSBValue.h

Index: lldb/trunk/tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
===
--- lldb/trunk/tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
+++ lldb/trunk/tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
@@ -18,6 +18,9 @@
 #include "MICmnMIValueTuple.h"
 #include "MIUtilString.h"
 
+static const char *kUnknownValue = "??";
+static const char *kUnresolvedCompositeValue = "{...}";
+
 //++
 //
 // Details: CMICmnLLDBUtilSBValue constructor.
@@ -32,8 +35,8 @@
 CMICmnLLDBUtilSBValue::CMICmnLLDBUtilSBValue(
 const lldb::SBValue &vrValue, const bool vbHandleCharType /* = false */,
 const bool vbHandleArrayType /* = true */)
-: m_rValue(const_cast(vrValue)), m_pUnkwn("??"),
-  m_pComposite("{...}"), m_bHandleCharType(vbHandleCharType),
+: m_rValue(const_cast(vrValue)),
+  m_bHandleCharType(vbHandleCharType),
   m_bHandleArrayType(vbHandleArrayType) {
   m_bValidSBValue = m_rValue.IsValid();
 }
@@ -80,7 +83,7 @@
 CMIUtilString CMICmnLLDBUtilSBValue::GetValue(
 const bool vbExpandAggregates /* = false */) const {
   if (!m_bValidSBValue)
-return m_pUnkwn;
+return kUnknownValue;
 
   CMICmnLLDBDebugSessionInfo &rSessionInfo(
   CMICmnLLDBDebugSessionInfo::Instance());
@@ -98,7 +101,7 @@
 return value;
 
   if (!vbExpandAggregates && !bPrintExpandAggregates)
-return m_pComposite;
+return kUnresolvedCompositeValue;
 
   bool bPrintAggregateFieldNames = false;
   bPrintAggregateFieldNames =
@@ -110,7 +113,7 @@
   CMICmnMIValueTuple miValueTuple;
   const bool bOk = GetCompositeValue(bPrintAggregateFieldNames, miValueTuple);
   if (!bOk)
-return m_pUnkwn;
+return kUnknownValue;
 
   value = miValueTuple.GetString();
   return value;
@@ -131,11 +134,11 @@
CMIUtilString &vwrValue) const {
   const MIuint nChildren = m_rValue.GetNumChildren();
   if (nChildren == 0) {
-vwrValue = GetValueSummary(!m_bHandleCharType && IsCharType(), m_pUnkwn);
+vwrValue = GetValueSummary(!m_bHandleCharType && IsCharType(), kUnknownValue);
 return MIstatus::success;
   } else if (IsPointerType()) {
 vwrValue =
-GetValueSummary(!m_bHandleCharType && IsPointeeCharType(), m_pUnkwn);
+GetValueSummary(!m_bHandleCharType && IsPointeeCharType(), kUnknownValue);
 return MIstatus::success;
   } else if (IsArrayType()) {
 CMICmnLLDBDebugSessionInfo &rSessionInfo(
@@ -187,13 +190,13 @@
 miValueTuple, vnDepth + 1);
   if (!bOk)
 // Can't obtain composite type
-value = m_pUnkwn;
+value = kUnknownValue;
   else
 // OK. Value is composite and was successfully got
 value = miValueTuple.GetString();
 } else {
   // Need to get value from composite type, but vnMaxDepth is reached
-  value = m_pComposite;
+  value = kUnresolvedCompositeValue;
 }
 const bool bNoQuotes = true;
 const CMICmnMIValueConst miValueConst(value, bNoQuotes);
@@ -404,7 +407,7 @@
 const MIuint64 nReadBytes =
 process.ReadMemory(addr, &ch, sizeof(ch), error);
 if (error.Fail() || nReadBytes != sizeof(ch))
-  return m_pUnkwn;
+  return kUnknownValue;
 else if (ch == 0)
   break;
 result.append(
@@ -425,7 +428,7 @@
 //--
 bool CMICmnLLDBUtilSBValue::IsNameUnknown() const {
   const CMIUtilString name(GetName());
-  return (name == m_pUnkwn);
+  return (name == kUnknownValue);
 }
 
 //++
@@ -438,7 +441,7 @@
 //--
 bool CMICmnLLDBUtilSBValue::IsValueUnknown() const {
   const CMIUtilString value(GetValue());
-  return (value == m_pUnkwn);
+  return (value == kUnknownValue);
 }
 
 //++
@@ -451,7 +454,7 @@
 //--
 CMIUtilString CMICmnLLDBUtilSBValue::GetTypeName() const {
   const char *pName = m_bValidSBValue ? m_rValue.GetTypeName() : nullptr;
-  const CMIUtilString text((pName != nullptr) ? pName : m_pUnkwn);
+  const CMIUtilString text((pName != nullptr) ? pName : kUnknownValue);
 
   return text;
 }
@@ -466,7 +469,7 @@
 //--
 CMIUtilString CMICmnLLDBUtilSBValue::GetTypeNameDisplay() const {
   const char *pName = m_bValidSBValue ? m_rValue.GetDisplayTypeName() : nullptr;
-  const CMIUtilString text((pName != nullptr) ? pName : m_pUnkwn);
+  const CMIUtilString text((pName != nullptr) ? pName : kUnknownValue);
 
   return text;
 }
Index: lldb/trunk/tools/lldb-mi/MICmnLLDBUtilSBValue.h
===

[Lldb-commits] [PATCH] D26124: [LLDB-MI] Escape MI output in a more consistent manner

2016-10-29 Thread Vadim Macagon via lldb-commits
enlight created this revision.
enlight added reviewers: ki.stfu, abidh.
enlight added a subscriber: LLDB.
enlight set the repository for this revision to rL LLVM.

While attempting to run lldb-mi on Windows it became apparent that it doesn't 
consistently escape output, for instance error messages contained paths with 
unescaped backslashes, and unescaped double-quotes. To address this issue 
without spending a ridiculous amount of time trying to track down every case 
where output isn't properly escaped I've opted to move all escaping into 
`CMICmnMIValueConst`. `CMICmnMIValueConst` is the basic building block of all 
output emitted by lldb-mi, so handling escaping in a consistent manner here 
will help to ensure all output is properly escaped. This change required 
removing any existing escaping of output to prevent double-escaping.

I've also removed the spacing code from `CMICmnMIValueTuple` and 
`CMICmnMIValueResult`, it was only misused to format composite values in 
`CMICmnLLDBUtilSBValue::GetCompositeValue()`. The format of composite values 
isn't specified by the GDB-MI spec, and as such these values shouldn't be built 
using `CMICmnMIValueTuple`, `CMICmnMIValueResult`, and `CMICmnMIValueConst`.


Repository:
  rL LLVM

https://reviews.llvm.org/D26124

Files:
  packages/Python/lldbsuite/test/tools/lldb-mi/syntax/TestMiSyntax.py
  packages/Python/lldbsuite/test/tools/lldb-mi/variable/TestMiGdbSetShowPrint.py
  tools/lldb-mi/MICmdCmdData.cpp
  tools/lldb-mi/MICmdCmdVar.cpp
  tools/lldb-mi/MICmnLLDBDebugSessionInfo.cpp
  tools/lldb-mi/MICmnLLDBDebugSessionInfo.h
  tools/lldb-mi/MICmnLLDBDebugSessionInfoVarObj.cpp
  tools/lldb-mi/MICmnLLDBDebuggerHandleEvents.cpp
  tools/lldb-mi/MICmnLLDBUtilSBValue.cpp
  tools/lldb-mi/MICmnLLDBUtilSBValue.h
  tools/lldb-mi/MICmnMIValueConst.cpp
  tools/lldb-mi/MICmnMIValueConst.h
  tools/lldb-mi/MICmnMIValueResult.cpp
  tools/lldb-mi/MICmnMIValueResult.h
  tools/lldb-mi/MICmnMIValueTuple.cpp
  tools/lldb-mi/MICmnMIValueTuple.h

Index: tools/lldb-mi/MICmnMIValueTuple.h
===
--- tools/lldb-mi/MICmnMIValueTuple.h
+++ tools/lldb-mi/MICmnMIValueTuple.h
@@ -38,12 +38,9 @@
 public:
   /* ctor */ CMICmnMIValueTuple();
   /* ctor */ CMICmnMIValueTuple(const CMICmnMIValueResult &vResult);
-  /* ctor */ CMICmnMIValueTuple(const CMICmnMIValueResult &vResult,
-const bool vbUseSpacing);
   //
   void Add(const CMICmnMIValueResult &vResult);
-  void Add(const CMICmnMIValueResult &vResult, const bool vbUseSpacing);
-  void Add(const CMICmnMIValueConst &vValue, const bool vbUseSpacing);
+  void Add(const CMICmnMIValueConst &vValue);
   CMIUtilString ExtractContentNoBrackets() const;
 
   // Overridden:
@@ -56,9 +53,4 @@
   void BuildTuple();
   void BuildTuple(const CMICmnMIValueResult &vResult);
   void BuildTuple(const CMIUtilString &vValue);
-
-  // Attributes:
-private:
-  bool m_bSpaceAfterComma; // True = put space separators into the string, false
-   // = no spaces used
 };
Index: tools/lldb-mi/MICmnMIValueTuple.cpp
===
--- tools/lldb-mi/MICmnMIValueTuple.cpp
+++ tools/lldb-mi/MICmnMIValueTuple.cpp
@@ -18,7 +18,7 @@
 // Return:  None.
 // Throws:  None.
 //--
-CMICmnMIValueTuple::CMICmnMIValueTuple() : m_bSpaceAfterComma(false) {
+CMICmnMIValueTuple::CMICmnMIValueTuple() {
   m_strValue = "{}";
 }
 
@@ -30,26 +30,7 @@
 // Return:  None.
 // Throws:  None.
 //--
-CMICmnMIValueTuple::CMICmnMIValueTuple(const CMICmnMIValueResult &vResult)
-: m_bSpaceAfterComma(false) {
-  m_strValue = vResult.GetString();
-  BuildTuple();
-  m_bJustConstructed = false;
-}
-
-//++
-//
-// Details: CMICmnMIValueTuple constructor.
-// Type:Method.
-// Args:vResult - (R) MI result object.
-//  vbUseSpacing- (R) True = put space separators into the string,
-//  false = no spaces used.
-// Return:  None.
-// Throws:  None.
-//--
-CMICmnMIValueTuple::CMICmnMIValueTuple(const CMICmnMIValueResult &vResult,
-   const bool vbUseSpacing)
-: m_bSpaceAfterComma(vbUseSpacing) {
+CMICmnMIValueTuple::CMICmnMIValueTuple(const CMICmnMIValueResult &vResult) {
   m_strValue = vResult.GetString();
   BuildTuple();
   m_bJustConstructed = false;
@@ -74,8 +55,7 @@
 // Throws:  None.
 //--
 void CMICmnMIValueTuple::BuildTuple() {
-  const char *pFormat = "{%s}";
-  m_strValue = CMIUtilString::Format(pFormat, m_strValue.c_str());
+  m_strValue = CMIUtilString::Format("{%s}", m_strValue.c_str());
 }
 
 //++
@@ -102,8 +82,7 @@
 m_strValue = m_strValue.substr(0, m_strValue.size() - 1);
   }
 
-  const char *pFormat = m_bSpaceAfterComma ? "{%s, %s}" : "{%s,%s}";
-  m_strValue = CMIUtilString::Format(pFormat, m_strValue.c_str(),
+  m_strValue = CMIUtilString::Format("{%s,%s}", m_st

[Lldb-commits] [PATCH] D26124: [LLDB-MI] Escape MI output in a more consistent manner

2016-11-02 Thread Vadim Macagon via lldb-commits
enlight added a comment.

Thanks for the review. `AddSlashes` is still used in a couple of places (but 
not for escaping MI output), so I'll leave it be for now.


Repository:
  rL LLVM

https://reviews.llvm.org/D26124



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


[Lldb-commits] [PATCH] D26124: [LLDB-MI] Escape MI output in a more consistent manner

2016-11-07 Thread Vadim Macagon via lldb-commits
enlight added a comment.

@ki.stfu Are you OK with this going in?


Repository:
  rL LLVM

https://reviews.llvm.org/D26124



___
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-09-29 Thread Vadim Macagon via lldb-commits
enlight planned changes to this revision.
enlight added a comment.

I'll submit a revised patch that contains an explanation of the generator 
expressions to aid future maintainers/contributors.



Comment at: cmake/modules/LLDBConfig.cmake:61
@@ +60,3 @@
+  # below, otherwise CMake will replace the whitespace with a semicolon in 
some contexts (which would stuff things up).
+  set (PYTHON_EXECUTABLE 
$<$:${PYTHON_DEBUG_EXE}>$<$>:${PYTHON_RELEASE_EXE}>)
+  set (PYTHON_LIBRARY 
$<$:${PYTHON_DEBUG_LIB}>$<$>:${PYTHON_RELEASE_LIB}>)

zturner wrote:
> enlight wrote:
> > zturner wrote:
> > > This line is hard to parse mentally, and I'm not sure I've seen this kind 
> > > of nested generator expression.  I trust you when you say it's right, but 
> > > can you explain what this does?
> > Sure thing.
> > 
> >   # `$` evaluates to `1` when the `Debug` configuration is 
> > being generated, or `0` in all other cases.
> >   # `$<$:${PYTHON_DEBUG_EXE}>` expands to 
> > `${PYTHON_DEBUG_EXE}` when the `Debug` configuration is being generated, or 
> > nothing (literally) in all other cases.
> >   # `$<$>:${PYTHON_RELEASE_EXE}>` expands to 
> > `${PYTHON_RELEASE_EXE}` when any configuration other than `Debug` is being 
> > generated, or nothing in all other cases.
> > 
> > Since the conditionals in 2 & 3 are mutually exclusive, and a conditional 
> > expression that evaluates to `0` yields no value at all, it's possible to 
> > concatenate them to obtain a single value. This value will be 
> > `${PYTHON_DEBUG_EXE}` when generating the Debug configuration, or 
> > `${PYTHON_RELEASE_EXE}` when generating any other configuration.
> Ahh, I understand.  Is it equivalent to write this:
> 
> if ($ == 1)
>   set(PYTHON_EXECUTABLE ${PYTHON_DEBUG_EXE})
> else()
>   set(PYTHON_EXECUTABLE ${PYTHON_RELEASE_EXE})
> endif()
> 
> ?  If so, I kind of prefer this way, if nothing else so that other people 
> will be able to understand it in the future if they go to edit this code.
Unfortunately that's not currently possible because the `if` command doesn't 
support generator expressions (not that the docs mention it or anything). So 
while CMake won't complain if you did this:

```
if ($)
  set (PYTHON_EXECUTABLE ${PYTHON_DEBUG_EXE})
else ()
  set (PYTHON_EXECUTABLE ${PYTHON_RELEASE_EXE})
endif ()
```

It wouldn't actually work as intended because the `if/else` is only evaluated 
once during the configuration step rather than per-build-configuration (during 
the generation step).


Repository:
  rL LLVM

http://reviews.llvm.org/D13234



___
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-09-30 Thread Vadim Macagon via lldb-commits
enlight updated this revision to Diff 36072.
enlight added a comment.
This revision is now accepted and ready to land.

Added an explanation of the generator expression used in this patch.


Repository:
  rL LLVM

http://reviews.llvm.org/D13234

Files:
  cmake/modules/LLDBConfig.cmake

Index: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ 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: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ 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 

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

2015-10-02 Thread Vadim Macagon via lldb-commits
enlight added a comment.

That looks fine to me. CMake prints those messages during the configuration 
step, at that point the generator expressions haven't been expanded yet. I 
could prettify those messages a bit to read: `Found PythonLibs: 
C:/Python27_LLDB/x86/libs/python27_d.lib and 
C:/Python27_LLDB/x86/libs/python27.lib`.


Repository:
  rL LLVM

http://reviews.llvm.org/D13234



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


Re: [Lldb-commits] [PATCH] D13404: Teach CMake to find versions of Python != 2.7

2015-10-03 Thread Vadim Macagon via lldb-commits
enlight added inline comments.


Comment at: cmake/modules/LLDBConfig.cmake:109
@@ +108,3 @@
+  set (PYTHON_EXECUTABLE 
$<$:${PYTHON_DEBUG_EXE}>$<$>:${PYTHON_RELEASE_EXE}>
 PARENT_SCOPE)
+  set (PYTHON_LIBRARY 
$<$:${PYTHON_DEBUG_LIB}>$<$>:${PYTHON_RELEASE_LIB}>
 PARENT_SCOPE)
+  set (PYTHON_DLL 
$<$:${PYTHON_DEBUG_DLL}>$<$>:${PYTHON_RELEASE_DLL}>
 PARENT_SCOPE)

PYTHON_LIBRARY is used in this scope later on, so it needs to be explicitly set 
for both this scope and the parent scope, like so:

```
set (PYTHON_LIBRARY 
$<$:${PYTHON_DEBUG_LIB}>$<$>:${PYTHON_RELEASE_LIB}>)
set (PYTHON_LIBRARY ${PYTHON_LIBRARY} PARENT_SCOPE)
```



Comment at: cmake/modules/LLDBConfig.cmake:112-114
@@ +111,5 @@
+
+  if (NOT LLDB_RELOCATABLE_PYTHON)
+add_definitions( -DLLDB_PYTHON_HOME="${PYTHON_HOME}" )
+  endif()
+

I think this belongs outside this function, along with `include_directories` 
below.


Comment at: cmake/modules/LLDBConfig.cmake:117
@@ +116,3 @@
+  if (PYTHON_LIBRARY)
+include_directories(${PYTHON_INCLUDE_DIR})
+  endif()

This command will never be executed because PYTHON_LIBRARY is only set in the 
parent scope. However, I'd prefer `include_directories()` wasn't here at all, 
let the caller of `find_python_libs_windows` do that instead so that the 
behavior is more similar to the built-in [[ 
https://cmake.org/cmake/help/v2.8.12/cmake.html#module:FindPythonLibs | 
FindPythonLibs ]] module (which means `PYTHON_INCLUDE_DIRS` should be made 
available in the parent scope, note the extra `S`).


Comment at: cmake/modules/LLDBConfig.cmake:131-133
@@ -104,1 +130,5 @@
+find_python_libs_windows()
+message("-- Found PythonExecutable: ${PYTHON_EXECUTABLE}")
+message("-- Found PythonLibs: ${PYTHON_LIBRARY}")
+message("-- Found PythonDLL: ${PYTHON_DLL}")
   else()

Please move these into `find_python_libs_windows()`, as I'll need access to the 
debug/release paths in order to avoid printing out the generator expressions.


Comment at: cmake/modules/LLDBStandalone.cmake:51-53
@@ -50,5 +50,5 @@
 
   # Verify that we can find a Python 2 interpreter.  Python 3 is unsupported.
   if (PYTHON_EXECUTABLE STREQUAL "")
-set(Python_ADDITIONAL_VERSIONS 2.7 2.6 2.5)
+set(Python_ADDITIONAL_VERSIONS 3.5 3.4 3.3 3.2 3.1 3.0 2.7 2.6 2.5)
 include(FindPythonInterp)

The comment no longer seems accurate.


http://reviews.llvm.org/D13404



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


Re: [Lldb-commits] [PATCH] D13404: Teach CMake to find versions of Python != 2.7

2015-10-03 Thread Vadim Macagon via lldb-commits
enlight added inline comments.


Comment at: cmake/modules/LLDBConfig.cmake:56
@@ +55,3 @@
+message("LLDB embedded Python on Windows requires specifying a value for 
PYTHON_HOME.  Python support disabled.")
+set(LLDB_DISABLE_PYTHON 1)
+return()

This will only set `LLDB_DISABLE_PYTHON` inside the function, you probably want 
to do `set (LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)`, or `set (LLDB_DISABLE_PYTHON 
1 CACHE INTERNAL "")` instead.


Comment at: cmake/modules/LLDBConfig.cmake:73
@@ +72,3 @@
+message("Python support will be disabled for this build.")
+set(LLDB_DISABLE_PYTHON 1)
+return()

Ditto.


http://reviews.llvm.org/D13404



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


Re: [Lldb-commits] [PATCH] D13201: Fix segmentation fault in lldb_private::Symbols::LocateExecutableSymbolFile()

2015-10-04 Thread Vadim Macagon via lldb-commits
enlight updated this revision to Diff 36468.
enlight added a comment.

Added a couple of unit tests, the Windows-specific cleanups will be submitted 
in a separate patch.


Repository:
  rL LLVM

http://reviews.llvm.org/D13201

Files:
  source/Host/common/Symbols.cpp
  unittests/Host/CMakeLists.txt
  unittests/Host/SymbolsTest.cpp

Index: unittests/Host/SymbolsTest.cpp
===
--- /dev/null
+++ unittests/Host/SymbolsTest.cpp
@@ -0,0 +1,30 @@
+//===-- SymbolsTest.cpp -*- C++ 
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "gtest/gtest.h"
+#include "lldb/Host/Symbols.h"
+#include "lldb/Core/ModuleSpec.h"
+
+using namespace lldb_private;
+
+TEST(SymbolsTest, 
LocateExecutableSymbolFileForUnknownExecutableAndUnknownSymbolFile)
+{
+ModuleSpec module_spec;
+FileSpec symbol_file_spec = 
Symbols::LocateExecutableSymbolFile(module_spec);
+EXPECT_TRUE(symbol_file_spec.GetFilename().IsEmpty());
+}
+
+TEST(SymbolsTest, 
LocateExecutableSymbolFileForUnknownExecutableAndMissingSymbolFile)
+{
+ModuleSpec module_spec;
+// using a GUID here because the symbol file shouldn't actually exist on 
disk
+
module_spec.GetSymbolFileSpec().SetFile("4A524676-B24B-4F4E-968A-551D465EBAF1.so",
 false);
+FileSpec symbol_file_spec = 
Symbols::LocateExecutableSymbolFile(module_spec);
+EXPECT_TRUE(symbol_file_spec.GetFilename().IsEmpty());
+}
Index: unittests/Host/CMakeLists.txt
===
--- unittests/Host/CMakeLists.txt
+++ unittests/Host/CMakeLists.txt
@@ -1,4 +1,5 @@
 add_lldb_unittest(HostTests
   SocketAddressTest.cpp
   SocketTest.cpp
+  SymbolsTest.cpp
   )
Index: source/Host/common/Symbols.cpp
===
--- source/Host/common/Symbols.cpp
+++ source/Host/common/Symbols.cpp
@@ -249,10 +249,6 @@
 uuid_str = uuid_str + ".debug";
 }
 
-// Get directory of our module. Needed to check debug files like this:
-//   /usr/lib/debug/usr/lib/library.so.debug
-std::string module_directory = 
module_spec.GetFileSpec().GetDirectory().AsCString();
-
 size_t num_directories = debug_file_search_paths.GetSize();
 for (size_t idx = 0; idx < num_directories; ++idx)
 {
@@ -267,7 +263,11 @@
 files.push_back (dirname + "/" + symbol_filename);
 files.push_back (dirname + "/.debug/" + symbol_filename);
 files.push_back (dirname + "/.build-id/" + uuid_str);
-files.push_back (dirname + module_directory + "/" + 
symbol_filename);
+
+// Some debug files may stored in the module directory like this:
+//   /usr/lib/debug/usr/lib/library.so.debug
+if (!file_dir.IsEmpty())
+files.push_back (dirname + file_dir.AsCString() + "/" + 
symbol_filename);
 
 const uint32_t num_files = files.size();
 for (size_t idx_file = 0; idx_file < num_files; ++idx_file)


Index: unittests/Host/SymbolsTest.cpp
===
--- /dev/null
+++ unittests/Host/SymbolsTest.cpp
@@ -0,0 +1,30 @@
+//===-- SymbolsTest.cpp -*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "gtest/gtest.h"
+#include "lldb/Host/Symbols.h"
+#include "lldb/Core/ModuleSpec.h"
+
+using namespace lldb_private;
+
+TEST(SymbolsTest, LocateExecutableSymbolFileForUnknownExecutableAndUnknownSymbolFile)
+{
+ModuleSpec module_spec;
+FileSpec symbol_file_spec = Symbols::LocateExecutableSymbolFile(module_spec);
+EXPECT_TRUE(symbol_file_spec.GetFilename().IsEmpty());
+}
+
+TEST(SymbolsTest, LocateExecutableSymbolFileForUnknownExecutableAndMissingSymbolFile)
+{
+ModuleSpec module_spec;
+// using a GUID here because the symbol file shouldn't actually exist on disk
+module_spec.GetSymbolFileSpec().SetFile("4A524676-B24B-4F4E-968A-551D465EBAF1.so", false);
+FileSpec symbol_file_spec = Symbols::LocateExecutableSymbolFile(module_spec);
+EXPECT_TRUE(symbol_file_spec.GetFilename().IsEmpty());
+}
Index: unittests/Host/CMakeLists.txt
===
--- unittests/Host/CMakeLists.txt
+++ unittests/Host/CMakeLists.txt
@@ -1,4 +1,5 @@
 add_lldb_unittest(HostTests
   SocketAddressTest.cpp
   SocketTest.cpp
+  SymbolsTest.cpp
   )
Index: source/Host/common/Symb

Re: [Lldb-commits] [PATCH] D13404: Teach CMake to find versions of Python != 2.7

2015-10-05 Thread Vadim Macagon via lldb-commits
enlight added inline comments.


Comment at: cmake/modules/LLDBConfig.cmake:113
@@ +112,3 @@
+  set (PYTHON_LIBRARY ${PYTHON_LIBRARY} PARENT_SCOPE)
+  set (PYTHON_DLL ${PYTHON_LIBRARY} PYTHON_DLL PARENT_SCOPE)
+  set (PYTHON_INCLUDE_DIRS ${PYTHON_INCLUDE_DIRS} PARENT_SCOPE)

You missed :P


Comment at: cmake/modules/LLDBConfig.cmake:140
@@ -106,1 +139,3 @@
+  
+  if (PYTHON_LIBRARY)
 include_directories(${PYTHON_INCLUDE_DIRS})

Can we make this `if (PYTHON_INCLUDE_DIRS)` instead?


http://reviews.llvm.org/D13404



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


[Lldb-commits] [PATCH] D13520: Make CMake display more readable paths to Python binaries on Windows

2015-10-07 Thread Vadim Macagon via lldb-commits
enlight created this revision.
enlight added reviewers: zturner, brucem.
enlight added a subscriber: lldb-commits.
enlight set the repository for this revision to rL LLVM.

Previously CMake would display messages like these:

```
-- LLDB Found PythonExecutable: 
$<$:C:/Projects/Python-2.7.9-bin/x64/python_d.exe>$<$>:C:/Projects/Python-2.7.9-bin/x64/python.exe>
-- LLDB Found PythonLibs: 
$<$:C:/Projects/Python-2.7.9-bin/x64/libs/python27_d.lib>$<$>:C:/Projects/Python-2.7.9-bin/x64/libs/python27.lib>
-- LLDB Found PythonDLL: 
$<$:C:/Projects/Python-2.7.9-bin/x64/python27_d.dll>$<$>:C:/Projects/Python-2.7.9-bin/x64/python27.dll>
```

This patch makes the messages look like this:

```
-- LLDB Found PythonExecutable: C:/Projects/Python-2.7.9-bin/x64/python.exe and 
C:/Projects/Python-2.7.9-bin/x64/python_d.exe
-- LLDB Found PythonLibs: C:/Projects/Python-2.7.9-bin/x64/libs/python27.lib 
and C:/Projects/Python-2.7.9-bin/x64/libs/python27_d.lib
-- LLDB Found PythonDLL: C:/Projects/Python-2.7.9-bin/x64/python27.dll and 
C:/Projects/Python-2.7.9-bin/x64/python27_d.dll
```

I've also added checks to ensure the messages are actually accurate, as in 
check that the files actually exist before claiming they've been found. If any 
of the files are missing Python integration will be disabled for the build.

Repository:
  rL LLVM

http://reviews.llvm.org/D13520

Files:
  cmake/modules/LLDBConfig.cmake

Index: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ cmake/modules/LLDBConfig.cmake
@@ -82,6 +82,42 @@
   file(TO_CMAKE_PATH "${PYTHON_HOME}/python.exe" PYTHON_RELEASE_EXE)
   file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/${PYTHONLIBS_BASE_NAME}.lib" 
PYTHON_RELEASE_LIB)
   file(TO_CMAKE_PATH "${PYTHON_HOME}/${PYTHONLIBS_BASE_NAME}.dll" 
PYTHON_RELEASE_DLL)
+  
+  if (NOT EXISTS ${PYTHON_DEBUG_EXE})
+message("Unable to find ${PYTHON_DEBUG_EXE}")
+unset(PYTHON_DEBUG_EXE)
+  endif()
+  
+  if (NOT EXISTS ${PYTHON_RELEASE_EXE})
+message("Unable to find ${PYTHON_RELEASE_EXE}")
+unset(PYTHON_RELEASE_EXE)
+  endif()
+  
+  if (NOT EXISTS ${PYTHON_DEBUG_LIB})
+message("Unable to find ${PYTHON_DEBUG_LIB}")
+unset(PYTHON_DEBUG_LIB)
+  endif()
+  
+  if (NOT EXISTS ${PYTHON_RELEASE_LIB})
+message("Unable to find ${PYTHON_RELEASE_LIB}")
+unset(PYTHON_RELEASE_LIB)
+  endif()
+  
+  if (NOT EXISTS ${PYTHON_DEBUG_DLL})
+message("Unable to find ${PYTHON_DEBUG_DLL}")
+unset(PYTHON_DEBUG_DLL)
+  endif()
+  
+  if (NOT EXISTS ${PYTHON_RELEASE_DLL})
+message("Unable to find ${PYTHON_RELEASE_DLL}")
+unset(PYTHON_RELEASE_DLL)
+  endif()
+  
+  if (NOT (PYTHON_DEBUG_EXE AND PYTHON_RELEASE_EXE AND PYTHON_DEBUG_LIB AND 
PYTHON_RELEASE_LIB AND PYTHON_DEBUG_DLL AND PYTHON_RELEASE_DLL))
+message("Python installation is corrupt. Python support will be disabled 
for this build.")
+set(LLDB_DISABLE_PYTHON 1 PARENT_SCOPE)
+return()
+  endif()
 
   # Generator expressions are evaluated in the context of each build 
configuration generated
   # by CMake. Here we use the $:VALUE logical generator 
expression to ensure
@@ -113,9 +149,9 @@
   set (PYTHON_DLL ${PYTHON_DLL} PARENT_SCOPE)
   set (PYTHON_INCLUDE_DIRS ${PYTHON_INCLUDE_DIRS} PARENT_SCOPE)
 
-  message("-- LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE}")
-  message("-- LLDB Found PythonLibs: ${PYTHON_LIBRARY}")
-  message("-- LLDB Found PythonDLL: ${PYTHON_DLL}")
+  message("-- LLDB Found PythonExecutable: ${PYTHON_RELEASE_EXE} and 
${PYTHON_DEBUG_EXE}")
+  message("-- LLDB Found PythonLibs: ${PYTHON_RELEASE_LIB} and 
${PYTHON_DEBUG_LIB}")
+  message("-- LLDB Found PythonDLL: ${PYTHON_RELEASE_DLL} and 
${PYTHON_DEBUG_DLL}")
   message("-- LLDB Found PythonIncludeDirs: ${PYTHON_INCLUDE_DIRS}")
 endfunction(find_python_libs_windows)
 


Index: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ cmake/modules/LLDBConfig.cmake
@@ -82,6 +82,42 @@
   file(TO_CMAKE_PATH "${PYTHON_HOME}/python.exe" PYTHON_RELEASE_EXE)
   file(TO_CMAKE_PATH "${PYTHON_HOME}/libs/${PYTHONLIBS_BASE_NAME}.lib" PYTHON_RELEASE_LIB)
   file(TO_CMAKE_PATH "${PYTHON_HOME}/${PYTHONLIBS_BASE_NAME}.dll" PYTHON_RELEASE_DLL)
+  
+  if (NOT EXISTS ${PYTHON_DEBUG_EXE})
+message("Unable to find ${PYTHON_DEBUG_EXE}")
+unset(PYTHON_DEBUG_EXE)
+  endif()
+  
+  if (NOT EXISTS ${PYTHON_RELEASE_EXE})
+message("Unable to find ${PYTHON_RELEASE_EXE}")
+unset(PYTHON_RELEASE_EXE)
+  endif()
+  
+  if (NOT EXISTS ${PYTHON_DEBUG_LIB})
+message("Unable to find ${PYTHON_DEBUG_LIB}")
+unset(PYTHON_DEBUG_LIB)
+  endif()
+  
+  if (NOT EXISTS ${PYTHON_RELEASE_LIB})
+message("Unable to find ${PYTHON_RELEASE_LIB}")
+unset(PYTHON_RELEASE_LIB)
+  endif()
+  
+  if (NOT EXISTS ${PYTHON_DEBUG_DLL})
+message("Unable to find ${PYTHON_DEBUG_DLL}")
+unset(PYTHON_DEBUG_DLL)
+  endif()
+  
+  if (NOT

Re: [Lldb-commits] [PATCH] D13404: Teach CMake to find versions of Python != 2.7

2015-10-08 Thread Vadim Macagon via lldb-commits
enlight added a comment.

Hi Zach,

Can you close this issue please?


http://reviews.llvm.org/D13404



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


[Lldb-commits] [PATCH] D13636: Symbols::LocateExecutableSymbolFile() shouldn't try to look for files in /usr/lib/debug on Windows

2015-10-11 Thread Vadim Macagon via lldb-commits
enlight created this revision.
enlight added reviewers: zturner, clayborg.
enlight added a subscriber: lldb-commits.
enlight set the repository for this revision to rL LLVM.

`/usr/lib/debug` doesn't exist on Windows so there's no point even attempting 
to look for symbol files in there.

Repository:
  rL LLVM

http://reviews.llvm.org/D13636

Files:
  source/Host/common/Symbols.cpp

Index: source/Host/common/Symbols.cpp
===
--- source/Host/common/Symbols.cpp
+++ source/Host/common/Symbols.cpp
@@ -235,8 +235,10 @@
 // Add current working directory.
 debug_file_search_paths.AppendIfUnique (FileSpec(".", true));
 
+#ifndef LLVM_ON_WIN32
 // Add /usr/lib/debug directory.
 debug_file_search_paths.AppendIfUnique (FileSpec("/usr/lib/debug", 
true));
+#endif // LLVM_ON_WIN32
 
 std::string uuid_str;
 const UUID &module_uuid = module_spec.GetUUID();


Index: source/Host/common/Symbols.cpp
===
--- source/Host/common/Symbols.cpp
+++ source/Host/common/Symbols.cpp
@@ -235,8 +235,10 @@
 // Add current working directory.
 debug_file_search_paths.AppendIfUnique (FileSpec(".", true));
 
+#ifndef LLVM_ON_WIN32
 // Add /usr/lib/debug directory.
 debug_file_search_paths.AppendIfUnique (FileSpec("/usr/lib/debug", true));
+#endif // LLVM_ON_WIN32
 
 std::string uuid_str;
 const UUID &module_uuid = module_spec.GetUUID();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [PATCH] D13636: Symbols::LocateExecutableSymbolFile() shouldn't try to look for files in /usr/lib/debug on Windows

2015-10-11 Thread Vadim Macagon via lldb-commits
enlight added a comment.

Zach,

I've looked at the path separator issue you've mentioned earlier in D13201 
, and I think it's fine 
as is. All those paths with the forward slashes end up in a FileSpec, which 
converts forward slashes to backward slashes before passing them through to any 
Win32 APIs, and `FileSpec::GetPath()` also converts slashes by default.


Repository:
  rL LLVM

http://reviews.llvm.org/D13636



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


[Lldb-commits] [lldb] r250175 - Symbols::LocateExecutableSymbolFile() shouldn't try to look for files in /usr/lib/debug on Windows

2015-10-13 Thread Vadim Macagon via lldb-commits
Author: enlight
Date: Tue Oct 13 11:30:28 2015
New Revision: 250175

URL: http://llvm.org/viewvc/llvm-project?rev=250175&view=rev
Log:
Symbols::LocateExecutableSymbolFile() shouldn't try to look for files in 
/usr/lib/debug on Windows

Summary:
/usr/lib/debug doesn't exist on Windows so there's no point even
attempting to look for symbol files in there.

Reviewers: zturner, clayborg

Subscribers: lldb-commits

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

Modified:
lldb/trunk/source/Host/common/Symbols.cpp

Modified: lldb/trunk/source/Host/common/Symbols.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/common/Symbols.cpp?rev=250175&r1=250174&r2=250175&view=diff
==
--- lldb/trunk/source/Host/common/Symbols.cpp (original)
+++ lldb/trunk/source/Host/common/Symbols.cpp Tue Oct 13 11:30:28 2015
@@ -238,8 +238,10 @@ Symbols::LocateExecutableSymbolFile (con
 // Add current working directory.
 debug_file_search_paths.AppendIfUnique (FileSpec(".", true));
 
+#ifndef LLVM_ON_WIN32
 // Add /usr/lib/debug directory.
 debug_file_search_paths.AppendIfUnique (FileSpec("/usr/lib/debug", 
true));
+#endif // LLVM_ON_WIN32
 
 std::string uuid_str;
 const UUID &module_uuid = module_spec.GetUUID();


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


Re: [Lldb-commits] [PATCH] D13636: Symbols::LocateExecutableSymbolFile() shouldn't try to look for files in /usr/lib/debug on Windows

2015-10-13 Thread Vadim Macagon via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL250175: Symbols::LocateExecutableSymbolFile() shouldn't try 
to look for files in… (authored by enlight).

Changed prior to commit:
  http://reviews.llvm.org/D13636?vs=37056&id=37261#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D13636

Files:
  lldb/trunk/source/Host/common/Symbols.cpp

Index: lldb/trunk/source/Host/common/Symbols.cpp
===
--- lldb/trunk/source/Host/common/Symbols.cpp
+++ lldb/trunk/source/Host/common/Symbols.cpp
@@ -238,8 +238,10 @@
 // Add current working directory.
 debug_file_search_paths.AppendIfUnique (FileSpec(".", true));
 
+#ifndef LLVM_ON_WIN32
 // Add /usr/lib/debug directory.
 debug_file_search_paths.AppendIfUnique (FileSpec("/usr/lib/debug", 
true));
+#endif // LLVM_ON_WIN32
 
 std::string uuid_str;
 const UUID &module_uuid = module_spec.GetUUID();


Index: lldb/trunk/source/Host/common/Symbols.cpp
===
--- lldb/trunk/source/Host/common/Symbols.cpp
+++ lldb/trunk/source/Host/common/Symbols.cpp
@@ -238,8 +238,10 @@
 // Add current working directory.
 debug_file_search_paths.AppendIfUnique (FileSpec(".", true));
 
+#ifndef LLVM_ON_WIN32
 // Add /usr/lib/debug directory.
 debug_file_search_paths.AppendIfUnique (FileSpec("/usr/lib/debug", true));
+#endif // LLVM_ON_WIN32
 
 std::string uuid_str;
 const UUID &module_uuid = module_spec.GetUUID();
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


Re: [Lldb-commits] [Diffusion] rL250335: Fix codesign command with cmake.

2015-10-21 Thread Vadim Macagon via lldb-commits
enlight added a subscriber: enlight.
enlight added a comment.

I believe LLVM requires CMake 2.8.12 or later (at least that was the case
when I looked three weeks ago).


Users:
  sas (Author)
  dawn (Auditor)

http://reviews.llvm.org/rL250335



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


Re: [Lldb-commits] [Diffusion] rL250335: Fix codesign command with cmake.

2015-10-22 Thread Vadim Macagon via lldb-commits
enlight added a comment.

It seems like it should be possible to conditionally enable this using 
CMAKE_VERSION 
.
 However that just means anyone who's silly enough to use an older CMake 
version may run into the issue this patch attempts to address, so arguably the 
proper fix is to bump up the CMake version requirement instead. Should probably 
run this by lldb-dev first.


Users:
  sas (Author)
  dawn (Auditor)

http://reviews.llvm.org/rL250335



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


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

2015-09-19 Thread Vadim Macagon via lldb-commits
enlight added a subscriber: enlight.
enlight added a comment.

According to the GDB-MI spec the exec-run 

 command already has a **start** option. Support for the **start** option can 
be detected by checking for **exec-run-start-option** in the list of features 
returned by the list-features 

 command. So, what's the rationale for diverging from the spec in this case?

In GDB your example would be written as:
-exec-run --start



Comment at: tools/lldb-mi/MICmdCmdExec.cpp:92
@@ +91,3 @@
+const char *pCmd = bProcessMustStopAtEntry ? "process launch -s" : 
"process launch";
+const lldb::ReturnStatus rtn = 
rSessionInfo.GetDebugger().GetCommandInterpreter().HandleCommand(pCmd, 
m_lldbResult);
+MIunused(rtn);

The process should be launched through the SB API, not the command interpreter. 
I'm not very familiar with the SB API but I'd try using the 
**lldb::eLaunchFlagStopAtEntry** flag with **SBLaunchInfo::SetLaunchFlags()**.


Repository:
  rL LLVM

http://reviews.llvm.org/D12977



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


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

2015-09-21 Thread Vadim Macagon via lldb-commits
enlight added inline comments.


Comment at: tools/lldb-mi/MICmdCmdExec.cpp:92
@@ +91,3 @@
+const char *pCmd = bProcessMustStopAtEntry ? "process launch -s" : 
"process launch";
+const lldb::ReturnStatus rtn = 
rSessionInfo.GetDebugger().GetCommandInterpreter().HandleCommand(pCmd, 
m_lldbResult);
+MIunused(rtn);

KLapshin wrote:
> KLapshin wrote:
> > enlight wrote:
> > > The process should be launched through the SB API, not the command 
> > > interpreter. I'm not very familiar with the SB API but I'd try using the 
> > > **lldb::eLaunchFlagStopAtEntry** flag with 
> > > **SBLaunchInfo::SetLaunchFlags()**.
> > You are right, no doubt - this is clear what Target and Process API direct 
> > usage is faster and straightforward manner.
> > 
> > Just couple words regarding why interpreter used instead here - patch was 
> > prepared at moment when lldb-MI had lack synchronization (via Listener) 
> > with lldb Core, so setting corresponding flag gave random results - app may 
> > stop or not. Via interpreter it worked fine always - that's why I stated 
> > "more reliable" in review header.
> > 
> > I will check if flag pass is enough currently - this will make patch 
> > shorter and clearer.
> Also - in many other places lldb-MI still use interpreter for cmds.
Yes, it's unfortunate that the interpreter is used to implement some commands, 
this will be cleaned up in due time I hope. I just don't want new code using 
the interpreter unless absolutely necessary, it should be possible to 
(eventually) do everything through the SB API. If the SB API doesn't work as 
expected please file a bug,


Repository:
  rL LLVM

http://reviews.llvm.org/D12977



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


Re: [Lldb-commits] [PATCH] D13201: Fix segmentation fault in lldb_private::Symbols::LocateExecutableSymbolFile()

2015-09-28 Thread Vadim Macagon via lldb-commits
enlight added a comment.

I've updated the summary with the scenario. I don't know how one would go about 
writing a test for this, mixed platform remote debugging is a bit finicky.



Comment at: source/Host/common/Symbols.cpp:238-250
@@ -237,15 +237,15 @@
 
 // Add /usr/lib/debug directory.
 debug_file_search_paths.AppendIfUnique (FileSpec("/usr/lib/debug", 
true));
 
 std::string uuid_str;
 const UUID &module_uuid = module_spec.GetUUID();
 if (module_uuid.IsValid())
 {
 // Some debug files are stored in the .build-id directory like 
this:
 //   
/usr/lib/debug/.build-id/ff/e7fe727889ad82bb153de2ad065b2189693315.debug
 uuid_str = module_uuid.GetAsString("");
 uuid_str.insert (2, 1, '/');
 uuid_str = uuid_str + ".debug";
 }
 

zturner wrote:
> Can you do all of this only if the target is not Windows?
You mean if the **host** is not Windows? Skipping `/usr/lib/debug` on Windows 
makes sense, but it seems like the `uuid_str` stuff could still apply if the 
symbol files are copied to or shared with Windows.


Comment at: source/Host/common/Symbols.cpp:263-270
@@ -266,6 +262,10 @@
 
 files.push_back (dirname + "/" + symbol_filename);
 files.push_back (dirname + "/.debug/" + symbol_filename);
 files.push_back (dirname + "/.build-id/" + uuid_str);
-files.push_back (dirname + module_directory + "/" + 
symbol_filename);
+
+// Some debug files may stored in the module directory like this:
+//   /usr/lib/debug/usr/lib/library.so.debug
+if (!file_dir.IsEmpty())
+files.push_back (dirname + file_dir.AsCString() + "/" + 
symbol_filename);
 

zturner wrote:
> Don't use literal slashes anywhere.  I know you're just copying the existing 
> code, which was already broken, but it seems easy enough to fix all this by 
> calling llvm::sys::path::append, which will do the right thing dependign on 
> the Host platform.
> 
> Since this code is in Host, it's ok to do this, since we're ultimately going 
> to pass this path directly through to the filesystem anyway, we already need 
> to be able to assume that we're dealing with a path that has the appropriate 
> separator for the platform anyway.
I'll submit a separate patch for the requested path separator changes. I'd 
prefer to do it after this patch though.


Repository:
  rL LLVM

http://reviews.llvm.org/D13201



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


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

2015-09-29 Thread Vadim Macagon via lldb-commits
enlight created this revision.
enlight added reviewers: brucem, zturner.
enlight added a subscriber: lldb-commits.
enlight set the repository for this revision to rL LLVM.

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.

Repository:
  rL LLVM

http://reviews.llvm.org/D13234

Files:
  cmake/modules/LLDBConfig.cmake

Index: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ cmake/modules/LLDBConfig.cmake
@@ -48,15 +48,19 @@
   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)
+
+  # Note that it's imperative that there is no whitespace between the 
debug and not-debug generator expressions
+  # below, otherwise CMake will replace the whitespace with a semicolon in 
some contexts (which would stuff things up).
+  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: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ cmake/modules/LLDBConfig.cmake
@@ -48,15 +48,19 @@
   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)
+
+  # Note that it's imperative that there is no whitespace between the debug and not-debug generator expressions
+  # below, otherwise CMake will replace the whitespace with a semicolon in some contexts (which would stuff things up).
+  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_D

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

2015-09-29 Thread Vadim Macagon via lldb-commits
enlight created this revision.
enlight added reviewers: brucem, zturner.
enlight added a subscriber: lldb-commits.
enlight set the repository for this revision to rL LLVM.

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.

Repository:
  rL LLVM

http://reviews.llvm.org/D13237

Files:
  CMakeLists.txt

Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ 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: CMakeLists.txt
===
--- CMakeLists.txt
+++ 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] D13234: Use the correct Python lib for each build configuration generated by the Visual Studio CMake generator

2015-09-29 Thread Vadim Macagon via lldb-commits
enlight added inline comments.


Comment at: cmake/modules/LLDBConfig.cmake:61
@@ +60,3 @@
+  # below, otherwise CMake will replace the whitespace with a semicolon in 
some contexts (which would stuff things up).
+  set (PYTHON_EXECUTABLE 
$<$:${PYTHON_DEBUG_EXE}>$<$>:${PYTHON_RELEASE_EXE}>)
+  set (PYTHON_LIBRARY 
$<$:${PYTHON_DEBUG_LIB}>$<$>:${PYTHON_RELEASE_LIB}>)

zturner wrote:
> This line is hard to parse mentally, and I'm not sure I've seen this kind of 
> nested generator expression.  I trust you when you say it's right, but can 
> you explain what this does?
Sure thing.

  # `$` evaluates to `1` when the `Debug` configuration is being 
generated, or `0` in all other cases.
  # `$<$:${PYTHON_DEBUG_EXE}>` expands to `${PYTHON_DEBUG_EXE}` 
when the `Debug` configuration is being generated, or nothing (literally) in 
all other cases.
  # `$<$>:${PYTHON_RELEASE_EXE}>` expands to 
`${PYTHON_RELEASE_EXE}` when any configuration other than `Debug` is being 
generated, or nothing in all other cases.

Since the conditionals in 2 & 3 are mutually exclusive, and a conditional 
expression that evaluates to `0` yields no value at all, it's possible to 
concatenate them to obtain a single value. This value will be 
`${PYTHON_DEBUG_EXE}` when generating the Debug configuration, or 
`${PYTHON_RELEASE_EXE}` when generating any other configuration.


Repository:
  rL LLVM

http://reviews.llvm.org/D13234



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