[Lldb-commits] [lldb] r335102 - BreakpointIDList: Use llvm::ArrayRef instead of pointer+length pair

2018-06-20 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Wed Jun 20 01:12:50 2018
New Revision: 335102

URL: http://llvm.org/viewvc/llvm-project?rev=335102&view=rev
Log:
BreakpointIDList: Use llvm::ArrayRef instead of pointer+length pair

NFC

Modified:
lldb/trunk/include/lldb/Breakpoint/BreakpointIDList.h
lldb/trunk/source/Breakpoint/BreakpointIDList.cpp
lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp

Modified: lldb/trunk/include/lldb/Breakpoint/BreakpointIDList.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Breakpoint/BreakpointIDList.h?rev=335102&r1=335101&r2=335102&view=diff
==
--- lldb/trunk/include/lldb/Breakpoint/BreakpointIDList.h (original)
+++ lldb/trunk/include/lldb/Breakpoint/BreakpointIDList.h Wed Jun 20 01:12:50 
2018
@@ -55,7 +55,7 @@ public:
 
   bool FindBreakpointID(const char *bp_id, size_t *position) const;
 
-  void InsertStringArray(const char **string_array, size_t array_size,
+  void InsertStringArray(llvm::ArrayRef string_array,
  CommandReturnObject &result);
 
   // Returns a pair consisting of the beginning and end of a breakpoint

Modified: lldb/trunk/source/Breakpoint/BreakpointIDList.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Breakpoint/BreakpointIDList.cpp?rev=335102&r1=335101&r2=335102&view=diff
==
--- lldb/trunk/source/Breakpoint/BreakpointIDList.cpp (original)
+++ lldb/trunk/source/Breakpoint/BreakpointIDList.cpp Wed Jun 20 01:12:50 2018
@@ -89,14 +89,13 @@ bool BreakpointIDList::FindBreakpointID(
   return FindBreakpointID(*bp_id, position);
 }
 
-void BreakpointIDList::InsertStringArray(const char **string_array,
- size_t array_size,
- CommandReturnObject &result) {
-  if (string_array == nullptr)
+void BreakpointIDList::InsertStringArray(
+llvm::ArrayRef string_array, CommandReturnObject &result) {
+  if(string_array.empty())
 return;
 
-  for (uint32_t i = 0; i < array_size; ++i) {
-auto bp_id = BreakpointID::ParseCanonicalReference(string_array[i]);
+  for (const char *str : string_array) {
+auto bp_id = BreakpointID::ParseCanonicalReference(str);
 if (bp_id.hasValue())
   m_breakpoint_ids.push_back(*bp_id);
   }

Modified: lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp?rev=335102&r1=335101&r2=335102&view=diff
==
--- lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectBreakpoint.cpp Wed Jun 20 01:12:50 
2018
@@ -2573,8 +2573,7 @@ void CommandObjectMultiwordBreakpoint::V
   // NOW, convert the list of breakpoint id strings in TEMP_ARGS into an actual
   // BreakpointIDList:
 
-  valid_ids->InsertStringArray(temp_args.GetConstArgumentVector(),
-   temp_args.GetArgumentCount(), result);
+  valid_ids->InsertStringArray(temp_args.GetArgumentArrayRef(), result);
 
   // At this point,  all of the breakpoint ids that the user passed in have
   // been converted to breakpoint IDs and put into valid_ids.


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

[Lldb-commits] [lldb] r335104 - Remove dependency from Host to python

2018-06-20 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Wed Jun 20 01:35:45 2018
New Revision: 335104

URL: http://llvm.org/viewvc/llvm-project?rev=335104&view=rev
Log:
Remove dependency from Host to python

Summary:
The only reason python was used in the Host module was to compute the
python path. I resolve this the same way as D47384 did for clang, by
moving the path computation into the python plugin and modifying
SBHostOS class to call into this module for ePathTypePythonDir.

Reviewers: zturner, jingham, davide

Subscribers: mgorny, lldb-commits

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

Modified:
lldb/trunk/include/lldb/Host/macosx/HostInfoMacOSX.h
lldb/trunk/include/lldb/Host/posix/HostInfoPosix.h
lldb/trunk/include/lldb/Host/windows/HostInfoWindows.h
lldb/trunk/source/API/SBHostOS.cpp
lldb/trunk/source/Host/CMakeLists.txt
lldb/trunk/source/Host/common/HostInfoBase.cpp
lldb/trunk/source/Host/macosx/objcxx/HostInfoMacOSX.mm
lldb/trunk/source/Host/posix/HostInfoPosix.cpp
lldb/trunk/source/Host/windows/HostInfoWindows.cpp
lldb/trunk/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt

lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h

Modified: lldb/trunk/include/lldb/Host/macosx/HostInfoMacOSX.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/macosx/HostInfoMacOSX.h?rev=335104&r1=335103&r2=335104&view=diff
==
--- lldb/trunk/include/lldb/Host/macosx/HostInfoMacOSX.h (original)
+++ lldb/trunk/include/lldb/Host/macosx/HostInfoMacOSX.h Wed Jun 20 01:35:45 
2018
@@ -37,7 +37,6 @@ protected:
   static void ComputeHostArchitectureSupport(ArchSpec &arch_32,
  ArchSpec &arch_64);
   static bool ComputeHeaderDirectory(FileSpec &file_spec);
-  static bool ComputePythonDirectory(FileSpec &file_spec);
   static bool ComputeSystemPluginsDirectory(FileSpec &file_spec);
   static bool ComputeUserPluginsDirectory(FileSpec &file_spec);
 };

Modified: lldb/trunk/include/lldb/Host/posix/HostInfoPosix.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/posix/HostInfoPosix.h?rev=335104&r1=335103&r2=335104&view=diff
==
--- lldb/trunk/include/lldb/Host/posix/HostInfoPosix.h (original)
+++ lldb/trunk/include/lldb/Host/posix/HostInfoPosix.h Wed Jun 20 01:35:45 2018
@@ -39,7 +39,6 @@ public:
 protected:
   static bool ComputeSupportExeDirectory(FileSpec &file_spec);
   static bool ComputeHeaderDirectory(FileSpec &file_spec);
-  static bool ComputePythonDirectory(FileSpec &file_spec);
 };
 }
 

Modified: lldb/trunk/include/lldb/Host/windows/HostInfoWindows.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Host/windows/HostInfoWindows.h?rev=335104&r1=335103&r2=335104&view=diff
==
--- lldb/trunk/include/lldb/Host/windows/HostInfoWindows.h (original)
+++ lldb/trunk/include/lldb/Host/windows/HostInfoWindows.h Wed Jun 20 01:35:45 
2018
@@ -39,9 +39,6 @@ public:
 
   static bool GetEnvironmentVar(const std::string &var_name, std::string &var);
 
-protected:
-  static bool ComputePythonDirectory(FileSpec &file_spec);
-
 private:
   static FileSpec m_program_filespec;
 };

Modified: lldb/trunk/source/API/SBHostOS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBHostOS.cpp?rev=335104&r1=335103&r2=335104&view=diff
==
--- lldb/trunk/source/API/SBHostOS.cpp (original)
+++ lldb/trunk/source/API/SBHostOS.cpp Wed Jun 20 01:35:45 2018
@@ -18,6 +18,7 @@
 #include "lldb/Utility/Log.h"
 
 #include "Plugins/ExpressionParser/Clang/ClangHost.h"
+#include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h"
 
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/Path.h"
@@ -48,7 +49,7 @@ SBFileSpec SBHostOS::GetLLDBPath(lldb::P
 fspec = HostInfo::GetHeaderDir();
 break;
   case ePathTypePythonDir:
-fspec = HostInfo::GetPythonDir();
+fspec = ScriptInterpreterPython::GetPythonDir();
 break;
   case ePathTypeLLDBSystemPlugins:
 fspec = HostInfo::GetSystemPluginDir();

Modified: lldb/trunk/source/Host/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/CMakeLists.txt?rev=335104&r1=335103&r2=335104&view=diff
==
--- lldb/trunk/source/Host/CMakeLists.txt (original)
+++ lldb/trunk/source/Host/CMakeLists.txt Wed Jun 20 01:35:45 2018
@@ -51,11 +51,6 @@ add_host_subdirectory(common
   common/UDPSocket.cpp
   )
 
-# Keep track of whether we want to provide a define for the
-# Python's architecture-specific lib path (i.e. where a
-# Python lldb module would go).
-set (g

[Lldb-commits] [PATCH] D48215: Remove dependency from Host to python

2018-06-20 Thread Pavel Labath via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL335104: Remove dependency from Host to python (authored by 
labath, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

https://reviews.llvm.org/D48215

Files:
  lldb/trunk/include/lldb/Host/macosx/HostInfoMacOSX.h
  lldb/trunk/include/lldb/Host/posix/HostInfoPosix.h
  lldb/trunk/include/lldb/Host/windows/HostInfoWindows.h
  lldb/trunk/source/API/SBHostOS.cpp
  lldb/trunk/source/Host/CMakeLists.txt
  lldb/trunk/source/Host/common/HostInfoBase.cpp
  lldb/trunk/source/Host/macosx/objcxx/HostInfoMacOSX.mm
  lldb/trunk/source/Host/posix/HostInfoPosix.cpp
  lldb/trunk/source/Host/windows/HostInfoWindows.cpp
  lldb/trunk/source/Plugins/ScriptInterpreter/Python/CMakeLists.txt
  lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
  lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h

Index: lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
===
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
@@ -347,6 +347,71 @@
   return "Embedded Python interpreter";
 }
 
+void ScriptInterpreterPython::ComputePythonDirForApple(
+llvm::SmallVectorImpl &path) {
+  auto style = llvm::sys::path::Style::posix;
+
+  llvm::StringRef path_ref(path.begin(), path.size());
+  auto rbegin = llvm::sys::path::rbegin(path_ref, style);
+  auto rend = llvm::sys::path::rend(path_ref);
+  auto framework = std::find(rbegin, rend, "LLDB.framework");
+  if (framework == rend) {
+ComputePythonDirForPosix(path);
+return;
+  }
+  path.resize(framework - rend);
+  llvm::sys::path::append(path, style, "LLDB.framework", "Resources", "Python");
+}
+
+void ScriptInterpreterPython::ComputePythonDirForPosix(
+llvm::SmallVectorImpl &path) {
+  auto style = llvm::sys::path::Style::posix;
+#if defined(LLDB_PYTHON_RELATIVE_LIBDIR)
+  // Build the path by backing out of the lib dir, then building with whatever
+  // the real python interpreter uses.  (e.g. lib for most, lib64 on RHEL
+  // x86_64).
+  llvm::sys::path::remove_filename(path, style);
+  llvm::sys::path::append(path, style, LLDB_PYTHON_RELATIVE_LIBDIR);
+#else
+  llvm::sys::path::append(path, style,
+  "python" + llvm::Twine(PY_MAJOR_VERSION) + "." +
+  llvm::Twine(PY_MINOR_VERSION),
+  "site-packages");
+#endif
+}
+
+void ScriptInterpreterPython::ComputePythonDirForWindows(
+llvm::SmallVectorImpl &path) {
+  auto style = llvm::sys::path::Style::windows;
+  llvm::sys::path::remove_filename(path, style);
+  llvm::sys::path::append(path, style, "lib", "site-packages");
+
+  // This will be injected directly through FileSpec.GetDirectory().SetString(),
+  // so we need to normalize manually.
+  std::replace(path.begin(), path.end(), '\\', '/');
+}
+
+FileSpec ScriptInterpreterPython::GetPythonDir() {
+  static FileSpec g_spec = []() {
+FileSpec spec = HostInfo::GetShlibDir();
+if (!spec)
+  return FileSpec();
+llvm::SmallString<64> path;
+spec.GetPath(path);
+
+#if defined(__APPLE__)
+ComputePythonDirForApple(path);
+#elif defined(_WIN32)
+ComputePythonDirForWindows(path);
+#else
+ComputePythonDirForPosix(path);
+#endif
+spec.GetDirectory().SetString(path);
+return spec;
+  }();
+  return g_spec;
+}
+
 lldb_private::ConstString ScriptInterpreterPython::GetPluginName() {
   return GetPluginNameStatic();
 }
@@ -3098,7 +3163,7 @@
   // that use a backslash as the path separator, this will result in executing
   // python code containing paths with unescaped backslashes.  But Python also
   // accepts forward slashes, so to make life easier we just use that.
-  if (FileSpec file_spec = HostInfo::GetPythonDir())
+  if (FileSpec file_spec = GetPythonDir())
 AddToSysPath(AddLocation::Beginning, file_spec.GetPath(false));
   if (FileSpec file_spec = HostInfo::GetShlibDir())
 AddToSysPath(AddLocation::Beginning, file_spec.GetPath(false));
Index: lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
===
--- lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
+++ lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h
@@ -445,6 +445,8 @@
 
   static const char *GetPluginDescriptionStatic();
 
+  static FileSpec GetPythonDir();
+
   //--
   // PluginInterface protocol
   //--
@@ -509,6 +511,10 @@
 
   static void AddToSysPath(AddLocation location, std::string path);
 
+  static void ComputePythonDirForApple(llvm::SmallVectorImpl &path);
+  sta

[Lldb-commits] [PATCH] D48351: Move dumping code out of RegisterValue class

2018-06-20 Thread Pavel Labath via Phabricator via lldb-commits 
labath created this revision.
labath added reviewers: zturner, jingham, clayborg.
Herald added a subscriber: mgorny.

The dump function was the only part of this class which depended on
high-level functionality. This was due to the DumpDataExtractor
function, which uses info from a running target to control dump format
(although, RegisterValue doesn't really use the high-level part of
DumpDataExtractor).

This patch follows the same approach done for the DataExtractor class,
and extracts the dumping code into a separate function/file. This file
can stay in the higher level code, while the RegisterValue class and
anything that does not depend in dumping can stay go to lower layers.


https://reviews.llvm.org/D48351

Files:
  include/lldb/Core/DumpRegisterValue.h
  include/lldb/Core/RegisterValue.h
  source/Commands/CommandObjectRegister.cpp
  source/Core/CMakeLists.txt
  source/Core/DumpRegisterValue.cpp
  source/Core/EmulateInstruction.cpp
  source/Core/FormatEntity.cpp
  source/Core/RegisterValue.cpp
  source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
  source/Target/ThreadPlanCallFunction.cpp
  source/Target/ThreadPlanTracer.cpp

Index: source/Target/ThreadPlanTracer.cpp
===
--- source/Target/ThreadPlanTracer.cpp
+++ source/Target/ThreadPlanTracer.cpp
@@ -13,6 +13,7 @@
 
 #include "lldb/Core/Debugger.h"
 #include "lldb/Core/Disassembler.h"
+#include "lldb/Core/DumpRegisterValue.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/State.h"
 #include "lldb/Core/StreamFile.h"
@@ -217,7 +218,8 @@
   reg_value != m_register_values[reg_num]) {
 if (reg_value.GetType() != RegisterValue::eTypeInvalid) {
   stream->PutCString("\n\t");
-  reg_value.Dump(stream, reg_info, true, false, eFormatDefault);
+  DumpRegisterValue(reg_value, stream, reg_info, true, false,
+eFormatDefault);
 }
   }
   m_register_values[reg_num] = reg_value;
Index: source/Target/ThreadPlanCallFunction.cpp
===
--- source/Target/ThreadPlanCallFunction.cpp
+++ source/Target/ThreadPlanCallFunction.cpp
@@ -15,6 +15,7 @@
 #include "lldb/Breakpoint/Breakpoint.h"
 #include "lldb/Breakpoint/BreakpointLocation.h"
 #include "lldb/Core/Address.h"
+#include "lldb/Core/DumpRegisterValue.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Symbol/ObjectFile.h"
 #include "lldb/Target/ABI.h"
@@ -186,7 +187,8 @@
  reg_idx < num_registers; ++reg_idx) {
   const RegisterInfo *reg_info = reg_ctx->GetRegisterInfoAtIndex(reg_idx);
   if (reg_ctx->ReadRegister(reg_info, reg_value)) {
-reg_value.Dump(&strm, reg_info, true, false, eFormatDefault);
+DumpRegisterValue(reg_value, &strm, reg_info, true, false,
+  eFormatDefault);
 strm.EOL();
   }
 }
Index: source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
===
--- source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
+++ source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
@@ -12,6 +12,7 @@
 #include "lldb/Core/Address.h"
 #include "lldb/Core/Disassembler.h"
 #include "lldb/Core/DumpDataExtractor.h"
+#include "lldb/Core/DumpRegisterValue.h"
 #include "lldb/Core/FormatEntity.h"
 #include "lldb/Core/PluginManager.h"
 #include "lldb/Target/ExecutionContext.h"
@@ -486,7 +487,7 @@
 strm.Printf("UnwindAssemblyInstEmulation::ReadRegister  (name = \"%s\") => "
 "synthetic_value = %i, value = ",
 reg_info->name, synthetic);
-reg_value.Dump(&strm, reg_info, false, false, eFormatDefault);
+DumpRegisterValue(reg_value, &strm, reg_info, false, false, eFormatDefault);
 log->PutString(strm.GetString());
   }
   return true;
@@ -512,7 +513,7 @@
 strm.Printf(
 "UnwindAssemblyInstEmulation::WriteRegister (name = \"%s\", value = ",
 reg_info->name);
-reg_value.Dump(&strm, reg_info, false, false, eFormatDefault);
+DumpRegisterValue(reg_value, &strm, reg_info, false, false, eFormatDefault);
 strm.PutCString(", context = ");
 context.Dump(strm, instruction);
 log->PutString(strm.GetString());
Index: source/Core/RegisterValue.cpp
===
--- source/Core/RegisterValue.cpp
+++ source/Core/RegisterValue.cpp
@@ -9,7 +9,6 @@
 
 #include "lldb/Core/RegisterValue.h"
 
-#include "lldb/Core/DumpDataExtractor.h"
 #include "lldb/Core/Scalar.h"
 #include "lldb/Utility/Args.h"
 #include "lldb/Utility/DataExtractor.h"
@@ -34,67 +33,6 @@
 using namespace lldb;
 using namespace lldb_private;
 
-bool RegisterValue::Dump(Stream *s, const RegisterInfo *reg_info,
- bool prefix_with_name, bool prefix_with_alt_name,
- Format format,
-

[Lldb-commits] [lldb] r335106 - Fix windows build broken by r335104

2018-06-20 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Wed Jun 20 02:00:30 2018
New Revision: 335106

URL: http://llvm.org/viewvc/llvm-project?rev=335106&view=rev
Log:
Fix windows build broken by r335104

lldb-python.h needs to be included first to work around some
incompatibilities between windows and python headers.

Modified:
lldb/trunk/source/API/SBHostOS.cpp

Modified: lldb/trunk/source/API/SBHostOS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBHostOS.cpp?rev=335106&r1=335105&r2=335106&view=diff
==
--- lldb/trunk/source/API/SBHostOS.cpp (original)
+++ lldb/trunk/source/API/SBHostOS.cpp Wed Jun 20 02:00:30 2018
@@ -7,6 +7,10 @@
 //
 
//===--===//
 
+#ifndef LLDB_DISABLE_PYTHON
+#include "Plugins/ScriptInterpreter/Python/lldb-python.h"
+#endif
+
 #include "lldb/API/SBHostOS.h"
 #include "lldb/API/SBError.h"
 #include "lldb/Host/Host.h"
@@ -18,7 +22,9 @@
 #include "lldb/Utility/Log.h"
 
 #include "Plugins/ExpressionParser/Clang/ClangHost.h"
+#ifndef LLDB_DISABLE_PYTHON
 #include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h"
+#endif
 
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/Path.h"
@@ -49,7 +55,9 @@ SBFileSpec SBHostOS::GetLLDBPath(lldb::P
 fspec = HostInfo::GetHeaderDir();
 break;
   case ePathTypePythonDir:
+#ifndef LLDB_DISABLE_PYTHON
 fspec = ScriptInterpreterPython::GetPythonDir();
+#endif
 break;
   case ePathTypeLLDBSystemPlugins:
 fspec = HostInfo::GetSystemPluginDir();


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

[Lldb-commits] [lldb] r335112 - Fix compilation with mingw-w64 (pr37873)

2018-06-20 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Wed Jun 20 02:53:30 2018
New Revision: 335112

URL: http://llvm.org/viewvc/llvm-project?rev=335112&view=rev
Log:
Fix compilation with mingw-w64 (pr37873)

Modified:
lldb/trunk/include/lldb/lldb-defines.h

Modified: lldb/trunk/include/lldb/lldb-defines.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/lldb-defines.h?rev=335112&r1=335111&r2=335112&view=diff
==
--- lldb/trunk/include/lldb/lldb-defines.h (original)
+++ lldb/trunk/include/lldb/lldb-defines.h Wed Jun 20 02:53:30 2018
@@ -12,7 +12,7 @@
 
 #include "lldb/lldb-types.h"
 
-#if defined(_MSC_VER)
+#if defined(_WIN32)
 #if defined(EXPORT_LIBLLDB)
 #define LLDB_API __declspec(dllexport)
 #elif defined(IMPORT_LIBLLDB)
@@ -20,7 +20,7 @@
 #else
 #define LLDB_API
 #endif
-#else // defined (_MSC_VER)
+#else // defined (_WIN32)
 #define LLDB_API
 #endif
 


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

[Lldb-commits] [lldb] r335114 - IRInterpreter: fix sign extension of small types (pr37840)

2018-06-20 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Wed Jun 20 03:45:29 2018
New Revision: 335114

URL: http://llvm.org/viewvc/llvm-project?rev=335114&view=rev
Log:
IRInterpreter: fix sign extension of small types (pr37840)

Sign-extension of small types (e.g. short) was not handled correctly.
The reason for that was that when we were assigning the a value to the
Scalar object, we would accidentally promote the type to int (even
though the assignment code in AssignTypeToMatch tried to cast the value
to the appropriate type, it would still invoke the "int" version of
operator=). Instead, I use the APInt version of operator=, where the
bitwidth is specified explicitly. Among other things, this allows us to
fold the individual size cases into one.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/expression_command/ir-interpreter/TestIRInterpreter.py
lldb/trunk/source/Expression/IRInterpreter.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/ir-interpreter/TestIRInterpreter.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/ir-interpreter/TestIRInterpreter.py?rev=335114&r1=335113&r2=335114&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/ir-interpreter/TestIRInterpreter.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/expression_command/ir-interpreter/TestIRInterpreter.py
 Wed Jun 20 03:45:29 2018
@@ -17,6 +17,7 @@ from lldbsuite.test import lldbutil
 class IRInterpreterTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
 
 def setUp(self):
 # Call super's setUp().
@@ -85,3 +86,10 @@ class IRInterpreterTestCase(TestBase):
 jit_result,
 "While evaluating " +
 expression)
+
+def test_type_conversions(self):
+target = self.dbg.GetDummyTarget()
+short_val = target.EvaluateExpression("(short)-1")
+self.assertEqual(short_val.GetValueAsSigned(), -1)
+long_val = target.EvaluateExpression("(long) "+ short_val.GetName())
+self.assertEqual(long_val.GetValueAsSigned(), -1)

Modified: lldb/trunk/source/Expression/IRInterpreter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Expression/IRInterpreter.cpp?rev=335114&r1=335113&r2=335114&view=diff
==
--- lldb/trunk/source/Expression/IRInterpreter.cpp (original)
+++ lldb/trunk/source/Expression/IRInterpreter.cpp Wed Jun 20 03:45:29 2018
@@ -154,16 +154,10 @@ public:
 
 switch (type_size) {
 case 1:
-  scalar = (uint8_t)u64value;
-  break;
 case 2:
-  scalar = (uint16_t)u64value;
-  break;
 case 4:
-  scalar = (uint32_t)u64value;
-  break;
 case 8:
-  scalar = (uint64_t)u64value;
+  scalar = llvm::APInt(type_size*8, u64value);
   break;
 default:
   return false;


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

[Lldb-commits] [PATCH] D48295: [WIP] Implement new ReturnMIStatus method of CMICmdBase class.

2018-06-20 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov updated this revision to Diff 152069.
apolyakov added a comment.

Changed method's name from `ReturnMIStatus` to `HandleSBError`. Also added one 
more use case(see -exec-step's Execute function).

The only thing that worries me is that if we want to specify handler for error 
case, we should do something like:

  SBError error = ...
  auto errorHandler = ...
  
  return HandleSBError(error, [] { return MIstatus::success; }, errorHandler);

since in C++ we can't skip first optional argument and only pass second one.


https://reviews.llvm.org/D48295

Files:
  tools/lldb-mi/MICmdBase.cpp
  tools/lldb-mi/MICmdBase.h
  tools/lldb-mi/MICmdCmdExec.cpp

Index: tools/lldb-mi/MICmdCmdExec.cpp
===
--- tools/lldb-mi/MICmdCmdExec.cpp
+++ tools/lldb-mi/MICmdCmdExec.cpp
@@ -233,23 +233,22 @@
 // Throws:  None.
 //--
 bool CMICmdCmdExecContinue::Execute() {
-  lldb::SBError error =
-  CMICmnLLDBDebugSessionInfo::Instance().GetProcess().Continue();
- 
-  if (error.Success()) {
-// CODETAG_DEBUG_SESSION_RUNNING_PROG_RECEIVED_SIGINT_PAUSE_PROGRAM
+  auto successCaseHandler = [this] {
 if (!CMIDriver::Instance().SetDriverStateRunningDebugging()) {
   const CMIUtilString &rErrMsg(CMIDriver::Instance().GetErrorDescription());
-  SetError(CMIUtilString::Format(MIRSRC(IDS_CMD_ERR_SET_NEW_DRIVER_STATE),
- m_cmdData.strMiCmd.c_str(),
- rErrMsg.c_str()));
+  this->SetError(CMIUtilString::Format(
+  MIRSRC(IDS_CMD_ERR_SET_NEW_DRIVER_STATE),
+  this->m_cmdData.strMiCmd.c_str(),
+  rErrMsg.c_str()));
   return MIstatus::failure;
 }
 return MIstatus::success;
-  }
+  };
 
-  SetError(error.GetCString());
-  return MIstatus::failure;
+  return HandleSBError(
+  CMICmnLLDBDebugSessionInfo::Instance().GetProcess().Continue(),
+  successCaseHandler
+  );
 }
 
 //++
@@ -502,11 +501,7 @@
   } else rSessionInfo.GetProcess().GetSelectedThread().StepInto(
  nullptr, LLDB_INVALID_LINE_NUMBER, error);
 
-  if (error.Success())
-return MIstatus::success;
-
-  SetError(error.GetCString());
-  return MIstatus::failure;
+  return HandleSBError(error);
 }
 
 //++
Index: tools/lldb-mi/MICmdBase.h
===
--- tools/lldb-mi/MICmdBase.h
+++ tools/lldb-mi/MICmdBase.h
@@ -12,6 +12,8 @@
 // C Includes
 // C++ Includes
 // Other libraries and framework includes
+#include "lldb/API/SBError.h"
+
 // Project includes
 #include "MICmdArgSet.h"
 #include "MICmdData.h"
@@ -80,6 +82,11 @@
   // Methods:
 protected:
   void SetError(const CMIUtilString &rErrMsg);
+  bool HandleSBError(const lldb::SBError &error,
+ const std::function &successHandler =
+ [] { return MIstatus::success; },
+ const std::function &errorHandler =
+ [] { return MIstatus::failure; });
   template  T *GetOption(const CMIUtilString &vStrOptionName);
   bool ParseValidateCmdOptions();
 
Index: tools/lldb-mi/MICmdBase.cpp
===
--- tools/lldb-mi/MICmdBase.cpp
+++ tools/lldb-mi/MICmdBase.cpp
@@ -214,6 +214,29 @@
 
 //++
 //
+// Details: Short cut function to check MI command's execute status and
+//  set an error in case of failure.
+// Type:Method.
+// Args:error - (R) Error description object.
+//  successHandler - (R) function describing actions to execute
+//  in case of success state of passed SBError object.
+//  errorHandler - (R) function describing actions to execute
+//  in case of fail status of passed SBError object.
+// Return:  bool.
+// Throws:  None.
+//--
+bool CMICmdBase::HandleSBError(const lldb::SBError &error,
+   const std::function &successHandler,
+   const std::function &errorHandler) {
+  if (error.Success())
+return successHandler();
+
+  SetError(error.GetCString());
+  return errorHandler();
+}
+
+//++
+//
 // Details: Ask a command to provide its unique identifier.
 // Type:Method.
 // Args:A unique identifier for this command class.
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov added a comment.

Just reminder that it still needs a review. Thanks in advance.


https://reviews.llvm.org/D47991



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

[Lldb-commits] [lldb] r335132 - Make sure TestNumThreads works with libc++

2018-06-20 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Wed Jun 20 07:54:34 2018
New Revision: 335132

URL: http://llvm.org/viewvc/llvm-project?rev=335132&view=rev
Log:
Make sure TestNumThreads works with libc++

The problem was that with libc++ the std::unique_lock declaration was
completely inlined, so there was no line table entry in the main.cpp
file to set a breakpoint on. Therefore, the breakpoint got moved to the
next line, but that meant the test would deadlock as the thread would
stop with the lock already held.

I fix that issue by adding a dummy statement before the std::unique_lock
line to anchor the breakpoint.

I think this should fix the issue because of which this test was
disabled on darwin, but someone should verify that before enabling it.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/TestNumThreads.py

lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/main.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/TestNumThreads.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/TestNumThreads.py?rev=335132&r1=335131&r2=335132&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/TestNumThreads.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/TestNumThreads.py
 Wed Jun 20 07:54:34 2018
@@ -16,13 +16,14 @@ import lldbsuite.test.lldbutil as lldbut
 class NumberOfThreadsTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
 
 def setUp(self):
 # Call super's setUp().
 TestBase.setUp(self)
 # Find the line numbers for our break points.
 self.thread3_notify_all_line = line_number('main.cpp', '// Set thread3 
break point on notify_all at this line.')
-self.thread3_before_lock_line = line_number('main.cpp', '// Set 
thread3 break point on lock at this line.')
+self.thread3_before_lock_line = line_number('main.cpp', '// 
thread3-before-lock')
 
 def test_number_of_threads(self):
 """Test number of threads."""

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/main.cpp?rev=335132&r1=335131&r2=335132&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/main.cpp
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/thread/num_threads/main.cpp
 Wed Jun 20 07:54:34 2018
@@ -12,7 +12,10 @@ void *
 thread3(void *input)
 {
 pseudo_barrier_wait(thread3_barrier);
-std::unique_lock lock(mutex); // Set thread3 break point on 
lock at this line.
+
+int dummy = 47; // thread3-before-lock
+
+std::unique_lock lock(mutex); 
 cond.notify_all(); // Set thread3 break point on notify_all at this line.
 return NULL;
 }


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

[Lldb-commits] [PATCH] D48295: [WIP] Implement new ReturnMIStatus method of CMICmdBase class.

2018-06-20 Thread Adrian Prantl via Phabricator via lldb-commits 
aprantl added a comment.

In https://reviews.llvm.org/D48295#1137595, @apolyakov wrote:

> Changed method's name from `ReturnMIStatus` to `HandleSBError`. Also added 
> one more use case(see -exec-step's Execute function).
>
> The only thing that worries me is that if we want to specify handler for 
> error case, we should do something like:
>
>   SBError error = ...
>   auto errorHandler = ...
>  
>   return HandleSBError(error, [] { return MIstatus::success; }, errorHandler);
>
>
> since in C++ we can't skip first optional argument and only pass second one.


Does it ever make sense to return something different than `MIstatus::failure` 
from the failure handler? Since HandleSBError sets the Error string, probably 
not. So we could change the error handler to a `const std::function`.

Then you can define the following overloads:

  bool CMICmdBase::HandleSBError(lldb::SBError error, const 
std::function successHandler = [] { return MIstatus::success; }, const 
std::function errorHandler = [] { return MIstatus::failure; });
  bool CMICmdBase::HandleSBError(lldb::SBError error, const 
std::function errorHandler);
  // this one is for the second half of Execute()
  bool CMICmdBase::HandleMIstatus(bool status, const std::function 
errorHandler = [] { return MIstatus::success; });

By the way, I don't think it makes sense to pass any of the arguments by 
reference. Both SBError and std::function should be very cheap to pass by value.


https://reviews.llvm.org/D48295



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

[Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Adrian Prantl via Phabricator via lldb-commits 
aprantl added a comment.

This patch is adding new overloads to SBAPI calls that don't return an SBError, 
such as:

  // Old:
  void StepOutOfFrame(SBFrame &frame);
  // New:
  void StepOutOfFrame(SBFrame &frame, SBError &error);

I wonder if it would be easier to use and more consistent with the rest of the 
API if we instead added an overload that returns an SBError, like this:

  // New:
  SBError StepOutOfFrameWithError(SBFrame &frame);
  // Alternative names that are just as ugly.
  SBError StepOutOfFrameE(SBFrame &frame);
  SBError StepOutOfFrame2(SBFrame &frame);

@clayborg, @jingham: What do you think?


https://reviews.llvm.org/D47991



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

[Lldb-commits] [lldb] r335149 - Make test sources compatible with android+libcxx+modules

2018-06-20 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Wed Jun 20 10:32:48 2018
New Revision: 335149

URL: http://llvm.org/viewvc/llvm-project?rev=335149&view=rev
Log:
Make test sources compatible with android+libcxx+modules

In a modules build, android is very picky about which symbols are
visible after including libc++ headers (e.g.  defines only
std::printf and not ::printf).

This consolidates the tests where this was an issue to always include
the  version of the headers and prefixes the symbols with std:: as
necessary.

Apart from that, there is no functional change in the tests.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/inlined_breakpoints/basic_type.cpp
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/class_types/main.cpp
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/main.cpp
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/ns.cpp
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/ns.h
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/ns2.cpp
lldb/trunk/packages/Python/lldbsuite/test/lang/cpp/namespace/ns3.cpp
lldb/trunk/packages/Python/lldbsuite/test/types/basic_type.cpp

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/inlined_breakpoints/basic_type.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/inlined_breakpoints/basic_type.cpp?rev=335149&r1=335148&r2=335149&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/inlined_breakpoints/basic_type.cpp
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/inlined_breakpoints/basic_type.cpp
 Wed Jun 20 10:32:48 2018
@@ -20,6 +20,9 @@
 
 #endif
 
+#include 
+#include 
+
 class a_class 
 {
 public:
@@ -79,12 +82,9 @@ typedef struct a_union_nonzero_tag {
 } a_union_nonzero_t;
 
 
-#include 
-#include 
-
 void Puts(char const *msg)
 {
-puts(msg);
+  std::puts(msg);
 }
 
 int 
@@ -124,53 +124,53 @@ main (int argc, char const *argv[])
 a_union_zero_t a_union_zero_array_unbounded[] = {{ T_VALUE_1 }, { 
T_VALUE_2 }};
 
 #ifdef T_PRINTF_FORMAT
-printf ("%s: a = '" T_PRINTF_FORMAT "'\n", T_CSTR, a);
-printf ("%s*: %p => *a_ptr = '" T_PRINTF_FORMAT "'\n", T_CSTR, a_ptr, 
*a_ptr);
-printf ("%s&: @%p => a_ref = '" T_PRINTF_FORMAT "'\n", T_CSTR, &a_ref, 
a_ref);
-
-printf ("%s[2]: a_array_bounded[0] = '" T_PRINTF_FORMAT "'\n", T_CSTR, 
a_array_bounded[0]);
-printf ("%s[2]: a_array_bounded[1] = '" T_PRINTF_FORMAT "'\n", T_CSTR, 
a_array_bounded[1]);
-
-printf ("%s[]: a_array_unbounded[0] = '" T_PRINTF_FORMAT "'\n", T_CSTR, 
a_array_unbounded[0]);
-printf ("%s[]: a_array_unbounded[1] = '" T_PRINTF_FORMAT "'\n", T_CSTR, 
a_array_unbounded[1]);
-
-printf ("(a_class) a_class_instance.m_a = '" T_PRINTF_FORMAT "'\n", 
a_class_instance.get_a());
-printf ("(a_class) a_class_instance.m_b = '" T_PRINTF_FORMAT "'\n", 
a_class_instance.get_b());
-printf ("(a_class*) a_class_ptr = %p, a_class_ptr->m_a = '" 
T_PRINTF_FORMAT "'\n", a_class_ptr, a_class_ptr->get_a());
-printf ("(a_class*) a_class_ptr = %p, a_class_ptr->m_b = '" 
T_PRINTF_FORMAT "'\n", a_class_ptr, a_class_ptr->get_b());
-printf ("(a_class&) a_class_ref = %p, a_class_ref.m_a = '" T_PRINTF_FORMAT 
"'\n", &a_class_ref, a_class_ref.get_a());
-printf ("(a_class&) a_class_ref = %p, a_class_ref.m_b = '" T_PRINTF_FORMAT 
"'\n", &a_class_ref, a_class_ref.get_b());
-
-printf ("(a_struct_t) a_struct.a = '" T_PRINTF_FORMAT "'\n", a_struct.a);
-printf ("(a_struct_t) a_struct.b = '" T_PRINTF_FORMAT "'\n", a_struct.b);
-printf ("(a_struct_t*) a_struct_ptr = %p, a_struct_ptr->a = '" 
T_PRINTF_FORMAT "'\n", a_struct_ptr, a_struct_ptr->a);
-printf ("(a_struct_t*) a_struct_ptr = %p, a_struct_ptr->b = '" 
T_PRINTF_FORMAT "'\n", a_struct_ptr, a_struct_ptr->b);
-printf ("(a_struct_t&) a_struct_ref = %p, a_struct_ref.a = '" 
T_PRINTF_FORMAT "'\n", &a_struct_ref, a_struct_ref.a);
-printf ("(a_struct_t&) a_struct_ref = %p, a_struct_ref.b = '" 
T_PRINTF_FORMAT "'\n", &a_struct_ref, a_struct_ref.b);
+std::printf ("%s: a = '" T_PRINTF_FORMAT "'\n", T_CSTR, a);
+std::printf ("%s*: %p => *a_ptr = '" T_PRINTF_FORMAT "'\n", T_CSTR, a_ptr, 
*a_ptr);
+std::printf ("%s&: @%p => a_ref = '" T_PRINTF_FORMAT "'\n", T_CSTR, 
&a_ref, a_ref);
+
+std::printf ("%s[2]: a_array_bounded[0] = '" T_PRINTF_FORMAT "'\n", 
T_CSTR, a_array_bounded[0]);
+std::printf ("%s[2]: a_array_bounded[1] = '" T_PRINTF_FORMAT "'\n", 
T_CSTR, a_array_bounded[1]);
+
+std::printf ("%s[]: a_array_unbounded[0] = '" T_PRINTF_FORMAT "'\n", 
T_CSTR, a_array_unbounded[0]);
+std::printf ("%s[]: a_array_unbounded[1] = '" T_PRINTF_FORMAT "'\n", 
T_CSTR, a_array_unbounded[1]);
+
+std::printf ("(a_class) a_class_instance.m_a = '" T_PRINTF_FORMAT "'\n", 
a_

Re: [Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Jim Ingham via lldb-commits 
The SB API's tend to take SBError as an in/out parameter for the cases where 
the function in question naturally returns some other value, and return an 
SBError when there's no other logical return value.

So in these cases it would be more in line with the general practice to return 
an SBError.  OTOH, I really don't like the practice of adding "Ex" or other 
similar function name decorations to get around the fact that C++ doesn't 
overload on return values.  IMO they make the API harder to remember.  And 
especially since we really should use the error version, so you will end up 
with the primary function having this weird tag as part of the name...

In balance I think adding it as an argument is better, but this is one of those 
cases where I would leave it to the taste of the implementor...

Jim




> On Jun 20, 2018, at 9:09 AM, Adrian Prantl via Phabricator 
>  wrote:
> 
> aprantl added a comment.
> 
> This patch is adding new overloads to SBAPI calls that don't return an 
> SBError, such as:
> 
>  // Old:
>  void StepOutOfFrame(SBFrame &frame);
>  // New:
>  void StepOutOfFrame(SBFrame &frame, SBError &error);
> 
> I wonder if it would be easier to use and more consistent with the rest of 
> the API if we instead added an overload that returns an SBError, like this:
> 
>  // New:
>  SBError StepOutOfFrameWithError(SBFrame &frame);
>  // Alternative names that are just as ugly.
>  SBError StepOutOfFrameE(SBFrame &frame);
>  SBError StepOutOfFrame2(SBFrame &frame);
> 
> @clayborg, @jingham: What do you think?
> 
> 
> https://reviews.llvm.org/D47991
> 
> 
> 

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

[Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added a comment.

The SB API's tend to take SBError as an in/out parameter for the cases where 
the function in question naturally returns some other value, and return an 
SBError when there's no other logical return value.

So in these cases it would be more in line with the general practice to return 
an SBError.  OTOH, I really don't like the practice of adding "Ex" or other 
similar function name decorations to get around the fact that C++ doesn't 
overload on return values.  IMO they make the API harder to remember.  And 
especially since we really should use the error version, so you will end up 
with the primary function having this weird tag as part of the name...

In balance I think adding it as an argument is better, but this is one of those 
cases where I would leave it to the taste of the implementor...

Jim


https://reviews.llvm.org/D47991



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

[Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov added a comment.

I think we just can make old versions of API methods returning SBError in all 
cases. This way we'll deal with SBError and won't break down API calls.
For example:

  // old
  void StepOver() {
...
  }
  
  // new
  SBError StepOver() {
...
return sb_error;
  }


https://reviews.llvm.org/D47991



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

[Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Adrian Prantl via Phabricator via lldb-commits 
aprantl accepted this revision.
aprantl added a comment.

Okay.. then let's go with this version.


https://reviews.llvm.org/D47991



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

[Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added a comment.

Won't this break client code that was calling StepOver?  We are pretty serious 
about maintaining binary compatibility with the SB API's.

Jim


https://reviews.llvm.org/D47991



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

Re: [Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Jim Ingham via lldb-commits 
Won't this break client code that was calling StepOver?  We are pretty serious 
about maintaining binary compatibility with the SB API's.

Jim


> On Jun 20, 2018, at 11:19 AM, Alexander Polyakov via Phabricator 
>  wrote:
> 
> apolyakov added a comment.
> 
> I think we just can make old versions of API methods returning SBError in all 
> cases. This way we'll deal with SBError and won't break down API calls.
> For example:
> 
>  // old
>  void StepOver() {
>...
>  }
> 
>  // new
>  SBError StepOver() {
>...
>return sb_error;
>  }
> 
> 
> https://reviews.llvm.org/D47991
> 
> 
> 

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

[Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Adrian Prantl via Phabricator via lldb-commits 
aprantl added a comment.

In https://reviews.llvm.org/D47991#1138029, @jingham wrote:

> Won't this break client code that was calling StepOver?  We are pretty 
> serious about maintaining binary compatibility with the SB API's.


Yeah, we can't replace existing function calls: The C++ name mangling could 
change, and the calling convention could change, too, depending on how big 
SBError is.


https://reviews.llvm.org/D47991



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

[Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov added a comment.

If some client uses `StepOver` like `sbThread.StepOver()`, then making 
`StepOver` return SBError won't break anything since in this case returned 
SBError value will just be ignored. Am I missing something?


https://reviews.llvm.org/D47991



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

Re: [Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Jim Ingham via lldb-commits 
The client won't be expecting a struct return, and will have generated code to 
take a void return.  If SBError happens to be returned in registers, nothing 
bad will happen, but if it's returned on the stack, that would corrupt the 
caller's stack.  Relying on the particular kind of struct return to keep out of 
trouble seems like a bad practice to me.

Jim


> On Jun 20, 2018, at 11:49 AM, Alexander Polyakov via Phabricator 
>  wrote:
> 
> apolyakov added a comment.
> 
> If some client uses `StepOver` like `sbThread.StepOver()`, then making 
> `StepOver` return SBError won't break anything since in this case returned 
> SBError value will just be ignored. Am I missing something?
> 
> 
> https://reviews.llvm.org/D47991
> 
> 
> 

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

[Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Jim Ingham via Phabricator via lldb-commits 
jingham added a comment.

The client won't be expecting a struct return, and will have generated code to 
take a void return.  If SBError happens to be returned in registers, nothing 
bad will happen, but if it's returned on the stack, that would corrupt the 
caller's stack.  Relying on the particular kind of struct return to keep out of 
trouble seems like a bad practice to me.

Jim


https://reviews.llvm.org/D47991



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

[Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov added a comment.

In https://reviews.llvm.org/D47991#1138071, @jingham wrote:

> The client won't be expecting a struct return, and will have generated code 
> to take a void return.  If SBError happens to be returned in registers, 
> nothing bad will happen, but if it's returned on the stack, that would 
> corrupt the caller's stack.  Relying on the particular kind of struct return 
> to keep out of trouble seems like a bad practice to me.
>
> Jim


Ok, then I suggest not to increase amount of methods in API doing the same 
stuff and keep SBError as in/out parameter.


https://reviews.llvm.org/D47991



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

[Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Jim Ingham via Phabricator via lldb-commits 
jingham accepted this revision.
jingham added a comment.
This revision is now accepted and ready to land.

That seems fine to me.


https://reviews.llvm.org/D47991



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

[Lldb-commits] [lldb] r335163 - Remove some instances of manual UUID pretty-printing

2018-06-20 Thread Pavel Labath via lldb-commits 
Author: labath
Date: Wed Jun 20 13:13:04 2018
New Revision: 335163

URL: http://llvm.org/viewvc/llvm-project?rev=335163&view=rev
Log:
Remove some instances of manual UUID pretty-printing

Identical functionality is already offered by the UUID::getAsString
method.

Modified:

lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
lldb/trunk/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp

Modified: 
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp?rev=335163&r1=335162&r2=335163&view=diff
==
--- 
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
 (original)
+++ 
lldb/trunk/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
 Wed Jun 20 13:13:04 2018
@@ -1403,30 +1403,12 @@ bool DynamicLoaderDarwinKernel::ReadAllK
 // Dump an image info structure to the file handle provided.
 //--
 void DynamicLoaderDarwinKernel::KextImageInfo::PutToLog(Log *log) const {
-  if (log == NULL)
-return;
-  const uint8_t *u = static_cast(m_uuid.GetBytes());
-
   if (m_load_address == LLDB_INVALID_ADDRESS) {
-if (u) {
-  log->Printf("\tuuid=%2.2X%2.2X%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2."
-  "2X-%2.2X%2.2X%2.2X%2.2X%2.2X%2.2X name=\"%s\" (UNLOADED)",
-  u[0], u[1], u[2], u[3], u[4], u[5], u[6], u[7], u[8], u[9],
-  u[10], u[11], u[12], u[13], u[14], u[15], m_name.c_str());
-} else
-  log->Printf("\tname=\"%s\" (UNLOADED)", m_name.c_str());
+LLDB_LOG(log, "uuid={0} name=\"{1}\" (UNLOADED)", m_uuid.GetAsString(),
+ m_name);
   } else {
-if (u) {
-  log->Printf("\taddr=0x%16.16" PRIx64 " size=0x%16.16" PRIx64
-  " 
uuid=%2.2X%2.2X%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-"
-  "%2.2X%2.2X%2.2X%2.2X%2.2X%2.2X name=\"%s\"",
-  m_load_address, m_size, u[0], u[1], u[2], u[3], u[4], u[5],
-  u[6], u[7], u[8], u[9], u[10], u[11], u[12], u[13], u[14],
-  u[15], m_name.c_str());
-} else {
-  log->Printf("\t[0x%16.16" PRIx64 " - 0x%16.16" PRIx64 ") name=\"%s\"",
-  m_load_address, m_load_address + m_size, m_name.c_str());
-}
+LLDB_LOG(log, "addr={0:x+16} size={1:x+16} uuid={2} name=\"{3}\"",
+m_load_address, m_size, m_uuid.GetAsString(), m_name);
   }
 }
 

Modified: 
lldb/trunk/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp?rev=335163&r1=335162&r2=335163&view=diff
==
--- lldb/trunk/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp 
(original)
+++ lldb/trunk/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp 
Wed Jun 20 13:13:04 2018
@@ -747,35 +747,14 @@ DynamicLoaderDarwin::ImageInfo::FindSegm
 // Dump an image info structure to the file handle provided.
 //--
 void DynamicLoaderDarwin::ImageInfo::PutToLog(Log *log) const {
-  if (log == NULL)
+  if (!log)
 return;
-  const uint8_t *u = (const uint8_t *)uuid.GetBytes();
-
   if (address == LLDB_INVALID_ADDRESS) {
-if (u) {
-  log->Printf("\t   modtime=0x%8.8" PRIx64
-  " 
uuid=%2.2X%2.2X%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-"
-  "%2.2X%2.2X%2.2X%2.2X%2.2X%2.2X path='%s' (UNLOADED)",
-  mod_date, u[0], u[1], u[2], u[3], u[4], u[5], u[6], u[7],
-  u[8], u[9], u[10], u[11], u[12], u[13], u[14], u[15],
-  file_spec.GetPath().c_str());
-} else
-  log->Printf("\t   modtime=0x%8.8" PRIx64
-  " path='%s' (UNLOADED)",
-  mod_date, file_spec.GetPath().c_str());
+LLDB_LOG(log, "modtime={0:x+8} uuid={1} path='{2}' (UNLOADED)", mod_date,
+ uuid.GetAsString(), file_spec.GetPath());
   } else {
-if (u) {
-  log->Printf("\taddress=0x%16.16" PRIx64 " modtime=0x%8.8" PRIx64
-  " 
uuid=%2.2X%2.2X%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-%2.2X%2.2X-"
-  "%2.2X%2.2X%2.2X%2.2X%2.2X%2.2X path='%s'",
-  address, mod_date, u[0], u[1], u[2], u[3], u[4], u[5], u[6],
-  u[7], u[8], u[9], u[10], u[11], u[12], u[13], u[14], u[15],
-  file_spec.GetPath().c_str());
-} else {
-  log->Printf("\taddress=0x%16.16" PRIx64 " modtime=0x%8.8" PRIx64
-  " path='%s'",
-  address, mod_date, file_s

[Lldb-commits] [PATCH] D48393: Make DWARFParsing more thread-safe

2018-06-20 Thread Frederic Riss via Phabricator via lldb-commits 
friss created this revision.
friss added reviewers: clayborg, labath, jingham.
Herald added subscribers: JDevlieghere, aprantl.

Debug information is read lazily so a lot of the state of the reader
is constructred incrementally. There's also nothing preventing symbol
queries to be performed at the same time by multiple threads. This
lead to a series of crashes where the data structures used for
bookkeeping got corrupted because of concurrent modification.

This patch uses a brute-force approach where every such data-structure
got converted to a thread-safe version. I'm happy to discuss
alternatives, and also to hear ideas about whatever preformance testing
I can do to asses the impact of this patch.


https://reviews.llvm.org/D48393

Files:
  include/lldb/Core/ThreadSafeDenseMap.h
  source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
  source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h
  source/Plugins/SymbolFile/DWARF/DWARFASTParserGo.cpp
  source/Plugins/SymbolFile/DWARF/DWARFASTParserJava.cpp
  source/Plugins/SymbolFile/DWARF/DWARFASTParserOCaml.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h

Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -20,12 +20,12 @@
 #include 
 
 // Other libraries and framework includes
-#include "llvm/ADT/DenseMap.h"
 #include "llvm/Support/Threading.h"
 
 #include "lldb/Utility/Flags.h"
 
 #include "lldb/Core/RangeMap.h"
+#include "lldb/Core/ThreadSafeDenseMap.h"
 #include "lldb/Core/UniqueCStringMap.h"
 #include "lldb/Core/dwarf.h"
 #include "lldb/Expression/DWARFExpression.h"
@@ -319,14 +319,17 @@
   void Dump(lldb_private::Stream &s) override;
 
 protected:
-  typedef llvm::DenseMap
+  typedef lldb_private::ThreadSafeDenseMap
   DIEToTypePtr;
-  typedef llvm::DenseMap
+  typedef lldb_private::ThreadSafeDenseMap
   DIEToVariableSP;
-  typedef llvm::DenseMap
+  typedef lldb_private::ThreadSafeDenseMap
   DIEToClangType;
-  typedef llvm::DenseMap ClangTypeToDIE;
+  typedef lldb_private::ThreadSafeDenseMap
+  ClangTypeToDIE;
 
   struct DWARFDataSegment {
 llvm::once_flag m_flag;
Index: source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -1413,8 +1413,9 @@
 const CompilerType &compiler_type) {
   CompilerType compiler_type_no_qualifiers =
   ClangUtil::RemoveFastQualifiers(compiler_type);
-  if (GetForwardDeclClangTypeToDie().count(
-  compiler_type_no_qualifiers.GetOpaqueQualType())) {
+  DIERef ref;
+  if (GetForwardDeclClangTypeToDie().Lookup(
+  compiler_type_no_qualifiers.GetOpaqueQualType(), ref)) {
 return true;
   }
   TypeSystem *type_system = compiler_type.GetTypeSystem();
@@ -1445,22 +1446,23 @@
   // We have a struct/union/class/enum that needs to be fully resolved.
   CompilerType compiler_type_no_qualifiers =
   ClangUtil::RemoveFastQualifiers(compiler_type);
-  auto die_it = GetForwardDeclClangTypeToDie().find(
-  compiler_type_no_qualifiers.GetOpaqueQualType());
-  if (die_it == GetForwardDeclClangTypeToDie().end()) {
+  DIERef ref;
+  if (!GetForwardDeclClangTypeToDie().Lookup(
+  compiler_type_no_qualifiers.GetOpaqueQualType(), ref)) {
 // We have already resolved this type...
 return true;
   }
 
-  DWARFDIE dwarf_die = GetDIE(die_it->getSecond());
+  DWARFDIE dwarf_die = GetDIE(ref);
   if (dwarf_die) {
 // Once we start resolving this type, remove it from the forward
 // declaration map in case anyone child members or other types require this
 // type to get resolved. The type will get resolved when all of the calls
 // to SymbolFileDWARF::ResolveClangOpaqueTypeDefinition are done.
-GetForwardDeclClangTypeToDie().erase(die_it);
+GetForwardDeclClangTypeToDie().Erase(
+compiler_type_no_qualifiers.GetOpaqueQualType());
 
-Type *type = GetDIEToType().lookup(dwarf_die.GetDIE());
+Type *type = GetDIEToType().Lookup(dwarf_die.GetDIE());
 
 Log *log(LogChannelDWARF::GetLogIfAny(DWARF_LOG_DEBUG_INFO |
   DWARF_LOG_TYPE_COMPLETION));
@@ -2587,7 +2589,7 @@
   bool resolve_function_context) {
   TypeSP type_sp;
   if (die) {
-Type *type_ptr = GetDIEToType().lookup(die.GetDIE());
+Type *type_ptr = GetDIEToType().Lookup(die.GetDIE());
 if (type_ptr == NULL) {
   CompileUnit *lldb_cu = GetCompUnitForDWARFCompUnit(die.GetCU());
   assert(lldb_cu);
@@ -2764,7 +2766,7 @@
type_die.GetID(), type_cu->GetID());
 
   if (die)
-GetDIEToType()[die.GetDIE()] = resolved_type;
+

[Lldb-commits] [PATCH] D48295: [WIP] Implement new ReturnMIStatus method of CMICmdBase class.

2018-06-20 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov added a comment.

With such overloads we'll get compile time error. If we have overload:

  bool HandleSBError(SBError error, std::function successHandler = [] 
{some func}, std::function errorHandler = [] {some func});
  bool HandleSBError(SBError error, std::function errorHandler);

and call it like:

  auto successCase = [] {
...
return MIstatus::failure;
  }
  
  bool status = HandleSBError(error, successCase);

we get compile error: call of HandleSBError is ambiguous.


https://reviews.llvm.org/D48295



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

[Lldb-commits] [PATCH] D48295: [WIP] Implement new ReturnMIStatus method of CMICmdBase class.

2018-06-20 Thread Alexander Polyakov via Phabricator via lldb-commits 
apolyakov added a comment.

By the way, I do not see a solution better than current patch, but, at the same 
time, I do not like current patch. Maybe we should discard this idea?


https://reviews.llvm.org/D48295



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

[Lldb-commits] [PATCH] D48393: Make DWARFParsing more thread-safe

2018-06-20 Thread Zachary Turner via Phabricator via lldb-commits 
zturner added a comment.

Long term I think one potentially interesting possibility for solving a lot of 
these threading and lazy evaluation issues is to make a task queue that runs 
all related operations on a single thread and returns a future you can wait on. 
 This way, the core data structures themselves do not need synchronization 
because they are only ever accessed from one thread.  I actually have a patch 
in progress  to make this kind of 
infrastructure, which I actually needed for a different reason, but it would 
work equally well here.

Mostly just putting this out there as an idea for down the road, not that you 
should do it right now.


https://reviews.llvm.org/D48393



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

[Lldb-commits] [lldb] r335180 - Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Alexander Polyakov via lldb-commits 
Author: apolyakov
Date: Wed Jun 20 14:43:16 2018
New Revision: 335180

URL: http://llvm.org/viewvc/llvm-project?rev=335180&view=rev
Log:
Improve SBThread's stepping API using SBError parameter.

Summary: The new methods will allow to get error messages from stepping API.

Reviewers: aprantl, clayborg, labath, jingham

Reviewed By: aprantl, clayborg, jingham

Subscribers: apolyakov, labath, jingham, clayborg, lemo, lldb-commits

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

Modified:
lldb/trunk/include/lldb/API/SBThread.h
lldb/trunk/scripts/interface/SBThread.i
lldb/trunk/source/API/SBThread.cpp

Modified: lldb/trunk/include/lldb/API/SBThread.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/API/SBThread.h?rev=335180&r1=335179&r2=335180&view=diff
==
--- lldb/trunk/include/lldb/API/SBThread.h (original)
+++ lldb/trunk/include/lldb/API/SBThread.h Wed Jun 20 14:43:16 2018
@@ -93,6 +93,8 @@ public:
 
   void StepOver(lldb::RunMode stop_other_threads = lldb::eOnlyDuringStepping);
 
+  void StepOver(lldb::RunMode stop_other_threads, SBError &error);
+
   void StepInto(lldb::RunMode stop_other_threads = lldb::eOnlyDuringStepping);
 
   void StepInto(const char *target_name,
@@ -103,10 +105,16 @@ public:
 
   void StepOut();
 
-  void StepOutOfFrame(lldb::SBFrame &frame);
+  void StepOut(SBError &error);
+
+  void StepOutOfFrame(SBFrame &frame);
+
+  void StepOutOfFrame(SBFrame &frame, SBError &error);
 
   void StepInstruction(bool step_over);
 
+  void StepInstruction(bool step_over, SBError &error);
+
   SBError StepOverUntil(lldb::SBFrame &frame, lldb::SBFileSpec &file_spec,
 uint32_t line);
 
@@ -119,6 +127,8 @@ public:
 
   void RunToAddress(lldb::addr_t addr);
 
+  void RunToAddress(lldb::addr_t addr, SBError &error);
+
   SBError ReturnFromFrame(SBFrame &frame, SBValue &return_value);
 
   SBError UnwindInnermostExpression();
@@ -146,8 +156,12 @@ public:
   //--
   bool Suspend();
 
+  bool Suspend(SBError &error);
+
   bool Resume();
 
+  bool Resume(SBError &error);
+
   bool IsSuspended();
 
   bool IsStopped();

Modified: lldb/trunk/scripts/interface/SBThread.i
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/interface/SBThread.i?rev=335180&r1=335179&r2=335180&view=diff
==
--- lldb/trunk/scripts/interface/SBThread.i (original)
+++ lldb/trunk/scripts/interface/SBThread.i Wed Jun 20 14:43:16 2018
@@ -211,6 +211,11 @@ public:
 void
 StepOver (lldb::RunMode stop_other_threads = lldb::eOnlyDuringStepping);
 
+%feature("autodoc",
+"Do a source level single step over in the currently selected thread.") 
StepOver;
+void
+StepOver (lldb::RunMode stop_other_threads, SBError &error);
+
 void
 StepInto (lldb::RunMode stop_other_threads = lldb::eOnlyDuringStepping);
 
@@ -218,7 +223,7 @@ public:
 StepInto (const char *target_name, lldb::RunMode stop_other_threads = 
lldb::eOnlyDuringStepping);
 
 %feature("autodoc", "
-Step  the current thread from the current source line to the line given by 
end_line, stopping if
+Step the current thread from the current source line to the line given by 
end_line, stopping if
 the thread steps into the function given by target_name.  If target_name 
is None, then stepping will stop
 in any of the places we would normally stop.
 ") StepInto;
@@ -231,12 +236,28 @@ public:
 void
 StepOut ();
 
+%feature("autodoc",
+"Step out of the currently selected thread.") StepOut;
+void
+StepOut (SBError &error);
+
 void
-StepOutOfFrame (lldb::SBFrame &frame);
+StepOutOfFrame (SBFrame &frame);
+
+%feature("autodoc",
+"Step out of the specified frame.") StepOutOfFrame;
+void
+StepOutOfFrame (SBFrame &frame, SBError &error);
 
 void
 StepInstruction(bool step_over);
 
+%feature("autodoc",
+"Do an instruction level single step in the currently selected thread.
+") StepInstruction;
+void
+StepInstruction(bool step_over, SBError &error);
+
 SBError
 StepOverUntil (lldb::SBFrame &frame,
lldb::SBFileSpec &file_spec,
@@ -254,6 +275,9 @@ public:
 void
 RunToAddress (lldb::addr_t addr);
 
+void
+RunToAddress (lldb::addr_t addr, SBError &error);
+
 %feature("autodoc", "
 Force a return from the frame passed in (and any frames younger than it)
 without executing any more code in those frames.  If return_value contains
@@ -297,9 +321,15 @@ public:
 ") Suspend;
 bool
 Suspend();
+
+bool
+Suspend(SBError &error);
 
 bool
 Resume ();
+
+bool
+Resume (SBError &error);
 
 bool
 IsSuspended();

Modified: lldb/trunk/source/API/SBThread.cpp
URL: 
http://llvm.org/viewvc/llvm-proj

[Lldb-commits] [PATCH] D47991: Improve SBThread's stepping API using SBError parameter.

2018-06-20 Thread Alexander Polyakov via Phabricator via lldb-commits 
This revision was automatically updated to reflect the committed changes.
Closed by commit rL335180: Improve SBThread's stepping API using SBError 
parameter. (authored by apolyakov, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D47991?vs=151773&id=152173#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D47991

Files:
  lldb/trunk/include/lldb/API/SBThread.h
  lldb/trunk/scripts/interface/SBThread.i
  lldb/trunk/source/API/SBThread.cpp

Index: lldb/trunk/source/API/SBThread.cpp
===
--- lldb/trunk/source/API/SBThread.cpp
+++ lldb/trunk/source/API/SBThread.cpp
@@ -633,6 +633,11 @@
 }
 
 void SBThread::StepOver(lldb::RunMode stop_other_threads) {
+  SBError error; // Ignored
+  StepOver(stop_other_threads, error);
+}
+
+void SBThread::StepOver(lldb::RunMode stop_other_threads, SBError &error) {
   Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_API));
 
   std::unique_lock lock;
@@ -643,37 +648,38 @@
 static_cast(exe_ctx.GetThreadPtr()),
 Thread::RunModeAsCString(stop_other_threads));
 
-  if (exe_ctx.HasThreadScope()) {
-Thread *thread = exe_ctx.GetThreadPtr();
-bool abort_other_plans = false;
-StackFrameSP frame_sp(thread->GetStackFrameAtIndex(0));
+  if (!exe_ctx.HasThreadScope()) {
+error.SetErrorString("this SBThread object is invalid");
+return;
+  }
 
-ThreadPlanSP new_plan_sp;
-if (frame_sp) {
-  if (frame_sp->HasDebugInformation()) {
-const LazyBool avoid_no_debug = eLazyBoolCalculate;
-SymbolContext sc(frame_sp->GetSymbolContext(eSymbolContextEverything));
-new_plan_sp = thread->QueueThreadPlanForStepOverRange(
-abort_other_plans, sc.line_entry, sc, stop_other_threads,
-avoid_no_debug);
-  } else {
-new_plan_sp = thread->QueueThreadPlanForStepSingleInstruction(
-true, abort_other_plans, stop_other_threads);
-  }
-}
+  Thread *thread = exe_ctx.GetThreadPtr();
+  bool abort_other_plans = false;
+  StackFrameSP frame_sp(thread->GetStackFrameAtIndex(0));
 
-// This returns an error, we should use it!
-ResumeNewPlan(exe_ctx, new_plan_sp.get());
+  ThreadPlanSP new_plan_sp;
+  if (frame_sp) {
+if (frame_sp->HasDebugInformation()) {
+  const LazyBool avoid_no_debug = eLazyBoolCalculate;
+  SymbolContext sc(frame_sp->GetSymbolContext(eSymbolContextEverything));
+  new_plan_sp = thread->QueueThreadPlanForStepOverRange(
+  abort_other_plans, sc.line_entry, sc, stop_other_threads,
+  avoid_no_debug);
+} else {
+  new_plan_sp = thread->QueueThreadPlanForStepSingleInstruction(
+  true, abort_other_plans, stop_other_threads);
+}
   }
+  error = ResumeNewPlan(exe_ctx, new_plan_sp.get());
 }
 
 void SBThread::StepInto(lldb::RunMode stop_other_threads) {
   StepInto(NULL, stop_other_threads);
 }
 
 void SBThread::StepInto(const char *target_name,
 lldb::RunMode stop_other_threads) {
-  SBError error;
+  SBError error; // Ignored
   StepInto(target_name, LLDB_INVALID_LINE_NUMBER, error, stop_other_threads);
 }
 
@@ -691,41 +697,48 @@
 target_name ? target_name : "",
 Thread::RunModeAsCString(stop_other_threads));
 
-  if (exe_ctx.HasThreadScope()) {
-bool abort_other_plans = false;
+  if (!exe_ctx.HasThreadScope()) {
+error.SetErrorString("this SBThread object is invalid");
+return;
+  }
 
-Thread *thread = exe_ctx.GetThreadPtr();
-StackFrameSP frame_sp(thread->GetStackFrameAtIndex(0));
-ThreadPlanSP new_plan_sp;
+  bool abort_other_plans = false;
 
-if (frame_sp && frame_sp->HasDebugInformation()) {
-  SymbolContext sc(frame_sp->GetSymbolContext(eSymbolContextEverything));
-  AddressRange range;
-  if (end_line == LLDB_INVALID_LINE_NUMBER)
-range = sc.line_entry.range;
-  else {
-if (!sc.GetAddressRangeFromHereToEndLine(end_line, range, error.ref()))
-  return;
-  }
-
-  const LazyBool step_out_avoids_code_without_debug_info =
-  eLazyBoolCalculate;
-  const LazyBool step_in_avoids_code_without_debug_info =
-  eLazyBoolCalculate;
-  new_plan_sp = thread->QueueThreadPlanForStepInRange(
-  abort_other_plans, range, sc, target_name, stop_other_threads,
-  step_in_avoids_code_without_debug_info,
-  step_out_avoids_code_without_debug_info);
-} else {
-  new_plan_sp = thread->QueueThreadPlanForStepSingleInstruction(
-  false, abort_other_plans, stop_other_threads);
-}
+  Thread *thread = exe_ctx.GetThreadPtr();
+  StackFrameSP frame_sp(thread->GetStackFrameAtIndex(0));
+  ThreadPlanSP new_plan_sp;
 
-error = ResumeNewPlan(exe_ctx, new_plan_sp.get());
+  if (frame_sp && frame_sp->HasDebugInformation()) {
+SymbolContext sc(frame_sp->GetSymbolContext(eSymbolContextEverything));
+AddressRange

[Lldb-commits] [PATCH] D48393: Make DWARFParsing more thread-safe

2018-06-20 Thread Frederic Riss via Phabricator via lldb-commits 
friss added a comment.

In https://reviews.llvm.org/D48393#1138398, @zturner wrote:

> Long term I think one potentially interesting possibility for solving a lot 
> of these threading and lazy evaluation issues is to make a task queue that 
> runs all related operations on a single thread and returns a future you can 
> wait on.  This way, the core data structures themselves do not need 
> synchronization because they are only ever accessed from one thread.  I 
> actually have a patch in progress  to make 
> this kind of infrastructure, which I actually needed for a different reason, 
> but it would work equally well here.
>
> Mostly just putting this out there as an idea for down the road, not that you 
> should do it right now.


It's an interesting idea, which comes with a couple of tradeoffs:

- We would be essentially serializing the DWARF parsing. I do not know if it 
needs to be a goal that we're able to do efficient multi-threaded parsing, but 
it's an obvious consequence which would need to be discussed.
- I have worked on a codebase relying heavily of serialized thread queues and 
something equivalent to futures to schedule work. Let's say that it was... 
interesting to debug. If we did this, we don't need to go to the same extremes 
though. (Also I'm wondering, would tasks running serially be allowed to enqueue 
other tasks and wait for them? Or would this be forbidden?)

I like the simplification aspect of it though. It is basically equivalent to 
adding locks at a higher abstraction level than the data-structures like I did. 
I was pondering that too, but I wasn't sure 1/ which level would be best and 2/ 
how to be sure I was not going to deadlock the whole thing.


https://reviews.llvm.org/D48393



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

Re: [Lldb-commits] [PATCH] D48393: Make DWARFParsing more thread-safe

2018-06-20 Thread Jim Ingham via lldb-commits 


> On Jun 20, 2018, at 3:14 PM, Frederic Riss via Phabricator 
>  wrote:
> 
> friss added a comment.
> 
> In https://reviews.llvm.org/D48393#1138398, @zturner wrote:
> 
>> Long term I think one potentially interesting possibility for solving a lot 
>> of these threading and lazy evaluation issues is to make a task queue that 
>> runs all related operations on a single thread and returns a future you can 
>> wait on.  This way, the core data structures themselves do not need 
>> synchronization because they are only ever accessed from one thread.  I 
>> actually have a patch in progress  to make 
>> this kind of infrastructure, which I actually needed for a different reason, 
>> but it would work equally well here.
>> 
>> Mostly just putting this out there as an idea for down the road, not that 
>> you should do it right now.
> 

> 
> It's an interesting idea, which comes with a couple of tradeoffs:
> 
> - We would be essentially serializing the DWARF parsing. I do not know if it 
> needs to be a goal that we're able to do efficient multi-threaded parsing, 
> but it's an obvious consequence which would need to be discussed.

One situation in which lldb gets used not infrequently is where a single lldb 
run owns a handful of concurrent Debugger's all managing separate debug 
sessions.  That's how Xcode uses lldb, and probably many other IDE's that allow 
multiple simultaneous debugging sessions.  Running all the debuggers in the 
same process allows them to share the parsed modules in the global module 
cache, so this is a pretty good performance win, but most of the debug 
information will be in modules specific to each Debugger.  So there's probably 
not much contention amongst these Debuggers for access to their DWARF files at 
present.

So it is not the case that access to debug information will be mostly serial by 
happenstance, and only occasionally will we have parallel requests.  
Serializing all these independent requests might be a bigger deal.  OTOH, we 
could fix that by having a pool of task queues that manage access to separate 
Modules in the global module cache.

> - I have worked on a codebase relying heavily of serialized thread queues and 
> something equivalent to futures to schedule work. Let's say that it was... 
> interesting to debug. If we did this, we don't need to go to the same 
> extremes though. (Also I'm wondering, would tasks running serially be allowed 
> to enqueue other tasks and wait for them? Or would this be forbidden?)

It is not uncommon that you would be parsing the DWARF for module A and find a 
type that is only known as a forward declaration.  In that case, lldb will look 
through the other Modules' debug info for a real definition, parse that and 
import it into module A.  So you would need to suspend one task, start another 
and wait on its completion.

Jim


> 
> I like the simplification aspect of it though. It is basically equivalent to 
> adding locks at a higher abstraction level than the data-structures like I 
> did. I was pondering that too, but I wasn't sure 1/ which level would be best 
> and 2/ how to be sure I was not going to deadlock the whole thing.
> 
> 
> https://reviews.llvm.org/D48393
> 
> 
> 

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

[Lldb-commits] [PATCH] D48295: [WIP] Implement new ReturnMIStatus method of CMICmdBase class.

2018-06-20 Thread Adrian Prantl via Phabricator via lldb-commits 
aprantl added a comment.

I guess you *could* use different function names, such as  HandleSBError, 
HandleSBErrorWithSuccess, HandleSBErrorWithSuccessAndFailure, ...


https://reviews.llvm.org/D48295



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