[Lldb-commits] [lldb] r355170 - Update com.apple.diagnosticd.diagnostic entitlement

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Thu Feb 28 19:34:51 2019
New Revision: 355170

URL: http://llvm.org/viewvc/llvm-project?rev=355170=rev
Log:
Update com.apple.diagnosticd.diagnostic entitlement
name to the newer com.apple.private.logging.diagnostic.

 

Modified:
lldb/trunk/tools/debugserver/source/debugserver-entitlements.plist
lldb/trunk/tools/debugserver/source/debugserver-macosx-entitlements.plist
lldb/trunk/tools/lldb-server/Darwin/resources/lldb-server-entitlements.plist

lldb/trunk/tools/lldb-server/Darwin/resources/lldb-server-macos-entitlements.plist

Modified: lldb/trunk/tools/debugserver/source/debugserver-entitlements.plist
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/debugserver-entitlements.plist?rev=355170=355169=355170=diff
==
--- lldb/trunk/tools/debugserver/source/debugserver-entitlements.plist 
(original)
+++ lldb/trunk/tools/debugserver/source/debugserver-entitlements.plist Thu Feb 
28 19:34:51 2019
@@ -16,7 +16,7 @@
 
 debugserver
 
-com.apple.diagnosticd.diagnostic
+com.apple.private.logging.diagnostic
 
 com.apple.security.network.server
 

Modified: 
lldb/trunk/tools/debugserver/source/debugserver-macosx-entitlements.plist
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/debugserver/source/debugserver-macosx-entitlements.plist?rev=355170=355169=355170=diff
==
--- lldb/trunk/tools/debugserver/source/debugserver-macosx-entitlements.plist 
(original)
+++ lldb/trunk/tools/debugserver/source/debugserver-macosx-entitlements.plist 
Thu Feb 28 19:34:51 2019
@@ -2,7 +2,7 @@
 http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
 
 
-com.apple.diagnosticd.diagnostic
+com.apple.private.logging.diagnostic
 
 com.apple.private.cs.debugger
 

Modified: 
lldb/trunk/tools/lldb-server/Darwin/resources/lldb-server-entitlements.plist
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-server/Darwin/resources/lldb-server-entitlements.plist?rev=355170=355169=355170=diff
==
--- 
lldb/trunk/tools/lldb-server/Darwin/resources/lldb-server-entitlements.plist 
(original)
+++ 
lldb/trunk/tools/lldb-server/Darwin/resources/lldb-server-entitlements.plist 
Thu Feb 28 19:34:51 2019
@@ -18,7 +18,7 @@
 
 debugserver
 
-com.apple.diagnosticd.diagnostic
+com.apple.private.logging.diagnostic
 
 com.apple.security.network.server
 

Modified: 
lldb/trunk/tools/lldb-server/Darwin/resources/lldb-server-macos-entitlements.plist
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-server/Darwin/resources/lldb-server-macos-entitlements.plist?rev=355170=355169=355170=diff
==
--- 
lldb/trunk/tools/lldb-server/Darwin/resources/lldb-server-macos-entitlements.plist
 (original)
+++ 
lldb/trunk/tools/lldb-server/Darwin/resources/lldb-server-macos-entitlements.plist
 Thu Feb 28 19:34:51 2019
@@ -2,7 +2,7 @@
 http://www.apple.com/DTDs/PropertyList-1.0.dtd;>
 
 
-com.apple.diagnosticd.diagnostic
+com.apple.private.logging.diagnostic
 
 
 


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

[Lldb-commits] [lldb] r355169 - Increase timeout in Symbols::DownloadObjectAndSymbolFile

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Thu Feb 28 19:24:59 2019
New Revision: 355169

URL: http://llvm.org/viewvc/llvm-project?rev=355169=rev
Log:
Increase timeout in Symbols::DownloadObjectAndSymbolFile 
from 30 seconds to 120 seconds.  We've seen cases where
this symbol lookup can exceed 30 seconds for people
working remotely.

 

Modified:
lldb/trunk/source/Symbol/LocateSymbolFileMacOSX.cpp

Modified: lldb/trunk/source/Symbol/LocateSymbolFileMacOSX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/LocateSymbolFileMacOSX.cpp?rev=355169=355168=355169=diff
==
--- lldb/trunk/source/Symbol/LocateSymbolFileMacOSX.cpp (original)
+++ lldb/trunk/source/Symbol/LocateSymbolFileMacOSX.cpp Thu Feb 28 19:24:59 2019
@@ -591,7 +591,7 @@ bool Symbols::DownloadObjectAndSymbolFil
 ,  // Signal int *
 _output, // Command output
 std::chrono::seconds(
-30), // Large timeout to allow for long dsym download times
+   120), // Large timeout to allow for long dsym download times
 false);  // Don't run in a shell (we don't need shell expansion)
 if (error.Success() && exit_status == 0 && !command_output.empty()) {
   CFCData data(CFDataCreateWithBytesNoCopy(


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

[Lldb-commits] [PATCH] D58748: [ExpressionParser] Test GetClangResourceDir

[Alex Langford via Phabricator via lldb-commits]

xiaobai planned changes to this revision.
xiaobai added a comment.

Looks like the test I wrote doesn't pass on MacOS, I need to investigate.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58748/new/

https://reviews.llvm.org/D58748



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

[Lldb-commits] [PATCH] D58748: [ExpressionParser] Test GetClangResourceDir

[Alex Langford via Phabricator via lldb-commits]

xiaobai updated this revision to Diff 188817.
xiaobai added a comment.

Reword comment to be clearer


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58748/new/

https://reviews.llvm.org/D58748

Files:
  packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py
  source/Plugins/ExpressionParser/Clang/ClangHost.cpp
  source/Plugins/ExpressionParser/Clang/ClangHost.h
  unittests/Expression/ClangParserTest.cpp

Index: unittests/Expression/ClangParserTest.cpp
===
--- unittests/Expression/ClangParserTest.cpp
+++ unittests/Expression/ClangParserTest.cpp
@@ -6,6 +6,8 @@
 //
 //===--===//
 
+#include "clang/Basic/Version.h"
+
 #include "Plugins/ExpressionParser/Clang/ClangHost.h"
 #include "TestingSupport/TestUtilities.h"
 #include "lldb/Host/FileSystem.h"
@@ -29,7 +31,7 @@
 };
 } // namespace
 
-#ifdef __APPLE__
+#if !defined(_WIN32)
 static std::string ComputeClangDir(std::string lldb_shlib_path,
bool verify = false) {
   FileSpec clang_dir;
@@ -38,6 +40,18 @@
   return clang_dir.GetPath();
 }
 
+TEST_F(ClangHostTest, ComputeClangDirectory) {
+  std::string path_to_liblldb = "/foo/bar/lib/";
+  std::string path_to_clang_dir = "/foo/bar/lib/clang/" CLANG_VERSION_STRING;
+  EXPECT_EQ(ComputeClangDir(path_to_liblldb), path_to_clang_dir);
+
+  // The path doesn't really exist, so setting verify to true should make
+  // ComputeClangDir to not give you path_to_clang_dir.
+  EXPECT_NE(ComputeClangDir(path_to_liblldb, true),
+ComputeClangDir(path_to_liblldb));
+}
+
+#if defined(__APPLE__)
 TEST_F(ClangHostTest, MacOSX) {
   // This returns whatever the POSIX fallback returns.
   std::string posix = "/usr/lib/liblldb.dylib";
@@ -76,4 +90,5 @@
   EXPECT_NE(ComputeClangDir(GetInputFilePath(xcode), true),
 ComputeClangDir(GetInputFilePath(xcode)));
 }
-#endif
+#endif // __APPLE__
+#endif // !_WIN32
Index: source/Plugins/ExpressionParser/Clang/ClangHost.h
===
--- source/Plugins/ExpressionParser/Clang/ClangHost.h
+++ source/Plugins/ExpressionParser/Clang/ClangHost.h
@@ -13,7 +13,7 @@
 
 class FileSpec;
 
-#if defined(__APPLE__)
+#if !defined(_WIN32)
 bool ComputeClangDirectory(FileSpec _shlib_spec, FileSpec _spec,
bool verify);
 #endif
Index: source/Plugins/ExpressionParser/Clang/ClangHost.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangHost.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangHost.cpp
@@ -32,13 +32,18 @@
 static bool ComputeClangDirectory(FileSpec _spec) { return false; }
 #else
 static bool DefaultComputeClangDirectory(FileSpec _spec) {
-  return HostInfoPosix::ComputePathRelativeToLibrary(
-  file_spec, (llvm::Twine("/lib") + CLANG_LIBDIR_SUFFIX + "/clang/" +
-  CLANG_VERSION_STRING)
- .str());
+  llvm::SmallString<128> relative_path;
+  llvm::sys::path::append(relative_path,
+  llvm::Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+  CLANG_VERSION_STRING);
+  return HostInfoPosix::ComputePathRelativeToLibrary(file_spec, relative_path);
 }
 
-#if defined(__APPLE__)
+static bool ComputeClangDirectory(FileSpec _spec) {
+  if (FileSpec lldb_file_spec = HostInfo::GetShlibDir())
+return ComputeClangDirectory(lldb_file_spec, file_spec, true);
+  return false;
+}
 
 static bool VerifyClangPath(const llvm::Twine _path) {
   if (FileSystem::Instance().IsDirectory(clang_path))
@@ -53,6 +58,20 @@
 
 bool lldb_private::ComputeClangDirectory(FileSpec _shlib_spec,
  FileSpec _spec, bool verify) {
+#if !defined(__APPLE__)
+  std::string raw_path = lldb_shlib_spec.GetPath();
+  llvm::StringRef parent_dir = llvm::sys::path::parent_path(raw_path);
+
+  llvm::SmallString<128> clang_dir(parent_dir);
+  llvm::sys::path::append(clang_dir, llvm::Twine("lib") + CLANG_LIBDIR_SUFFIX,
+  "clang", CLANG_VERSION_STRING);
+  if (!verify || VerifyClangPath(clang_dir)) {
+file_spec.GetDirectory().SetString(clang_dir);
+FileSystem::Instance().Resolve(file_spec);
+return true;
+  }
+  return DefaultComputeClangDirectory(file_spec);
+#else
   std::string raw_path = lldb_shlib_spec.GetPath();
 
   auto rev_it = llvm::sys::path::rbegin(raw_path);
@@ -114,20 +133,8 @@
   file_spec.SetFile(raw_path.c_str(), FileSpec::Style::native);
   FileSystem::Instance().Resolve(file_spec);
   return true;
-}
-
-static bool ComputeClangDirectory(FileSpec _spec) {
-  if (FileSpec lldb_file_spec = HostInfo::GetShlibDir())
-return ComputeClangDirectory(lldb_file_spec, file_spec, true);
-  return false;
-}
-#else  // __APPLE__
-
-// All non-Apple posix systems.
-static bool ComputeClangDirectory(FileSpec _spec) {
-  return 

[Lldb-commits] [PATCH] D58748: [ExpressionParser] Test GetClangResourceDir

[Alex Langford via Phabricator via lldb-commits]

xiaobai updated this revision to Diff 188816.
xiaobai added a comment.

Address suggestions and add unit test


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58748/new/

https://reviews.llvm.org/D58748

Files:
  packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py
  source/Plugins/ExpressionParser/Clang/ClangHost.cpp
  source/Plugins/ExpressionParser/Clang/ClangHost.h
  unittests/Expression/ClangParserTest.cpp

Index: unittests/Expression/ClangParserTest.cpp
===
--- unittests/Expression/ClangParserTest.cpp
+++ unittests/Expression/ClangParserTest.cpp
@@ -6,6 +6,8 @@
 //
 //===--===//
 
+#include "clang/Basic/Version.h"
+
 #include "Plugins/ExpressionParser/Clang/ClangHost.h"
 #include "TestingSupport/TestUtilities.h"
 #include "lldb/Host/FileSystem.h"
@@ -29,7 +31,7 @@
 };
 } // namespace
 
-#ifdef __APPLE__
+#if !defined(_WIN32)
 static std::string ComputeClangDir(std::string lldb_shlib_path,
bool verify = false) {
   FileSpec clang_dir;
@@ -38,6 +40,18 @@
   return clang_dir.GetPath();
 }
 
+TEST_F(ClangHostTest, ComputeClangDirectory) {
+  std::string path_to_liblldb = "/foo/bar/lib/";
+  std::string path_to_clang_dir = "/foo/bar/lib/clang/" CLANG_VERSION_STRING;
+  EXPECT_EQ(ComputeClangDir(path_to_liblldb), path_to_clang_dir);
+
+  // The path doesn't really exist, so verify shouldn't return
+  // path_to_clang_dir.
+  EXPECT_NE(ComputeClangDir(path_to_liblldb, true),
+ComputeClangDir(path_to_liblldb));
+}
+
+#if defined(__APPLE__)
 TEST_F(ClangHostTest, MacOSX) {
   // This returns whatever the POSIX fallback returns.
   std::string posix = "/usr/lib/liblldb.dylib";
@@ -76,4 +90,5 @@
   EXPECT_NE(ComputeClangDir(GetInputFilePath(xcode), true),
 ComputeClangDir(GetInputFilePath(xcode)));
 }
-#endif
+#endif // __APPLE__
+#endif // !_WIN32
Index: source/Plugins/ExpressionParser/Clang/ClangHost.h
===
--- source/Plugins/ExpressionParser/Clang/ClangHost.h
+++ source/Plugins/ExpressionParser/Clang/ClangHost.h
@@ -13,7 +13,7 @@
 
 class FileSpec;
 
-#if defined(__APPLE__)
+#if !defined(_WIN32)
 bool ComputeClangDirectory(FileSpec _shlib_spec, FileSpec _spec,
bool verify);
 #endif
Index: source/Plugins/ExpressionParser/Clang/ClangHost.cpp
===
--- source/Plugins/ExpressionParser/Clang/ClangHost.cpp
+++ source/Plugins/ExpressionParser/Clang/ClangHost.cpp
@@ -32,13 +32,18 @@
 static bool ComputeClangDirectory(FileSpec _spec) { return false; }
 #else
 static bool DefaultComputeClangDirectory(FileSpec _spec) {
-  return HostInfoPosix::ComputePathRelativeToLibrary(
-  file_spec, (llvm::Twine("/lib") + CLANG_LIBDIR_SUFFIX + "/clang/" +
-  CLANG_VERSION_STRING)
- .str());
+  llvm::SmallString<128> relative_path;
+  llvm::sys::path::append(relative_path,
+  llvm::Twine("lib") + CLANG_LIBDIR_SUFFIX, "clang",
+  CLANG_VERSION_STRING);
+  return HostInfoPosix::ComputePathRelativeToLibrary(file_spec, relative_path);
 }
 
-#if defined(__APPLE__)
+static bool ComputeClangDirectory(FileSpec _spec) {
+  if (FileSpec lldb_file_spec = HostInfo::GetShlibDir())
+return ComputeClangDirectory(lldb_file_spec, file_spec, true);
+  return false;
+}
 
 static bool VerifyClangPath(const llvm::Twine _path) {
   if (FileSystem::Instance().IsDirectory(clang_path))
@@ -53,6 +58,20 @@
 
 bool lldb_private::ComputeClangDirectory(FileSpec _shlib_spec,
  FileSpec _spec, bool verify) {
+#if !defined(__APPLE__)
+  std::string raw_path = lldb_shlib_spec.GetPath();
+  llvm::StringRef parent_dir = llvm::sys::path::parent_path(raw_path);
+
+  llvm::SmallString<128> clang_dir(parent_dir);
+  llvm::sys::path::append(clang_dir, llvm::Twine("lib") + CLANG_LIBDIR_SUFFIX,
+  "clang", CLANG_VERSION_STRING);
+  if (!verify || VerifyClangPath(clang_dir)) {
+file_spec.GetDirectory().SetString(clang_dir);
+FileSystem::Instance().Resolve(file_spec);
+return true;
+  }
+  return DefaultComputeClangDirectory(file_spec);
+#else
   std::string raw_path = lldb_shlib_spec.GetPath();
 
   auto rev_it = llvm::sys::path::rbegin(raw_path);
@@ -114,20 +133,8 @@
   file_spec.SetFile(raw_path.c_str(), FileSpec::Style::native);
   FileSystem::Instance().Resolve(file_spec);
   return true;
-}
-
-static bool ComputeClangDirectory(FileSpec _spec) {
-  if (FileSpec lldb_file_spec = HostInfo::GetShlibDir())
-return ComputeClangDirectory(lldb_file_spec, file_spec, true);
-  return false;
-}
-#else  // __APPLE__
-
-// All non-Apple posix systems.
-static bool ComputeClangDirectory(FileSpec _spec) {
-  return DefaultComputeClangDirectory(file_spec);
-}

[Lldb-commits] [PATCH] D58564: [Reproducers] Add command provider

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere updated this revision to Diff 188813.
JDevlieghere added a comment.

Thanks Pavel. I've updated the patch with your suggestion. I agree it's a lot 
better :-)

I implemented the logic in the Debugger rather than the SBDebugger because I 
think the latter should be a thin wrapper, but let me know if you had a 
particular reason for this.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58564/new/

https://reviews.llvm.org/D58564

Files:
  lldb/include/lldb/Core/Debugger.h
  lldb/include/lldb/Core/IOHandler.h
  lldb/include/lldb/Utility/Reproducer.h
  lldb/source/Commands/CommandObjectCommands.cpp
  lldb/source/Commands/CommandObjectExpression.cpp
  lldb/source/Core/Debugger.cpp
  lldb/source/Core/IOHandler.cpp
  lldb/source/Expression/REPL.cpp
  lldb/source/Interpreter/CommandInterpreter.cpp
  lldb/source/Utility/Reproducer.cpp

Index: lldb/source/Utility/Reproducer.cpp
===
--- lldb/source/Utility/Reproducer.cpp
+++ lldb/source/Utility/Reproducer.cpp
@@ -220,8 +220,45 @@
   return (it != m_files.end()) && (*it == file);
 }
 
+DataRecorder *CommandProvider::GetNewDataRecorder() {
+  std::size_t i = m_data_recorders.size() + 1;
+  std::string filename = (llvm::Twine(info::name) + llvm::Twine("-") +
+  llvm::Twine(i) + llvm::Twine(".txt"))
+ .str();
+  m_data_recorders.push_back(llvm::make_unique(
+  GetRoot().CopyByAppendingPathComponent(filename)));
+  return m_data_recorders.back().get();
+}
+
+DataRecorder *CommandProvider::GetCurrentDataRecorder() {
+  if (m_data_recorders.empty())
+return nullptr;
+  return m_data_recorders.back().get();
+}
+
+void CommandProvider::Keep() {
+  std::vector files;
+  for (auto  : m_data_recorders)
+files.push_back(recorder->GetFilename().GetPath());
+
+  FileSpec file = GetRoot().CopyByAppendingPathComponent(info::file);
+  std::error_code ec;
+  llvm::raw_fd_ostream os(file.GetPath(), ec, llvm::sys::fs::F_Text);
+  if (ec)
+return;
+  yaml::Output yout(os);
+  yout << files;
+
+  m_data_recorders.clear();
+}
+
+void CommandProvider::Discard() { m_data_recorders.clear(); }
+
 void ProviderBase::anchor() {}
 char ProviderBase::ID = 0;
 char FileProvider::ID = 0;
+char CommandProvider::ID = 0;
 const char *FileInfo::name = "files";
 const char *FileInfo::file = "files.yaml";
+const char *CommandInfo::name = "command-interpreter";
+const char *CommandInfo::file = "command-interpreter.yaml";
Index: lldb/source/Interpreter/CommandInterpreter.cpp
===
--- lldb/source/Interpreter/CommandInterpreter.cpp
+++ lldb/source/Interpreter/CommandInterpreter.cpp
@@ -2483,7 +2483,7 @@
// or written
   debugger.GetPrompt(), llvm::StringRef(),
   false, // Not multi-line
-  debugger.GetUseColor(), 0, *this));
+  debugger.GetUseColor(), 0, *this, nullptr));
   const bool old_async_execution = debugger.GetAsyncExecution();
 
   // Set synchronous execution if we are not stopping on continue
@@ -2905,8 +2905,9 @@
 llvm::StringRef(), // Continuation prompt
 true,  // Get multiple lines
 debugger.GetUseColor(),
-0,  // Don't show line numbers
-delegate)); // IOHandlerDelegate
+0, // Don't show line numbers
+delegate,  // IOHandlerDelegate
+nullptr)); // FileShadowCollector
 
   if (io_handler_sp) {
 io_handler_sp->SetUserData(baton);
@@ -2928,8 +2929,9 @@
 llvm::StringRef(), // Continuation prompt
 true,  // Get multiple lines
 debugger.GetUseColor(),
-0,  // Don't show line numbers
-delegate)); // IOHandlerDelegate
+0, // Don't show line numbers
+delegate,  // IOHandlerDelegate
+nullptr)); // FileShadowCollector
 
   if (io_handler_sp) {
 io_handler_sp->SetUserData(baton);
@@ -2980,8 +2982,9 @@
 llvm::StringRef(), // Continuation prompt
 false, // Don't enable multiple line input, just single line commands
 m_debugger.GetUseColor(),
-0, // Don't show line numbers
-*this);
+0, // Don't show line numbers
+*this, // IOHandlerDelegate
+GetDebugger().GetInputRecorder());
   }
   return m_command_io_handler_sp;
 }
Index: lldb/source/Expression/REPL.cpp
===
--- lldb/source/Expression/REPL.cpp
+++ lldb/source/Expression/REPL.cpp
@@ -75,13 +75,13 @@
 Debugger  = m_target.GetDebugger();
 m_io_handler_sp = std::make_shared(
 

[Lldb-commits] [PATCH] D58564: [Reproducers] Add command provider

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere updated this revision to Diff 188809.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58564/new/

https://reviews.llvm.org/D58564

Files:
  lldb/include/lldb/Core/Debugger.h
  lldb/include/lldb/Core/IOHandler.h
  lldb/include/lldb/Utility/Reproducer.h
  lldb/source/Commands/CommandObjectCommands.cpp
  lldb/source/Commands/CommandObjectExpression.cpp
  lldb/source/Core/Debugger.cpp
  lldb/source/Core/IOHandler.cpp
  lldb/source/Expression/REPL.cpp
  lldb/source/Interpreter/CommandInterpreter.cpp
  lldb/source/Utility/Reproducer.cpp

Index: lldb/source/Utility/Reproducer.cpp
===
--- lldb/source/Utility/Reproducer.cpp
+++ lldb/source/Utility/Reproducer.cpp
@@ -220,8 +220,45 @@
   return (it != m_files.end()) && (*it == file);
 }
 
+DataRecorder *CommandProvider::GetNewDataRecorder() {
+  std::size_t i = m_data_recorders.size() + 1;
+  std::string filename = (llvm::Twine(info::name) + llvm::Twine("-") +
+  llvm::Twine(i) + llvm::Twine(".txt"))
+ .str();
+  m_data_recorders.push_back(llvm::make_unique(
+  GetRoot().CopyByAppendingPathComponent(filename)));
+  return m_data_recorders.back().get();
+}
+
+DataRecorder *CommandProvider::GetCurrentDataRecorder() {
+  if (m_data_recorders.empty())
+return nullptr;
+  return m_data_recorders.back().get();
+}
+
+void CommandProvider::Keep() {
+  std::vector files;
+  for (auto  : m_data_recorders)
+files.push_back(recorder->GetFilename().GetPath());
+
+  FileSpec file = GetRoot().CopyByAppendingPathComponent(info::file);
+  std::error_code ec;
+  llvm::raw_fd_ostream os(file.GetPath(), ec, llvm::sys::fs::F_Text);
+  if (ec)
+return;
+  yaml::Output yout(os);
+  yout << files;
+
+  m_data_recorders.clear();
+}
+
+void CommandProvider::Discard() { m_data_recorders.clear(); }
+
 void ProviderBase::anchor() {}
 char ProviderBase::ID = 0;
 char FileProvider::ID = 0;
+char CommandProvider::ID = 0;
 const char *FileInfo::name = "files";
 const char *FileInfo::file = "files.yaml";
+const char *CommandInfo::name = "command-interpreter";
+const char *CommandInfo::file = "command-interpreter.yaml";
Index: lldb/source/Interpreter/CommandInterpreter.cpp
===
--- lldb/source/Interpreter/CommandInterpreter.cpp
+++ lldb/source/Interpreter/CommandInterpreter.cpp
@@ -2483,7 +2483,7 @@
// or written
   debugger.GetPrompt(), llvm::StringRef(),
   false, // Not multi-line
-  debugger.GetUseColor(), 0, *this));
+  debugger.GetUseColor(), 0, *this, debugger.GetInputRecorder()));
   const bool old_async_execution = debugger.GetAsyncExecution();
 
   // Set synchronous execution if we are not stopping on continue
@@ -2905,8 +2905,9 @@
 llvm::StringRef(), // Continuation prompt
 true,  // Get multiple lines
 debugger.GetUseColor(),
-0,  // Don't show line numbers
-delegate)); // IOHandlerDelegate
+0, // Don't show line numbers
+delegate,  // IOHandlerDelegate
+nullptr)); // FileShadowCollector
 
   if (io_handler_sp) {
 io_handler_sp->SetUserData(baton);
@@ -2928,8 +2929,9 @@
 llvm::StringRef(), // Continuation prompt
 true,  // Get multiple lines
 debugger.GetUseColor(),
-0,  // Don't show line numbers
-delegate)); // IOHandlerDelegate
+0, // Don't show line numbers
+delegate,  // IOHandlerDelegate
+nullptr)); // FileShadowCollector
 
   if (io_handler_sp) {
 io_handler_sp->SetUserData(baton);
@@ -2980,8 +2982,9 @@
 llvm::StringRef(), // Continuation prompt
 false, // Don't enable multiple line input, just single line commands
 m_debugger.GetUseColor(),
-0, // Don't show line numbers
-*this);
+0, // Don't show line numbers
+*this, // IOHandlerDelegate
+GetDebugger().GetInputRecorder());
   }
   return m_command_io_handler_sp;
 }
Index: lldb/source/Expression/REPL.cpp
===
--- lldb/source/Expression/REPL.cpp
+++ lldb/source/Expression/REPL.cpp
@@ -75,13 +75,13 @@
 Debugger  = m_target.GetDebugger();
 m_io_handler_sp = std::make_shared(
 debugger, IOHandler::Type::REPL,
-  "lldb-repl", // Name of input reader for history
-  llvm::StringRef("> "), // prompt
-  llvm::StringRef(". "), // Continuation prompt
-   

[Lldb-commits] [lldb] r355155 - Symbols.cpp in unittest moved too.

[Jason Molenda via lldb-commits]

Author: jmolenda
Date: Thu Feb 28 15:37:28 2019
New Revision: 355155

URL: http://llvm.org/viewvc/llvm-project?rev=355155=rev
Log:
Symbols.cpp in unittest moved too.

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

Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=355155=355154=355155=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Thu Feb 28 15:37:28 2019
@@ -431,6 +431,7 @@
9A3D43EC1F3237F900EB767C /* ListenerTest.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 9A3D43E31F3237D500EB767C /* ListenerTest.cpp */; 
};
AFF1273622276F1600C25726 /* LocateSymbolFile.cpp in Sources */ 
= {isa = PBXBuildFile; fileRef = AFF1273422276F1100C25726 /* 
LocateSymbolFile.cpp */; };
AFC3068122276F62002675EA /* LocateSymbolFileMacOSX.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = AFC3068022276F62002675EA /* 
LocateSymbolFileMacOSX.cpp */; };
+   AFB4C8142228A7B40018086A /* LocateSymbolFileTest.cpp in Sources 
*/ = {isa = PBXBuildFile; fileRef = AFB4C818A7AE0018086A /* 
LocateSymbolFileTest.cpp */; };
255EFF741AFABA720069F277 /* LockFileBase.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 255EFF731AFABA720069F277 /* LockFileBase.cpp */; 
};
255EFF761AFABA950069F277 /* LockFilePosix.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 255EFF751AFABA950069F277 /* LockFilePosix.cpp 
*/; };
2689004213353E0400698AC0 /* Log.cpp in Sources */ = {isa = 
PBXBuildFile; fileRef = 26BC7E7F10F1B85900F91463 /* Log.cpp */; };
@@ -953,7 +954,6 @@
268900E013353E6F00698AC0 /* SymbolVendor.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = AF94005711C03F6500085DB9 /* SymbolVendor.cpp */; 
};
2635879417822FC2004C30BA /* SymbolVendorELF.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 2635879017822E56004C30BA /* SymbolVendorELF.cpp 
*/; };
268900CF13353E5F00698AC0 /* SymbolVendorMacOSX.cpp in Sources 
*/ = {isa = PBXBuildFile; fileRef = 260C89E210F57C5600BB2B04 /* 
SymbolVendorMacOSX.cpp */; };
-   23CB153F1D66DA9300EDDDE1 /* SymbolsTest.cpp in Sources */ = 
{isa = PBXBuildFile; fileRef = 2321F93B1BDD332400BA9A93 /* SymbolsTest.cpp */; 
};
268900E113353E6F00698AC0 /* Symtab.cpp in Sources */ = {isa = 
PBXBuildFile; fileRef = 26BC7F1F10F1B8EC00F91463 /* Symtab.cpp */; };
3F8169311ABB7A6D001DA9DF /* SystemInitializer.cpp in Sources */ 
= {isa = PBXBuildFile; fileRef = 3F81692E1ABB7A6D001DA9DF /* 
SystemInitializer.cpp */; };
3F8169321ABB7A6D001DA9DF /* SystemInitializerCommon.cpp in 
Sources */ = {isa = PBXBuildFile; fileRef = 3F81692F1ABB7A6D001DA9DF /* 
SystemInitializerCommon.cpp */; };
@@ -2107,6 +2107,7 @@
9A3D43E31F3237D500EB767C /* ListenerTest.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
path = ListenerTest.cpp; sourceTree = ""; };
AFF1273422276F1100C25726 /* LocateSymbolFile.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = LocateSymbolFile.cpp; path = source/Symbol/LocateSymbolFile.cpp; 
sourceTree = ""; };
AFC3068022276F62002675EA /* LocateSymbolFileMacOSX.cpp */ = 
{isa = PBXFileReference; fileEncoding = 4; lastKnownFileType = 
sourcecode.cpp.cpp; name = LocateSymbolFileMacOSX.cpp; path = 
source/Symbol/LocateSymbolFileMacOSX.cpp; sourceTree = ""; };
+   AFB4C818A7AE0018086A /* LocateSymbolFileTest.cpp */ = {isa 
= PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
path = LocateSymbolFileTest.cpp; sourceTree = ""; };
255EFF731AFABA720069F277 /* LockFileBase.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
path = LockFileBase.cpp; sourceTree = ""; };
255EFF751AFABA950069F277 /* LockFilePosix.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
path = LockFilePosix.cpp; sourceTree = ""; };
255EFF711AFABA4D0069F277 /* LockFileWindows.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
name = LockFileWindows.cpp; path = source/Host/windows/LockFileWindows.cpp; 
sourceTree = ""; };
@@ -3062,7 +3063,6 @@
260C89E210F57C5600BB2B04 /* SymbolVendorMacOSX.cpp */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp; 
path = SymbolVendorMacOSX.cpp; sourceTree = ""; };
260C89E310F57C5600BB2B04 /* SymbolVendorMacOSX.h */ = {isa = 
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path = 
SymbolVendorMacOSX.h; sourceTree = ""; };
 

[Lldb-commits] [PATCH] D58793: [CMake] Make liblldb depend on clang-headers

[Alex Langford via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL355149: [CMake] Make liblldb depend on clang-headers 
(authored by xiaobai, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58793/new/

https://reviews.llvm.org/D58793

Files:
  lldb/trunk/source/API/CMakeLists.txt


Index: lldb/trunk/source/API/CMakeLists.txt
===
--- lldb/trunk/source/API/CMakeLists.txt
+++ lldb/trunk/source/API/CMakeLists.txt
@@ -151,6 +151,10 @@
   )
 endif()
 
+if (NOT LLDB_BUILT_STANDALONE)
+  add_dependencies(liblldb clang-headers)
+endif()
+
 if(LLDB_BUILD_FRAMEWORK)
   include(LLDBFramework)
 endif()


Index: lldb/trunk/source/API/CMakeLists.txt
===
--- lldb/trunk/source/API/CMakeLists.txt
+++ lldb/trunk/source/API/CMakeLists.txt
@@ -151,6 +151,10 @@
   )
 endif()
 
+if (NOT LLDB_BUILT_STANDALONE)
+  add_dependencies(liblldb clang-headers)
+endif()
+
 if(LLDB_BUILD_FRAMEWORK)
   include(LLDBFramework)
 endif()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58792: Add "operator bool" to SB APIs

[Shafik Yaghmour via Phabricator via lldb-commits]

shafik added a comment.

It stood out to me that some of the conversions were not `const` and I can see 
that `IsValid` is not consistently `const` across the API but after talking to 
@jingham it is unfortunately something we can't change.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58792/new/

https://reviews.llvm.org/D58792



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

[Lldb-commits] [PATCH] D58654: Move Config.h from Host to Utility

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere resigned from this revision.
JDevlieghere added a comment.

I believe this isn't relevant anymore after moving Symbols?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58654/new/

https://reviews.llvm.org/D58654



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

[Lldb-commits] [PATCH] D58793: [CMake] Make liblldb depend on clang-headers

[Raphael Isemann via Phabricator via lldb-commits]

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

LGTM.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58793/new/

https://reviews.llvm.org/D58793



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

[Lldb-commits] [PATCH] D58793: [CMake] Make liblldb depend on clang-headers

[Alex Langford via Phabricator via lldb-commits]

xiaobai created this revision.
xiaobai added reviewers: labath, zturner, sgraenitz.
Herald added a subscriber: mgorny.

The clang headers are useful when dealing with clang modules. There is also a
way to get to the clang headers from the SB API so it would be nice if they were
also available when we just build lldb.


https://reviews.llvm.org/D58793

Files:
  source/API/CMakeLists.txt


Index: source/API/CMakeLists.txt
===
--- source/API/CMakeLists.txt
+++ source/API/CMakeLists.txt
@@ -151,6 +151,10 @@
   )
 endif()
 
+if (NOT LLDB_BUILT_STANDALONE)
+  add_dependencies(liblldb clang-headers)
+endif()
+
 if(LLDB_BUILD_FRAMEWORK)
   include(LLDBFramework)
 endif()


Index: source/API/CMakeLists.txt
===
--- source/API/CMakeLists.txt
+++ source/API/CMakeLists.txt
@@ -151,6 +151,10 @@
   )
 endif()
 
+if (NOT LLDB_BUILT_STANDALONE)
+  add_dependencies(liblldb clang-headers)
+endif()
+
 if(LLDB_BUILD_FRAMEWORK)
   include(LLDBFramework)
 endif()
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58790: Adding test to cover the correct import of SourceLocation pertaining to a built-in during expression parsing

[Shafik Yaghmour via Phabricator via lldb-commits]

shafik updated this revision to Diff 188780.
shafik marked 5 inline comments as done.
shafik added a comment.

Addressing comments


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58790/new/

https://reviews.llvm.org/D58790

Files:
  
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/Makefile
  
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py
  packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/main.m


Index: 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/main.m
===
--- /dev/null
+++ 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/main.m
@@ -0,0 +1,6 @@
+#import 
+
+int main(int argc, const char * argv[]) {
+
+return 0; // break here
+}
Index: 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py
===
--- /dev/null
+++ 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py
@@ -0,0 +1,27 @@
+"""
+They may be cases where an expression will import SourceLocation and if the
+SourceLocation ends up with a FileID that is a built-in we need to copy that
+buffer over correctly.
+"""
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestImportBuiltinFileID(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@skipUnlessDarwin
+@skipIfDarwinEmbedded
+@add_test_categories(["gmodules"])
+def test_import_builtin_fileid(self):
+self.build()
+
+lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.m", False))
+
+self.expect("expr int (*DBG_CGImageGetRenderingIntent)(void *) = ((int 
(*)(void *))CGImageGetRenderingIntent); DBG_CGImageGetRenderingIntent((void 
*)0x00);", 
+substrs=['$0 = 0'])
Index: 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/Makefile
===
--- /dev/null
+++ 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/Makefile
@@ -0,0 +1,6 @@
+LEVEL = ../../make
+
+OBJC_SOURCES := main.m
+
+include $(LEVEL)/Makefile.rules
+LDFLAGS += -framework Cocoa


Index: packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/main.m
===
--- /dev/null
+++ packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/main.m
@@ -0,0 +1,6 @@
+#import 
+
+int main(int argc, const char * argv[]) {
+
+return 0; // break here
+}
Index: packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py
===
--- /dev/null
+++ packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py
@@ -0,0 +1,27 @@
+"""
+They may be cases where an expression will import SourceLocation and if the
+SourceLocation ends up with a FileID that is a built-in we need to copy that
+buffer over correctly.
+"""
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestImportBuiltinFileID(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@skipUnlessDarwin
+@skipIfDarwinEmbedded
+@add_test_categories(["gmodules"])
+def test_import_builtin_fileid(self):
+self.build()
+
+lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.m", False))
+
+self.expect("expr int (*DBG_CGImageGetRenderingIntent)(void *) = ((int (*)(void *))CGImageGetRenderingIntent); DBG_CGImageGetRenderingIntent((void *)0x00);", 
+substrs=['$0 = 0'])
Index: packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/Makefile
===
--- /dev/null
+++ packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/Makefile
@@ -0,0 +1,6 @@
+LEVEL = ../../make
+
+OBJC_SOURCES := main.m
+
+include $(LEVEL)/Makefile.rules
+LDFLAGS += -framework Cocoa
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58792: Add "operator bool" to SB APIs

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: zturner, jingham, clayborg.
Herald added a reviewer: jfb.
Herald added a reviewer: serge-sans-paille.
Herald added a subscriber: jdoerfert.

Our python version of the SB API has (the python equivalent of)
operator bool, but the C++ version doesn't.

This is because our python operators are added by modify-python-lldb.py,
which performs postprocessing on the swig-generated interface files.

In this patch, I add the "operator bool" to all SB classes which have an
IsValid method (which is the same logic used by modify-python-lldb.py).
This way, we make the two interfaces more constent, and it allows us to
rely on swig's automatic syntesis of python __nonzero__ methods instead
of doing manual fixups.


https://reviews.llvm.org/D58792

Files:
  include/lldb/API/SBAddress.h
  include/lldb/API/SBBlock.h
  include/lldb/API/SBBreakpoint.h
  include/lldb/API/SBBreakpointLocation.h
  include/lldb/API/SBBreakpointName.h
  include/lldb/API/SBBroadcaster.h
  include/lldb/API/SBCommandInterpreter.h
  include/lldb/API/SBCommandReturnObject.h
  include/lldb/API/SBCommunication.h
  include/lldb/API/SBCompileUnit.h
  include/lldb/API/SBData.h
  include/lldb/API/SBDebugger.h
  include/lldb/API/SBDeclaration.h
  include/lldb/API/SBError.h
  include/lldb/API/SBEvent.h
  include/lldb/API/SBFileSpec.h
  include/lldb/API/SBFrame.h
  include/lldb/API/SBFunction.h
  include/lldb/API/SBInstruction.h
  include/lldb/API/SBInstructionList.h
  include/lldb/API/SBLineEntry.h
  include/lldb/API/SBListener.h
  include/lldb/API/SBModule.h
  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
  include/lldb/API/SBStream.h
  include/lldb/API/SBStringList.h
  include/lldb/API/SBStructuredData.h
  include/lldb/API/SBSymbol.h
  include/lldb/API/SBSymbolContext.h
  include/lldb/API/SBSymbolContextList.h
  include/lldb/API/SBTarget.h
  include/lldb/API/SBThread.h
  include/lldb/API/SBThreadCollection.h
  include/lldb/API/SBThreadPlan.h
  include/lldb/API/SBTrace.h
  include/lldb/API/SBTraceOptions.h
  include/lldb/API/SBType.h
  include/lldb/API/SBTypeCategory.h
  include/lldb/API/SBTypeEnumMember.h
  include/lldb/API/SBTypeFilter.h
  include/lldb/API/SBTypeFormat.h
  include/lldb/API/SBTypeNameSpecifier.h
  include/lldb/API/SBTypeSummary.h
  include/lldb/API/SBTypeSynthetic.h
  include/lldb/API/SBUnixSignals.h
  include/lldb/API/SBValue.h
  include/lldb/API/SBValueList.h
  include/lldb/API/SBVariablesOptions.h
  include/lldb/API/SBWatchpoint.h
  scripts/Python/modify-python-lldb.py
  scripts/interface/SBAddress.i
  scripts/interface/SBBlock.i
  scripts/interface/SBBreakpoint.i
  scripts/interface/SBBreakpointLocation.i
  scripts/interface/SBBreakpointName.i
  scripts/interface/SBBroadcaster.i
  scripts/interface/SBCommandInterpreter.i
  scripts/interface/SBCommandReturnObject.i
  scripts/interface/SBCommunication.i
  scripts/interface/SBCompileUnit.i
  scripts/interface/SBData.i
  scripts/interface/SBDebugger.i
  scripts/interface/SBDeclaration.i
  scripts/interface/SBError.i
  scripts/interface/SBEvent.i
  scripts/interface/SBFileSpec.i
  scripts/interface/SBFrame.i
  scripts/interface/SBFunction.i
  scripts/interface/SBInstruction.i
  scripts/interface/SBInstructionList.i
  scripts/interface/SBLineEntry.i
  scripts/interface/SBListener.i
  scripts/interface/SBModule.i
  scripts/interface/SBModuleSpec.i
  scripts/interface/SBPlatform.i
  scripts/interface/SBProcess.i
  scripts/interface/SBProcessInfo.i
  scripts/interface/SBQueue.i
  scripts/interface/SBQueueItem.i
  scripts/interface/SBSection.i
  scripts/interface/SBStream.i
  scripts/interface/SBStringList.i
  scripts/interface/SBStructuredData.i
  scripts/interface/SBSymbol.i
  scripts/interface/SBSymbolContext.i
  scripts/interface/SBSymbolContextList.i
  scripts/interface/SBTarget.i
  scripts/interface/SBThread.i
  scripts/interface/SBThreadCollection.i
  scripts/interface/SBThreadPlan.i
  scripts/interface/SBTrace.i
  scripts/interface/SBTraceOptions.i
  scripts/interface/SBType.i
  scripts/interface/SBTypeCategory.i
  scripts/interface/SBTypeEnumMember.i
  scripts/interface/SBTypeFilter.i
  scripts/interface/SBTypeFormat.i
  scripts/interface/SBTypeNameSpecifier.i
  scripts/interface/SBTypeSummary.i
  scripts/interface/SBTypeSynthetic.i
  scripts/interface/SBUnixSignals.i
  scripts/interface/SBValue.i
  scripts/interface/SBValueList.i
  scripts/interface/SBVariablesOptions.i
  scripts/interface/SBWatchpoint.i
  scripts/lldb.swig
  source/API/SBAddress.cpp
  source/API/SBBlock.cpp
  source/API/SBBreakpoint.cpp
  source/API/SBBreakpointLocation.cpp
  source/API/SBBreakpointName.cpp
  source/API/SBBroadcaster.cpp
  source/API/SBCommandInterpreter.cpp
  source/API/SBCommandReturnObject.cpp
  source/API/SBCommunication.cpp
  source/API/SBCompileUnit.cpp
  

[Lldb-commits] [PATCH] D58790: Adding test to cover the correct import of SourceLocation pertaining to a built-in during expression parsing

[Davide Italiano via Phabricator via lldb-commits]

davide added a comment.

Just a drive-by comment. I think writing this as a inline test would make it 
more compact (and maybe slightly more readable because you don't have to look 
at two files), but if you prefer this way, I don't have a strong preference.




Comment at: 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py:3
+They may be cases where an expression will import SourceLocation and if the
+SoureLocation ends up with a FileID that is a built-in we need to copy that
+buffer over correctly.

minor, `SourceLocation`.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58790/new/

https://reviews.llvm.org/D58790



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

[Lldb-commits] [PATCH] D58790: Adding test to cover the correct import of SourceLocation pertaining to a built-in during expression parsing

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added inline comments.



Comment at: 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py:18
+@skipUnlessDarwin
+@add_test_categories(["gmodules"])
+def test_import_builtin_fileid(self):

aprantl wrote:
> do you mean: skip unless gmodules?
My mistake, this does what you intend.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58790/new/

https://reviews.llvm.org/D58790



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

[Lldb-commits] [PATCH] D58790: Adding test to cover the correct import of SourceLocation pertaining to a built-in during expression parsing

[Adrian Prantl via Phabricator via lldb-commits]

aprantl added inline comments.



Comment at: 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py:17
+
+@skipUnlessDarwin
+@add_test_categories(["gmodules"])

The Cocoa framework only exists on macOS, there's a skipDarwinEmbedded (or 
similar) decorator that you can use to skip the test on iOS. Alternatively, if 
the problem also reproduces by including CoreGraphics alone, that one I believe 
exists everywhere.



Comment at: 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py:18
+@skipUnlessDarwin
+@add_test_categories(["gmodules"])
+def test_import_builtin_fileid(self):

do you mean: skip unless gmodules?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58790/new/

https://reviews.llvm.org/D58790



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

[Lldb-commits] [PATCH] D58748: [ExpressionParser] Test GetClangResourceDir

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py:20
+# GetClangResourceDir doesn't work on windows yet
+@expectedFailureAll(oslist=["windows"])
 @no_debug_info_test

xiaobai wrote:
> labath wrote:
> > xiaobai wrote:
> > > teemperor wrote:
> > > > Doesn't that mean that we no longer test any of the paths on windows? 
> > > > E.g. if someone breaks `lldb.ePathTypeLLDBShlibDir` we will not see 
> > > > this test failing on Windows. I would prefer of extracting the ClangDir 
> > > > test into it's own method that we mark as failing.
> > > Technically it is being tested but it is expected to fail. That being 
> > > said, I don't mind extracting the ClangDir test into its own method while 
> > > I work on implementing it, but I don't think it needs its own test. Maybe 
> > > after I implement `GetClangResourceDir` on windows I can merge the tests? 
> > > :P 
> > That sounds fine, though I have to say that these tests don't really test 
> > much. There is a test for the MacOS functionality here in 
> > unittests/Expression/ClangParserTest.cpp, which is much more detailed. It 
> > would be great if you could add a windows version there too.
> I originally added this test there, but testing things there as-is is 
> presents a disadvantage: The unittests don't link against liblldb but the 
> individual lldb libraries, so the methods that figure out where the Clang 
> Resource Dir (and pretty much any other directory for that matter) will 
> report something like this:
> `/path/to/llvm/build/tools/lldb/unittests/lib/clang/9.0.0`. So, the best this 
> test could do is set that the filespec had a directory and not a filename 
> set, which is what this test already does.
> 
> That being said, the way MacOS is being tested is much nicer. I could do a 
> small refactor so the non-MacOS posix implementation is closer to the MacOS 
> implementation and add a Linux test (and eventually a windows test) to 
> `unittests/Expression/ClangParserTest.cpp` as well. What do you think?
Sounds like a plan.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58748/new/

https://reviews.llvm.org/D58748



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

[Lldb-commits] [PATCH] D58790: Adding test to cover the correct import of SourceLocation pertaining to a built-in during expression parsing

[Shafik Yaghmour via Phabricator via lldb-commits]

shafik created this revision.
shafik added reviewers: teemperor, aprantl, jingham, martong.
Herald added subscribers: jdoerfert, rnkovacs.
Herald added a reviewer: serge-sans-paille.

This tests a fix in the ASTImpoter.cpp to ensure that we import built-in 
correctly, see differential:

https://reviews.llvm.org/D58743

Once this change is merged this test should pass and should catch regressions 
in this feature.


https://reviews.llvm.org/D58790

Files:
  
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/Makefile
  
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py
  packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/main.m


Index: 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/main.m
===
--- /dev/null
+++ 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/main.m
@@ -0,0 +1,6 @@
+#import 
+
+int main(int argc, const char * argv[]) {
+
+return 0; // break here
+}
Index: 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py
===
--- /dev/null
+++ 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py
@@ -0,0 +1,26 @@
+"""
+They may be cases where an expression will import SourceLocation and if the
+SoureLocation ends up with a FileID that is a built-in we need to copy that
+buffer over correctly.
+"""
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestImportBuiltinFileID(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@skipUnlessDarwin
+@add_test_categories(["gmodules"])
+def test_import_builtin_fileid(self):
+self.build()
+
+lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.m", False))
+
+self.expect("expr int (*DBG_CGImageGetRenderingIntent)(void *) = ((int 
(*)(void *))CGImageGetRenderingIntent); DBG_CGImageGetRenderingIntent((void 
*)0x00);", 
+substrs=['$0 = 0'])
Index: 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/Makefile
===
--- /dev/null
+++ 
packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/Makefile
@@ -0,0 +1,6 @@
+LEVEL = ../../make
+
+OBJC_SOURCES := main.m
+
+include $(LEVEL)/Makefile.rules
+LDFLAGS += -framework Cocoa


Index: packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/main.m
===
--- /dev/null
+++ packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/main.m
@@ -0,0 +1,6 @@
+#import 
+
+int main(int argc, const char * argv[]) {
+
+return 0; // break here
+}
Index: packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py
===
--- /dev/null
+++ packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/TestImportBuiltinFileID.py
@@ -0,0 +1,26 @@
+"""
+They may be cases where an expression will import SourceLocation and if the
+SoureLocation ends up with a FileID that is a built-in we need to copy that
+buffer over correctly.
+"""
+
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestImportBuiltinFileID(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@skipUnlessDarwin
+@add_test_categories(["gmodules"])
+def test_import_builtin_fileid(self):
+self.build()
+
+lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.m", False))
+
+self.expect("expr int (*DBG_CGImageGetRenderingIntent)(void *) = ((int (*)(void *))CGImageGetRenderingIntent); DBG_CGImageGetRenderingIntent((void *)0x00);", 
+substrs=['$0 = 0'])
Index: packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/Makefile
===
--- /dev/null
+++ packages/Python/lldbsuite/test/expression_command/import_builtin_fileid/Makefile
@@ -0,0 +1,6 @@
+LEVEL = ../../make
+
+OBJC_SOURCES := main.m
+
+include $(LEVEL)/Makefile.rules
+LDFLAGS += -framework Cocoa
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58748: [ExpressionParser] Test GetClangResourceDir

[Alex Langford via Phabricator via lldb-commits]

xiaobai marked an inline comment as done.
xiaobai added inline comments.



Comment at: packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py:20
+# GetClangResourceDir doesn't work on windows yet
+@expectedFailureAll(oslist=["windows"])
 @no_debug_info_test

labath wrote:
> xiaobai wrote:
> > teemperor wrote:
> > > Doesn't that mean that we no longer test any of the paths on windows? 
> > > E.g. if someone breaks `lldb.ePathTypeLLDBShlibDir` we will not see this 
> > > test failing on Windows. I would prefer of extracting the ClangDir test 
> > > into it's own method that we mark as failing.
> > Technically it is being tested but it is expected to fail. That being said, 
> > I don't mind extracting the ClangDir test into its own method while I work 
> > on implementing it, but I don't think it needs its own test. Maybe after I 
> > implement `GetClangResourceDir` on windows I can merge the tests? :P 
> That sounds fine, though I have to say that these tests don't really test 
> much. There is a test for the MacOS functionality here in 
> unittests/Expression/ClangParserTest.cpp, which is much more detailed. It 
> would be great if you could add a windows version there too.
I originally added this test there, but testing things there as-is is presents 
a disadvantage: The unittests don't link against liblldb but the individual 
lldb libraries, so the methods that figure out where the Clang Resource Dir 
(and pretty much any other directory for that matter) will report something 
like this:
`/path/to/llvm/build/tools/lldb/unittests/lib/clang/9.0.0`. So, the best this 
test could do is set that the filespec had a directory and not a filename set, 
which is what this test already does.

That being said, the way MacOS is being tested is much nicer. I could do a 
small refactor so the non-MacOS posix implementation is closer to the MacOS 
implementation and add a Linux test (and eventually a windows test) to 
`unittests/Expression/ClangParserTest.cpp` as well. What do you think?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58748/new/

https://reviews.llvm.org/D58748



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

[Lldb-commits] [PATCH] D58748: [ExpressionParser] Test GetClangResourceDir

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py:20
+# GetClangResourceDir doesn't work on windows yet
+@expectedFailureAll(oslist=["windows"])
 @no_debug_info_test

xiaobai wrote:
> teemperor wrote:
> > Doesn't that mean that we no longer test any of the paths on windows? E.g. 
> > if someone breaks `lldb.ePathTypeLLDBShlibDir` we will not see this test 
> > failing on Windows. I would prefer of extracting the ClangDir test into 
> > it's own method that we mark as failing.
> Technically it is being tested but it is expected to fail. That being said, I 
> don't mind extracting the ClangDir test into its own method while I work on 
> implementing it, but I don't think it needs its own test. Maybe after I 
> implement `GetClangResourceDir` on windows I can merge the tests? :P 
That sounds fine, though I have to say that these tests don't really test much. 
There is a test for the MacOS functionality here in 
unittests/Expression/ClangParserTest.cpp, which is much more detailed. It would 
be great if you could add a windows version there too.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58748/new/

https://reviews.llvm.org/D58748



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

Re: [Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

[Pavel Labath via lldb-commits]

On 28/02/2019 20:29, Davide Italiano wrote:

On Thu, Feb 28, 2019 at 11:21 AM Davide Italiano  wrote:


On Thu, Feb 28, 2019 at 11:19 AM Davide Italiano  wrote:


If I add:

diff --git a/lldb/source/Host/common/MainLoop.cpp
b/lldb/source/Host/common/MainLoop.cpp
index a4803936196..4fee76865ee 100644
--- a/lldb/source/Host/common/MainLoop.cpp
+++ b/lldb/source/Host/common/MainLoop.cpp
@@ -23,6 +23,8 @@
  // (ppoll is present but not implemented properly). On windows we use WSApoll
  // (which does not support signals).

+#define HAVE_SYS_EVENT_H 1
+
  #if HAVE_SYS_EVENT_H
  #include 
  #elif defined(_WIN32)

to my checkout it works. It looks like somehow llvm-config.h isn't
propagate properly so `HAVE_SYS_EVENT_H` isn't defined?
This looks like a bug to me, but maybe there's an easy way to work around it.



And in fact, this is what I see in my build directory:

$ grep -R SYS_EVENT './include/llvm/Config/llvm-config.h'
$

--
Davide



The following patch "fixes" the modules build for me.

$ git diff
diff --git a/lldb/include/lldb/Host/Editline.h
b/lldb/include/lldb/Host/Editline.h
index a942ede05ce..ab712670ec1 100644
--- a/lldb/include/lldb/Host/Editline.h
+++ b/lldb/include/lldb/Host/Editline.h
@@ -28,6 +28,8 @@
  // e) Emoji support is fairly terrible, presumably it doesn't understand
  // composed characters?

+#include "lldb/Host/Config.h"
+
  #ifndef liblldb_Editline_h_
  #define liblldb_Editline_h_
  #if defined(__cplusplus)
diff --git a/lldb/source/Host/common/MainLoop.cpp
b/lldb/source/Host/common/MainLoop.cpp
index a4803936196..24a2f80fd10 100644
--- a/lldb/source/Host/common/MainLoop.cpp
+++ b/lldb/source/Host/common/MainLoop.cpp
@@ -8,6 +8,7 @@

  #include "llvm/Config/llvm-config.h"

+#include "lldb/Host/Config.h"
  #include "lldb/Host/MainLoop.h"
  #include "lldb/Host/PosixApi.h"
  #include "lldb/Utility/Status.h"

Raphael/Pavel, I'm going to commit this because it's a serious
regression for us, and the workaround doesn't seem terrible. I would
appreciate a post-commit review (or, if you have, a better way of
fixing this).



I think this is fine. It may not even be a workaround, but a proper way 
to modularize MainLoop.cpp (it ought to include Config.h, since it 
really does depend on symbols defined there).


Just, could you please move the `#include "lldb/Host/Config.h"` inside 
the include guard in Editline.h (it's enough for it to be included 
before the first use of LLDB_EDITLINE_WCHAR_T or whatever is the macro 
name).


BTW, if you're going to be cherry-picking this anywhere, you may want to 
include r355103 as well.


cheers,
pavel
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

[Davide Italiano via lldb-commits]

On Thu, Feb 28, 2019 at 11:21 AM Davide Italiano  wrote:
>
> On Thu, Feb 28, 2019 at 11:19 AM Davide Italiano  
> wrote:
> >
> > If I add:
> >
> > diff --git a/lldb/source/Host/common/MainLoop.cpp
> > b/lldb/source/Host/common/MainLoop.cpp
> > index a4803936196..4fee76865ee 100644
> > --- a/lldb/source/Host/common/MainLoop.cpp
> > +++ b/lldb/source/Host/common/MainLoop.cpp
> > @@ -23,6 +23,8 @@
> >  // (ppoll is present but not implemented properly). On windows we use 
> > WSApoll
> >  // (which does not support signals).
> >
> > +#define HAVE_SYS_EVENT_H 1
> > +
> >  #if HAVE_SYS_EVENT_H
> >  #include 
> >  #elif defined(_WIN32)
> >
> > to my checkout it works. It looks like somehow llvm-config.h isn't
> > propagate properly so `HAVE_SYS_EVENT_H` isn't defined?
> > This looks like a bug to me, but maybe there's an easy way to work around 
> > it.
> >
>
> And in fact, this is what I see in my build directory:
>
> $ grep -R SYS_EVENT './include/llvm/Config/llvm-config.h'
> $
>
> --
> Davide


The following patch "fixes" the modules build for me.

$ git diff
diff --git a/lldb/include/lldb/Host/Editline.h
b/lldb/include/lldb/Host/Editline.h
index a942ede05ce..ab712670ec1 100644
--- a/lldb/include/lldb/Host/Editline.h
+++ b/lldb/include/lldb/Host/Editline.h
@@ -28,6 +28,8 @@
 // e) Emoji support is fairly terrible, presumably it doesn't understand
 // composed characters?

+#include "lldb/Host/Config.h"
+
 #ifndef liblldb_Editline_h_
 #define liblldb_Editline_h_
 #if defined(__cplusplus)
diff --git a/lldb/source/Host/common/MainLoop.cpp
b/lldb/source/Host/common/MainLoop.cpp
index a4803936196..24a2f80fd10 100644
--- a/lldb/source/Host/common/MainLoop.cpp
+++ b/lldb/source/Host/common/MainLoop.cpp
@@ -8,6 +8,7 @@

 #include "llvm/Config/llvm-config.h"

+#include "lldb/Host/Config.h"
 #include "lldb/Host/MainLoop.h"
 #include "lldb/Host/PosixApi.h"
 #include "lldb/Utility/Status.h"

Raphael/Pavel, I'm going to commit this because it's a serious
regression for us, and the workaround doesn't seem terrible. I would
appreciate a post-commit review (or, if you have, a better way of
fixing this).
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

[Davide Italiano via lldb-commits]

On Thu, Feb 28, 2019 at 11:19 AM Davide Italiano  wrote:
>
> If I add:
>
> diff --git a/lldb/source/Host/common/MainLoop.cpp
> b/lldb/source/Host/common/MainLoop.cpp
> index a4803936196..4fee76865ee 100644
> --- a/lldb/source/Host/common/MainLoop.cpp
> +++ b/lldb/source/Host/common/MainLoop.cpp
> @@ -23,6 +23,8 @@
>  // (ppoll is present but not implemented properly). On windows we use WSApoll
>  // (which does not support signals).
>
> +#define HAVE_SYS_EVENT_H 1
> +
>  #if HAVE_SYS_EVENT_H
>  #include 
>  #elif defined(_WIN32)
>
> to my checkout it works. It looks like somehow llvm-config.h isn't
> propagate properly so `HAVE_SYS_EVENT_H` isn't defined?
> This looks like a bug to me, but maybe there's an easy way to work around it.
>

And in fact, this is what I see in my build directory:

$ grep -R SYS_EVENT './include/llvm/Config/llvm-config.h'
$

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

Re: [Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

[Davide Italiano via lldb-commits]

If I add:

diff --git a/lldb/source/Host/common/MainLoop.cpp
b/lldb/source/Host/common/MainLoop.cpp
index a4803936196..4fee76865ee 100644
--- a/lldb/source/Host/common/MainLoop.cpp
+++ b/lldb/source/Host/common/MainLoop.cpp
@@ -23,6 +23,8 @@
 // (ppoll is present but not implemented properly). On windows we use WSApoll
 // (which does not support signals).

+#define HAVE_SYS_EVENT_H 1
+
 #if HAVE_SYS_EVENT_H
 #include 
 #elif defined(_WIN32)

to my checkout it works. It looks like somehow llvm-config.h isn't
propagate properly so `HAVE_SYS_EVENT_H` isn't defined?
This looks like a bug to me, but maybe there's an easy way to work around it.

On Thu, Feb 28, 2019 at 11:04 AM Davide Italiano  wrote:
>
> On Thu, Feb 28, 2019 at 10:31 AM Davide Italiano  
> wrote:
> >
> > On Thu, Feb 28, 2019 at 8:25 AM Raphael Isemann via lldb-commits
> >  wrote:
> > >
> > > Am Do., 28. Feb. 2019 um 17:11 Uhr schrieb Pavel Labath via
> > > lldb-commits :
> > > >
> > > > On 28/02/2019 16:18, Pavel Labath via lldb-commits wrote:
> > > > > On 28/02/2019 02:37, Davide Italiano via Phabricator wrote:
> > > > >> davide added a comment.
> > > > >> Herald added a subscriber: jdoerfert.
> > > > >> Herald added a project: LLVM.
> > > > >>
> > > > >> Pavel, this broke unicode handling for lldb on MacOS. If you type
> > > > >> something in the lldb cmdline, it won't print the right character but
> > > > >> a series of unicode sequences.
> > > > >> The main concern is that this also breaks the Swift REPL (powered by
> > > > >> lldb).
> > > > >>
> > > > >> Looks like something like this:
> > > > >>
> > > > >>$ git diff
> > > > >>diff --git a/lldb/include/lldb/Host/Editline.h
> > > > >> b/lldb/include/lldb/Host/Editline.h
> > > > >>index cb40f1e6917..e53991c450f 100644
> > > > >>--- a/lldb/include/lldb/Host/Editline.h
> > > > >>+++ b/lldb/include/lldb/Host/Editline.h
> > > > >>@@ -51,6 +51,7 @@
> > > > >> #include 
> > > > >> #include 
> > > > >>+#include "lldb/Host/Config.h"
> > > > >> #include "lldb/Host/ConnectionFileDescriptor.h"
> > > > >> #include "lldb/Host/Predicate.h"
> > > > >> #include "lldb/Utility/FileSpec.h"
> > > > >>
> > > > >> "fixes" the CMake build. I'm seeing failures if I apply the same 
> > > > >> patch
> > > > >> to the Xcode project.
> > > > >
> > > > > Have you tried putting the `#include "lldb/Host/Config.h"` at the top 
> > > > > of
> > > > > Editline.h, so that LLDB_EDITLINE_USE_WCHAR is defined before the
> > > > > ```
> > > > > #if LLDB_EDITLINE_USE_WCHAR
> > > > > #include 
> > > > > #endif
> > > > > ```
> > > > > block ?
> > > >
> > > >
> > > >
> > > > Ok, I've done some more experiments, and I'm pretty sure this will fix
> > > > things. I didn't commit that yet because I found that this breaks the
> > > > modules build. I am not sure why is that, but I suspect this is because
> > > > we don't have a modulemap file for the lldb/Host/Config.h file. I am not
> > > > sure if I'll have time to fix that today.
> > > >
> > > > cheers,
> > > > pavel
> > > > ___
> > > > lldb-commits mailing list
> > > > lldb-commits@lists.llvm.org
> > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> > >
> > > Can you post the error if you still have the log around? If modules
> > > fail because this simple header is duplicated then that's an
> > > interesting Clang bug.
> > >
> > > - Raphael
> > >
> >
> > I confirm that putting the include at the beginning of the file fixes
> > my issues with Xcodebuild. I'm trying to reproduce with the modules
> > build and attach the log here.
> >
>
> Raphael, this is the error I'm seeing:
>
> [2689/3391] Building CXX object
> tools/lldb/source/Host/CMakeFiles/lldbHost.dir/common/MainLoop.cpp.o
>
> FAILED: tools/lldb/source/Host/CMakeFiles/lldbHost.dir/common/MainLoop.cpp.o
>
> /Applications/Xcode4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
>  -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -DLIBXML2_DEFINED
> -DLLDB_CONFIGURATION_RELEASE -DLLDB_USE_OS_LOG
> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -Itools/lldb/source/Host
> -I/Users/davide/llvm-monorepo/llvm-mono/llvm/tools/lldb/source/Host
> -Itools/lldb/include
> -I/Users/davide/llvm-monorepo/llvm-mono/llvm/tools/lldb/include
> -isystem 
> /Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/libxml2
> -Iinclude -I/Users/davide/llvm-monorepo/llvm-mono/llvm/include
> -I/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/python2.7
> -I/Users/davide/llvm-monorepo/llvm-mono/llvm/tools/clang/include
> -Itools/lldb/../clang/include
> -I/Users/davide/llvm-monorepo/llvm-mono/llvm/tools/lldb/source/. -fPIC
> -fvisibility-inlines-hidden -Werror=date-time
> -Werror=unguarded-availability-new -std=c++11 -fmodules
> 

[Lldb-commits] [PATCH] D58648: Improve process launch comments for Windows

[Adrian McCarthy via Phabricator via lldb-commits]

amccarth closed this revision.
amccarth added a comment.

Closed with r355121.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58648/new/

https://reviews.llvm.org/D58648



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

[Lldb-commits] [lldb] r355121 - Improve process launch comments for Windows

[Adrian McCarthy via lldb-commits]

Author: amccarth
Date: Thu Feb 28 11:14:02 2019
New Revision: 355121

URL: http://llvm.org/viewvc/llvm-project?rev=355121=rev
Log:
Improve process launch comments for Windows

The existing comment about over-allocating the command line was incorrect.  The
contents of the command line may be changed, but it's not necessary to over
allocate.  The changes will be limited to the existing contents of the string
(e.g., by replacing spaces with L'\0' to tokenize the command line).

Also added a comment explaining a possible cause of failure to save the next
programmer some time when they try to debug a 64-bit process from a 32-bit
LLDB.

Modified:
lldb/trunk/source/Host/windows/ProcessLauncherWindows.cpp

Modified: lldb/trunk/source/Host/windows/ProcessLauncherWindows.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Host/windows/ProcessLauncherWindows.cpp?rev=355121=355120=355121=diff
==
--- lldb/trunk/source/Host/windows/ProcessLauncherWindows.cpp (original)
+++ lldb/trunk/source/Host/windows/ProcessLauncherWindows.cpp Thu Feb 28 
11:14:02 2019
@@ -104,17 +104,21 @@ ProcessLauncherWindows::LaunchProcess(co
   llvm::ConvertUTF8toWide(commandLine, wcommandLine);
   llvm::ConvertUTF8toWide(launch_info.GetWorkingDirectory().GetCString(),
   wworkingDirectory);
+  // If the command line is empty, it's best to pass a null pointer to tell
+  // CreateProcessW to use the executable name as the command line.  If the
+  // command line is not empty, its contents may be modified by CreateProcessW.
+  WCHAR *pwcommandLine = wcommandLine.empty() ? nullptr : [0];
 
-  wcommandLine.resize(PATH_MAX); // Needs to be over-allocated because
- // CreateProcessW can modify it
   BOOL result = ::CreateProcessW(
-  wexecutable.c_str(), [0], NULL, NULL, TRUE, flags, 
env_block,
+  wexecutable.c_str(), pwcommandLine, NULL, NULL, TRUE, flags, env_block,
   wworkingDirectory.size() == 0 ? NULL : wworkingDirectory.c_str(),
   , );
 
   if (!result) {
 // Call GetLastError before we make any other system calls.
 error.SetError(::GetLastError(), eErrorTypeWin32);
+// Note that error 50 ("The request is not supported") will occur if you
+// try debug a 64-bit inferior from a 32-bit LLDB.
   }
 
   if (result) {


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

[Lldb-commits] [PATCH] D58748: [ExpressionParser] Test GetClangResourceDir

[Alex Langford via Phabricator via lldb-commits]

xiaobai added inline comments.



Comment at: packages/Python/lldbsuite/test/functionalities/paths/TestPaths.py:20
+# GetClangResourceDir doesn't work on windows yet
+@expectedFailureAll(oslist=["windows"])
 @no_debug_info_test

teemperor wrote:
> Doesn't that mean that we no longer test any of the paths on windows? E.g. if 
> someone breaks `lldb.ePathTypeLLDBShlibDir` we will not see this test failing 
> on Windows. I would prefer of extracting the ClangDir test into it's own 
> method that we mark as failing.
Technically it is being tested but it is expected to fail. That being said, I 
don't mind extracting the ClangDir test into its own method while I work on 
implementing it, but I don't think it needs its own test. Maybe after I 
implement `GetClangResourceDir` on windows I can merge the tests? :P 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58748/new/

https://reviews.llvm.org/D58748



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

Re: [Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

[Davide Italiano via lldb-commits]

On Thu, Feb 28, 2019 at 10:31 AM Davide Italiano  wrote:
>
> On Thu, Feb 28, 2019 at 8:25 AM Raphael Isemann via lldb-commits
>  wrote:
> >
> > Am Do., 28. Feb. 2019 um 17:11 Uhr schrieb Pavel Labath via
> > lldb-commits :
> > >
> > > On 28/02/2019 16:18, Pavel Labath via lldb-commits wrote:
> > > > On 28/02/2019 02:37, Davide Italiano via Phabricator wrote:
> > > >> davide added a comment.
> > > >> Herald added a subscriber: jdoerfert.
> > > >> Herald added a project: LLVM.
> > > >>
> > > >> Pavel, this broke unicode handling for lldb on MacOS. If you type
> > > >> something in the lldb cmdline, it won't print the right character but
> > > >> a series of unicode sequences.
> > > >> The main concern is that this also breaks the Swift REPL (powered by
> > > >> lldb).
> > > >>
> > > >> Looks like something like this:
> > > >>
> > > >>$ git diff
> > > >>diff --git a/lldb/include/lldb/Host/Editline.h
> > > >> b/lldb/include/lldb/Host/Editline.h
> > > >>index cb40f1e6917..e53991c450f 100644
> > > >>--- a/lldb/include/lldb/Host/Editline.h
> > > >>+++ b/lldb/include/lldb/Host/Editline.h
> > > >>@@ -51,6 +51,7 @@
> > > >> #include 
> > > >> #include 
> > > >>+#include "lldb/Host/Config.h"
> > > >> #include "lldb/Host/ConnectionFileDescriptor.h"
> > > >> #include "lldb/Host/Predicate.h"
> > > >> #include "lldb/Utility/FileSpec.h"
> > > >>
> > > >> "fixes" the CMake build. I'm seeing failures if I apply the same patch
> > > >> to the Xcode project.
> > > >
> > > > Have you tried putting the `#include "lldb/Host/Config.h"` at the top of
> > > > Editline.h, so that LLDB_EDITLINE_USE_WCHAR is defined before the
> > > > ```
> > > > #if LLDB_EDITLINE_USE_WCHAR
> > > > #include 
> > > > #endif
> > > > ```
> > > > block ?
> > >
> > >
> > >
> > > Ok, I've done some more experiments, and I'm pretty sure this will fix
> > > things. I didn't commit that yet because I found that this breaks the
> > > modules build. I am not sure why is that, but I suspect this is because
> > > we don't have a modulemap file for the lldb/Host/Config.h file. I am not
> > > sure if I'll have time to fix that today.
> > >
> > > cheers,
> > > pavel
> > > ___
> > > lldb-commits mailing list
> > > lldb-commits@lists.llvm.org
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> >
> > Can you post the error if you still have the log around? If modules
> > fail because this simple header is duplicated then that's an
> > interesting Clang bug.
> >
> > - Raphael
> >
>
> I confirm that putting the include at the beginning of the file fixes
> my issues with Xcodebuild. I'm trying to reproduce with the modules
> build and attach the log here.
>

Raphael, this is the error I'm seeing:

[2689/3391] Building CXX object
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/common/MainLoop.cpp.o

FAILED: tools/lldb/source/Host/CMakeFiles/lldbHost.dir/common/MainLoop.cpp.o

/Applications/Xcode4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
 -DGTEST_HAS_RTTI=0 -DHAVE_ROUND -DLIBXML2_DEFINED
-DLLDB_CONFIGURATION_RELEASE -DLLDB_USE_OS_LOG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-Itools/lldb/source/Host
-I/Users/davide/llvm-monorepo/llvm-mono/llvm/tools/lldb/source/Host
-Itools/lldb/include
-I/Users/davide/llvm-monorepo/llvm-mono/llvm/tools/lldb/include
-isystem 
/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/libxml2
-Iinclude -I/Users/davide/llvm-monorepo/llvm-mono/llvm/include
-I/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/python2.7
-I/Users/davide/llvm-monorepo/llvm-mono/llvm/tools/clang/include
-Itools/lldb/../clang/include
-I/Users/davide/llvm-monorepo/llvm-mono/llvm/tools/lldb/source/. -fPIC
-fvisibility-inlines-hidden -Werror=date-time
-Werror=unguarded-availability-new -std=c++11 -fmodules
-fmodules-cache-path=/Users/davide/llvm-monorepo/llvm-mono/build-re/module.cache
-fcxx-modules -Wall -Wextra -Wno-unused-parameter -Wwrite-strings
-Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long
-Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type
-Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion
-fdiagnostics-color -Wno-deprecated-declarations -Wno-unknown-pragmas
-Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -O3
-DNDEBUG -isysroot
/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
   -fno-exceptions -fno-rtti -MD -MT
tools/lldb/source/Host/CMakeFiles/lldbHost.dir/common/MainLoop.cpp.o
-MF tools/lldb/source/Host/CMakeFiles/lldbHost.dir/common/MainLoop.cpp.o.d
-o tools/lldb/source/Host/CMakeFiles/lldbHost.dir/common/MainLoop.cpp.o
-c 
/Users/davide/llvm-monorepo/llvm-mono/llvm/tools/lldb/source/Host/common/MainLoop.cpp

[Lldb-commits] [PATCH] D58648: Improve process launch comments for Windows

[Adrian McCarthy via Phabricator via lldb-commits]

amccarth added a comment.

Thanks.  I really don't know what other types of conditions may trigger that 
"request is not supported" message, so I'm going to shy away from trying to 
make it more specific.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58648/new/

https://reviews.llvm.org/D58648



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

Re: [Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

[Davide Italiano via lldb-commits]

On Thu, Feb 28, 2019 at 8:25 AM Raphael Isemann via lldb-commits
 wrote:
>
> Am Do., 28. Feb. 2019 um 17:11 Uhr schrieb Pavel Labath via
> lldb-commits :
> >
> > On 28/02/2019 16:18, Pavel Labath via lldb-commits wrote:
> > > On 28/02/2019 02:37, Davide Italiano via Phabricator wrote:
> > >> davide added a comment.
> > >> Herald added a subscriber: jdoerfert.
> > >> Herald added a project: LLVM.
> > >>
> > >> Pavel, this broke unicode handling for lldb on MacOS. If you type
> > >> something in the lldb cmdline, it won't print the right character but
> > >> a series of unicode sequences.
> > >> The main concern is that this also breaks the Swift REPL (powered by
> > >> lldb).
> > >>
> > >> Looks like something like this:
> > >>
> > >>$ git diff
> > >>diff --git a/lldb/include/lldb/Host/Editline.h
> > >> b/lldb/include/lldb/Host/Editline.h
> > >>index cb40f1e6917..e53991c450f 100644
> > >>--- a/lldb/include/lldb/Host/Editline.h
> > >>+++ b/lldb/include/lldb/Host/Editline.h
> > >>@@ -51,6 +51,7 @@
> > >> #include 
> > >> #include 
> > >>+#include "lldb/Host/Config.h"
> > >> #include "lldb/Host/ConnectionFileDescriptor.h"
> > >> #include "lldb/Host/Predicate.h"
> > >> #include "lldb/Utility/FileSpec.h"
> > >>
> > >> "fixes" the CMake build. I'm seeing failures if I apply the same patch
> > >> to the Xcode project.
> > >
> > > Have you tried putting the `#include "lldb/Host/Config.h"` at the top of
> > > Editline.h, so that LLDB_EDITLINE_USE_WCHAR is defined before the
> > > ```
> > > #if LLDB_EDITLINE_USE_WCHAR
> > > #include 
> > > #endif
> > > ```
> > > block ?
> >
> >
> >
> > Ok, I've done some more experiments, and I'm pretty sure this will fix
> > things. I didn't commit that yet because I found that this breaks the
> > modules build. I am not sure why is that, but I suspect this is because
> > we don't have a modulemap file for the lldb/Host/Config.h file. I am not
> > sure if I'll have time to fix that today.
> >
> > cheers,
> > pavel
> > ___
> > lldb-commits mailing list
> > lldb-commits@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
> Can you post the error if you still have the log around? If modules
> fail because this simple header is duplicated then that's an
> interesting Clang bug.
>
> - Raphael
>

I confirm that putting the include at the beginning of the file fixes
my issues with Xcodebuild. I'm trying to reproduce with the modules
build and attach the log here.

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

Re: [Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

[Raphael Isemann via lldb-commits]

Am Do., 28. Feb. 2019 um 17:11 Uhr schrieb Pavel Labath via
lldb-commits :
>
> On 28/02/2019 16:18, Pavel Labath via lldb-commits wrote:
> > On 28/02/2019 02:37, Davide Italiano via Phabricator wrote:
> >> davide added a comment.
> >> Herald added a subscriber: jdoerfert.
> >> Herald added a project: LLVM.
> >>
> >> Pavel, this broke unicode handling for lldb on MacOS. If you type
> >> something in the lldb cmdline, it won't print the right character but
> >> a series of unicode sequences.
> >> The main concern is that this also breaks the Swift REPL (powered by
> >> lldb).
> >>
> >> Looks like something like this:
> >>
> >>$ git diff
> >>diff --git a/lldb/include/lldb/Host/Editline.h
> >> b/lldb/include/lldb/Host/Editline.h
> >>index cb40f1e6917..e53991c450f 100644
> >>--- a/lldb/include/lldb/Host/Editline.h
> >>+++ b/lldb/include/lldb/Host/Editline.h
> >>@@ -51,6 +51,7 @@
> >> #include 
> >> #include 
> >>+#include "lldb/Host/Config.h"
> >> #include "lldb/Host/ConnectionFileDescriptor.h"
> >> #include "lldb/Host/Predicate.h"
> >> #include "lldb/Utility/FileSpec.h"
> >>
> >> "fixes" the CMake build. I'm seeing failures if I apply the same patch
> >> to the Xcode project.
> >
> > Have you tried putting the `#include "lldb/Host/Config.h"` at the top of
> > Editline.h, so that LLDB_EDITLINE_USE_WCHAR is defined before the
> > ```
> > #if LLDB_EDITLINE_USE_WCHAR
> > #include 
> > #endif
> > ```
> > block ?
>
>
>
> Ok, I've done some more experiments, and I'm pretty sure this will fix
> things. I didn't commit that yet because I found that this breaks the
> modules build. I am not sure why is that, but I suspect this is because
> we don't have a modulemap file for the lldb/Host/Config.h file. I am not
> sure if I'll have time to fix that today.
>
> cheers,
> pavel
> ___
> lldb-commits mailing list
> lldb-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Can you post the error if you still have the log around? If modules
fail because this simple header is duplicated then that's an
interesting Clang bug.

- Raphael

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

Re: [Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

[Pavel Labath via lldb-commits]

On 28/02/2019 16:18, Pavel Labath via lldb-commits wrote:

On 28/02/2019 02:37, Davide Italiano via Phabricator wrote:

davide added a comment.
Herald added a subscriber: jdoerfert.
Herald added a project: LLVM.

Pavel, this broke unicode handling for lldb on MacOS. If you type 
something in the lldb cmdline, it won't print the right character but 
a series of unicode sequences.
The main concern is that this also breaks the Swift REPL (powered by 
lldb).


Looks like something like this:

   $ git diff
   diff --git a/lldb/include/lldb/Host/Editline.h 
b/lldb/include/lldb/Host/Editline.h

   index cb40f1e6917..e53991c450f 100644
   --- a/lldb/include/lldb/Host/Editline.h
   +++ b/lldb/include/lldb/Host/Editline.h
   @@ -51,6 +51,7 @@
    #include 
    #include 
   +#include "lldb/Host/Config.h"
    #include "lldb/Host/ConnectionFileDescriptor.h"
    #include "lldb/Host/Predicate.h"
    #include "lldb/Utility/FileSpec.h"

"fixes" the CMake build. I'm seeing failures if I apply the same patch 
to the Xcode project.


Have you tried putting the `#include "lldb/Host/Config.h"` at the top of 
Editline.h, so that LLDB_EDITLINE_USE_WCHAR is defined before the

```
#if LLDB_EDITLINE_USE_WCHAR
#include 
#endif
```
block ?




Ok, I've done some more experiments, and I'm pretty sure this will fix 
things. I didn't commit that yet because I found that this breaks the 
modules build. I am not sure why is that, but I suspect this is because 
we don't have a modulemap file for the lldb/Host/Config.h file. I am not 
sure if I'll have time to fix that today.


cheers,
pavel
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [lldb] r355103 - [cmake] Move LLDB_DISABLE_LIBEDIT handling code into a central place

[Pavel Labath via lldb-commits]

Author: labath
Date: Thu Feb 28 08:04:54 2019
New Revision: 355103

URL: http://llvm.org/viewvc/llvm-project?rev=355103=rev
Log:
[cmake] Move LLDB_DISABLE_LIBEDIT handling code into a central place

This was previously scattered between the main CMakeLists.txt file and
LLDBGenerateConfig.cmake and LLDBConfig.cmake. This caused the some of
the code to be executed in incorrect order. Specifically, the check for
el_winsertstr was done before libedit_LIBRARIES was computed, and so it
always failed on the first run.

Moving it the two checks to a central place makes sure this doesn't
happen again and improves the overall readability.

Modified:
lldb/trunk/CMakeLists.txt
lldb/trunk/cmake/modules/LLDBConfig.cmake
lldb/trunk/cmake/modules/LLDBGenerateConfig.cmake

Modified: lldb/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=355103=355102=355103=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Thu Feb 28 08:04:54 2019
@@ -22,12 +22,6 @@ else()
   add_definitions( -DLLDB_CONFIGURATION_RELEASE )
 endif()
 
-if (LLDB_DISABLE_LIBEDIT)
-  add_definitions( -DLLDB_DISABLE_LIBEDIT )
-else()
-  find_package(LibEdit REQUIRED)
-endif()
-
 if(APPLE)
   add_definitions(-DLLDB_USE_OS_LOG)
 endif()

Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=355103=355102=355103=diff
==
--- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake Thu Feb 28 08:04:54 2019
@@ -1,4 +1,5 @@
 include(CheckCXXSymbolExists)
+include(CheckTypeSize)
 
 set(LLDB_PROJECT_ROOT ${CMAKE_CURRENT_SOURCE_DIR})
 set(LLDB_SOURCE_ROOT "${CMAKE_CURRENT_SOURCE_DIR}/source")
@@ -91,6 +92,29 @@ if (LLDB_DISABLE_CURSES)
   add_definitions( -DLLDB_DISABLE_CURSES )
 endif()
 
+if (LLDB_DISABLE_LIBEDIT)
+  add_definitions( -DLLDB_DISABLE_LIBEDIT )
+else()
+  find_package(LibEdit REQUIRED)
+
+  # Check if we libedit capable of handling wide characters (built with
+  # '--enable-widec').
+  set(CMAKE_REQUIRED_LIBRARIES ${libedit_LIBRARIES})
+  set(CMAKE_REQUIRED_INCLUDES ${libedit_INCLUDE_DIRS})
+  check_symbol_exists(el_winsertstr histedit.h LLDB_EDITLINE_USE_WCHAR)
+  set(CMAKE_EXTRA_INCLUDE_FILES histedit.h)
+  check_type_size(el_rfunc_t LLDB_EL_RFUNC_T_SIZE)
+  if (LLDB_EL_RFUNC_T_SIZE STREQUAL "")
+set(LLDB_HAVE_EL_RFUNC_T 0)
+  else()
+set(LLDB_HAVE_EL_RFUNC_T 1)
+  endif()
+  set(CMAKE_REQUIRED_LIBRARIES)
+  set(CMAKE_REQUIRED_INCLUDES)
+  set(CMAKE_EXTRA_INCLUDE_FILES)
+endif()
+
+
 # On Windows, we can't use the normal FindPythonLibs module that comes with 
CMake,
 # for a number of reasons.
 # 1) Prior to MSVC 2015, it is only possible to embed Python if python itself 
was

Modified: lldb/trunk/cmake/modules/LLDBGenerateConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBGenerateConfig.cmake?rev=355103=355102=355103=diff
==
--- lldb/trunk/cmake/modules/LLDBGenerateConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBGenerateConfig.cmake Thu Feb 28 08:04:54 2019
@@ -4,7 +4,6 @@ include(CheckSymbolExists)
 include(CheckIncludeFile)
 include(CheckIncludeFiles)
 include(CheckLibraryExists)
-include(CheckTypeSize)
 
 set(CMAKE_REQUIRED_DEFINITIONS -D_GNU_SOURCE)
 check_symbol_exists(ppoll poll.h HAVE_PPOLL)
@@ -28,24 +27,6 @@ if(NOT UNIX)
   set(LLDB_DISABLE_POSIX 1)
 endif()
 
-if (NOT LLDB_DISABLE_LIBEDIT)
-  # Check if we libedit capable of handling wide characters (built with
-  # '--enable-widec').
-  set(CMAKE_REQUIRED_LIBRARIES ${libedit_LIBRARIES})
-  set(CMAKE_REQUIRED_INCLUDES ${libedit_INCLUDE_DIRS})
-  check_symbol_exists(el_winsertstr histedit.h LLDB_EDITLINE_USE_WCHAR)
-  set(CMAKE_EXTRA_INCLUDE_FILES histedit.h)
-  check_type_size(el_rfunc_t LLDB_EL_RFUNC_T_SIZE)
-  if (LLDB_EL_RFUNC_T_SIZE STREQUAL "")
-set(LLDB_HAVE_EL_RFUNC_T 0)
-  else()
-set(LLDB_HAVE_EL_RFUNC_T 1)
-  endif()
-  set(CMAKE_REQUIRED_LIBRARIES)
-  set(CMAKE_REQUIRED_INCLUDES)
-  set(CMAKE_EXTRA_INCLUDE_FILES)
-endif()
-
 if(NOT LLDB_CONFIG_HEADER_INPUT)
  set(LLDB_CONFIG_HEADER_INPUT ${LLDB_INCLUDE_ROOT}/lldb/Host/Config.h.cmake)
 endif()


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

Re: [Lldb-commits] [PATCH] D47625: [cmake] Detect presence of wide-char libedit at build time

[Pavel Labath via lldb-commits]

On 28/02/2019 02:37, Davide Italiano via Phabricator wrote:

davide added a comment.
Herald added a subscriber: jdoerfert.
Herald added a project: LLVM.

Pavel, this broke unicode handling for lldb on MacOS. If you type something in 
the lldb cmdline, it won't print the right character but a series of unicode 
sequences.
The main concern is that this also breaks the Swift REPL (powered by lldb).

Looks like something like this:

   $ git diff
   diff --git a/lldb/include/lldb/Host/Editline.h 
b/lldb/include/lldb/Host/Editline.h
   index cb40f1e6917..e53991c450f 100644
   --- a/lldb/include/lldb/Host/Editline.h
   +++ b/lldb/include/lldb/Host/Editline.h
   @@ -51,6 +51,7 @@
#include 
#include 

   +#include "lldb/Host/Config.h"

#include "lldb/Host/ConnectionFileDescriptor.h"
#include "lldb/Host/Predicate.h"
#include "lldb/Utility/FileSpec.h"

"fixes" the CMake build. I'm seeing failures if I apply the same patch to the 
Xcode project.


Have you tried putting the `#include "lldb/Host/Config.h"` at the top of 
Editline.h, so that LLDB_EDITLINE_USE_WCHAR is defined before the

```
#if LLDB_EDITLINE_USE_WCHAR
#include 
#endif
```
block ?
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D58564: [Reproducers] Add command provider

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D58564#1412674 , @JDevlieghere 
wrote:

> Pavel made a good point that with the previous implementation, the first call 
> to RunCommandInterpreter would replay every recorded commands. This is indeed 
> incorrect, because it's possible and likely that the state of the debugger 
> has changed between different runs of the commands interpreter.
>
> Now every call to RunCommandInterpreter gets its own buffer. During replay, 
> we will change the input file handler before invocation of 
> "RunCommandInterpreter". This works because this function is only called 
> through the SB layer.
>
> I'm not convinced doing the recorded at a lower level has any benefits. I 
> investigated this route before and the IOHandler seems basically the same 
> things as the command interpreter. We would still need to make the 
> distinction between things that should and shouldn't be recorded (e.g. 
> sourcing a file vs every command in the file). This would be a lot harder to 
> do there, because we have less information.


In my imagination, this "information" would come down from 
`SBDebugger::SetInputFileHandle`, together with the `FILE*` we actually read 
the commands from. So, a really crude prototype could be something like:

  SBDebugger::SetInputFileHandle(FILE *in) {
  if (recording) m_debugger->SetInputFileHandle(in, /*new argument!!!*/ new 
FileShadowRecorder(...));
  else if (replaying) m_debugger->SetInputFileHandle(GetRecordedFile(...), 
nullptr);
  }

The FILE* would trickle down into where you read the commands (this could be 
the IOHandler, or it could be the CommandInterpreter object),  where you would 
do something like:

  auto stuff = read_stuff(in);
  if (shadow_recorder)
shadow_recorder->record_stuff(stuff);

Now when you're sourcing an external file, you just pass in a nullptr for the 
recorder when you're setting the input handle for the command interpreter.

So, in essence the shadow recorder would kind of serve the same purpose as your 
`add_to_reproducer` flag, but IMO this would be better because it would come 
straight from the source (`SetInputFileHandle`) and you wouldn't need to rely 
on comments like "This works because this function is only called through the 
SB layer". Another benefit would be that this would work out-of-the-box in case 
you have multiple SBDebugger objects around, each with it's own command 
interpreter (right now this wouldn't work because the `StartNewBuffer` thingies 
would step on each others toes). I don't know when or if you plan to support 
that, but right now that tells me that this is a better design.




Comment at: lldb/source/Interpreter/CommandInterpreter.cpp:144
+for (std::size_t i = 0; i < m_commands.size(); ++i) {
+  llvm::Twine filename = llvm::Twine(info::name) + llvm::Twine("-") +
+ llvm::Twine(i) + llvm::Twine(".txt");

This is incorrect usage of the Twine class. The temporary Twine objects will be 
destroyed before you get a chance to stringify them.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58564/new/

https://reviews.llvm.org/D58564



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

[Lldb-commits] [PATCH] D58648: Improve process launch comments for Windows

[Pavel Labath via Phabricator via lldb-commits]

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

Looks fine to me. If this "The request is not supported" error is something 
that makes it's way to the user, and the error code is reasonably unambiguous 
(it +/- only happens when debugging 64 bit process from 32bit lldb), you may 
want to consider changing the error message to something more understandable.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58648/new/

https://reviews.llvm.org/D58648



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