[Lldb-commits] [PATCH] D65363: [lldb-vscode] add `launchCommands` to handle launch specific commands

[Wanyi Ye via Phabricator via lldb-commits]

kusmour created this revision.
kusmour added a reviewer: xiaobai.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

This can help `lldb-vscode` handle launch commands associate with remote 
platform
attach request have field `attachCommands` to handle attach specific commands
add a corresponding one for launch request
if no launch command is provided, create a new target and launch; otherwise, 
execute the launch command


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D65363

Files:
  lldb/tools/lldb-vscode/lldb-vscode.cpp


Index: lldb/tools/lldb-vscode/lldb-vscode.cpp
===
--- lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -1180,6 +1180,7 @@
   g_vsc.pre_run_commands = GetStrings(arguments, "preRunCommands");
   g_vsc.stop_commands = GetStrings(arguments, "stopCommands");
   g_vsc.exit_commands = GetStrings(arguments, "exitCommands");
+  auto launchCommands = GetStrings(arguments, "launchCommands");
   g_vsc.stop_at_entry = GetBoolean(arguments, "stopOnEntry", false);
   const auto debuggerRoot = GetString(arguments, "debuggerRoot");
 
@@ -1252,11 +1253,19 @@
 
   // Run any pre run LLDB commands the user specified in the launch.json
   g_vsc.RunPreRunCommands();
-
-  // Disable async events so the launch will be successful when we return from
-  // the launch call and the launch will happen synchronously
   g_vsc.debugger.SetAsync(false);
-  g_vsc.target.Launch(g_vsc.launch_info, error);
+  if (launchCommands.empty()) {
+// Disable async events so the launch will be successful when we return 
from
+// the launch call and the launch will happen synchronously
+g_vsc.target.Launch(g_vsc.launch_info, error);
+// g_vsc.debugger.SetAsync(true);
+  } else {
+g_vsc.RunLLDBCommands("Running launchCommands:", launchCommands);
+// The custom commands might have created a new target so we should use the
+// selected target after these commands are run.
+g_vsc.target = g_vsc.debugger.GetSelectedTarget();
+  }
+
   if (error.Fail()) {
 response["success"] = llvm::json::Value(false);
 EmplaceSafeString(response, "message", std::string(error.GetCString()));


Index: lldb/tools/lldb-vscode/lldb-vscode.cpp
===
--- lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -1180,6 +1180,7 @@
   g_vsc.pre_run_commands = GetStrings(arguments, "preRunCommands");
   g_vsc.stop_commands = GetStrings(arguments, "stopCommands");
   g_vsc.exit_commands = GetStrings(arguments, "exitCommands");
+  auto launchCommands = GetStrings(arguments, "launchCommands");
   g_vsc.stop_at_entry = GetBoolean(arguments, "stopOnEntry", false);
   const auto debuggerRoot = GetString(arguments, "debuggerRoot");
 
@@ -1252,11 +1253,19 @@
 
   // Run any pre run LLDB commands the user specified in the launch.json
   g_vsc.RunPreRunCommands();
-
-  // Disable async events so the launch will be successful when we return from
-  // the launch call and the launch will happen synchronously
   g_vsc.debugger.SetAsync(false);
-  g_vsc.target.Launch(g_vsc.launch_info, error);
+  if (launchCommands.empty()) {
+// Disable async events so the launch will be successful when we return from
+// the launch call and the launch will happen synchronously
+g_vsc.target.Launch(g_vsc.launch_info, error);
+// g_vsc.debugger.SetAsync(true);
+  } else {
+g_vsc.RunLLDBCommands("Running launchCommands:", launchCommands);
+// The custom commands might have created a new target so we should use the
+// selected target after these commands are run.
+g_vsc.target = g_vsc.debugger.GetSelectedTarget();
+  }
+
   if (error.Fail()) {
 response["success"] = llvm::json::Value(false);
 EmplaceSafeString(response, "message", std::string(error.GetCString()));
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D65362: [CMake] Move project() call to main CMake file

[Haibo Huang via Phabricator via lldb-commits]

hhb created this revision.
Herald added subscribers: lldb-commits, mgorny.
Herald added a project: LLDB.

The main CMake file don't have a project() call. In this case, cmake will run a 
dummy project(Project ) at the very beginning. Even before 
cmake_minimum_required. And a series of compiler detections will be triggered.

This is problematic if we depends on some policy to be set. E.g. CMP0056. 
try_compile will fail before we have a chance to do anything.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65362

Files:
  lldb/CMakeLists.txt
  lldb/cmake/modules/LLDBStandalone.cmake


Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -1,5 +1,3 @@
-project(lldb)
-
 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 
'install' target." OFF)
 
 find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
Index: lldb/CMakeLists.txt
===
--- lldb/CMakeLists.txt
+++ lldb/CMakeLists.txt
@@ -14,6 +14,7 @@
 # If we are not building as part of LLVM, build LLDB as a standalone project,
 # using LLVM as an external library.
 if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+  project(lldb)
   include(LLDBStandalone)
 endif()
 


Index: lldb/cmake/modules/LLDBStandalone.cmake
===
--- lldb/cmake/modules/LLDBStandalone.cmake
+++ lldb/cmake/modules/LLDBStandalone.cmake
@@ -1,5 +1,3 @@
-project(lldb)
-
 option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF)
 
 find_package(LLVM REQUIRED CONFIG HINTS "${LLVM_DIR}" NO_CMAKE_FIND_ROOT_PATH)
Index: lldb/CMakeLists.txt
===
--- lldb/CMakeLists.txt
+++ lldb/CMakeLists.txt
@@ -14,6 +14,7 @@
 # If we are not building as part of LLVM, build LLDB as a standalone project,
 # using LLVM as an external library.
 if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+  project(lldb)
   include(LLDBStandalone)
 endif()
 
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D65122: [Symbol] Use llvm::Expected when getting TypeSystems

[Alex Langford via Phabricator via lldb-commits]

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

Address comments:

- Use Expected
- Did some formatting
- Made error checking more explicit


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

https://reviews.llvm.org/D65122

Files:
  include/lldb/Core/Module.h
  include/lldb/Symbol/SymbolFile.h
  include/lldb/Symbol/TypeSystem.h
  include/lldb/Target/Target.h
  source/API/SBModule.cpp
  source/Breakpoint/Watchpoint.cpp
  source/Core/Module.cpp
  source/Core/ValueObjectRegister.cpp
  source/DataFormatters/VectorType.cpp
  source/Expression/Materializer.cpp
  source/Plugins/ExpressionParser/Clang/ClangASTSource.cpp
  source/Plugins/Language/CPlusPlus/BlockPointer.cpp
  source/Plugins/Language/ObjC/CoreMedia.cpp
  source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.h
  source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.cpp
  source/Plugins/SymbolFile/DWARF/DWARFBaseDIE.h
  source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
  source/Plugins/SymbolFile/DWARF/DWARFUnit.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDwo.h
  source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.cpp
  source/Plugins/SymbolFile/NativePDB/PdbAstBuilder.h
  source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
  source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h
  source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
  source/Plugins/SymbolFile/PDB/SymbolFilePDB.h
  source/Plugins/SystemRuntime/MacOSX/AppleGetItemInfoHandler.cpp
  source/Symbol/SymbolFile.cpp
  source/Symbol/Type.cpp
  source/Symbol/TypeSystem.cpp
  source/Target/StackFrame.cpp
  source/Target/Target.cpp
  source/Target/ThreadPlanTracer.cpp
  tools/lldb-test/lldb-test.cpp

Index: tools/lldb-test/lldb-test.cpp
===
--- tools/lldb-test/lldb-test.cpp
+++ tools/lldb-test/lldb-test.cpp
@@ -528,10 +528,15 @@
   if (!symfile)
 return make_string_error("Module has no symbol file.");
 
-  auto clang_ast_ctx = llvm::dyn_cast_or_null(
-  symfile->GetTypeSystemForLanguage(eLanguageTypeC_plus_plus));
+  auto type_system_or_err =
+  symfile->GetTypeSystemForLanguage(eLanguageTypeC_plus_plus);
+  if (!type_system_or_err)
+return make_string_error("Can't retrieve ClangASTContext");
+
+  auto *clang_ast_ctx =
+  llvm::dyn_cast_or_null(_system_or_err.get());
   if (!clang_ast_ctx)
-return make_string_error("Can't retrieve Clang AST context.");
+return make_string_error("Retrieved TypeSystem was not a ClangASTContext");
 
   auto ast_ctx = clang_ast_ctx->getASTContext();
   if (!ast_ctx)
Index: source/Target/ThreadPlanTracer.cpp
===
--- source/Target/ThreadPlanTracer.cpp
+++ source/Target/ThreadPlanTracer.cpp
@@ -93,15 +93,19 @@
 
 TypeFromUser ThreadPlanAssemblyTracer::GetIntPointerType() {
   if (!m_intptr_type.IsValid()) {
-TargetSP target_sp(m_thread.CalculateTarget());
-if (target_sp) {
-  TypeSystem *type_system =
-  target_sp->GetScratchTypeSystemForLanguage(nullptr, eLanguageTypeC);
-  if (type_system)
-m_intptr_type =
-TypeFromUser(type_system->GetBuiltinTypeForEncodingAndBitSize(
+if (auto target_sp = m_thread.CalculateTarget()) {
+  auto type_system_or_err =
+  target_sp->GetScratchTypeSystemForLanguage(eLanguageTypeC);
+  if (auto err = type_system_or_err.takeError()) {
+llvm::consumeError(std::move(err));
+LLDB_LOG(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_TYPES),
+ llvm::toString(std::move(err)).c_str());
+  } else {
+m_intptr_type = TypeFromUser(
+type_system_or_err->GetBuiltinTypeForEncodingAndBitSize(
 eEncodingUint,
 target_sp->GetArchitecture().GetAddressByteSize() * 8));
+  }
 }
   }
   return m_intptr_type;
Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -2119,15 +2119,12 @@
 target->SetExecutableModule(exe_module_sp, eLoadDependentsYes);
 }
 
-TypeSystem *Target::GetScratchTypeSystemForLanguage(Status *error,
-lldb::LanguageType language,
-bool create_on_demand) {
+llvm::Expected
+Target::GetScratchTypeSystemForLanguage(lldb::LanguageType language,
+bool create_on_demand) {
   if (!m_valid)
-return nullptr;
-
-  if (error) {
-error->Clear();
-  }
+return llvm::make_error("Invalid Target",
+   llvm::inconvertibleErrorCode());
 
   if (language == eLanguageTypeMipsAssembler // GNU AS and LLVM use it for all
  

[Lldb-commits] [PATCH] D65249: [NFC] use C++11 in AlignOf.h

[Billy Robert O'Neal III via Phabricator via lldb-commits]

BillyONeal added a comment.

(In fact I observe many patterns in this review like:

enum { Foo = alignof(void*); }
aligned_storage_t<1234, Foo> x;

and then a bunch of casting to treat it as a char buffer; if it was just born 
as a char buffer you can remove both the casts and the enum hack:

alignas(void*) char x[1234];


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65249



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

[Lldb-commits] [PATCH] D65249: [NFC] use C++11 in AlignOf.h

[Billy Robert O'Neal III via Phabricator via lldb-commits]

BillyONeal added a comment.

In D65249#1603335 , @jfb wrote:

> @rnk: how about I add a bit of code that wraps `aligned_storage` on all 
> platforms except MSVC (where I'd implement it as Billy suggests). That would 
> mean updating all the uses of `aligned_storage` to this LLVM one, but that's 
> not a big deal.


Why not just always use the alignas version? Or even better, not involve a 
library for something you can say in the core language at all?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65249



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

Can we add a section for "Building LLDB with Xcode"? We had a shell script 
patch that was going to be checked in, not sure if it made it. But it did a two 
part thing where it built LLVM and clang and then generated an Xcode project. I 
would rather just produce the Xcode project using cmake, very similar to other 
instructions. My mac cmake line has:

  cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb" 
-DCMAKE_BUILD_TYPE:STRING=Debug -DLLVM_ENABLE_ASSERTIONS:BOOL=TRUE 
-DLLDB_BUILD_FRAMEWORK:BOOL=TRUE -DLLDB_USE_SYSTEM_DEBUGSERVER=ON 
/path/to/llvm-project/llvm

Important bits are the projects being set to "clang;libcxx;lldb" (include 
libcxx) and building the framework and using the system debugserver


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65249: [NFC] use C++11 in AlignOf.h

[JF Bastien via Phabricator via lldb-commits]

jfb added a comment.

In D65249#1603278 , @BillyONeal wrote:

> > @BillyONeal do you know if 19.11 has the aligned_storage issue on x86?
>
> aligned_storage is still capped at what the library can fake with unions. It 
> would be an ABI break to change it to use alignas, so things where the x86 
> stack temporarily breaks T's usual alignment rules will affect it (and for 
> all releases using VS2015's ABI). We recommend customers use `alignas(T) 
> unsigned char space[sizeof(T)]` if they can't tolerate such limitations.


Thanks!

@rnk: how about I add a bit of code that wraps `aligned_storage` on all 
platforms except MSVC (where I'd implement it as Billy suggests). That would 
mean updating all the uses of `aligned_storage` to this LLVM one, but that's 
not a big deal.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65249



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

[Lldb-commits] [PATCH] D65249: [NFC] use C++11 in AlignOf.h

[Billy Robert O'Neal III via Phabricator via lldb-commits]

BillyONeal added a comment.

> @BillyONeal do you know if 19.11 has the aligned_storage issue on x86?

aligned_storage is still capped at what the library can fake with unions. It 
would be an ABI break to change it to use alignas, so things where the x86 
stack temporarily breaks T's usual alignment rules will affect it (and for all 
releases using VS2015's ABI). We recommend customers use `alignas(T) unsigned 
char space[sizeof(T)]` if they can't tolerate such limitations.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65249



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

[Lldb-commits] [PATCH] D65353: [lldb] Also include the array definition in Properties.inc

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere created this revision.
JDevlieghere added a reviewer: teemperor.

Right now our Properties.inc only generates the initializer for the options 
list but
not the array declaration boilerplate around it. As the array definition is 
identical for all arrays,
we might as well also let the Properties.inc generate it alongside the 
initializers.

Unfortunately we cannot do the same for enums, as there's this magic 
`ePropertyExperimental`, 
which needs to come at the end to be interpreted correctly. Hopefully we can 
get rid of this in
the future and do the same for the property enums.


https://reviews.llvm.org/D65353

Files:
  lldb/source/Core/Debugger.cpp
  lldb/source/Core/ModuleList.cpp
  lldb/source/Interpreter/CommandInterpreter.cpp
  lldb/source/Interpreter/Properties.td
  lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
  lldb/source/Plugins/JITLoader/GDB/JITLoaderGDB.cpp
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwinKernel.cpp
  lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
  lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
  lldb/source/Plugins/StructuredData/DarwinLog/StructuredDataDarwinLog.cpp
  lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  lldb/source/Target/Platform.cpp
  lldb/source/Target/Process.cpp
  lldb/source/Target/Target.cpp
  lldb/source/Target/Thread.cpp
  lldb/utils/TableGen/LLDBPropertyDefEmitter.cpp

Index: lldb/utils/TableGen/LLDBPropertyDefEmitter.cpp
===
--- lldb/utils/TableGen/LLDBPropertyDefEmitter.cpp
+++ lldb/utils/TableGen/LLDBPropertyDefEmitter.cpp
@@ -124,8 +124,11 @@
   // user to define the macro for the options that are needed.
   OS << "// Property definitions for " << PropertyName << "\n";
   OS << "#ifdef " << NeededMacro << "\n";
+  OS << "static constexpr PropertyDefinition g_" << PropertyName
+ << "_properties[] = {\n";
   for (Record *R : PropertyRecords)
 emitProperty(R, OS);
+  OS << "};\n";
   // We undefine the macro for the user like Clang's include files are doing it.
   OS << "#undef " << NeededMacro << "\n";
   OS << "#endif // " << PropertyName << " Property\n\n";
@@ -144,8 +147,10 @@
   // user to define the macro for the options that are needed.
   OS << "// Property enum cases for " << PropertyName << "\n";
   OS << "#ifdef " << NeededMacro << "\n";
+  // OS << "enum {\n";
   for (Record *R : PropertyRecords)
 emitPropertyEnum(R, OS);
+  // OS << "};\n";
   // We undefine the macro for the user like Clang's include files are doing it.
   OS << "#undef " << NeededMacro << "\n";
   OS << "#endif // " << PropertyName << " Property\n\n";
Index: lldb/source/Target/Thread.cpp
===
--- lldb/source/Target/Thread.cpp
+++ lldb/source/Target/Thread.cpp
@@ -63,10 +63,8 @@
   return *g_settings_sp_ptr;
 }
 
-static constexpr PropertyDefinition g_properties[] = {
 #define LLDB_PROPERTIES_thread
 #include "Properties.inc"
-};
 
 enum {
 #define LLDB_PROPERTIES_thread
@@ -108,7 +106,7 @@
   if (is_global) {
 m_collection_sp =
 std::make_shared(ConstString("thread"));
-m_collection_sp->Initialize(g_properties);
+m_collection_sp->Initialize(g_thread_properties);
   } else
 m_collection_sp = std::make_shared(
 Thread::GetGlobalProperties().get());
@@ -133,25 +131,25 @@
 bool ThreadProperties::GetTraceEnabledState() const {
   const uint32_t idx = ePropertyEnableThreadTrace;
   return m_collection_sp->GetPropertyAtIndexAsBoolean(
-  nullptr, idx, g_properties[idx].default_uint_value != 0);
+  nullptr, idx, g_thread_properties[idx].default_uint_value != 0);
 }
 
 bool ThreadProperties::GetStepInAvoidsNoDebug() const {
   const uint32_t idx = ePropertyStepInAvoidsNoDebug;
   return m_collection_sp->GetPropertyAtIndexAsBoolean(
-  nullptr, idx, g_properties[idx].default_uint_value != 0);
+  nullptr, idx, g_thread_properties[idx].default_uint_value != 0);
 }
 
 bool ThreadProperties::GetStepOutAvoidsNoDebug() const {
   const uint32_t idx = ePropertyStepOutAvoidsNoDebug;
   return m_collection_sp->GetPropertyAtIndexAsBoolean(
-  nullptr, idx, g_properties[idx].default_uint_value != 0);
+  nullptr, idx, g_thread_properties[idx].default_uint_value != 0);
 }
 
 uint64_t ThreadProperties::GetMaxBacktraceDepth() const {
   const uint32_t idx = ePropertyMaxBacktraceDepth;
   return m_collection_sp->GetPropertyAtIndexAsUInt64(
-  nullptr, idx, g_properties[idx].default_uint_value != 0);
+  nullptr, idx, g_thread_properties[idx].default_uint_value != 0);
 }
 
 // Thread Event Data
Index: lldb/source/Target/Target.cpp
===
--- lldb/source/Target/Target.cpp
+++ lldb/source/Target/Target.cpp
@@ -3273,10 +3273,8 @@
  "Load complete information when loading modules from memory. Currently "
  "this setting loads sections and all 

[Lldb-commits] [PATCH] D65311: [dotest] Remove multiprocessing

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

This seems okay to me.  I would also check with Jason.  I don't know who 
coordinates running tests remotely - or even if they can run in parallel now.  
But that's the one bit I don't understand well enough to say yea or nay on.


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

https://reviews.llvm.org/D65311



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

[Lldb-commits] [lldb] r367153 - [CMake] Print the correct variables

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Fri Jul 26 13:58:10 2019
New Revision: 367153

URL: http://llvm.org/viewvc/llvm-project?rev=367153=rev
Log:
[CMake] Print the correct variables

This didn't get updated after we decided to set PYTHON_MAJOR_VERSION and
PYTHON_MINOR_VERSION in find_python_libs_windows, instead of parsing the
variables ourselves.

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

Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=367153=367152=367153=diff
==
--- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake Fri Jul 26 13:58:10 2019
@@ -226,7 +226,7 @@ if (NOT LLDB_DISABLE_PYTHON)
 # version for the system provided interpreter and libraries.
 if (NOT PYTHON_VERSION_MAJOR VERSION_EQUAL pythonlibs_major OR
 NOT PYTHON_VERSION_MINOR VERSION_EQUAL pythonlibs_minor)
-  message(FATAL_ERROR "Found incompatible Python interpreter 
(${python_major}.${python_minor})"
+  message(FATAL_ERROR "Found incompatible Python interpreter 
(${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})"
   " and Python libraries 
(${pythonlibs_major}.${pythonlibs_minor})")
 endif()
   endif()


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

[Lldb-commits] [PATCH] D65249: [NFC] use C++11 in AlignOf.h

[JF Bastien via Phabricator via lldb-commits]

jfb added a subscriber: BillyONeal.
jfb added a comment.

In D65249#1603133 , @rnk wrote:

> I still think this concern applies:
>  https://reviews.llvm.org/D64417#1576675
>
> I'm not sure how to track down an 19.11 release to test if we can pass 
> std::aligned_storage values through function calls on x86. We might be better 
> off raising the minimum to 19.14, which is a more recent MSVC release in the 
> 2017 track. I don't think it's too much to ask developers to use the most 
> recent version of the 2017 compiler, they won't have to change IDEs.


@BillyONeal do you know if 19.11 has the `aligned_storage` issue on x86?

If it does then indeed we should raise the minimum version, I'll send an RFC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65249



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

[Lldb-commits] [lldb] r367152 - [TableGen] Fix stale include paths

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Fri Jul 26 13:55:07 2019
New Revision: 367152

URL: http://llvm.org/viewvc/llvm-project?rev=367152=rev
Log:
[TableGen] Fix stale include paths

This worked locally because the include files were not regenerated, but
fails when performing a clean build.

Modified:
lldb/trunk/source/Core/Debugger.cpp
lldb/trunk/source/Core/ModuleList.cpp

Modified: lldb/trunk/source/Core/Debugger.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Debugger.cpp?rev=367152=367151=367152=diff
==
--- lldb/trunk/source/Core/Debugger.cpp (original)
+++ lldb/trunk/source/Core/Debugger.cpp Fri Jul 26 13:55:07 2019
@@ -204,12 +204,12 @@ static constexpr OptionEnumValueElement
 
 static constexpr PropertyDefinition g_properties[] = {
 #define LLDB_PROPERTIES_debugger
-#include "lldb/Core/Properties.inc"
+#include "Properties.inc"
 };
 
 enum {
 #define LLDB_PROPERTIES_debugger
-#include "lldb/Core/PropertiesEnum.inc"
+#include "PropertiesEnum.inc"
 };
 
 LoadPluginCallbackType Debugger::g_load_plugin_callback = nullptr;

Modified: lldb/trunk/source/Core/ModuleList.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ModuleList.cpp?rev=367152=367151=367152=diff
==
--- lldb/trunk/source/Core/ModuleList.cpp (original)
+++ lldb/trunk/source/Core/ModuleList.cpp Fri Jul 26 13:55:07 2019
@@ -67,12 +67,12 @@ namespace {
 
 static constexpr PropertyDefinition g_properties[] = {
 #define LLDB_PROPERTIES_modulelist
-#include "lldb/Core/Properties.inc"
+#include "Properties.inc"
 };
 
 enum {
 #define LLDB_PROPERTIES_modulelist
-#include "lldb/Core/PropertiesEnum.inc"
+#include "PropertiesEnum.inc"
 };
 
 } // namespace
@@ -126,9 +126,9 @@ ModuleList::ModuleList(ModuleList::Notif
 const ModuleList ::operator=(const ModuleList ) {
   if (this != ) {
 std::lock(m_modules_mutex, rhs.m_modules_mutex);
-std::lock_guard lhs_guard(m_modules_mutex, 
+std::lock_guard lhs_guard(m_modules_mutex,
 std::adopt_lock);
-std::lock_guard rhs_guard(rhs.m_modules_mutex, 
+std::lock_guard rhs_guard(rhs.m_modules_mutex,
 std::adopt_lock);
 m_modules = rhs.m_modules;
   }
@@ -146,8 +146,8 @@ void ModuleList::AppendImpl(const Module
   }
 }
 
-void ModuleList::Append(const ModuleSP _sp, bool notify) { 
-  AppendImpl(module_sp, notify); 
+void ModuleList::Append(const ModuleSP _sp, bool notify) {
+  AppendImpl(module_sp, notify);
 }
 
 void ModuleList::ReplaceEquivalent(const ModuleSP _sp) {


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

[Lldb-commits] [PATCH] D65249: [NFC] use C++11 in AlignOf.h

[Reid Kleckner via Phabricator via lldb-commits]

rnk added a comment.

I still think this concern applies:
https://reviews.llvm.org/D64417#1576675

I'm not sure how to track down an 19.11 release to test if we can pass 
std::aligned_storage values through function calls on x86. We might be better 
off raising the minimum to 19.14, which is a more recent MSVC release in the 
2017 track. I don't think it's too much to ask developers to use the most 
recent version of the 2017 compiler, they won't have to change IDEs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65249



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

[Lldb-commits] [PATCH] D65331: [lldb] Also include the array definition in CommandOptions.inc

[Jonas Devlieghere via Phabricator via lldb-commits]

JDevlieghere added inline comments.



Comment at: lldb/utils/TableGen/LLDBOptionDefEmitter.cpp:146
   // We undefine the macro for the user like Clang's include files are doing 
it.
+  OS << "};\n";
   OS << "#undef " << NeededMacro << "\n";

Let's move this before the comment.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D65331



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

[Lldb-commits] [PATCH] D65271: Increase testsuite packet-timeout 5secs -> 1min

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil added a comment.

In D65271#1602143 , @labath wrote:

> I think I'd go for threading it in from VSCodeTestCaseBase. Maybe not as an 
> argument to `request_attach` and friends, but possibly as an argument to the 
> `DebugCommunication` object constructor.


That looks as a good place to me, thanks. Be careful with the review I do not 
know Python almost at all.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D65271



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

[Lldb-commits] [PATCH] D65271: Increase testsuite packet-timeout 5secs -> 5mins

[Jan Kratochvil via Phabricator via lldb-commits]

jankratochvil updated this revision to Diff 211973.

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D65271

Files:
  lldb/lit/lit-lldb-init.in
  lldb/packages/Python/lldbsuite/test/api/multithreaded/driver.cpp.template
  
lldb/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestNoWatchpointSupportInfo.py
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
  lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
  lldb/tools/lldb-test/lldb-test.cpp

Index: lldb/tools/lldb-test/lldb-test.cpp
===
--- lldb/tools/lldb-test/lldb-test.cpp
+++ lldb/tools/lldb-test/lldb-test.cpp
@@ -976,6 +976,12 @@
 
   auto Dbg = lldb_private::Debugger::CreateInstance();
   ModuleList::GetGlobalModuleListProperties().SetEnableExternalLookup(false);
+  // There is no SB API for settings in general like:
+  // GetGlobalPluginProperties()->SetPacketTimeout(std::chrono::seconds(60));
+  CommandReturnObject Result;
+  Dbg->GetCommandInterpreter().HandleCommand(
+  "settings set plugin.process.gdb-remote.packet-timeout 60",
+  /*add_to_history*/ eLazyBoolNo, Result);
 
   if (!opts::Log.empty())
 Dbg->EnableLog("lldb", {"all"}, opts::Log, 0, errs());
Index: lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
===
--- lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
+++ lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
@@ -99,7 +99,7 @@
 
 class DebugCommunication(object):
 
-def __init__(self, recv, send):
+def __init__(self, recv, send, init_commands):
 self.trace_file = None
 self.send = send
 self.recv = recv
@@ -118,6 +118,7 @@
 self.output = {}
 self.configuration_done_sent = False
 self.frame_scopes = {}
+self.init_commands = init_commands
 
 @classmethod
 def encode_content(cls, s):
@@ -447,8 +448,7 @@
 args_dict['waitFor'] = waitFor
 if trace:
 args_dict['trace'] = trace
-args_dict['initCommands'] = [
-'settings set symbols.enable-external-lookup false']
+args_dict['initCommands'] = self.init_commands
 if initCommands:
 args_dict['initCommands'].extend(initCommands)
 if preRunCommands:
@@ -578,8 +578,7 @@
 args_dict['shellExpandArguments'] = shellExpandArguments
 if trace:
 args_dict['trace'] = trace
-args_dict['initCommands'] = [
-'settings set symbols.enable-external-lookup false']
+args_dict['initCommands'] = self.init_commands
 if initCommands:
 args_dict['initCommands'].extend(initCommands)
 if preRunCommands:
@@ -822,7 +821,7 @@
 
 
 class DebugAdaptor(DebugCommunication):
-def __init__(self, executable=None, port=None):
+def __init__(self, executable=None, port=None, init_commands=[]):
 self.process = None
 if executable is not None:
 self.process = subprocess.Popen([executable],
@@ -830,11 +829,12 @@
 stdout=subprocess.PIPE,
 stderr=subprocess.PIPE)
 DebugCommunication.__init__(self, self.process.stdout,
-self.process.stdin)
+self.process.stdin, init_commands)
 elif port is not None:
 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 s.connect(('127.0.0.1', port))
-DebugCommunication.__init__(self, s.makefile('r'), s.makefile('w'))
+DebugCommunication.__init__(self, s.makefile('r'), s.makefile('w'),
+init_commands)
 
 def get_pid(self):
 if self.process:
Index: lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
===
--- lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
+++ lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/lldbvscode_testcase.py
@@ -11,7 +11,8 @@
 '''Create the Visual Studio Code debug adaptor'''
 self.assertTrue(os.path.exists(self.lldbVSCodeExec),
 'lldb-vscode must exist')
-self.vscode = vscode.DebugAdaptor(executable=self.lldbVSCodeExec)
+self.vscode = vscode.DebugAdaptor(
+executable=self.lldbVSCodeExec, init_commands=Base.setUpCommands())
 
 def build_and_create_debug_adaptor(self):
 self.build()
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ 

[Lldb-commits] [PATCH] D65122: [Symbol] Use llvm::Expected when getting TypeSystems

[Alex Langford via Phabricator via lldb-commits]

xiaobai added a comment.

I'm going to update this diff with what I changed to give y'all a better idea 
of what has been changed. I shoulda done that to begin with... :P

In D65122#1602145 , @labath wrote:

> In D65122#1602067 , @JDevlieghere 
> wrote:
>
> > In D65122#1602025 , @xiaobai wrote:
> >
> > > After going through this and modifying this patch, I can't help but 
> > > wonder if `llvm::Optional` would be more appropriate. There 
> > > are plenty of instances where it's not a hard error if you can't get a 
> > > TypeSystem and the appropriate action is probably just to log and move 
> > > on. I am conflicted because I like how Expected forces you to be more 
> > > rigorous with error handling but I can't help but feel it is the wrong 
> > > abstraction. Thoughts?
> >
> >
> > I think an `Optional` would be fine. We can always create an `Error` when 
> > necessary, with the trade-off of being a little less precision about the 
> > root cause, which honestly doesn't seem that informative anyway.
>
>
> I'm not that familiar with type systems, so I don't know if an explicit error 
> value is useful. Adopting Error/Expected initially has a slightly higher 
> barrier because the surrounding code does not know about Errors, and so you 
> have to do something explicit and verbose to the error, and then create a 
> default value of the return type anyway. But, as the surrounding code adopts 
> Errors, the verboseness should disappear. This, of course, assumes that we 
> want to adopt Errors here and in the surrounding code.
>
> What I am familiar with though is the `Optional` template, I can note that 
> there is no such thing as an `Optional` (the Optional template does not 
> play well with references). You could make that a thing, but an 
> `Optional` is essentially just a `T *`, which is what we have now :D. And 
> I wouldn't want `Optional` as that just creates more ambiguity.
>
> Thinking ahead I am wondering if we could just arrange things such that the 
> TypeSystem creation always succeeds. One day, I am hoping to arrange is so 
> that a Module will always have an associated ObjectFile and a SymbolFile (by 
> avoiding creating a Module if the ObjectFile construction fails, and creating 
> an "empty" SymbolFile if needed). At that point being able to always create a 
> type system would not seem unreasonable. I don't think any of this is 
> directly relevant here and now, but it may speak against introducing Expected 
> here (if you agree with my vision, that is).


Yeah, switching to an Optional or Optional doesn't seem like an actual 
tangible improvement over what we have now... And an Expected seems to at 
least promote better error handling.  The initial cost is indeed high though. :P
Eventually having a system such that makes TypeSystem creation always succeed 
would be much nicer. Though I agree, I think that using an Expected here is 
better than returning a pointer since TypeSystem creation can fail right now. I 
don't think it should be too difficult to change back if and when we get to 
that point.

In D65122#1602853 , @jingham wrote:

> It seems to me part of the goal of Alex's efforts is to make it possible for 
> a given lldb to have or not have support for any particular type system.  In 
> some future day they might even be live pluggable, so that which ones get 
> loaded would be a user choice.  In that future, it is never an error to not 
> have a given type system.  And even if lldb has builtin code to support a 
> given type system, I may not want to pay the cost to construct it.  If I'm 
> debugging ObjC code in a program that also supports swift, I might want to 
> tell lldb not to bother with swift types.
>
> If that seems reasonable, then TypeSystems are really optional, and you 
> should always be prepared for one not to exist.  IIUC that's better expressed 
> by Optional than Expected.


Yes, that is definitely a part of my goal. That's why I felt Optional better 
suited this than Expected... but I also feel that Expected forces people to be 
more careful.


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

https://reviews.llvm.org/D65122



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

[Lldb-commits] [lldb] r367140 - [TableGen] Move core properties into a separate file (NFC)

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Fri Jul 26 11:14:12 2019
New Revision: 367140

URL: http://llvm.org/viewvc/llvm-project?rev=367140=rev
Log:
[TableGen] Move core properties into a separate file (NFC)

With the plugins having their own tablgen file, it makes sense to split
off the core properties as well.

Added:
lldb/trunk/source/Core/Properties.td
Removed:
lldb/trunk/include/lldb/Core/CMakeLists.txt
lldb/trunk/include/lldb/Core/Properties.td
Modified:
lldb/trunk/CMakeLists.txt
lldb/trunk/source/Core/CMakeLists.txt

Modified: lldb/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=367140=367139=367140=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Fri Jul 26 11:14:12 2019
@@ -54,7 +54,6 @@ endif()
 
 # TableGen
 add_subdirectory(utils/TableGen)
-add_subdirectory(include/lldb/Core)
 
 add_subdirectory(source)
 add_subdirectory(tools)

Removed: lldb/trunk/include/lldb/Core/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/CMakeLists.txt?rev=367139=auto
==
--- lldb/trunk/include/lldb/Core/CMakeLists.txt (original)
+++ lldb/trunk/include/lldb/Core/CMakeLists.txt (removed)
@@ -1,7 +0,0 @@
-lldb_tablegen(Properties.inc -gen-lldb-property-defs
-  SOURCE Properties.td
-  TARGET LLDBPropertiesGen)
-
-lldb_tablegen(PropertiesEnum.inc -gen-lldb-property-enum-defs
-  SOURCE Properties.td
-  TARGET LLDBPropertiesEnumGen)

Removed: lldb/trunk/include/lldb/Core/Properties.td
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Properties.td?rev=367139=auto
==
--- lldb/trunk/include/lldb/Core/Properties.td (original)
+++ lldb/trunk/include/lldb/Core/Properties.td (removed)
@@ -1,118 +0,0 @@
-include "PropertiesBase.td"
-
-let Definition = "modulelist" in {
-  def EnableExternalLookup: Property<"enable-external-lookup", "Boolean">,
-Global,
-DefaultTrue,
-Desc<"Control the use of external tools and repositories to locate symbol 
files. Directories listed in target.debug-file-search-paths and directory of 
the executable are always checked first for separate debug info files. Then 
depending on this setting: On macOS, Spotlight would be also used to locate a 
matching .dSYM bundle based on the UUID of the executable. On NetBSD, directory 
/usr/libdata/debug would be also searched. On platforms other than NetBSD 
directory /usr/lib/debug would be also searched.">;
-  def ClangModulesCachePath: Property<"clang-modules-cache-path", "FileSpec">,
-Global,
-DefaultStringValue<"">,
-Desc<"The path to the clang modules cache directory 
(-fmodules-cache-path).">;
-}
-
-let Definition = "debugger" in {
-  def AutoConfirm: Property<"auto-confirm", "Boolean">,
-Global,
-DefaultFalse,
-Desc<"If true all confirmation prompts will receive their default reply.">;
-  def DisassemblyFormat: Property<"disassembly-format", "FormatEntity">,
-Global,
-
DefaultStringValue<"{${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:n}{${function.changed}n{${module.file.basename}`}{${function.name-without-args}}:n}{${current-pc-arrow}
 }${addr-file-or-load}{ <${function.concrete-only-addr-offset-no-padding}>}: ">,
-Desc<"The default disassembly format string to use when disassembling 
instruction sequences.">;
-  def FrameFormat: Property<"frame-format", "FormatEntity">,
-Global,
-DefaultStringValue<"frame #${frame.index}: 
${ansi.fg.yellow}${frame.pc}${ansi.normal}{ 
${module.file.basename}{`${function.name-with-args}{${frame.no-debug}${function.pc-offset{
 at 
${ansi.fg.cyan}${line.file.basename}${ansi.normal}:${ansi.fg.yellow}${line.number}${ansi.normal}{:${ansi.fg.yellow}${line.column}${ansi.normal}}}{${function.is-optimized}
 [opt]}{${frame.is-artificial} [artificial]}n">,
-Desc<"The default frame format string to use when displaying stack frame 
information for threads.">;
-  def NotiftVoid: Property<"notify-void", "Boolean">,
-Global,
-DefaultFalse,
-Desc<"Notify the user explicitly if an expression returns void (default: 
false).">;
-  def Prompt: Property<"prompt", "String">,
-Global,
-
DefaultEnumValue<"OptionValueString::eOptionEncodeCharacterEscapeSequences">,
-DefaultStringValue<"(lldb) ">,
-Desc<"The debugger command line prompt displayed for the user.">;
-  def ScriptLanguage: Property<"script-lang", "Enum">,
-Global,
-DefaultEnumValue<"eScriptLanguagePython">,
-EnumValues<"OptionEnumValues(g_language_enumerators)">,
-Desc<"The script language to be used for evaluating user-written 
scripts.">;
-  def StopDisassemblyCount: Property<"stop-disassembly-count", "SInt64">,
-Global,
-DefaultUnsignedValue<4>,
-

[Lldb-commits] [lldb] r367139 - [TableGen] Move target properties into a separate file (NFC)

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Fri Jul 26 11:14:08 2019
New Revision: 367139

URL: http://llvm.org/viewvc/llvm-project?rev=367139=rev
Log:
[TableGen] Move target properties into a separate file (NFC)

With the plugins having their own tablgen file, it makes sense to split
off the target properties as well.

Added:
lldb/trunk/source/Target/Properties.td
Modified:
lldb/trunk/include/lldb/Core/Properties.td
lldb/trunk/source/Target/CMakeLists.txt
lldb/trunk/source/Target/Platform.cpp
lldb/trunk/source/Target/Process.cpp
lldb/trunk/source/Target/Target.cpp
lldb/trunk/source/Target/Thread.cpp

Modified: lldb/trunk/include/lldb/Core/Properties.td
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Properties.td?rev=367139=367138=367139=diff
==
--- lldb/trunk/include/lldb/Core/Properties.td (original)
+++ lldb/trunk/include/lldb/Core/Properties.td Fri Jul 26 11:14:08 2019
@@ -1,238 +1,5 @@
 include "PropertiesBase.td"
 
-let Definition = "experimental" in {
-  def InjectLocalVars : Property<"inject-local-vars", "Boolean">,
-Global, DefaultTrue,
-Desc<"If true, inject local variables explicitly into the expression text. 
This will fix symbol resolution when there are name collisions between ivars 
and local variables. But it can make expressions run much more slowly.">;
-  def UseModernTypeLookup : Property<"use-modern-type-lookup", "Boolean">,
-Global, DefaultFalse,
-Desc<"If true, use Clang's modern type lookup infrastructure.">;
-}
-
-let Definition = "target" in {
-  def DefaultArch: Property<"default-arch", "Arch">,
-Global,
-DefaultStringValue<"">,
-Desc<"Default architecture to choose, when there's a choice.">;
-  def MoveToNearestCode: Property<"move-to-nearest-code", "Boolean">,
-DefaultTrue,
-Desc<"Move breakpoints to nearest code.">;
-  def Language: Property<"language", "Language">,
-DefaultEnumValue<"eLanguageTypeUnknown">,
-Desc<"The language to use when interpreting expressions entered in 
commands.">;
-  def ExprPrefix: Property<"expr-prefix", "FileSpec">,
-DefaultStringValue<"">,
-Desc<"Path to a file containing expressions to be prepended to all 
expressions.">;
-  def PreferDynamic: Property<"prefer-dynamic-value", "Enum">,
-DefaultEnumValue<"eDynamicDontRunTarget">,
-EnumValues<"OptionEnumValues(g_dynamic_value_types)">,
-Desc<"Should printed values be shown as their dynamic value.">;
-  def EnableSynthetic: Property<"enable-synthetic-value", "Boolean">,
-DefaultTrue,
-Desc<"Should synthetic values be used by default whenever available.">;
-  def SkipPrologue: Property<"skip-prologue", "Boolean">,
-DefaultTrue,
-Desc<"Skip function prologues when setting breakpoints by name.">;
-  def SourceMap: Property<"source-map", "PathMap">,
-DefaultStringValue<"">,
-Desc<"Source path remappings are used to track the change of location 
between a source file when built, and where it exists on the current system.  
It consists of an array of duples, the first element of each duple is some part 
(starting at the root) of the path to the file when it was built, and the 
second is where the remainder of the original build hierarchy is rooted on the 
local system.  Each element of the array is checked in order and the first one 
that results in a match wins.">;
-  def ExecutableSearchPaths: Property<"exec-search-paths", "FileSpecList">,
-DefaultStringValue<"">,
-Desc<"Executable search paths to use when locating executable files whose 
paths don't match the local file system.">;
-  def DebugFileSearchPaths: Property<"debug-file-search-paths", 
"FileSpecList">,
-DefaultStringValue<"">,
-Desc<"List of directories to be searched when locating debug symbol files. 
See also symbols.enable-external-lookup.">;
-  def ClangModuleSearchPaths: Property<"clang-module-search-paths", 
"FileSpecList">,
-DefaultStringValue<"">,
-Desc<"List of directories to be searched when locating modules for 
Clang.">;
-  def AutoImportClangModules: Property<"auto-import-clang-modules", "Boolean">,
-DefaultTrue,
-Desc<"Automatically load Clang modules referred to by the program.">;
-  def ImportStdModule: Property<"import-std-module", "Boolean">,
-DefaultFalse,
-Desc<"Import the C++ std module to improve debugging STL containers.">;
-  def AutoApplyFixIts: Property<"auto-apply-fixits", "Boolean">,
-DefaultTrue,
-Desc<"Automatically apply fix-it hints to expressions.">;
-  def NotifyAboutFixIts: Property<"notify-about-fixits", "Boolean">,
-DefaultTrue,
-Desc<"Print the fixed expression text.">;
-  def SaveObjects: Property<"save-jit-objects", "Boolean">,
-DefaultFalse,
-Desc<"Save intermediate object files generated by the LLVM JIT">;
-  def MaxChildrenCount: Property<"max-children-count", "SInt64">,
-DefaultUnsignedValue<256>,
-Desc<"Maximum number of children to 

[Lldb-commits] [lldb] r367138 - [TableGen] Move interpreter properties into a separate file (NFC)

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Fri Jul 26 11:14:04 2019
New Revision: 367138

URL: http://llvm.org/viewvc/llvm-project?rev=367138=rev
Log:
[TableGen] Move interpreter properties into a separate file (NFC)

With the plugins having their own tablgen file, it makes sense to split
off the interpreter properties as well.

Added:
lldb/trunk/source/Interpreter/Properties.td
Modified:
lldb/trunk/CMakeLists.txt
lldb/trunk/include/lldb/Core/Properties.td
lldb/trunk/source/Interpreter/CMakeLists.txt
lldb/trunk/source/Interpreter/CommandInterpreter.cpp

Modified: lldb/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=367138=367137=367138=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Fri Jul 26 11:14:04 2019
@@ -52,14 +52,14 @@ if(CMAKE_CROSSCOMPILING AND LLDB_BUILT_S
 -DClang_DIR=${NATIVE_Clang_DIR})
 endif()
 
+# TableGen
 add_subdirectory(utils/TableGen)
+add_subdirectory(include/lldb/Core)
+
 add_subdirectory(source)
 add_subdirectory(tools)
 add_subdirectory(docs)
 
-# Needed by tablegen.
-add_subdirectory(include/lldb/Core)
-
 option(LLDB_INCLUDE_TESTS "Generate build targets for the LLDB unit tests." 
${LLVM_INCLUDE_TESTS})
 option(LLDB_TEST_USE_CUSTOM_C_COMPILER "Use the C compiler provided via 
LLDB_TEST_C_COMPILER for building test inferiors (instead of the just-built 
compiler). Defaults to OFF." OFF)
 option(LLDB_TEST_USE_CUSTOM_CXX_COMPILER "Use the C++ compiler provided via 
LLDB_TEST_CXX_COMPILER for building test inferiors (instead of the just-built 
compiler). Defaults to OFF." OFF)

Modified: lldb/trunk/include/lldb/Core/Properties.td
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Properties.td?rev=367138=367137=367138=diff
==
--- lldb/trunk/include/lldb/Core/Properties.td (original)
+++ lldb/trunk/include/lldb/Core/Properties.td Fri Jul 26 11:14:04 2019
@@ -349,31 +349,3 @@ let Definition = "debugger" in {
 DefaultStringValue<"frame #${frame.index}: 
${ansi.fg.yellow}${frame.pc}${ansi.normal}{ 
${module.file.basename}{`${function.name-without-args}{${frame.no-debug}${function.pc-offset{
 at 
${ansi.fg.cyan}${line.file.basename}${ansi.normal}:${ansi.fg.yellow}${line.number}${ansi.normal}{:${ansi.fg.yellow}${line.column}${ansi.normal}}}{${function.is-optimized}
 [opt]}{${frame.is-artificial} [artificial]}n">,
 Desc<"The default frame format string to use when displaying stack 
frameinformation for threads from thread backtrace unique.">;
 }
-
-
-let Definition = "commandinterpreter" in {
-  def ExpandRegexAliases: Property<"expand-regex-aliases", "Boolean">,
-Global,
-DefaultFalse,
-Desc<"If true, regular expression alias commands will show the expanded 
command that will be executed. This can be used to debug new regular expression 
alias commands.">;
-  def PromptOnQuit: Property<"prompt-on-quit", "Boolean">,
-Global,
-DefaultTrue,
-Desc<"If true, LLDB will prompt you before quitting if there are any live 
processes being debugged. If false, LLDB will quit without asking in any 
case.">;
-  def StopCmdSourceOnError: Property<"stop-command-source-on-error", 
"Boolean">,
-Global,
-DefaultTrue,
-Desc<"If true, LLDB will stop running a 'command source' script upon 
encountering an error.">;
-  def SpaceReplPrompts: Property<"space-repl-prompts", "Boolean">,
-Global,
-DefaultFalse,
-Desc<"If true, blank lines will be printed between between REPL 
submissions.">;
-  def EchoCommands: Property<"echo-commands", "Boolean">,
-Global,
-DefaultTrue,
-Desc<"If true, commands will be echoed before they are evaluated.">;
-  def EchoCommentCommands: Property<"echo-comment-commands", "Boolean">,
-Global,
-DefaultTrue,
-Desc<"If true, commands will be echoed even if they are pure comment 
lines.">;
-}

Modified: lldb/trunk/source/Interpreter/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Interpreter/CMakeLists.txt?rev=367138=367137=367138=diff
==
--- lldb/trunk/source/Interpreter/CMakeLists.txt (original)
+++ lldb/trunk/source/Interpreter/CMakeLists.txt Fri Jul 26 11:14:04 2019
@@ -1,3 +1,11 @@
+lldb_tablegen(Properties.inc -gen-lldb-property-defs
+  SOURCE Properties.td
+  TARGET LLDBInterpreterPropertiesGen)
+
+lldb_tablegen(PropertiesEnum.inc -gen-lldb-property-enum-defs
+  SOURCE Properties.td
+  TARGET LLDBInterpreterPropertiesEnumGen)
+
 add_lldb_library(lldbInterpreter
   CommandAlias.cpp
   CommandHistory.cpp
@@ -56,7 +64,9 @@ add_lldb_library(lldbInterpreter
 Support
   )
 
-add_dependencies(lldbInterpreter LLDBPropertiesGen LLDBPropertiesEnumGen)
+add_dependencies(lldbInterpreter
+  LLDBInterpreterPropertiesGen
+  LLDBInterpreterPropertiesEnumGen)
 

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Adrian McCarthy via Phabricator via lldb-commits]

amccarth added inline comments.



Comment at: lldb/docs/resources/build.rst:94
+project, it generates the files needed by your build tool. The recommended
+build tool for LLVM is Ninja. Please also read `Building LLVM with CMake
+`_.

stella.stamenova wrote:
> sgraenitz wrote:
> > stella.stamenova wrote:
> > > Is Ninja the recommended build tool on Windows as well?
> > Well it's recommended for LLVM and I used it for LLDB on Windows in the 
> > past.
> > Maybe @zturner knows more about it?
> LLDB does build with both Ninja and VS on Windows. I don't know that either 
> one is "recommended" though and we usually build with VS.
I use Ninja exclusively for both LLVM in general and LLDB in particular, 
regardless of whether I'm building with MSVC or bootstrapping with Clang.

Having a VS solution is great for finding your way around the repo and 
debugging.  But Ninja seems to build much faster.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65122: [Symbol] Use llvm::Expected when getting TypeSystems

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

It seems to me part of the goal of Alex's efforts is to make it possible for a 
given lldb to have or not have support for any particular type system.  In some 
future day they might even be live pluggable, so that which ones get loaded 
would be a user choice.  In that future, it is never an error to not have a 
given type system.  And even if lldb has builtin code to support a given type 
system, I may not want to pay the cost to construct it.  If I'm debugging ObjC 
code in a program that also supports swift, I might want to tell lldb not to 
bother with swift types.

If that seems reasonable, then TypeSystems are really optional, and you should 
always be prepared for one not to exist.  IIUC that's better expressed by 
Optional than Expected.


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

https://reviews.llvm.org/D65122



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added inline comments.



Comment at: lldb/docs/resources/build.rst:94
+project, it generates the files needed by your build tool. The recommended
+build tool for LLVM is Ninja. Please also read `Building LLVM with CMake
+`_.

sgraenitz wrote:
> stella.stamenova wrote:
> > Is Ninja the recommended build tool on Windows as well?
> Well it's recommended for LLVM and I used it for LLDB on Windows in the past.
> Maybe @zturner knows more about it?
LLDB does build with both Ninja and VS on Windows. I don't know that either one 
is "recommended" though and we usually build with VS.



Comment at: lldb/docs/resources/build.rst:105
+
+  > cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb" [] 
path/to/llvm-project/llvm
+

sgraenitz wrote:
> stella.stamenova wrote:
> > I thought some of the tests need lld as well
> So far, the documentation didn't mention lld. I would recommend using lld to 
> **build** LLDB on Linux, but AFAIK it's not required to build lld along with 
> LLDB.
For example, lldb\lit\SymbolFile\DWARF\debug-types-basic.test contains this:

# REQUIRES: lld

There are other tests as well that require lld.



Comment at: lldb/docs/resources/build.rst:235
+
+  > cmake -G "Visual Studio 14 2015"  
+

sgraenitz wrote:
> stella.stamenova wrote:
> > We retired VS2015 support
> What generator string would you like to see here instead? (So far I just kept 
> what was there.)
cmake -G "Visual Studio 15 2017 Win64" -Thost=x64


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65293: Document the fact that LLDB_LOG uses llvm::format_providers

[Jim Ingham via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367132: Document that LLDB_LOG macros use the 
format_providers. (authored by jingham, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65293?vs=211791=211964#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65293

Files:
  lldb/trunk/include/lldb/Utility/Log.h


Index: lldb/trunk/include/lldb/Utility/Log.h
===
--- lldb/trunk/include/lldb/Utility/Log.h
+++ lldb/trunk/include/lldb/Utility/Log.h
@@ -206,6 +206,26 @@
 
 } // namespace lldb_private
 
+/// The LLDB_LOG* macros defined below are the way to emit log messages.
+///
+/// Note that the macros surround the arguments in a check for the log
+/// being on, so you can freely call methods in arguments without affecting
+/// the non-log execution flow.
+///
+/// If you need to do more complex computations to prepare the log message
+/// be sure to add your own if (log) check, since we don't want logging to
+/// have any effect when not on.
+///
+/// However, the LLDB_LOG macro uses the llvm::formatv system (see the
+/// ProgrammersManual page in the llvm docs for more details).  This allows
+/// the use of "format_providers" to auto-format datatypes, and there are
+/// already formatters for some of the llvm and lldb datatypes.
+///
+/// So if you need to do non-trivial formatting of one of these types, be
+/// sure to grep the lldb and llvm sources for "format_provider" to see if
+/// there is already a formatter before doing in situ formatting, and if
+/// possible add a provider if one does not already exist.
+
 #define LLDB_LOG(log, ...) 
\
   do { 
\
 ::lldb_private::Log *log_private = (log);  
\


Index: lldb/trunk/include/lldb/Utility/Log.h
===
--- lldb/trunk/include/lldb/Utility/Log.h
+++ lldb/trunk/include/lldb/Utility/Log.h
@@ -206,6 +206,26 @@
 
 } // namespace lldb_private
 
+/// The LLDB_LOG* macros defined below are the way to emit log messages.
+///
+/// Note that the macros surround the arguments in a check for the log
+/// being on, so you can freely call methods in arguments without affecting
+/// the non-log execution flow.
+///
+/// If you need to do more complex computations to prepare the log message
+/// be sure to add your own if (log) check, since we don't want logging to
+/// have any effect when not on.
+///
+/// However, the LLDB_LOG macro uses the llvm::formatv system (see the
+/// ProgrammersManual page in the llvm docs for more details).  This allows
+/// the use of "format_providers" to auto-format datatypes, and there are
+/// already formatters for some of the llvm and lldb datatypes.
+///
+/// So if you need to do non-trivial formatting of one of these types, be
+/// sure to grep the lldb and llvm sources for "format_provider" to see if
+/// there is already a formatter before doing in situ formatting, and if
+/// possible add a provider if one does not already exist.
+
 #define LLDB_LOG(log, ...) \
   do { \
 ::lldb_private::Log *log_private = (log);  \
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D65293: Document the fact that LLDB_LOG uses llvm::format_providers

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

Yeah, I didn't want to bother with formatting in case there were suggestions on 
content.  I checked in a version that's correctly truncated.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D65293



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

[Lldb-commits] [lldb] r367132 - Document that LLDB_LOG macros use the format_providers.

[Jim Ingham via lldb-commits]

Author: jingham
Date: Fri Jul 26 10:25:20 2019
New Revision: 367132

URL: http://llvm.org/viewvc/llvm-project?rev=367132=rev
Log:
Document that LLDB_LOG macros use the format_providers.

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

Modified:
lldb/trunk/include/lldb/Utility/Log.h

Modified: lldb/trunk/include/lldb/Utility/Log.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Utility/Log.h?rev=367132=367131=367132=diff
==
--- lldb/trunk/include/lldb/Utility/Log.h (original)
+++ lldb/trunk/include/lldb/Utility/Log.h Fri Jul 26 10:25:20 2019
@@ -206,6 +206,26 @@ private:
 
 } // namespace lldb_private
 
+/// The LLDB_LOG* macros defined below are the way to emit log messages.
+///
+/// Note that the macros surround the arguments in a check for the log
+/// being on, so you can freely call methods in arguments without affecting
+/// the non-log execution flow.
+///
+/// If you need to do more complex computations to prepare the log message
+/// be sure to add your own if (log) check, since we don't want logging to
+/// have any effect when not on.
+///
+/// However, the LLDB_LOG macro uses the llvm::formatv system (see the
+/// ProgrammersManual page in the llvm docs for more details).  This allows
+/// the use of "format_providers" to auto-format datatypes, and there are
+/// already formatters for some of the llvm and lldb datatypes.
+///
+/// So if you need to do non-trivial formatting of one of these types, be
+/// sure to grep the lldb and llvm sources for "format_provider" to see if
+/// there is already a formatter before doing in situ formatting, and if
+/// possible add a provider if one does not already exist.
+
 #define LLDB_LOG(log, ...) 
\
   do { 
\
 ::lldb_private::Log *log_private = (log);  
\


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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added a comment.

In D65330#1602786 , @jryans wrote:

> On http://releases.llvm.org/, for some recent versions like 8.0.0, the 
> "Documentation" column has separate versioned links for "llvm clang lld 
> clang-extra libc++ polly", but lldb doesn't appear there.


Interesting. Thks!




Comment at: lldb/docs/resources/build.rst:94
+project, it generates the files needed by your build tool. The recommended
+build tool for LLVM is Ninja. Please also read `Building LLVM with CMake
+`_.

stella.stamenova wrote:
> Is Ninja the recommended build tool on Windows as well?
Well it's recommended for LLVM and I used it for LLDB on Windows in the past.
Maybe @zturner knows more about it?



Comment at: lldb/docs/resources/build.rst:105
+
+  > cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb" [] 
path/to/llvm-project/llvm
+

stella.stamenova wrote:
> I thought some of the tests need lld as well
So far, the documentation didn't mention lld. I would recommend using lld to 
**build** LLDB on Linux, but AFAIK it's not required to build lld along with 
LLDB.



Comment at: lldb/docs/resources/build.rst:235
+
+  > cmake -G "Visual Studio 14 2015"  
+

stella.stamenova wrote:
> We retired VS2015 support
What generator string would you like to see here instead? (So far I just kept 
what was there.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D47384: Remove dependency from Host to clang

[Marshall Clow via Phabricator via lldb-commits]

mclow.lists added inline comments.
Herald added a project: LLVM.



Comment at: lldb/trunk/source/Plugins/ExpressionParser/Clang/ClangHost.cpp:77
+  const char *swift_clang_resource_dir = "usr/lib/swift/clang";
+  auto parent = std::next(rev_it);
+  if (parent != r_end && *parent == "SharedFrameworks") {

This line fails to build on my old Mac Pro (Mac OS X 10.11, apple-clang-8), 
complaining that `std::next` requires a forward iterator, and `rev_it` is not 
one.

changing this code to:
```
auto parent = rev_it;
std::advance(parent, 1);
```
fixes the compile error.

Note that these are the most recent OS and tools for this computer.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D47384



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[J. Ryan Stinnett via Phabricator via lldb-commits]

jryans added a comment.

In D65330#1602779 , @sgraenitz wrote:

> Where did you find the //sub-project list of versioned docs//?


On http://releases.llvm.org/, for some recent versions like 8.0.0, the 
"Documentation" column has separate versioned links for "llvm clang lld 
clang-extra libc++ polly", but lldb doesn't appear there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added inline comments.



Comment at: lldb/docs/resources/build.rst:94
+project, it generates the files needed by your build tool. The recommended
+build tool for LLVM is Ninja. Please also read `Building LLVM with CMake
+`_.

Is Ninja the recommended build tool on Windows as well?



Comment at: lldb/docs/resources/build.rst:105
+
+  > cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb" [] 
path/to/llvm-project/llvm
+

I thought some of the tests need lld as well



Comment at: lldb/docs/resources/build.rst:235
+
+  > cmake -G "Visual Studio 14 2015"  
+

We retired VS2015 support


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added a comment.

In D65330#1602756 , @jryans wrote:

> Hmm, are there the LLDB docs archived per release? [...] LLDB doesn't seem to 
> appear in sub-project list of versioned docs


Right, Clang docs are here: 
https://releases.llvm.org/8.0.0/tools/clang/docs/index.html, but it's not the 
same as http://clang.llvm.org/
Apparently, LLDB docs aren't archived. Where did you find the //sub-project 
list of versioned docs//?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Adrian McCarthy via Phabricator via lldb-commits]

amccarth added a comment.

Looks good.  Thanks for doing these updates!




Comment at: lldb/docs/resources/build.rst:85
+The LLVM project is migrating to a single monolithic respository for LLVM and
+its subprojects. This is the recommended way to build LLDB. Checkout the
+source-tree with git:

"Check out" should be two words here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[J. Ryan Stinnett via Phabricator via lldb-commits]

jryans accepted this revision.
jryans added a comment.

In D65330#1602737 , @sgraenitz wrote:

> I added a few links to LLVM documentation here and wondered what to do with 
> them, if this gets cherry-picked to `release/9.x`, e.g. 
> https://llvm.org/docs/CMake.html Ideally they would point to their 9.x 
> counterparts, e.g. https://releases.llvm.org/9.0.0/docs/CMake.html and with 
> 9.0.1 it should become https://releases.llvm.org/9.0.1/docs/CMake.html
>
> `llvm/docs/AdvancedBuilds.rst` links within one build directory using 
> ":doc:`CMake`", but apparently this doesn't work cross-project?
>
> I could imaging to patch it once for the release and use `configure_file` 
> from CMake to import the current version, but I am no sure if it's worth the 
> effort =)
>
> Is there a simple way to do this in Sphinx? Ideas / opinions?


Hmm, are there the LLDB docs archived per release? For LLVM overall, there's 
https://releases.llvm.org/ with links to say 
https://releases.llvm.org/8.0.0/docs/index.html, but LLDB doesn't seem to 
appear in sub-project list of versioned docs... I would say it's fine to not 
worry about this for now, and we can improve in a separate patch if needed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65230: [CMake] Loosen Python version check and ignore patch version

[Adrian McCarthy via Phabricator via lldb-commits]

amccarth added a comment.

In D65230#1602370 , @labath wrote:

> Thanks.
>
> BTW, I tried this on windows, and it didn't blow up in my face, I think it 
> should be relatively safe. I couldn't reproduce the problems that @amccarth 
> was experiencing, so I don't know if it fixes that problem. It would be good 
> to know whether it does, as we could cherry-pick this to the release branch 
> in that case.


Sorry for the slow reply.  I've been in a conference most of the week.

Since my problem tends to be a "just me" problem that doesn't affect the bots 
or apparently anyone else, I don't think a cherrypick is necessary.

By having only one version of Python on my machine, I was able to work around 
that problem.  Unfortunately, I've been stuck on another problem since making 
that change (specifically, all dotest.py tests report "Python memory allocator 
called without holding the GIL" and crash).  This, too, seems to be a "just me" 
thing, and I'm continuing to work on that this morning.  Until I get that 
figured out, I don't think I want to perturb my environment further by 
re-installing a second version of Python.  I suspect the other patch to 
eliminate multiprocessing from dotest.py might solve the GIL problem as well, 
but I want to know more first.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D65230



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

Re: [Lldb-commits] [lldb] r366985 - LLGS: fix tracking execve on linux

[Hans Wennborg via lldb-commits]

Merged to release_90 in r367128.

On Wed, Jul 24, 2019 at 11:37 PM Pavel Labath via lldb-commits
 wrote:
>
> Author: labath
> Date: Wed Jul 24 23:38:33 2019
> New Revision: 366985
>
> URL: http://llvm.org/viewvc/llvm-project?rev=366985=rev
> Log:
> LLGS: fix tracking execve on linux
>
> Summary:
> Due to a logic error, lldb-server ended up asserting/crashing every time
> the debugged process attempted an execve(). This fixes the error, and
> extends TestExec to work on other platforms too. The "extension"
> consists of avoiding non-standard posix_spawn extensions and using the
> classic execve() call, which should be available on any platform that
> actually supports re-execing. I change the test decorator from
> @skipUnlessDarwin to @skipIfWindows.
>
> Reviewers: clayborg, jasonmolenda
>
> Subscribers: lldb-commits
>
> Differential Revision: https://reviews.llvm.org/D65207
>
> Modified:
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/TestExec.py
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/main.cpp
> lldb/trunk/source/Plugins/Process/Linux/NativeProcessLinux.cpp
>
> Modified: 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/TestExec.py
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/TestExec.py?rev=366985=366984=366985=diff
> ==
> --- 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/TestExec.py 
> (original)
> +++ 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/TestExec.py 
> Wed Jul 24 23:38:33 2019
> @@ -18,17 +18,17 @@ class ExecTestCase(TestBase):
>
>  mydir = TestBase.compute_mydir(__file__)
>
> -@skipUnlessDarwin
>  @expectedFailureAll(archs=['i386'], bugnumber="rdar://28656532")
>  @expectedFailureAll(oslist=["ios", "tvos", "watchos", "bridgeos"], 
> bugnumber="rdar://problem/34559552") # this exec test has problems on ios 
> systems
>  @skipIfSanitized # rdar://problem/43756823
> +@skipIfWindows
>  def test_hitting_exec (self):
>  self.do_test(False)
>
> -@skipUnlessDarwin
>  @expectedFailureAll(archs=['i386'], bugnumber="rdar://28656532")
>  @expectedFailureAll(oslist=["ios", "tvos", "watchos", "bridgeos"], 
> bugnumber="rdar://problem/34559552") # this exec test has problems on ios 
> systems
>  @skipIfSanitized # rdar://problem/43756823
> +@skipIfWindows
>  def test_skipping_exec (self):
>  self.do_test(True)
>
>
> Modified: 
> lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/main.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/main.cpp?rev=366985=366984=366985=diff
> ==
> --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/main.cpp 
> (original)
> +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/exec/main.cpp 
> Wed Jul 24 23:38:33 2019
> @@ -1,76 +1,16 @@
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
> +#include 
>
> -static void
> -exit_with_errno (int err, const char *prefix)
> -{
> -if (err)
> -{
> -fprintf (stderr,
> - "%s%s",
> - prefix ? prefix : "",
> - strerror(err));
> -exit (err);
> -}
> -}
> -
> -static pid_t
> -spawn_process (const char *progname,
> -   const char **argv,
> -   const char **envp,
> -   int )
> -{
> -pid_t pid = 0;
> -
> -const posix_spawn_file_actions_t *file_actions = NULL;
> -posix_spawnattr_t attr;
> -err = posix_spawnattr_init ();
> -if (err)
> -return pid;
> -
> -short flags = POSIX_SPAWN_SETEXEC | POSIX_SPAWN_SETSIGDEF | 
> POSIX_SPAWN_SETSIGMASK;
> -err = posix_spawnattr_setflags (, flags);
> -if (err == 0)
> -{
> -// Use the default signal masks
> -sigset_t no_signals;
> -sigset_t all_signals;
> -sigemptyset (_signals);
> -sigfillset (_signals);
> -posix_spawnattr_setsigmask(, _signals);
> -posix_spawnattr_setsigdefault(, _signals);
> -
> -err = posix_spawn (,
> -   progname,
> -   file_actions,
> -   ,
> -   (char * const *)argv,
> -   (char * const *)envp);
> -
> -posix_spawnattr_destroy();
> -}
> -return pid;
> -}
> -
> -int
> -main (int argc, char const **argv)
> -{
> -char *buf = (char*) malloc (strlen (argv[0]) + 12);
> -strlcpy (buf, argv[0], strlen (argv[0]) + 1);
> -std::string directory_name (::dirname (buf));
> -
> -std::string other_program = directory_name + "/secondprog";
> -  

[Lldb-commits] [PATCH] D65331: [lldb] Also include the array definition in CommandOptions.inc

[Jonas Devlieghere via Phabricator via lldb-commits]

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

LGTM


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D65331



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[J. Ryan Stinnett via Phabricator via lldb-commits]

jryans added a comment.

In D65330#1602715 , @sgraenitz wrote:

> Cool, patch `Diff 211951` has the change. Here's the difference in generated 
> output:
>  https://weliveindetail.github.io/blog/res/lldb-docs/resources/build.html
>  
> https://weliveindetail.github.io/blog/res/lldb-docs/resources/build-merged-vs.html


Thanks, this looks good to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [lldb] r367127 - [CMake] Fix find_python_libs_windows

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Fri Jul 26 09:32:49 2019
New Revision: 367127

URL: http://llvm.org/viewvc/llvm-project?rev=367127=rev
Log:
[CMake] Fix find_python_libs_windows

Exporting PYTHON_INCLUDE_DIR to the Python scope somehow got lost in my
last change. Add it back again. This should fix the Windows bot!

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

Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=367127=367126=367127=diff
==
--- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake Fri Jul 26 09:32:49 2019
@@ -191,6 +191,7 @@ function(find_python_libs_windows)
   set(PYTHON_EXECUTABLE ${PYTHON_EXE} PARENT_SCOPE)
   set(PYTHON_LIBRARY ${PYTHON_LIB} PARENT_SCOPE)
   set(PYTHON_DLL ${PYTHON_DLL} PARENT_SCOPE)
+  set(PYTHON_INCLUDE_DIR ${PYTHON_INCLUDE_DIR} PARENT_SCOPE)
   set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}" PARENT_SCOPE)
   set(PYTHON_VERSION_STRING ${PYTHON_VERSION_STRING} PARENT_SCOPE)
   set(PYTHON_VERSION_MAJOR ${PYTHON_VERSION_MAJOR} PARENT_SCOPE)


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

[Lldb-commits] [lldb] r367125 - [CMake] Print Python version on Windows

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Fri Jul 26 09:15:19 2019
New Revision: 367125

URL: http://llvm.org/viewvc/llvm-project?rev=367125=rev
Log:
[CMake] Print Python version on Windows

Trying to figure out what's causing the Windows bot to fail.

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

Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=367125=367124=367125=diff
==
--- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake Fri Jul 26 09:15:19 2019
@@ -197,8 +197,8 @@ function(find_python_libs_windows)
   set(PYTHON_VERSION_MINOR ${PYTHON_VERSION_MINOR} PARENT_SCOPE)
   set(PYTHON_VERSION_PATCH ${PYTHON_VERSION_PATCH} PARENT_SCOPE)
 
-  message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE}")
-  message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIBRARY}")
+  message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE} 
(${PYTHON_VERSION_STRING})")
+  message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIB} 
(${PYTHONLIBS_VERSION_STRING})")
   message(STATUS "LLDB Found PythonDLL: ${PYTHON_DLL}")
   message(STATUS "LLDB Found PythonIncludeDirs: ${PYTHON_INCLUDE_DIR}")
 endfunction(find_python_libs_windows)


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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added a comment.

>> Since //Visual Studio// is the only section in //Building LLDB with CMake 
>> and Other Generators// now, ...
> 
> Yes, this sounds like a good plan.

Cool, patch `Diff 211951` has the change. Here's the difference in generated 
output:
https://weliveindetail.github.io/blog/res/lldb-docs/resources/build.html
https://weliveindetail.github.io/blog/res/lldb-docs/resources/build-merged-vs.html


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz updated this revision to Diff 211951.
sgraenitz added a comment.

Merge Visual Studio build instructions into `Common CMake options > Windows`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330

Files:
  lldb/docs/resources/build.rst

Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -78,23 +78,83 @@
 * If you are building both Clang and LLDB together, be sure to also check out
   libc++, which is a required for testing on macOS.
 
-Building LLDB with CMake & Ninja
-
+Building LLDB with CMake
+
+
+The LLVM project is migrating to a single monolithic respository for LLVM and
+its subprojects. This is the recommended way to build LLDB. Checkout the
+source-tree with git:
+
+::
+
+  > git clone https://github.com/llvm/llvm-project.git
 
 CMake is a cross-platform build-generator tool. CMake does not build the
-project, it generates the files needed by your build tool. Assuming you're
-using Ninja, the invocation looks like this:
+project, it generates the files needed by your build tool. The recommended
+build tool for LLVM is Ninja. Please also read `Building LLVM with CMake
+`_.
+
+Regular in-tree builds
+**
+
+Create a new directory for your build-tree. From there run CMake and point it
+to the ``llvm`` directory in the source-tree:
+
+::
+
+  > cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb" [] path/to/llvm-project/llvm
+
+We used the ``LLVM_ENABLE_PROJECTS`` option here to tell the build-system which
+subprojects to build in addition to LLVM (for more options see `Common CMake
+Options <#commoncmakeoptions>`_ and `CMake Caches <#cmakecaches>`_). Now run
+ninja to perform the actual build. We pass ``lldb`` here as the target, so it
+only builds what is necessary to run the lldb driver:
+
+::
+
+  > ninja lldb
+
+Standalone builds
+*
+
+This is another way to build LLDB. We can use the same source-tree as we
+checked out above, but now we will have two build-trees:
+
+* the main build-tree for LLDB in ``/path/to/lldb-build``
+* a provided build-tree for LLVM and Clang in ``/path/to/llvm-build``
+
+Run CMake with ``-B`` pointing to a new directory for the provided build-tree
+and the positional argument pointing to the ``llvm`` directory in the
+source-tree. Note that we leave out LLDB here and only include Clang (and libcxx
+on macOS). Then we build the ``ALL`` target with ninja:
 
 ::
 
-  > cmake -G Ninja  
+  > cmake -B /path/to/llvm-build -G Ninja \
+  -DLLVM_ENABLE_PROJECTS=clang \
+  [] /path/to/llvm-project/llvm
+  > ninja
 
-Once CMake has configured your build, you can run ``ninja`` to build LLDB.
+Now run CMake a second time with ``-B`` pointing to a new directory for the
+main build-tree and the positional argument pointing to the ``lldb`` directory
+in the source-tree. In order to find the provided build-tree, the build-system
+needs the options ``LLVM_DIR`` and ``Clang_DIR`` (CMake variables are
+case-sensitive!):
 
 ::
 
+  > cmake -B /path/to/lldb-build -G Ninja \
+  -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
+  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
+  [] /path/to/llvm-project/lldb
   > ninja lldb
 
+
+.. _CommonCMakeOptions:
+
+Common CMake options
+
+
 Following is a description of some of the most important CMake variables which
 you are likely to encounter. A variable FOO is set by adding ``-DFOO=value`` to
 the CMake command line.
@@ -128,7 +188,7 @@
 test execution.
 
 Windows
-***
+^^^
 
 Although the following CMake variables are by no means Windows specific, they
 are commonly used on Windows.
@@ -161,8 +221,27 @@
   -DLLDB_TEST_C_COMPILER=d:\src\llvmbuild\ninja_release\bin\clang.exe^
   
 
+
+Building with ninja is both faster and simpler than building with Visual Studio,
+but chances are you still want to debug LLDB with an IDE. One solution is to run
+cmake twice and generate the output into two different folders. One for
+compiling (the ninja folder), and one for editing, browsing and debugging.
+
+Follow the previous instructions in one directory, and generate a Visual Studio
+project in another directory.
+
+::
+
+  > cmake -G "Visual Studio 14 2015"  
+
+Then you can open the .sln file in Visual Studio, set lldb as the startup
+project, and use F5 to run it. You need only edit the project settings to set
+the executable and the working directory to point to binaries inside of the
+ninja tree.
+
+
 NetBSD
-**
+^^
 
 Current stable NetBSD release doesn't ship with libpanel(3), therefore it's
 required to disable curses(3) support with the
@@ -170,48 +249,66 @@
 ``/usr/include/panel.h`` exists in your system.
 
 macOS
-*
+^
 

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz updated this revision to Diff 211950.
sgraenitz added a comment.

Polishing


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330

Files:
  lldb/docs/resources/build.rst

Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -81,20 +81,80 @@
 Building LLDB with CMake & Ninja
 
 
+The LLVM project is migrating to a single monolithic respository for LLVM and
+its subprojects. This is the recommended way to build LLDB. Checkout the
+source-tree with git:
+
+::
+
+  > git clone https://github.com/llvm/llvm-project.git
+
 CMake is a cross-platform build-generator tool. CMake does not build the
-project, it generates the files needed by your build tool. Assuming you're
-using Ninja, the invocation looks like this:
+project, it generates the files needed by your build tool. The recommended
+build tool for LLVM is Ninja. Please also read `Building LLVM with CMake
+`_.
+
+Regular in-tree builds
+**
+
+Create a new directory for your build-tree. From there run CMake and point it
+to the ``llvm`` directory in the source-tree:
+
+::
+
+  > cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb" [] path/to/llvm-project/llvm
+
+We used the ``LLVM_ENABLE_PROJECTS`` option here to tell the build-system which
+subprojects to build in addition to LLVM (for more options see `Common CMake
+Options <#commoncmakeoptions>`_ and `CMake Caches <#cmakecaches>`_). Now run
+ninja to perform the actual build. We pass ``lldb`` here as the target, so it
+only builds what is necessary to run the lldb driver:
+
+::
+
+  > ninja lldb
+
+Standalone builds
+*
+
+This is another way to build LLDB. We can use the same source-tree as we
+checked out above, but now we will have two build-trees:
+
+* the main build-tree for LLDB in ``/path/to/lldb-build``
+* a provided build-tree for LLVM and Clang in ``/path/to/llvm-build``
+
+Run CMake with ``-B`` pointing to a new directory for the provided build-tree
+and the positional argument pointing to the ``llvm`` directory in the
+source-tree. Note that we leave out LLDB here and only include Clang (and libcxx
+on macOS). Then we build the ``ALL`` target with ninja:
 
 ::
 
-  > cmake -G Ninja  
+  > cmake -B /path/to/llvm-build -G Ninja \
+  -DLLVM_ENABLE_PROJECTS=clang \
+  [] /path/to/llvm-project/llvm
+  > ninja
 
-Once CMake has configured your build, you can run ``ninja`` to build LLDB.
+Now run CMake a second time with ``-B`` pointing to a new directory for the
+main build-tree and the positional argument pointing to the ``lldb`` directory
+in the source-tree. In order to find the provided build-tree, the build-system
+needs the options ``LLVM_DIR`` and ``Clang_DIR`` (CMake variables are
+case-sensitive!):
 
 ::
 
+  > cmake -B /path/to/lldb-build -G Ninja \
+  -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
+  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
+  [] /path/to/llvm-project/lldb
   > ninja lldb
 
+
+.. _CommonCMakeOptions:
+
+Common CMake options
+
+
 Following is a description of some of the most important CMake variables which
 you are likely to encounter. A variable FOO is set by adding ``-DFOO=value`` to
 the CMake command line.
@@ -128,7 +188,7 @@
 test execution.
 
 Windows
-***
+^^^
 
 Although the following CMake variables are by no means Windows specific, they
 are commonly used on Windows.
@@ -162,7 +222,7 @@
   
 
 NetBSD
-**
+^^
 
 Current stable NetBSD release doesn't ship with libpanel(3), therefore it's
 required to disable curses(3) support with the
@@ -170,22 +230,75 @@
 ``/usr/include/panel.h`` exists in your system.
 
 macOS
-*
+^
 
 Here are some commonly used LLDB-specific CMake variables on macOS.
 
 * ``LLDB_BUILD_FRAMEWORK:BOOL`` : Builds the LLDB.framework.
 * ``LLDB_CODESIGN_IDENTITY:STRING`` : Determines the codesign identity to use.
-  An empty string means skip building debugserver to avoid codesigning.
+  The default is ``lldb_codesign`` (see the `Code-signing section <#codesigning>`_).
+
+
+.. _CMakeCaches:
+
+CMake caches
+
+
+CMake caches allow to store common sets of configuration options in the form of
+CMake scripts and can be useful to reproduce builds for particular use-cases
+(see by analogy `usage in LLVM and Clang `_).
+A cache is passed to CMake with the ``-C`` flag, following the absolute path to
+the file on disk. Subsequent ``-D`` options are still allowed. Please find the
+currently available caches in the `lldb/cmake/caches/
+`_
+directory.
+
+Common configurations on macOS
+^^
+
+Build, test 

[Lldb-commits] [PATCH] D65230: [CMake] Loosen Python version check and ignore patch version

[Jonas Devlieghere via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367115: [CMake] Loosen Python version check and ignore patch 
version (authored by JDevlieghere, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D65230?vs=211811=211939#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65230

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


Index: lldb/trunk/cmake/modules/LLDBConfig.cmake
===
--- lldb/trunk/cmake/modules/LLDBConfig.cmake
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake
@@ -140,7 +140,6 @@
  PYTHONLIBS_VERSION_STRING "${python_version_str}")
 message(STATUS "Found Python library version ${PYTHONLIBS_VERSION_STRING}")
 string(REGEX REPLACE "([0-9]+)[.]([0-9]+)[.][0-9]+" "python\\1\\2" 
PYTHONLIBS_BASE_NAME "${PYTHONLIBS_VERSION_STRING}")
-set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}" PARENT_SCOPE)
 unset(python_version_str)
   else()
 message(WARNING "Unable to find ${PYTHON_INCLUDE_DIR}/patchlevel.h, Python 
installation is corrupt.")
@@ -175,13 +174,31 @@
 return()
   endif()
 
-  set (PYTHON_EXECUTABLE ${PYTHON_EXE} PARENT_SCOPE)
-  set (PYTHON_LIBRARY ${PYTHON_LIB} PARENT_SCOPE)
-  set (PYTHON_DLL ${PYTHON_DLL} PARENT_SCOPE)
-  set (PYTHON_INCLUDE_DIR ${PYTHON_INCLUDE_DIR} PARENT_SCOPE)
+  # Find the version of the Python interpreter.
+  execute_process(COMMAND "${PYTHON_EXE}" -c
+  "import sys; sys.stdout.write(';'.join([str(x) for x in 
sys.version_info[:3]]))"
+  OUTPUT_VARIABLE PYTHON_VERSION_OUTPUT
+  RESULT_VARIABLE PYTHON_VERSION_RESULT
+  ERROR_QUIET)
+  if(NOT PYTHON_VERSION_RESULT)
+string(REPLACE ";" "." PYTHON_VERSION_STRING "${PYTHON_VERSION_OUTPUT}")
+list(GET PYTHON_VERSION_OUTPUT 0 PYTHON_VERSION_MAJOR)
+list(GET PYTHON_VERSION_OUTPUT 1 PYTHON_VERSION_MINOR)
+list(GET PYTHON_VERSION_OUTPUT 2 PYTHON_VERSION_PATCH)
+  endif()
+
+  # Set the same variables as FindPythonInterp and FindPythonLibs.
+  set(PYTHON_EXECUTABLE ${PYTHON_EXE} PARENT_SCOPE)
+  set(PYTHON_LIBRARY ${PYTHON_LIB} PARENT_SCOPE)
+  set(PYTHON_DLL ${PYTHON_DLL} PARENT_SCOPE)
+  set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}" PARENT_SCOPE)
+  set(PYTHON_VERSION_STRING ${PYTHON_VERSION_STRING} PARENT_SCOPE)
+  set(PYTHON_VERSION_MAJOR ${PYTHON_VERSION_MAJOR} PARENT_SCOPE)
+  set(PYTHON_VERSION_MINOR ${PYTHON_VERSION_MINOR} PARENT_SCOPE)
+  set(PYTHON_VERSION_PATCH ${PYTHON_VERSION_PATCH} PARENT_SCOPE)
 
-  message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXE}")
-  message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIB}")
+  message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE}")
+  message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIBRARY}")
   message(STATUS "LLDB Found PythonDLL: ${PYTHON_DLL}")
   message(STATUS "LLDB Found PythonIncludeDirs: ${PYTHON_INCLUDE_DIR}")
 endfunction(find_python_libs_windows)
@@ -199,9 +216,18 @@
 find_package(PythonLibs REQUIRED)
   endif()
 
-  if (NOT PYTHON_VERSION_STRING VERSION_EQUAL PYTHONLIBS_VERSION_STRING AND
-  NOT CMAKE_CROSSCOMPILING)
-message(FATAL_ERROR "Found incompatible Python interpreter 
(${PYTHON_VERSION_STRING}) and Python libraries (${PYTHONLIBS_VERSION_STRING})")
+  if (NOT CMAKE_CROSSCOMPILING)
+string(REPLACE "." ";" pythonlibs_version_list 
${PYTHONLIBS_VERSION_STRING})
+list(GET pythonlibs_version_list 0 pythonlibs_major)
+list(GET pythonlibs_version_list 1 pythonlibs_minor)
+
+# Ignore the patch version. Some versions of macOS report a different patch
+# version for the system provided interpreter and libraries.
+if (NOT PYTHON_VERSION_MAJOR VERSION_EQUAL pythonlibs_major OR
+NOT PYTHON_VERSION_MINOR VERSION_EQUAL pythonlibs_minor)
+  message(FATAL_ERROR "Found incompatible Python interpreter 
(${python_major}.${python_minor})"
+  " and Python libraries 
(${pythonlibs_major}.${pythonlibs_minor})")
+endif()
   endif()
 
   if (PYTHON_INCLUDE_DIR)


Index: lldb/trunk/cmake/modules/LLDBConfig.cmake
===
--- lldb/trunk/cmake/modules/LLDBConfig.cmake
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake
@@ -140,7 +140,6 @@
  PYTHONLIBS_VERSION_STRING "${python_version_str}")
 message(STATUS "Found Python library version ${PYTHONLIBS_VERSION_STRING}")
 string(REGEX REPLACE "([0-9]+)[.]([0-9]+)[.][0-9]+" "python\\1\\2" PYTHONLIBS_BASE_NAME "${PYTHONLIBS_VERSION_STRING}")
-set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}" PARENT_SCOPE)
 unset(python_version_str)
   else()
 message(WARNING "Unable to find ${PYTHON_INCLUDE_DIR}/patchlevel.h, Python installation is corrupt.")
@@ -175,13 +174,31 @@

[Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

[Guilherme Andrade via Phabricator via lldb-commits]

guiandrade added a comment.

Thanks, labath@

Could anyone please merge this for me?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62931



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

[Lldb-commits] [lldb] r367115 - [CMake] Loosen Python version check and ignore patch version

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Fri Jul 26 07:26:33 2019
New Revision: 367115

URL: http://llvm.org/viewvc/llvm-project?rev=367115=rev
Log:
[CMake] Loosen Python version check and ignore patch version

Some versions of macOS report a different patch version for the system
provided interpreter and libraries.

Differential revision: https://reviews.llvm.org/D65230

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

Modified: lldb/trunk/cmake/modules/LLDBConfig.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBConfig.cmake?rev=367115=367114=367115=diff
==
--- lldb/trunk/cmake/modules/LLDBConfig.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBConfig.cmake Fri Jul 26 07:26:33 2019
@@ -140,7 +140,6 @@ function(find_python_libs_windows)
  PYTHONLIBS_VERSION_STRING "${python_version_str}")
 message(STATUS "Found Python library version ${PYTHONLIBS_VERSION_STRING}")
 string(REGEX REPLACE "([0-9]+)[.]([0-9]+)[.][0-9]+" "python\\1\\2" 
PYTHONLIBS_BASE_NAME "${PYTHONLIBS_VERSION_STRING}")
-set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}" PARENT_SCOPE)
 unset(python_version_str)
   else()
 message(WARNING "Unable to find ${PYTHON_INCLUDE_DIR}/patchlevel.h, Python 
installation is corrupt.")
@@ -175,13 +174,31 @@ function(find_python_libs_windows)
 return()
   endif()
 
-  set (PYTHON_EXECUTABLE ${PYTHON_EXE} PARENT_SCOPE)
-  set (PYTHON_LIBRARY ${PYTHON_LIB} PARENT_SCOPE)
-  set (PYTHON_DLL ${PYTHON_DLL} PARENT_SCOPE)
-  set (PYTHON_INCLUDE_DIR ${PYTHON_INCLUDE_DIR} PARENT_SCOPE)
+  # Find the version of the Python interpreter.
+  execute_process(COMMAND "${PYTHON_EXE}" -c
+  "import sys; sys.stdout.write(';'.join([str(x) for x in 
sys.version_info[:3]]))"
+  OUTPUT_VARIABLE PYTHON_VERSION_OUTPUT
+  RESULT_VARIABLE PYTHON_VERSION_RESULT
+  ERROR_QUIET)
+  if(NOT PYTHON_VERSION_RESULT)
+string(REPLACE ";" "." PYTHON_VERSION_STRING "${PYTHON_VERSION_OUTPUT}")
+list(GET PYTHON_VERSION_OUTPUT 0 PYTHON_VERSION_MAJOR)
+list(GET PYTHON_VERSION_OUTPUT 1 PYTHON_VERSION_MINOR)
+list(GET PYTHON_VERSION_OUTPUT 2 PYTHON_VERSION_PATCH)
+  endif()
+
+  # Set the same variables as FindPythonInterp and FindPythonLibs.
+  set(PYTHON_EXECUTABLE ${PYTHON_EXE} PARENT_SCOPE)
+  set(PYTHON_LIBRARY ${PYTHON_LIB} PARENT_SCOPE)
+  set(PYTHON_DLL ${PYTHON_DLL} PARENT_SCOPE)
+  set(PYTHONLIBS_VERSION_STRING "${PYTHONLIBS_VERSION_STRING}" PARENT_SCOPE)
+  set(PYTHON_VERSION_STRING ${PYTHON_VERSION_STRING} PARENT_SCOPE)
+  set(PYTHON_VERSION_MAJOR ${PYTHON_VERSION_MAJOR} PARENT_SCOPE)
+  set(PYTHON_VERSION_MINOR ${PYTHON_VERSION_MINOR} PARENT_SCOPE)
+  set(PYTHON_VERSION_PATCH ${PYTHON_VERSION_PATCH} PARENT_SCOPE)
 
-  message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXE}")
-  message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIB}")
+  message(STATUS "LLDB Found PythonExecutable: ${PYTHON_EXECUTABLE}")
+  message(STATUS "LLDB Found PythonLibs: ${PYTHON_LIBRARY}")
   message(STATUS "LLDB Found PythonDLL: ${PYTHON_DLL}")
   message(STATUS "LLDB Found PythonIncludeDirs: ${PYTHON_INCLUDE_DIR}")
 endfunction(find_python_libs_windows)
@@ -199,9 +216,18 @@ if (NOT LLDB_DISABLE_PYTHON)
 find_package(PythonLibs REQUIRED)
   endif()
 
-  if (NOT PYTHON_VERSION_STRING VERSION_EQUAL PYTHONLIBS_VERSION_STRING AND
-  NOT CMAKE_CROSSCOMPILING)
-message(FATAL_ERROR "Found incompatible Python interpreter 
(${PYTHON_VERSION_STRING}) and Python libraries (${PYTHONLIBS_VERSION_STRING})")
+  if (NOT CMAKE_CROSSCOMPILING)
+string(REPLACE "." ";" pythonlibs_version_list 
${PYTHONLIBS_VERSION_STRING})
+list(GET pythonlibs_version_list 0 pythonlibs_major)
+list(GET pythonlibs_version_list 1 pythonlibs_minor)
+
+# Ignore the patch version. Some versions of macOS report a different patch
+# version for the system provided interpreter and libraries.
+if (NOT PYTHON_VERSION_MAJOR VERSION_EQUAL pythonlibs_major OR
+NOT PYTHON_VERSION_MINOR VERSION_EQUAL pythonlibs_minor)
+  message(FATAL_ERROR "Found incompatible Python interpreter 
(${python_major}.${python_minor})"
+  " and Python libraries 
(${pythonlibs_major}.${pythonlibs_minor})")
+endif()
   endif()
 
   if (PYTHON_INCLUDE_DIR)


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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[J. Ryan Stinnett via Phabricator via lldb-commits]

jryans added a comment.

In D65330#1602583 , @sgraenitz wrote:

> Since //Visual Studio// is the only section in //Building LLDB with CMake and 
> Other Generators// now, I would like to:
>
> - move it merge it with another one, preferably //Common CMake options > 
> Windows//
> - rename //Building LLDB with CMake & Ninja// into //Building LLDB with 
> CMake// (analog and with a link to http://llvm.org/docs/CMake.html)
>
>   Would that be acceptable?


Yes, this sounds like a good plan.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added a comment.

Updated rendered HTML: 
http://weliveindetail.github.io/blog/res/lldb-docs/resources/build.html


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added a comment.

Since //Visual Studio// is the only section in //Building LLDB with CMake and 
Other Generators// now, I would like to:

- move it merge it with another one, preferably //Common CMake options > 
Windows//
- rename //Building LLDB with CMake & Ninja// into //Building LLDB with CMake// 
(analog and with a link to http://llvm.org/docs/CMake.html)

Would that be acceptable?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [lldb] r367110 - [lldb][NFC] Remove eDiagnosticOriginGo

[Raphael Isemann via lldb-commits]

Author: teemperor
Date: Fri Jul 26 07:00:13 2019
New Revision: 367110

URL: http://llvm.org/viewvc/llvm-project?rev=367110=rev
Log:
[lldb][NFC] Remove eDiagnosticOriginGo

This enum value is unused as we removed Go support.

Modified:
lldb/trunk/include/lldb/Expression/DiagnosticManager.h

Modified: lldb/trunk/include/lldb/Expression/DiagnosticManager.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Expression/DiagnosticManager.h?rev=367110=367109=367110=diff
==
--- lldb/trunk/include/lldb/Expression/DiagnosticManager.h (original)
+++ lldb/trunk/include/lldb/Expression/DiagnosticManager.h Fri Jul 26 07:00:13 
2019
@@ -23,7 +23,6 @@ enum DiagnosticOrigin {
   eDiagnosticOriginUnknown = 0,
   eDiagnosticOriginLLDB,
   eDiagnosticOriginClang,
-  eDiagnosticOriginGo,
   eDiagnosticOriginSwift,
   eDiagnosticOriginLLVM
 };
@@ -47,7 +46,6 @@ public:
 switch (kind) {
 case eDiagnosticOriginUnknown:
 case eDiagnosticOriginLLDB:
-case eDiagnosticOriginGo:
 case eDiagnosticOriginLLVM:
   return true;
 case eDiagnosticOriginClang:


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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz updated this revision to Diff 211930.
sgraenitz marked an inline comment as done.
sgraenitz added a comment.

Polish section `Standalone builds`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330

Files:
  lldb/docs/resources/build.rst

Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -81,20 +81,79 @@
 Building LLDB with CMake & Ninja
 
 
+The LLVM project is migrating to a single monolithic respository for LLVM and
+its subprojects. This is the recommended way to build LLDB. Checkout the
+source-tree with git:
+
+::
+
+  > git clone https://github.com/llvm/llvm-project.git
+
 CMake is a cross-platform build-generator tool. CMake does not build the
-project, it generates the files needed by your build tool. Assuming you're
-using Ninja, the invocation looks like this:
+project, it generates the files needed by your build tool. The recommended
+build tool for LLVM is Ninja.
+
+Regular in-tree builds
+**
+
+Create a new directory for your build-tree. From there run CMake and point it
+to the ``llvm`` directory in the source-tree:
+
+::
+
+  > cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb" [] path/to/llvm-project/llvm
+
+We used the ``LLVM_ENABLE_PROJECTS`` option here to tell the build-system which
+subprojects to build in addition to LLVM (for more options see `Common CMake
+Options <#commoncmakeoptions>`_ and `CMake Caches <#cmakecaches>`_). Now run ninja to perform the actual build.
+We pass ``lldb`` here as the target, so it only builds what is necessary to run
+the lldb driver:
+
+::
+
+  > ninja lldb
+
+Standalone builds
+*
+
+This is another way to build LLDB. We can use the same source-tree as we
+checked out above, but now we will have two build-trees:
+
+* the main build-tree for LLDB in ``/path/to/lldb-build``
+* a provided build-tree for LLVM and Clang in ``/path/to/llvm-build``
+
+Run CMake with ``-B`` pointing to a new directory for the provided build-tree
+and the positional argument pointing to the ``llvm`` directory in the
+source-tree. Note that we leave out LLDB here and only include Clang (and libcxx
+on macOS). Then we build the ``ALL`` target with ninja:
 
 ::
 
-  > cmake -G Ninja  
+  > cmake -B /path/to/llvm-build -G Ninja \
+  -DLLVM_ENABLE_PROJECTS=clang \
+  [] /path/to/llvm-project/llvm
+  > ninja
 
-Once CMake has configured your build, you can run ``ninja`` to build LLDB.
+Now run CMake a second time with ``-B`` pointing to a new directory for the
+main build-tree and the positional argument pointing to the ``lldb`` directory
+in the source-tree. In order to find the provided build-tree, the build-system
+needs the options ``LLVM_DIR`` and ``Clang_DIR`` (CMake variables are
+case-sensitive!):
 
 ::
 
+  > cmake -B /path/to/lldb-build -G Ninja \
+  -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
+  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
+  [] /path/to/llvm-project/lldb
   > ninja lldb
 
+
+.. _CommonCMakeOptions:
+
+Common CMake options
+
+
 Following is a description of some of the most important CMake variables which
 you are likely to encounter. A variable FOO is set by adding ``-DFOO=value`` to
 the CMake command line.
@@ -128,7 +187,7 @@
 test execution.
 
 Windows
-***
+^^^
 
 Although the following CMake variables are by no means Windows specific, they
 are commonly used on Windows.
@@ -162,7 +221,7 @@
   
 
 NetBSD
-**
+^^
 
 Current stable NetBSD release doesn't ship with libpanel(3), therefore it's
 required to disable curses(3) support with the
@@ -170,22 +229,71 @@
 ``/usr/include/panel.h`` exists in your system.
 
 macOS
-*
+^
 
 Here are some commonly used LLDB-specific CMake variables on macOS.
 
 * ``LLDB_BUILD_FRAMEWORK:BOOL`` : Builds the LLDB.framework.
 * ``LLDB_CODESIGN_IDENTITY:STRING`` : Determines the codesign identity to use.
-  An empty string means skip building debugserver to avoid codesigning.
+  The default is ``lldb_codesign`` (see the `Code-signing section <#codesigning>`_).
+
+
+.. _CMakeCaches:
+
+CMake caches
+
+
+CMake caches allow to store common sets of configuration options in the form of
+CMake scripts. They are passed to CMake with the ``-C`` flag, following the
+absolute path to the file on disk. Subsequent ``-D`` options are still allowed.
+Please find the currently available caches in the 
+`lldb/cmake/caches/ `_
+directory. 
+
+Common configurations on macOS
+^^
+
+Build, test and install LLDB from the `monorepo `_:
+
+::
+
+  > git clone https://github.com/llvm/llvm-project
+
+  > cmake -B 

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[J. Ryan Stinnett via Phabricator via lldb-commits]

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

Great!  Thanks for working on this!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz updated this revision to Diff 211931.
sgraenitz marked 2 inline comments as done.
sgraenitz added a comment.

Polish section `CMake caches`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330

Files:
  lldb/docs/resources/build.rst

Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -81,20 +81,79 @@
 Building LLDB with CMake & Ninja
 
 
+The LLVM project is migrating to a single monolithic respository for LLVM and
+its subprojects. This is the recommended way to build LLDB. Checkout the
+source-tree with git:
+
+::
+
+  > git clone https://github.com/llvm/llvm-project.git
+
 CMake is a cross-platform build-generator tool. CMake does not build the
-project, it generates the files needed by your build tool. Assuming you're
-using Ninja, the invocation looks like this:
+project, it generates the files needed by your build tool. The recommended
+build tool for LLVM is Ninja.
+
+Regular in-tree builds
+**
+
+Create a new directory for your build-tree. From there run CMake and point it
+to the ``llvm`` directory in the source-tree:
+
+::
+
+  > cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb" [] path/to/llvm-project/llvm
+
+We used the ``LLVM_ENABLE_PROJECTS`` option here to tell the build-system which
+subprojects to build in addition to LLVM (for more options see `Common CMake
+Options <#commoncmakeoptions>`_ and `CMake Caches <#cmakecaches>`_). Now run ninja to perform the actual build.
+We pass ``lldb`` here as the target, so it only builds what is necessary to run
+the lldb driver:
+
+::
+
+  > ninja lldb
+
+Standalone builds
+*
+
+This is another way to build LLDB. We can use the same source-tree as we
+checked out above, but now we will have two build-trees:
+
+* the main build-tree for LLDB in ``/path/to/lldb-build``
+* a provided build-tree for LLVM and Clang in ``/path/to/llvm-build``
+
+Run CMake with ``-B`` pointing to a new directory for the provided build-tree
+and the positional argument pointing to the ``llvm`` directory in the
+source-tree. Note that we leave out LLDB here and only include Clang (and libcxx
+on macOS). Then we build the ``ALL`` target with ninja:
 
 ::
 
-  > cmake -G Ninja  
+  > cmake -B /path/to/llvm-build -G Ninja \
+  -DLLVM_ENABLE_PROJECTS=clang \
+  [] /path/to/llvm-project/llvm
+  > ninja
 
-Once CMake has configured your build, you can run ``ninja`` to build LLDB.
+Now run CMake a second time with ``-B`` pointing to a new directory for the
+main build-tree and the positional argument pointing to the ``lldb`` directory
+in the source-tree. In order to find the provided build-tree, the build-system
+needs the options ``LLVM_DIR`` and ``Clang_DIR`` (CMake variables are
+case-sensitive!):
 
 ::
 
+  > cmake -B /path/to/lldb-build -G Ninja \
+  -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
+  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
+  [] /path/to/llvm-project/lldb
   > ninja lldb
 
+
+.. _CommonCMakeOptions:
+
+Common CMake options
+
+
 Following is a description of some of the most important CMake variables which
 you are likely to encounter. A variable FOO is set by adding ``-DFOO=value`` to
 the CMake command line.
@@ -128,7 +187,7 @@
 test execution.
 
 Windows
-***
+^^^
 
 Although the following CMake variables are by no means Windows specific, they
 are commonly used on Windows.
@@ -162,7 +221,7 @@
   
 
 NetBSD
-**
+^^
 
 Current stable NetBSD release doesn't ship with libpanel(3), therefore it's
 required to disable curses(3) support with the
@@ -170,22 +229,75 @@
 ``/usr/include/panel.h`` exists in your system.
 
 macOS
-*
+^
 
 Here are some commonly used LLDB-specific CMake variables on macOS.
 
 * ``LLDB_BUILD_FRAMEWORK:BOOL`` : Builds the LLDB.framework.
 * ``LLDB_CODESIGN_IDENTITY:STRING`` : Determines the codesign identity to use.
-  An empty string means skip building debugserver to avoid codesigning.
+  The default is ``lldb_codesign`` (see the `Code-signing section <#codesigning>`_).
+
+
+.. _CMakeCaches:
+
+CMake caches
+
+
+CMake caches allow to store common sets of configuration options in the form of
+CMake scripts and can be useful to reproduce builds for particular use-cases
+(similar to their `usage in LLVM and Clang `_).
+They are passed to CMake with the ``-C`` flag, following the absolute path to
+the file on disk. Subsequent ``-D`` options are still allowed. Please find the
+currently available caches in the `lldb/cmake/caches/
+`_
+directory.
+
+Common configurations on macOS
+^^
+
+Build, test and install LLDB 

[Lldb-commits] [PATCH] D65331: [lldb] Also include the array definition in CommandOptions.inc

[Raphael Isemann via Phabricator via lldb-commits]

teemperor created this revision.
teemperor added a reviewer: JDevlieghere.
Herald added subscribers: lldb-commits, abidh.
Herald added a project: LLDB.

Right now our CommandOptions.inc only generates the initializer for the options 
list but
not the array declaration boilerplate around it. As the array definition is 
identical for all arrays,
we might as well also let the CommandOptions.inc generate it alongside the 
initializers.

This patch will also allow us to generate additional declarations related to 
that option list in
the future (e.g. a enum class representing the specific options which would 
make our
handling code less prone).


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D65331

Files:
  lldb/source/Commands/CommandObjectBreakpoint.cpp
  lldb/source/Commands/CommandObjectBreakpointCommand.cpp
  lldb/source/Commands/CommandObjectCommands.cpp
  lldb/source/Commands/CommandObjectDisassemble.cpp
  lldb/source/Commands/CommandObjectExpression.cpp
  lldb/source/Commands/CommandObjectFrame.cpp
  lldb/source/Commands/CommandObjectHelp.cpp
  lldb/source/Commands/CommandObjectLog.cpp
  lldb/source/Commands/CommandObjectMemory.cpp
  lldb/source/Commands/CommandObjectPlatform.cpp
  lldb/source/Commands/CommandObjectProcess.cpp
  lldb/source/Commands/CommandObjectRegister.cpp
  lldb/source/Commands/CommandObjectSettings.cpp
  lldb/source/Commands/CommandObjectSource.cpp
  lldb/source/Commands/CommandObjectTarget.cpp
  lldb/source/Commands/CommandObjectThread.cpp
  lldb/source/Commands/CommandObjectType.cpp
  lldb/source/Commands/CommandObjectWatchpoint.cpp
  lldb/source/Commands/CommandObjectWatchpointCommand.cpp
  lldb/utils/TableGen/LLDBOptionDefEmitter.cpp

Index: lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
===
--- lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
+++ lldb/utils/TableGen/LLDBOptionDefEmitter.cpp
@@ -129,18 +129,21 @@
 /// Emits all option initializers to the raw_ostream.
 static void emitOptions(std::string Command, std::vector Option,
 raw_ostream ) {
+  std::string ID = Command;
+  std::replace(ID.begin(), ID.end(), ' ', '_');
   // Generate the macro that the user needs to define before including the
   // *.inc file.
-  std::string NeededMacro = "LLDB_OPTIONS_" + Command;
-  std::replace(NeededMacro.begin(), NeededMacro.end(), ' ', '_');
+  std::string NeededMacro = "LLDB_OPTIONS_" + ID;
 
   // All options are in one file, so we need put them behind macros and ask the
   // user to define the macro for the options that are needed.
   OS << "// Options for " << Command << "\n";
   OS << "#ifdef " << NeededMacro << "\n";
+  OS << "constexpr static OptionDefinition g_" + ID + "_options[] = {\n";
   for (Record *R : Option)
 emitOption(R, OS);
   // We undefine the macro for the user like Clang's include files are doing it.
+  OS << "};\n";
   OS << "#undef " << NeededMacro << "\n";
   OS << "#endif // " << Command << " command\n\n";
 }
Index: lldb/source/Commands/CommandObjectWatchpointCommand.cpp
===
--- lldb/source/Commands/CommandObjectWatchpointCommand.cpp
+++ lldb/source/Commands/CommandObjectWatchpointCommand.cpp
@@ -42,10 +42,8 @@
   return OptionEnumValues(g_script_option_enumeration);
 }
 
-static constexpr OptionDefinition g_watchpoint_command_add_options[] = {
 #define LLDB_OPTIONS_watchpoint_command_add
 #include "CommandOptions.inc"
-};
 
 class CommandObjectWatchpointCommandAdd : public CommandObjectParsed,
   public IOHandlerDelegateMultiline {
Index: lldb/source/Commands/CommandObjectWatchpoint.cpp
===
--- lldb/source/Commands/CommandObjectWatchpoint.cpp
+++ lldb/source/Commands/CommandObjectWatchpoint.cpp
@@ -146,11 +146,8 @@
 
 // CommandObjectWatchpointList::Options
 #pragma mark List::CommandOptions
-
-static constexpr OptionDefinition g_watchpoint_list_options[] = {
 #define LLDB_OPTIONS_watchpoint_list
 #include "CommandOptions.inc"
-};
 
 #pragma mark List
 
@@ -507,10 +504,8 @@
 // CommandObjectWatchpointIgnore
 
 #pragma mark Ignore::CommandOptions
-static constexpr OptionDefinition g_watchpoint_ignore_options[] = {
 #define LLDB_OPTIONS_watchpoint_ignore
 #include "CommandOptions.inc"
-};
 
 class CommandObjectWatchpointIgnore : public CommandObjectParsed {
 public:
@@ -625,11 +620,8 @@
 // CommandObjectWatchpointModify
 
 #pragma mark Modify::CommandOptions
-
-static constexpr OptionDefinition g_watchpoint_modify_options[] = {
 #define LLDB_OPTIONS_watchpoint_modify
 #include "CommandOptions.inc"
-};
 
 #pragma mark Modify
 
Index: lldb/source/Commands/CommandObjectType.cpp
===
--- lldb/source/Commands/CommandObjectType.cpp
+++ lldb/source/Commands/CommandObjectType.cpp
@@ -95,10 +95,8 @@
   return false;
 }
 
-static constexpr 

[Lldb-commits] [lldb] r367106 - DWARF: Improve type safety or range lists parsing

[Pavel Labath via lldb-commits]

Author: labath
Date: Fri Jul 26 06:15:28 2019
New Revision: 367106

URL: http://llvm.org/viewvc/llvm-project?rev=367106=rev
Log:
DWARF: Improve type safety or range lists parsing

Delete the abstract GetOffset function, which is only defined for
rnglists entries. Instead fix up entries which refer to the range list
classes so that one can statically know that he is dealing with the
rnglists section and call the function that way.

Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp?rev=367106=367105=367106=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.cpp Fri Jul 26 
06:15:28 2019
@@ -123,11 +123,6 @@ bool DWARFDebugRanges::FindRanges(const
   return false;
 }
 
-uint64_t DWARFDebugRanges::GetOffset(size_t Index) const {
-  lldbassert(false && "DW_FORM_rnglistx is not present before DWARF5");
-  return 0;
-}
-
 bool DWARFDebugRngLists::ExtractRangeList(
 const DWARFDataExtractor , uint8_t addrSize,
 lldb::offset_t *offset_ptr, std::vector ) {

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h?rev=367106=367105=367106=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugRanges.h Fri Jul 26 
06:15:28 2019
@@ -24,7 +24,6 @@ public:
   virtual void Extract(lldb_private::DWARFContext ) = 0;
   virtual bool FindRanges(const DWARFUnit *cu, dw_offset_t debug_ranges_offset,
   DWARFRangeList _list) const = 0;
-  virtual uint64_t GetOffset(size_t Index) const = 0;
 };
 
 class DWARFDebugRanges final : public DWARFDebugRangesBase {
@@ -34,7 +33,6 @@ public:
   void Extract(lldb_private::DWARFContext ) override;
   bool FindRanges(const DWARFUnit *cu, dw_offset_t debug_ranges_offset,
   DWARFRangeList _list) const override;
-  uint64_t GetOffset(size_t Index) const override;
 
   static void Dump(lldb_private::Stream ,
const lldb_private::DWARFDataExtractor _ranges_data,
@@ -62,7 +60,7 @@ public:
   void Extract(lldb_private::DWARFContext ) override;
   bool FindRanges(const DWARFUnit *cu, dw_offset_t debug_ranges_offset,
   DWARFRangeList _list) const override;
-  uint64_t GetOffset(size_t Index) const override;
+  uint64_t GetOffset(size_t Index) const;
 
 protected:
   bool ExtractRangeList(const lldb_private::DWARFDataExtractor ,

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp?rev=367106=367105=367106=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFUnit.cpp Fri Jul 26 
06:15:28 2019
@@ -870,7 +870,7 @@ DWARFUnit::FindRnglistFromOffset(dw_offs
 
 llvm::Expected
 DWARFUnit::FindRnglistFromIndex(uint32_t index) const {
-  const DWARFDebugRangesBase *debug_rnglists = m_dwarf.GetDebugRngLists();
+  const DWARFDebugRngLists *debug_rnglists = m_dwarf.GetDebugRngLists();
   if (!debug_rnglists)
 return llvm::make_error(
 "No debug_rnglists section");

Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp?rev=367106=367105=367106=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp Fri Jul 26 
06:15:28 2019
@@ -598,7 +598,7 @@ SymbolFileDWARF::GetDWARFCompileUnit(lld
   return nullptr;
 }
 
-DWARFDebugRangesBase *SymbolFileDWARF::GetDebugRanges() {
+DWARFDebugRanges *SymbolFileDWARF::GetDebugRanges() {
   if (!m_ranges) {
 static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
 Timer scoped_timer(func_cat, "%s this = %p", LLVM_PRETTY_FUNCTION,
@@ -613,7 +613,7 @@ DWARFDebugRangesBase *SymbolFileDWARF::G
   return m_ranges.get();
 }
 
-DWARFDebugRangesBase *SymbolFileDWARF::GetDebugRngLists() {
+DWARFDebugRngLists 

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[J. Ryan Stinnett via Phabricator via lldb-commits]

jryans added a comment.

In general, this looks great overall! I added few comments on things that would 
be good to clarify.




Comment at: lldb/docs/resources/build.rst:108
+subprojects to build in addition to LLVM. Read more about additional options in
+the CMake Options paragraph. Now run ninja to perform the actual build. We pass
+``lldb`` here as the target, so it only builds what is necessary to run the

Nit: It would be nice to have this link to the CMake Options paragraph.



Comment at: lldb/docs/resources/build.rst:144
+  -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
+  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
+  [] /path/to/llvm-project/lldb

Is the casing of `Clang_DIR` important here? (In most cases, CMake defines are 
all upper case, but perhaps this one is special?) If the casing is important, I 
would suggest noting that here. If it's not important, it's probably simpler go 
all upper case to match other usages.



Comment at: lldb/docs/resources/build.rst:242
+`lldb/cmake/caches/ 
`_
+directory. 
+

It's unclear from reading the paragraph if using these caches is recommended 
for most users. If it is, it would helpful to state that. In general, some kind 
of statement that answers "who should use this" would help.



Comment at: lldb/docs/resources/build.rst:260
+
+Build LLDB Standalone for development with Xcode:
+

Nit: Standalone -> standalone perhaps?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz updated this revision to Diff 211922.
sgraenitz marked 2 inline comments as done.
sgraenitz added a comment.

Add links to sections


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330

Files:
  lldb/docs/resources/build.rst

Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -81,20 +81,76 @@
 Building LLDB with CMake & Ninja
 
 
+The LLVM project is migrating to a single monolithic respository for LLVM and
+its subprojects. This is the recommended way to build LLDB. Checkout the
+source-tree with git:
+
+::
+
+  > git clone https://github.com/llvm/llvm-project.git
+
 CMake is a cross-platform build-generator tool. CMake does not build the
-project, it generates the files needed by your build tool. Assuming you're
-using Ninja, the invocation looks like this:
+project, it generates the files needed by your build tool. The recommended
+build tool for LLVM is Ninja.
+
+Regular in-tree builds
+**
+
+Create a new directory for your build-tree. From there run CMake and point it
+to the ``llvm`` directory in the source-tree:
+
+::
+
+  > cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb" [] path/to/llvm-project/llvm
+
+We used the ``LLVM_ENABLE_PROJECTS`` option here to tell the build-system which
+subprojects to build in addition to LLVM (for more options see `Common CMake
+Options <#commoncmakeoptions>`_ and `CMake Caches <#cmakecaches>`_). Now run ninja to perform the actual build.
+We pass ``lldb`` here as the target, so it only builds what is necessary to run
+the lldb driver:
+
+::
+
+  > ninja lldb
+
+Standalone builds
+*
+
+This is another way to build LLDB. You can use the same source-tree as we
+checked out above, but now we will use two build-trees:
+
+* the main build-tree for LLDB
+* a provided build-tree for LLVM and Clang
+
+We start with the latter. In a new directory, run CMake and point it to the
+``llvm`` directory in the source-tree. This time we leave out LLDB and only
+include Clang. Then we build all targets with ninja:
 
 ::
 
-  > cmake -G Ninja  
+  > cmake -B /path/to/llvm-build -G Ninja \
+  -DLLVM_ENABLE_PROJECTS=clang \
+  [] /path/to/llvm-project/llvm
+  > ninja
 
-Once CMake has configured your build, you can run ``ninja`` to build LLDB.
+Now create a second directory for the LLDB build-tree and run CMake pointing to
+the ``lldb`` directory in the source-tree. In order to find the provided
+build-tree, the build-system needs the options ``LLVM_DIR`` and ``Clang_DIR``:
 
 ::
 
+  > cmake -B /path/to/lldb-build -G Ninja \
+  -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
+  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
+  [] /path/to/llvm-project/lldb
   > ninja lldb
 
+
+.. _CommonCMakeOptions:
+
+Common CMake options
+
+
 Following is a description of some of the most important CMake variables which
 you are likely to encounter. A variable FOO is set by adding ``-DFOO=value`` to
 the CMake command line.
@@ -128,7 +184,7 @@
 test execution.
 
 Windows
-***
+^^^
 
 Although the following CMake variables are by no means Windows specific, they
 are commonly used on Windows.
@@ -162,7 +218,7 @@
   
 
 NetBSD
-**
+^^
 
 Current stable NetBSD release doesn't ship with libpanel(3), therefore it's
 required to disable curses(3) support with the
@@ -170,22 +226,71 @@
 ``/usr/include/panel.h`` exists in your system.
 
 macOS
-*
+^
 
 Here are some commonly used LLDB-specific CMake variables on macOS.
 
 * ``LLDB_BUILD_FRAMEWORK:BOOL`` : Builds the LLDB.framework.
 * ``LLDB_CODESIGN_IDENTITY:STRING`` : Determines the codesign identity to use.
-  An empty string means skip building debugserver to avoid codesigning.
+  The default is ``lldb_codesign`` (see the `Code-signing section <#codesigning>`_).
+
+
+.. _CMakeCaches:
+
+CMake caches
+
+
+CMake caches allow to store common sets of configuration options in the form of
+CMake scripts. They are passed to CMake with the ``-C`` flag, following the
+absolute path to the file on disk. Subsequent ``-D`` options are still allowed.
+Please find the currently available caches in the 
+`lldb/cmake/caches/ `_
+directory. 
+
+Common configurations on macOS
+^^
+
+Build, test and install LLDB from the `monorepo `_:
+
+::
+
+  > git clone https://github.com/llvm/llvm-project
+
+  > cmake -B /path/to/lldb-build -G Ninja \
+  -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-macOS.cmake \
+  -DLLVM_ENABLE_PROJECTS="clang;libcxx;lldb" \
+  llvm-project/llvm
+
+  > DESTDIR=/path/to/lldb-install ninja -C 

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Looks good to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65282: ObjectFileELF: permit thread-local sections with overlapping file addresses

[Fangrui Song via Phabricator via lldb-commits]

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

In D65282#1602293 , @labath wrote:

> In D65282#1602244 , @MaskRay wrote:
>
> > > Are you referring to the "image lookup" command specifically, or is it a 
> > > more general question about the internals of lldb too?
> >
> > Both:) This patch doesn't change the `Address: a.o[0x1010] 
> > (a.o.PT_LOAD[0]..tdata + 0)` output so I was puzzled what this patch 
> > intends to do.
>
>
> What do you mean by "doesn't change"? After this patch the addresses always 
> resolve to the .data section..
>
> > 
> > 
> >> However, I can see how it might be interesting to be able to see the 
> >> initial value of a thread local variable much like we can display the 
> >> initial value of a global variable without launching a process. For this 
> >> case, a flag to Section::ContainsFileAddress saying "yes, I want to look 
> >> up in thread-local sections now" would suffice, but I don't know if this 
> >> is the only use case...
> > 
> > Yes, inspecting the initial value of a thread-local variable is a use case. 
> > To that end, can this be done by introducing another member variable 
> > instead of overloading `m_sections_up` with a new purpose (adding 
> > `PT_TLS`)? If PT_TLS is recorded in a different variable, the change below 
> > can be deleted.
>
> I think that would be pretty significant departure from the current design of 
> lldb. Lldb expects that the "section list" of a module will contain all of 
> the module's sections (and before I started messing with these functions, it 
> did). This includes non-loadable sections like .debug_info et al. While one 
> could concieve a world where tls sections are in a special "tls" section 
> list, I am not sure this is actually useful -- if we're going to think of the 
> tls addresses as address spaces, then its reasonable to have more than two 
> address spaces one day (there are people interested in that), and so we 
> couldn't have a fixed set of section lists.


I see. If that would be a significant departure, the current approach should be 
the choice. I didn't non-SHF_ALLOC sections are also in the list. If 
.debug_info et all are in the list, I don't see any problem to have PT_TLS in 
the list since those PT_LOAD are already in the list.

>> 
>> 
>>bool Section::ContainsFileAddress(addr_t vm_addr) const {
>>  const addr_t file_addr = GetFileAddress();
>>   -  if (file_addr != LLDB_INVALID_ADDRESS) {
>>   +  if (file_addr != LLDB_INVALID_ADDRESS && !IsThreadSpecific()) {
>> 
>> 
>> (An adjacent pair of PT_LOAD segments can load the same file contents, e.g. 
>> PT_LOAD `[0x150, 0x1234)` and `[0x1234, 0x1800)` will transform to mmap 
>> calls with ranges `[0, 0x2000)` and `[0x1000, 0x2000)` at runtime if the 
>> runtime page size = 0x1000. They share one page in the file. If you ask what 
>> a specific offset in the file is mapped to, there can be multiple PT_LOAD 
>> segments (physical -> VMA is not unique). Fortunately the reverse mapping 
>> VMA -> physical offset can be treated as unique in practice 
>> (`[p_vaddr,p_vaddr+p_memsz)` ranges do not overlap).)
> 
> I am not 100% what you mean by this, but I think there's some confusion about 
> names of things here. In lldb terms, a "file address" is the "load address, 
> as it is written in the file. It is not the "physical offset within the 
> file", which lldb calls "file offset". Unfortunately, this terminology has 
> caused a lot of confusion in the past, but I don't know what would be the 
> best way to resolve this. How does lld call these things? I guess there's 
> less confusion there as lld does not have to care about real, memory, load 
> addresses...

Maybe we can refer to these things with ELF terminology: p_offset (offsets in 
the file)/p_vaddr (VMA)/p_paddr (LMA)...




Comment at: lit/Modules/ELF/PT_LOAD-overlap-PT_TLS.yaml:62
+Flags:   [ SHF_ALLOC, SHF_WRITE ]
+Address: 0x1000
+AddressAlign:0x4

labath wrote:
> MaskRay wrote:
> > `.data = .tbss = 0x1010` is a more realistic scenario.
> > 
> > Normally, a SHT_PROGBITS section may overlap with a SHT_NOBITS section, but 
> > two SHT_PROGBITS sections do not overlap (ld has an on-by-default check `ld 
> > --check-sections`). Linkers allocate file bytes for SHT_PROGBITS sections 
> > so their occupied bytes cannot be reused by other sections (without fixing 
> > addresses with a linker script).
> Interesting. I can that easily, but I'm wondering, do you know the reason for 
> that? Is it just how it falls out of the default linker processing of things, 
> or would something actually break if I assigned identical addresses to two 
> SHT_PROGBITS sections?
https://github.com/llvm-mirror/lld/blob/master/ELF/Writer.cpp#L2412

SHT_PROGBITS sections occupy space in the file but SHT_NOBITS sections 

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz added a comment.

View rendered HTML output here: 
http://weliveindetail.github.io/blog/res/lldb-docs/resources/build.html


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Raphael Isemann via Phabricator via lldb-commits]

teemperor added a comment.

LGTM (beside the standalone build section which I have no experience with).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65330



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

[Lldb-commits] [PATCH] D65330: [lldb][docs] Update documentation for monorepo and CMake caches

[Stefan Gränitz via Phabricator via lldb-commits]

sgraenitz created this revision.
sgraenitz added reviewers: JDevlieghere, jingham, labath, stella.stamenova, 
teemperor, jryans, kastiglione.
Herald added a project: LLDB.
sgraenitz added a subscriber: friss.
sgraenitz added reviewers: xiaobai, compnerd.

The lldb build system made good progress in the last months, but documentation 
was still lacking behind. Here's a patch to catch up. It would be nice to get 
an update also to the `release/9.x` branch. What do you think?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D65330

Files:
  lldb/docs/resources/build.rst

Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -81,20 +81,73 @@
 Building LLDB with CMake & Ninja
 
 
+The LLVM project is migrating to a single monolithic respository for LLVM and
+its subprojects. This is the recommended way to build LLDB. Checkout the
+source-tree with git:
+
+::
+
+  > git clone https://github.com/llvm/llvm-project.git
+
 CMake is a cross-platform build-generator tool. CMake does not build the
-project, it generates the files needed by your build tool. Assuming you're
-using Ninja, the invocation looks like this:
+project, it generates the files needed by your build tool. The recommended
+build tool for LLVM is Ninja.
+
+Regular in-tree builds
+**
+
+Create a new directory for your build-tree. From there run CMake and point it
+to the ``llvm`` directory in the source-tree:
+
+::
+
+  > cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb" [] path/to/llvm-project/llvm
+
+We used the ``LLVM_ENABLE_PROJECTS`` option here to tell the build-system which
+subprojects to build in addition to LLVM. Read more about additional options in
+the CMake Options paragraph. Now run ninja to perform the actual build. We pass
+``lldb`` here as the target, so it only builds what is necessary to run the
+lldb driver:
+
+::
+
+  > ninja lldb
+
+Standalone builds
+*
+
+This is another way to build LLDB. You can use the same source-tree as we
+checked out above, but now we will use two build-trees:
+
+* the main build-tree for LLDB
+* a provided build-tree for LLVM and Clang
+
+We start with the latter. In a new directory, run CMake and point it to the
+``llvm`` directory in the source-tree. This time we leave out LLDB and only
+include Clang. Then we build all targets with ninja:
 
 ::
 
-  > cmake -G Ninja  
+  > cmake -B /path/to/llvm-build -G Ninja \
+  -DLLVM_ENABLE_PROJECTS=clang \
+  [] /path/to/llvm-project/llvm
+  > ninja
 
-Once CMake has configured your build, you can run ``ninja`` to build LLDB.
+Now create a second directory for the LLDB build-tree and run CMake pointing to
+the ``lldb`` directory in the source-tree. In order to find the provided
+build-tree, the build-system needs the options ``LLVM_DIR`` and ``Clang_DIR``:
 
 ::
 
+  > cmake -B /path/to/lldb-build -G Ninja \
+  -DLLVM_DIR=/path/to/llvm-build/lib/cmake/llvm \
+  -DClang_DIR=/path/to/llvm-build/lib/cmake/clang \
+  [] /path/to/llvm-project/lldb
   > ninja lldb
 
+Common CMake options
+
+
 Following is a description of some of the most important CMake variables which
 you are likely to encounter. A variable FOO is set by adding ``-DFOO=value`` to
 the CMake command line.
@@ -128,7 +181,7 @@
 test execution.
 
 Windows
-***
+^^^
 
 Although the following CMake variables are by no means Windows specific, they
 are commonly used on Windows.
@@ -162,7 +215,7 @@
   
 
 NetBSD
-**
+^^
 
 Current stable NetBSD release doesn't ship with libpanel(3), therefore it's
 required to disable curses(3) support with the
@@ -170,22 +223,68 @@
 ``/usr/include/panel.h`` exists in your system.
 
 macOS
-*
+^
 
 Here are some commonly used LLDB-specific CMake variables on macOS.
 
 * ``LLDB_BUILD_FRAMEWORK:BOOL`` : Builds the LLDB.framework.
 * ``LLDB_CODESIGN_IDENTITY:STRING`` : Determines the codesign identity to use.
-  An empty string means skip building debugserver to avoid codesigning.
+  The default is ``lldb_codesign`` (see the `Code-signing section <#codesigning>`_).
+
+CMake caches
+
+
+CMake caches allow to store common sets of configuration options in the form of
+CMake scripts. They are passed to CMake with the ``-C`` flag, following the
+absolute path to the file on disk. Subsequent ``-D`` options are still allowed.
+Please find the currently available caches in the 
+`lldb/cmake/caches/ `_
+directory. 
+
+Common configurations on macOS
+^^
+
+Build, test and install LLDB from the `monorepo `_:
+
+::
+
+  > git clone https://github.com/llvm/llvm-project
+
+  > cmake -B /path/to/lldb-build -G Ninja \
+  -C 

[Lldb-commits] [PATCH] D65329: SymbolVendor: Move locking into the Symbol Files

[Pavel Labath via Phabricator via lldb-commits]

labath created this revision.
labath added reviewers: clayborg, JDevlieghere, jingham.
Herald added a subscriber: aprantl.
Herald added a reviewer: jdoerfert.

The last bit of functionality in SymbolVendor passthrough functions is
the locking the module mutex. While it may be nice doing the locking in
a central place, we weren't really succesful in doing that right now,
because some SymbolFile function could still be called without going
through the SymbolVendor. This meant in SymbolFileDWARF (the only
battle-tested symbol file implementation) roughly a half of the
functions was taking additional locks and another half was asserting
that the lock is already held. By making the SymbolFile responsible for
locking, we can at least make the situation in SymbolFileDWARF more
consistent.


https://reviews.llvm.org/D65329

Files:
  source/Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
  source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
  source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
  source/Plugins/SymbolFile/PDB/SymbolFilePDB.cpp
  source/Plugins/SymbolFile/Symtab/SymbolFileSymtab.cpp
  source/Symbol/SymbolFile.cpp
  source/Symbol/SymbolVendor.cpp

Index: source/Symbol/SymbolVendor.cpp
===
--- source/Symbol/SymbolVendor.cpp
+++ source/Symbol/SymbolVendor.cpp
@@ -76,135 +76,83 @@
 }
 
 size_t SymbolVendor::GetNumCompileUnits() {
-  ModuleSP module_sp(GetModule());
-  if (module_sp) {
-std::lock_guard guard(module_sp->GetMutex());
-if (m_sym_file_up)
-  return m_sym_file_up->GetNumCompileUnits();
-  }
+  if (m_sym_file_up)
+return m_sym_file_up->GetNumCompileUnits();
   return 0;
 }
 
 lldb::LanguageType SymbolVendor::ParseLanguage(CompileUnit _unit) {
-  ModuleSP module_sp(GetModule());
-  if (module_sp) {
-std::lock_guard guard(module_sp->GetMutex());
-if (m_sym_file_up)
-  return m_sym_file_up->ParseLanguage(comp_unit);
-  }
+  if (m_sym_file_up)
+return m_sym_file_up->ParseLanguage(comp_unit);
   return eLanguageTypeUnknown;
 }
 
 size_t SymbolVendor::ParseFunctions(CompileUnit _unit) {
-  ModuleSP module_sp(GetModule());
-  if (module_sp) {
-std::lock_guard guard(module_sp->GetMutex());
-if (m_sym_file_up)
-  return m_sym_file_up->ParseFunctions(comp_unit);
-  }
+  if (m_sym_file_up)
+return m_sym_file_up->ParseFunctions(comp_unit);
   return 0;
 }
 
 bool SymbolVendor::ParseLineTable(CompileUnit _unit) {
-  ModuleSP module_sp(GetModule());
-  if (module_sp) {
-std::lock_guard guard(module_sp->GetMutex());
-if (m_sym_file_up)
-  return m_sym_file_up->ParseLineTable(comp_unit);
-  }
+  if (m_sym_file_up)
+return m_sym_file_up->ParseLineTable(comp_unit);
   return false;
 }
 
 bool SymbolVendor::ParseDebugMacros(CompileUnit _unit) {
-  ModuleSP module_sp(GetModule());
-  if (module_sp) {
-std::lock_guard guard(module_sp->GetMutex());
-if (m_sym_file_up)
-  return m_sym_file_up->ParseDebugMacros(comp_unit);
-  }
+  if (m_sym_file_up)
+return m_sym_file_up->ParseDebugMacros(comp_unit);
   return false;
 }
 bool SymbolVendor::ParseSupportFiles(CompileUnit _unit,
  FileSpecList _files) {
-  ModuleSP module_sp(GetModule());
-  if (module_sp) {
-std::lock_guard guard(module_sp->GetMutex());
-if (m_sym_file_up)
-  return m_sym_file_up->ParseSupportFiles(comp_unit, support_files);
-  }
+  if (m_sym_file_up)
+return m_sym_file_up->ParseSupportFiles(comp_unit, support_files);
   return false;
 }
 
 bool SymbolVendor::ParseIsOptimized(CompileUnit _unit) {
-  ModuleSP module_sp(GetModule());
-  if (module_sp) {
-std::lock_guard guard(module_sp->GetMutex());
-if (m_sym_file_up)
-  return m_sym_file_up->ParseIsOptimized(comp_unit);
-  }
+  if (m_sym_file_up)
+return m_sym_file_up->ParseIsOptimized(comp_unit);
   return false;
 }
 
 bool SymbolVendor::ParseImportedModules(
 const SymbolContext , std::vector _modules) {
-  ModuleSP module_sp(GetModule());
-  if (module_sp) {
-std::lock_guard guard(module_sp->GetMutex());
-if (m_sym_file_up)
-  return m_sym_file_up->ParseImportedModules(sc, imported_modules);
-  }
+  if (m_sym_file_up)
+return m_sym_file_up->ParseImportedModules(sc, imported_modules);
   return false;
 }
 
 size_t SymbolVendor::ParseBlocksRecursive(Function ) {
-  ModuleSP module_sp(GetModule());
-  if (module_sp) {
-std::lock_guard guard(module_sp->GetMutex());
-if (m_sym_file_up)
-  return m_sym_file_up->ParseBlocksRecursive(func);
-  }
+  if (m_sym_file_up)
+return m_sym_file_up->ParseBlocksRecursive(func);
   return 0;
 }
 
 size_t SymbolVendor::ParseTypes(CompileUnit _unit) {
-  ModuleSP module_sp(GetModule());
-  if (module_sp) {
-std::lock_guard guard(module_sp->GetMutex());
-if (m_sym_file_up)
-  return m_sym_file_up->ParseTypes(comp_unit);
-  }
+  if 

[Lldb-commits] [lldb] r367102 - [lldb] Don't dynamically allocate the posix option validator.

[Raphael Isemann via lldb-commits]

Author: teemperor
Date: Fri Jul 26 04:46:21 2019
New Revision: 367102

URL: http://llvm.org/viewvc/llvm-project?rev=367102=rev
Log:
[lldb] Don't dynamically allocate the posix option validator.

We dynamically allocate the option validator which means we
can't mark this list of OptionDefinitions as constexpr. It's also
more complicated than necessary.

Modified:
lldb/trunk/source/Commands/CommandObjectPlatform.cpp
lldb/trunk/source/Commands/Options.td
lldb/trunk/source/Commands/OptionsBase.td
lldb/trunk/utils/TableGen/LLDBOptionDefEmitter.cpp

Modified: lldb/trunk/source/Commands/CommandObjectPlatform.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/CommandObjectPlatform.cpp?rev=367102=367101=367102=diff
==
--- lldb/trunk/source/Commands/CommandObjectPlatform.cpp (original)
+++ lldb/trunk/source/Commands/CommandObjectPlatform.cpp Fri Jul 26 04:46:21 
2019
@@ -1041,7 +1041,8 @@ protected:
 
 // "platform process list"
 
-static OptionDefinition g_platform_process_list_options[] = {
+static PosixPlatformCommandOptionValidator posix_validator;
+static constexpr OptionDefinition g_platform_process_list_options[] = {
 #define LLDB_OPTIONS_platform_process_list
 #include "CommandOptions.inc"
 };
@@ -1166,23 +1167,6 @@ protected:
   public:
 CommandOptions()
 : Options(), match_info(), show_args(false), verbose(false) {
-  static llvm::once_flag g_once_flag;
-  llvm::call_once(g_once_flag, []() {
-PosixPlatformCommandOptionValidator *posix_validator =
-new PosixPlatformCommandOptionValidator();
-for (auto  : g_platform_process_list_options) {
-  switch (Option.short_option) {
-  case 'u':
-  case 'U':
-  case 'g':
-  case 'G':
-Option.validator = posix_validator;
-break;
-  default:
-break;
-  }
-}
-  });
 }
 
 ~CommandOptions() override = default;

Modified: lldb/trunk/source/Commands/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/Options.td?rev=367102=367101=367102=diff
==
--- lldb/trunk/source/Commands/Options.td (original)
+++ lldb/trunk/source/Commands/Options.td Fri Jul 26 04:46:21 2019
@@ -576,16 +576,16 @@ let Command = "platform process list" in
   def platform_process_list_parent : Option<"parent", "P">, GroupRange<2, 6>,
 Arg<"Pid">, Desc<"Find processes that have a matching parent process ID.">;
   def platform_process_list_uid : Option<"uid", "u">, GroupRange<2, 6>,
-Arg<"UnsignedInteger">,
+Arg<"UnsignedInteger">, Validator<"_validator">,
 Desc<"Find processes that have a matching user ID.">;
   def platform_process_list_euid : Option<"euid", "U">, GroupRange<2, 6>,
-Arg<"UnsignedInteger">,
+Arg<"UnsignedInteger">, Validator<"_validator">,
 Desc<"Find processes that have a matching effective user ID.">;
   def platform_process_list_gid : Option<"gid", "g">, GroupRange<2, 6>,
-Arg<"UnsignedInteger">,
+Arg<"UnsignedInteger">, Validator<"_validator">,
 Desc<"Find processes that have a matching group ID.">;
   def platform_process_list_egid : Option<"egid", "G">, GroupRange<2, 6>,
-Arg<"UnsignedInteger">,
+Arg<"UnsignedInteger">, Validator<"_validator">,
 Desc<"Find processes that have a matching effective group ID.">;
   def platform_process_list_arch : Option<"arch", "a">, GroupRange<2, 6>,
 Arg<"Architecture">,

Modified: lldb/trunk/source/Commands/OptionsBase.td
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Commands/OptionsBase.td?rev=367102=367101=367102=diff
==
--- lldb/trunk/source/Commands/OptionsBase.td (original)
+++ lldb/trunk/source/Commands/OptionsBase.td Fri Jul 26 04:46:21 2019
@@ -46,7 +46,9 @@
 

 // Field: validator
 // Default value: 0 (No validator for option)
-// Set by: Nothing. This is currently only set after initialization in LLDB.
+// Set by:
+//  - `Validator`: Sets the value to a given validator (which has to exist in
+// the surrounding code.
 

 // Field: enum_values
 // Default value: {} (No enum associated with this option)
@@ -169,3 +171,8 @@ class Completions completio
 class Completion {
   list Completions = [completion];
 }
+
+// Sets the validator for a given option.
+class Validator {
+  string Validator = validator;
+}

Modified: lldb/trunk/utils/TableGen/LLDBOptionDefEmitter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/utils/TableGen/LLDBOptionDefEmitter.cpp?rev=367102=367101=367102=diff

[Lldb-commits] [PATCH] D65293: Document the fact that LLDB_LOG uses llvm::format_providers

[Pavel Labath via Phabricator via lldb-commits]

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

I think this is the best place to put that comment. Your lines are longer than 
80 chars though. :)


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D65293



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

[Lldb-commits] [PATCH] D65230: [CMake] Loosen Python version check and ignore patch version

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Thanks.

BTW, I tried this on windows, and it didn't blow up in my face, I think it 
should be relatively safe. I couldn't reproduce the problems that @amccarth was 
experiencing, so I don't know if it fixes that problem. It would be good to 
know whether it does, as we could cherry-pick this to the release branch in 
that case.


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

https://reviews.llvm.org/D65230



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

[Lldb-commits] [PATCH] D65282: ObjectFileELF: permit thread-local sections with overlapping file addresses

[Pavel Labath via Phabricator via lldb-commits]

labath updated this revision to Diff 211904.
labath added a comment.

Split the test into two


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

https://reviews.llvm.org/D65282

Files:
  lit/Modules/ELF/PT_LOAD-overlap-PT_TLS.yaml
  lit/Modules/ELF/PT_TLS-overlap-PT_LOAD.yaml
  source/Core/Section.cpp
  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp

Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1714,6 +1714,8 @@
   VMMap Segments = VMMap(Alloc);
   VMMap Sections = VMMap(Alloc);
   lldb_private::Log *Log = GetLogIfAllCategoriesSet(LIBLLDB_LOG_MODULES);
+  size_t SegmentCount = 0;
+  std::string SegmentName;
 
   VMRange GetVMRange(const ELFSectionHeader ) {
 addr_t Address = H.sh_addr;
@@ -1728,18 +1730,23 @@
   }
 
 public:
-  VMAddressProvider(ObjectFile::Type Type) : ObjectType(Type) {}
+  VMAddressProvider(ObjectFile::Type Type, llvm::StringRef SegmentName)
+  : ObjectType(Type), SegmentName(SegmentName) {}
+
+  std::string GetNextSegmentName() const {
+return llvm::formatv("{0}[{1}]", SegmentName, SegmentCount).str();
+  }
 
   llvm::Optional GetAddressInfo(const ELFProgramHeader ) {
 if (H.p_memsz == 0) {
-  LLDB_LOG(Log,
-   "Ignoring zero-sized PT_LOAD segment. Corrupt object file?");
+  LLDB_LOG(Log, "Ignoring zero-sized {0} segment. Corrupt object file?",
+   SegmentName);
   return llvm::None;
 }
 
 if (Segments.overlaps(H.p_vaddr, H.p_vaddr + H.p_memsz)) {
-  LLDB_LOG(Log,
-   "Ignoring overlapping PT_LOAD segment. Corrupt object file?");
+  LLDB_LOG(Log, "Ignoring overlapping {0} segment. Corrupt object file?",
+   SegmentName);
   return llvm::None;
 }
 return VMRange(H.p_vaddr, H.p_memsz);
@@ -1774,6 +1781,7 @@
 
   void AddSegment(const VMRange , SectionSP Seg) {
 Segments.insert(Range.GetRangeBase(), Range.GetRangeEnd(), std::move(Seg));
+++SegmentCount;
   }
 
   void AddSection(SectionAddressInfo Info, SectionSP Sect) {
@@ -1792,28 +1800,31 @@
 return;
 
   m_sections_up = llvm::make_unique();
-  VMAddressProvider address_provider(GetType());
+  VMAddressProvider regular_provider(GetType(), "PT_LOAD");
+  VMAddressProvider tls_provider(GetType(), "PT_TLS");
 
-  size_t LoadID = 0;
   for (const auto  : llvm::enumerate(ProgramHeaders())) {
 const ELFProgramHeader  = EnumPHdr.value();
-if (PHdr.p_type != PT_LOAD)
+if (PHdr.p_type != PT_LOAD && PHdr.p_type != PT_TLS)
   continue;
 
-auto InfoOr = address_provider.GetAddressInfo(PHdr);
+VMAddressProvider  =
+PHdr.p_type == PT_TLS ? tls_provider : regular_provider;
+auto InfoOr = provider.GetAddressInfo(PHdr);
 if (!InfoOr)
   continue;
 
-ConstString Name(("PT_LOAD[" + llvm::Twine(LoadID++) + "]").str());
 uint32_t Log2Align = llvm::Log2_64(std::max(PHdr.p_align, 1));
 SectionSP Segment = std::make_shared(
-GetModule(), this, SegmentID(EnumPHdr.index()), Name,
-eSectionTypeContainer, InfoOr->GetRangeBase(), InfoOr->GetByteSize(),
-PHdr.p_offset, PHdr.p_filesz, Log2Align, /*flags*/ 0);
+GetModule(), this, SegmentID(EnumPHdr.index()),
+ConstString(provider.GetNextSegmentName()), eSectionTypeContainer,
+InfoOr->GetRangeBase(), InfoOr->GetByteSize(), PHdr.p_offset,
+PHdr.p_filesz, Log2Align, /*flags*/ 0);
 Segment->SetPermissions(GetPermissions(PHdr));
+Segment->SetIsThreadSpecific(PHdr.p_type == PT_TLS);
 m_sections_up->AddSection(Segment);
 
-address_provider.AddSegment(*InfoOr, std::move(Segment));
+provider.AddSegment(*InfoOr, std::move(Segment));
   }
 
   ParseSectionHeaders();
@@ -1828,7 +1839,9 @@
 const uint64_t file_size =
 header.sh_type == SHT_NOBITS ? 0 : header.sh_size;
 
-auto InfoOr = address_provider.GetAddressInfo(header);
+VMAddressProvider  =
+header.sh_flags & SHF_TLS ? tls_provider : regular_provider;
+auto InfoOr = provider.GetAddressInfo(header);
 if (!InfoOr)
   continue;
 
@@ -1859,7 +1872,7 @@
 section_sp->SetIsThreadSpecific(header.sh_flags & SHF_TLS);
 (InfoOr->Segment ? InfoOr->Segment->GetChildren() : *m_sections_up)
 .AddSection(section_sp);
-address_provider.AddSection(std::move(*InfoOr), std::move(section_sp));
+provider.AddSection(std::move(*InfoOr), std::move(section_sp));
   }
 
   // For eTypeDebugInfo files, the Symbol Vendor will take care of updating the
Index: source/Core/Section.cpp
===
--- source/Core/Section.cpp
+++ source/Core/Section.cpp
@@ -269,7 +269,7 @@
 
 bool Section::ContainsFileAddress(addr_t vm_addr) const {
   const addr_t file_addr = GetFileAddress();
-  if (file_addr != LLDB_INVALID_ADDRESS) {
+  if (file_addr != 

[Lldb-commits] [PATCH] D65282: ObjectFileELF: permit thread-local sections with overlapping file addresses

[Pavel Labath via Phabricator via lldb-commits]

labath marked 2 inline comments as done.
labath added a comment.

In D65282#1602244 , @MaskRay wrote:

> > Are you referring to the "image lookup" command specifically, or is it a 
> > more general question about the internals of lldb too?
>
> Both:) This patch doesn't change the `Address: a.o[0x1010] 
> (a.o.PT_LOAD[0]..tdata + 0)` output so I was puzzled what this patch intends 
> to do.


What do you mean by "doesn't change"? After this patch the addresses always 
resolve to the .data section..

> 
> 
>> However, I can see how it might be interesting to be able to see the initial 
>> value of a thread local variable much like we can display the initial value 
>> of a global variable without launching a process. For this case, a flag to 
>> Section::ContainsFileAddress saying "yes, I want to look up in thread-local 
>> sections now" would suffice, but I don't know if this is the only use case...
> 
> Yes, inspecting the initial value of a thread-local variable is a use case. 
> To that end, can this be done by introducing another member variable instead 
> of overloading `m_sections_up` with a new purpose (adding `PT_TLS`)? If 
> PT_TLS is recorded in a different variable, the change below can be deleted.

I think that would be pretty significant departure from the current design of 
lldb. Lldb expects that the "section list" of a module will contain all of the 
module's sections (and before I started messing with these functions, it did). 
This includes non-loadable sections like .debug_info et al. While one could 
concieve a world where tls sections are in a special "tls" section list, I am 
not sure this is actually useful -- if we're going to think of the tls 
addresses as address spaces, then its reasonable to have more than two address 
spaces one day (there are people interested in that), and so we couldn't have a 
fixed set of section lists.

> 
> 
>bool Section::ContainsFileAddress(addr_t vm_addr) const {
>  const addr_t file_addr = GetFileAddress();
>   -  if (file_addr != LLDB_INVALID_ADDRESS) {
>   +  if (file_addr != LLDB_INVALID_ADDRESS && !IsThreadSpecific()) {
> 
> 
> (An adjacent pair of PT_LOAD segments can load the same file contents, e.g. 
> PT_LOAD `[0x150, 0x1234)` and `[0x1234, 0x1800)` will transform to mmap calls 
> with ranges `[0, 0x2000)` and `[0x1000, 0x2000)` at runtime if the runtime 
> page size = 0x1000. They share one page in the file. If you ask what a 
> specific offset in the file is mapped to, there can be multiple PT_LOAD 
> segments (physical -> VMA is not unique). Fortunately the reverse mapping VMA 
> -> physical offset can be treated as unique in practice 
> (`[p_vaddr,p_vaddr+p_memsz)` ranges do not overlap).)

I am not 100% what you mean by this, but I think there's some confusion about 
names of things here. In lldb terms, a "file address" is the "load address, as 
it is written in the file. It is not the "physical offset within the file", 
which lldb calls "file offset". Unfortunately, this terminology has caused a 
lot of confusion in the past, but I don't know what would be the best way to 
resolve this. How does lld call these things? I guess there's less confusion 
there as lld does not have to care about real, memory, load addresses...




Comment at: lit/Modules/ELF/PT_LOAD-overlap-PT_TLS.yaml:68
+Flags:   [ SHF_ALLOC, SHF_WRITE, SHF_TLS ]
+Address: 0x1010
+AddressAlign:0x4

MaskRay wrote:
> labath wrote:
> > MaskRay wrote:
> > > > .tbss 0x1000 NOBITS
> > > >
> > > > .tdata 0x1010 PROGBITS
> > > 
> > > Move .tdata before .tbss (0xff0) to make the example more realistic?
> > > 
> > > .tdata has a larger address than .tbss. I think this is impossible in 
> > > ld.bfd, but you can make .tbss go before .tdata with a broken lld linker 
> > > script.
> > I'll change the order here. The thing I was trying to test here is that 
> > addresses in .data are found regardless of whether it comes before or after 
> > a tls section. I think already having two TLS segments is somewhat 
> > unrealistic, and I could make it more real by splitting this into two 
> > tests, but it did not seem necessary, as lldb does not care about details 
> > like this.
> Multiple PT_TLS is unrealistic. None of glibc/musl/FreeBSD rtld supports more 
> than 1 PT_TLS (they will just pick the last one and ignore the others).
Ok, so let's go for two tests then.



Comment at: lit/Modules/ELF/PT_LOAD-overlap-PT_TLS.yaml:62
+Flags:   [ SHF_ALLOC, SHF_WRITE ]
+Address: 0x1000
+AddressAlign:0x4

MaskRay wrote:
> `.data = .tbss = 0x1010` is a more realistic scenario.
> 
> Normally, a SHT_PROGBITS section may overlap with a SHT_NOBITS section, but 
> two SHT_PROGBITS sections do not overlap (ld has an on-by-default check `ld 
> --check-sections`). Linkers allocate file bytes for SHT_PROGBITS sections so 
> their 

[Lldb-commits] [PATCH] D65282: ObjectFileELF: permit thread-local sections with overlapping file addresses

[Fangrui Song via Phabricator via lldb-commits]

MaskRay added inline comments.



Comment at: lit/Modules/ELF/PT_LOAD-overlap-PT_TLS.yaml:62
+Flags:   [ SHF_ALLOC, SHF_WRITE ]
+Address: 0x1000
+AddressAlign:0x4

`.data = .tbss = 0x1010` is a more realistic scenario.

Normally, a SHT_PROGBITS section may overlap with a SHT_NOBITS section, but two 
SHT_PROGBITS sections do not overlap (ld has an on-by-default check `ld 
--check-sections`). Linkers allocate file bytes for SHT_PROGBITS sections so 
their occupied bytes cannot be reused by other sections (without fixing 
addresses with a linker script).


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

https://reviews.llvm.org/D65282



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

[Lldb-commits] [PATCH] D65282: ObjectFileELF: permit thread-local sections with overlapping file addresses

[Fangrui Song via Phabricator via lldb-commits]

MaskRay added a comment.

> Are you referring to the "image lookup" command specifically, or is it a more 
> general question about the internals of lldb too?

Both:) This patch doesn't change the `Address: a.o[0x1010] 
(a.o.PT_LOAD[0]..tdata + 0)` output so I was puzzled what this patch intends to 
do.

> However, I can see how it might be interesting to be able to see the initial 
> value of a thread local variable much like we can display the initial value 
> of a global variable without launching a process. For this case, a flag to 
> Section::ContainsFileAddress saying "yes, I want to look up in thread-local 
> sections now" would suffice, but I don't know if this is the only use case...

Yes, inspecting the initial value of a thread-local variable is a use case. To 
that end, can this be done by introducing another member variable instead of 
overloading `m_sections_up` with a new purpose (adding `PT_TLS`)? If PT_TLS is 
recorded in a different variable, the change below can be deleted.

   bool Section::ContainsFileAddress(addr_t vm_addr) const {
 const addr_t file_addr = GetFileAddress();
  -  if (file_addr != LLDB_INVALID_ADDRESS) {
  +  if (file_addr != LLDB_INVALID_ADDRESS && !IsThreadSpecific()) {

(An adjacent pair of PT_LOAD segments can load the same file contents, e.g. 
PT_LOAD `[0x150, 0x1234)` and `[0x1234, 0x1800)` will transform to mmap calls 
with ranges `[0, 0x2000)` and `[0x1000, 0x2000)` at runtime if the runtime page 
size = 0x1000. They share one page in the file. If you ask what a specific 
offset in the file is mapped to, there can be multiple PT_LOAD segments 
(physical -> VMA is not unique). Fortunately the reverse mapping VMA -> 
physical offset can be treated as unique in practice 
(`[p_vaddr,p_vaddr+p_memsz)` ranges do not overlap).)




Comment at: lit/Modules/ELF/PT_LOAD-overlap-PT_TLS.yaml:68
+Flags:   [ SHF_ALLOC, SHF_WRITE, SHF_TLS ]
+Address: 0x1010
+AddressAlign:0x4

labath wrote:
> MaskRay wrote:
> > > .tbss 0x1000 NOBITS
> > >
> > > .tdata 0x1010 PROGBITS
> > 
> > Move .tdata before .tbss (0xff0) to make the example more realistic?
> > 
> > .tdata has a larger address than .tbss. I think this is impossible in 
> > ld.bfd, but you can make .tbss go before .tdata with a broken lld linker 
> > script.
> I'll change the order here. The thing I was trying to test here is that 
> addresses in .data are found regardless of whether it comes before or after a 
> tls section. I think already having two TLS segments is somewhat unrealistic, 
> and I could make it more real by splitting this into two tests, but it did 
> not seem necessary, as lldb does not care about details like this.
Multiple PT_TLS is unrealistic. None of glibc/musl/FreeBSD rtld supports more 
than 1 PT_TLS (they will just pick the last one and ignore the others).


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

https://reviews.llvm.org/D65282



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

[Lldb-commits] [PATCH] D65282: ObjectFileELF: permit thread-local sections with overlapping file addresses

[Pavel Labath via Phabricator via lldb-commits]

labath updated this revision to Diff 211899.
labath marked 3 inline comments as done.
labath added a comment.

- update according to review comments


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

https://reviews.llvm.org/D65282

Files:
  lit/Modules/ELF/PT_LOAD-overlap-PT_TLS.yaml
  source/Core/Section.cpp
  source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp

Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -1772,6 +1772,8 @@
   VMMap Segments = VMMap(Alloc);
   VMMap Sections = VMMap(Alloc);
   lldb_private::Log *Log = GetLogIfAllCategoriesSet(LIBLLDB_LOG_MODULES);
+  size_t SegmentCount = 0;
+  std::string SegmentName;
 
   VMRange GetVMRange(const ELFSectionHeader ) {
 addr_t Address = H.sh_addr;
@@ -1786,18 +1788,23 @@
   }
 
 public:
-  VMAddressProvider(ObjectFile::Type Type) : ObjectType(Type) {}
+  VMAddressProvider(ObjectFile::Type Type, llvm::StringRef SegmentName)
+  : ObjectType(Type), SegmentName(SegmentName) {}
+
+  std::string GetNextSegmentName() const {
+return llvm::formatv("{0}[{1}]", SegmentName, SegmentCount).str();
+  }
 
   llvm::Optional GetAddressInfo(const ELFProgramHeader ) {
 if (H.p_memsz == 0) {
-  LLDB_LOG(Log,
-   "Ignoring zero-sized PT_LOAD segment. Corrupt object file?");
+  LLDB_LOG(Log, "Ignoring zero-sized {0} segment. Corrupt object file?",
+   SegmentName);
   return llvm::None;
 }
 
 if (Segments.overlaps(H.p_vaddr, H.p_vaddr + H.p_memsz)) {
-  LLDB_LOG(Log,
-   "Ignoring overlapping PT_LOAD segment. Corrupt object file?");
+  LLDB_LOG(Log, "Ignoring overlapping {0} segment. Corrupt object file?",
+   SegmentName);
   return llvm::None;
 }
 return VMRange(H.p_vaddr, H.p_memsz);
@@ -1832,6 +1839,7 @@
 
   void AddSegment(const VMRange , SectionSP Seg) {
 Segments.insert(Range.GetRangeBase(), Range.GetRangeEnd(), std::move(Seg));
+++SegmentCount;
   }
 
   void AddSection(SectionAddressInfo Info, SectionSP Sect) {
@@ -1850,28 +1858,31 @@
 return;
 
   m_sections_up = llvm::make_unique();
-  VMAddressProvider address_provider(GetType());
+  VMAddressProvider regular_provider(GetType(), "PT_LOAD");
+  VMAddressProvider tls_provider(GetType(), "PT_TLS");
 
-  size_t LoadID = 0;
   for (const auto  : llvm::enumerate(ProgramHeaders())) {
 const ELFProgramHeader  = EnumPHdr.value();
-if (PHdr.p_type != PT_LOAD)
+if (PHdr.p_type != PT_LOAD && PHdr.p_type != PT_TLS)
   continue;
 
-auto InfoOr = address_provider.GetAddressInfo(PHdr);
+VMAddressProvider  =
+PHdr.p_type == PT_TLS ? tls_provider : regular_provider;
+auto InfoOr = provider.GetAddressInfo(PHdr);
 if (!InfoOr)
   continue;
 
-ConstString Name(("PT_LOAD[" + llvm::Twine(LoadID++) + "]").str());
 uint32_t Log2Align = llvm::Log2_64(std::max(PHdr.p_align, 1));
 SectionSP Segment = std::make_shared(
-GetModule(), this, SegmentID(EnumPHdr.index()), Name,
-eSectionTypeContainer, InfoOr->GetRangeBase(), InfoOr->GetByteSize(),
-PHdr.p_offset, PHdr.p_filesz, Log2Align, /*flags*/ 0);
+GetModule(), this, SegmentID(EnumPHdr.index()),
+ConstString(provider.GetNextSegmentName()), eSectionTypeContainer,
+InfoOr->GetRangeBase(), InfoOr->GetByteSize(), PHdr.p_offset,
+PHdr.p_filesz, Log2Align, /*flags*/ 0);
 Segment->SetPermissions(GetPermissions(PHdr));
+Segment->SetIsThreadSpecific(PHdr.p_type == PT_TLS);
 m_sections_up->AddSection(Segment);
 
-address_provider.AddSegment(*InfoOr, std::move(Segment));
+provider.AddSegment(*InfoOr, std::move(Segment));
   }
 
   ParseSectionHeaders();
@@ -1886,7 +1897,9 @@
 const uint64_t file_size =
 header.sh_type == SHT_NOBITS ? 0 : header.sh_size;
 
-auto InfoOr = address_provider.GetAddressInfo(header);
+VMAddressProvider  =
+header.sh_flags & SHF_TLS ? tls_provider : regular_provider;
+auto InfoOr = provider.GetAddressInfo(header);
 if (!InfoOr)
   continue;
 
@@ -1917,7 +1930,7 @@
 section_sp->SetIsThreadSpecific(header.sh_flags & SHF_TLS);
 (InfoOr->Segment ? InfoOr->Segment->GetChildren() : *m_sections_up)
 .AddSection(section_sp);
-address_provider.AddSection(std::move(*InfoOr), std::move(section_sp));
+provider.AddSection(std::move(*InfoOr), std::move(section_sp));
   }
 
   // For eTypeDebugInfo files, the Symbol Vendor will take care of updating the
Index: source/Core/Section.cpp
===
--- source/Core/Section.cpp
+++ source/Core/Section.cpp
@@ -269,7 +269,7 @@
 
 bool Section::ContainsFileAddress(addr_t vm_addr) const {
   const addr_t file_addr = GetFileAddress();
-  if (file_addr != LLDB_INVALID_ADDRESS) {
+  if 

[Lldb-commits] [lldb] r367095 - Fix some "control reaches end of non-void function" warnings

[Pavel Labath via lldb-commits]

Author: labath
Date: Fri Jul 26 02:38:23 2019
New Revision: 367095

URL: http://llvm.org/viewvc/llvm-project?rev=367095=rev
Log:
Fix some "control reaches end of non-void function" warnings

Modified:
lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp

Modified: lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp?rev=367095=367094=367095=diff
==
--- lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp 
(original)
+++ lldb/trunk/source/Plugins/DynamicLoader/POSIX-DYLD/DYLDRendezvous.cpp Fri 
Jul 26 02:38:23 2019
@@ -240,6 +240,7 @@ bool DYLDRendezvous::UpdateSOEntriesFrom
   case eNoAction:
 return false;
   }
+  llvm_unreachable("Fully covered switch above!");
 }
 
 bool DYLDRendezvous::UpdateSOEntries() {
@@ -256,6 +257,7 @@ bool DYLDRendezvous::UpdateSOEntries() {
   case eNoAction:
 return false;
   }
+  llvm_unreachable("Fully covered switch above!");
 }
 
 bool DYLDRendezvous::FillSOEntryFromModuleInfo(


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

[Lldb-commits] [PATCH] D65282: ObjectFileELF: permit thread-local sections with overlapping file addresses

[Pavel Labath via Phabricator via lldb-commits]

labath marked an inline comment as done.
labath added a comment.

> Do you mind explaining more how you'd like to improve file-address-based 
> lookups for PT_TLS?

I don't have this fully thought through (I was hoping this would develop as use 
cases start showing up), but...

Are you referring to the "image lookup" command specifically, or is it a more 
general question about the internals of lldb too?

Regarding "image lookup", the simplest way would be to add a "--tls" flag to 
look in the "tls" address space. Or even a more generic "address space" flag, 
as there are people interested in more address spaces. Or, we could just change 
the command to find and display multiple matches. But then the test here would 
need to be changed, as my main interest is that the correct address is found 
when evaluating DW_OP_addr and friends -- the "image lookup" thing is just a 
proxy.

As for internal interfaces, I guess similar options would be possible, but 
there I'm even more fuzzy about which ones are better because I don't know what 
are the ways in which this may be used. I know that the DW_OP_form_tls_address 
lookup currently completely ignores the "file" addresses of the sections and 
just straight to "load" addresses and real memory. This is not completely 
surprising as you need a thread to see thread local data, and if you have a 
thread, you have a live process to query. However, I can see how it might be 
interesting to be able to see the initial value of a thread local variable much 
like we can display the initial value of a global variable without launching a 
process. For this case, a flag to `Section::ContainsFileAddress` saying "yes, I 
want to look up in thread-local sections now" would suffice, but I don't know 
if this is the only use case...




Comment at: lit/Modules/ELF/PT_LOAD-overlap-PT_TLS.yaml:68
+Flags:   [ SHF_ALLOC, SHF_WRITE, SHF_TLS ]
+Address: 0x1010
+AddressAlign:0x4

MaskRay wrote:
> > .tbss 0x1000 NOBITS
> >
> > .tdata 0x1010 PROGBITS
> 
> Move .tdata before .tbss (0xff0) to make the example more realistic?
> 
> .tdata has a larger address than .tbss. I think this is impossible in ld.bfd, 
> but you can make .tbss go before .tdata with a broken lld linker script.
I'll change the order here. The thing I was trying to test here is that 
addresses in .data are found regardless of whether it comes before or after a 
tls section. I think already having two TLS segments is somewhat unrealistic, 
and I could make it more real by splitting this into two tests, but it did not 
seem necessary, as lldb does not care about details like this.


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

https://reviews.llvm.org/D65282



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

[Lldb-commits] [PATCH] D65230: [CMake] Loosen Python version check and ignore patch version

[Stefan Gränitz via Phabricator via lldb-commits]

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

LGTM


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

https://reviews.llvm.org/D65230



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

[Lldb-commits] [lldb] r367090 - ObjectFileELF: Use llvm::JamCRC to refactor CRC32 computation

[Fangrui Song via lldb-commits]

Author: maskray
Date: Fri Jul 26 01:33:36 2019
New Revision: 367090

URL: http://llvm.org/viewvc/llvm-project?rev=367090=rev
Log:
ObjectFileELF: Use llvm::JamCRC to refactor CRC32 computation

Reviewed By: labath

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

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

Modified: lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp?rev=367090=367089=367090=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp Fri Jul 26 
01:33:36 2019
@@ -35,6 +35,7 @@
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Object/Decompressor.h"
 #include "llvm/Support/ARMBuildAttributes.h"
+#include "llvm/Support/JamCRC.h"
 #include "llvm/Support/MathExtras.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/MipsABIFlags.h"
@@ -428,67 +429,11 @@ bool ObjectFileELF::MagicBytesMatch(Data
   return false;
 }
 
-/*
- * crc function from http://svnweb.freebsd.org/base/head/sys/libkern/crc32.c
- *
- *   COPYRIGHT (C) 1986 Gary S. Brown. You may use this program, or
- *   code or tables extracted from it, as desired without restriction.
- */
-static uint32_t calc_crc32(uint32_t crc, const void *buf, size_t size) {
-  static const uint32_t g_crc32_tab[] = {
-  0x, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f,
-  0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
-  0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, 0x1db71064, 0x6ab020f2,
-  0xf3b97148, 0x84be41de, 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
-  0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9,
-  0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
-  0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, 0x35b5a8fa, 0x42b2986c,
-  0xdbbbc9d6, 0xacbcf940, 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
-  0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423,
-  0xcfba9599, 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
-  0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190, 0x01db7106,
-  0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
-  0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, 0x7f6a0dbb, 0x086d3d2d,
-  0x91646c97, 0xe6635c01, 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
-  0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950,
-  0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
-  0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, 0x4adfa541, 0x3dd895d7,
-  0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
-  0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9, 0x5005713c, 0x270241aa,
-  0xbe0b1010, 0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
-  0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17, 0x2eb40d81,
-  0xb7bd5c3b, 0xc0ba6cad, 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
-  0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683, 0xe3630b12, 0x94643b84,
-  0x0d6d6a3e, 0x7a6a5aa8, 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
-  0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb,
-  0x196c3671, 0x6e6b06e7, 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
-  0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5, 0xd6d6a3e8, 0xa1d1937e,
-  0x38d8c2c4, 0x4fdff252, 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
-  0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55,
-  0x316e8eef, 0x4669be79, 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
-  0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 0xc5ba3bbe, 0xb2bd0b28,
-  0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
-  0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, 0x9c0906a9, 0xeb0e363f,
-  0x72076785, 0x05005713, 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
-  0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, 0x86d3d2d4, 0xf1d4e242,
-  0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
-  0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, 0x8f659eff, 0xf862ae69,
-  0x616bffd3, 0x166ccf45, 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
-  0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, 0xaed16a4a, 0xd9d65adc,
-  0x40df0b66, 0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
-  0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605, 0xcdd70693,
-  0x54de5729, 0x23d967bf, 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
-  0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d};
-  const uint8_t *p = (const uint8_t *)buf;
-
-  crc = crc ^ ~0U;
-  while (size--)
-crc = g_crc32_tab[(crc ^ 

[Lldb-commits] [PATCH] D65122: [Symbol] Use llvm::Expected when getting TypeSystems

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D65122#1602067 , @JDevlieghere 
wrote:

> In D65122#1602025 , @xiaobai wrote:
>
> > After going through this and modifying this patch, I can't help but wonder 
> > if `llvm::Optional` would be more appropriate. There are 
> > plenty of instances where it's not a hard error if you can't get a 
> > TypeSystem and the appropriate action is probably just to log and move on. 
> > I am conflicted because I like how Expected forces you to be more rigorous 
> > with error handling but I can't help but feel it is the wrong abstraction. 
> > Thoughts?
>
>
> I think an `Optional` would be fine. We can always create an `Error` when 
> necessary, with the trade-off of being a little less precision about the root 
> cause, which honestly doesn't seem that informative anyway.


I'm not that familiar with type systems, so I don't know if an explicit error 
value is useful. Adopting Error/Expected initially has a slightly higher 
barrier because the surrounding code does not know about Errors, and so you 
have to do something explicit and verbose to the error, and then create a 
default value of the return type anyway. But, as the surrounding code adopts 
Errors, the verboseness should disappear. This, of course, assumes that we want 
to adopt Errors here and in the surrounding code.

What I am familiar with though is the `Optional` template, I can note that 
there is no such thing as an `Optional` (the Optional template does not 
play well with references). You could make that a thing, but an `Optional` 
is essentially just a `T *`, which is what we have now :D. And I wouldn't want 
`Optional` as that just creates more ambiguity.

Thinking ahead I am wondering if we could just arrange things such that the 
TypeSystem creation always succeeds. One day, I am hoping to arrange is so that 
a Module will always have an associated ObjectFile and a SymbolFile (by 
avoiding creating a Module if the ObjectFile construction fails, and creating 
an "empty" SymbolFile if needed). At that point being able to always create a 
type system would not seem unreasonable. I don't think any of this is directly 
relevant here and now, but it may speak against introducing Expected here (if 
you agree with my vision, that is).


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

https://reviews.llvm.org/D65122



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

[Lldb-commits] [PATCH] D65271: Increase testsuite packet-timeout 5secs -> 5mins

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D65271#1601717 , @jankratochvil 
wrote:

> In D65271#1600829 , @labath wrote:
>
> > Why not unify now? It shouldn't be too hard to at least unify all the 
> > instances in dotest python code to a single place. That would already cut 
> > the number of places that need to be kept synced in half...
>
>
> Done; but I do not like much that `from lldbsuite.test.lldbtest import Base` 
> in `vscode.py` but then other choices (passing `Base.setUpCommands()` from 
> callers) looks even more messy to me.


I think I'd go for threading it in from VSCodeTestCaseBase. Maybe not as an 
argument to `request_attach` and friends, but possibly as an argument to the 
`DebugCommunication` object constructor.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D65271



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

[Lldb-commits] [PATCH] D65282: ObjectFileELF: permit thread-local sections with overlapping file addresses

[Fangrui Song via Phabricator via lldb-commits]

MaskRay added inline comments.



Comment at: lit/Modules/ELF/PT_LOAD-overlap-PT_TLS.yaml:44
+# LOOKUP-LABEL: image lookup -a 0x1010
+# LOOKUP:   Address: {{.*}}.PT_LOAD[0]..data + 16)
+

Do you mind explaining more how you'd like to improve file-address-based 
lookups for PT_TLS?

> (lldb) image lookup -a 0x1010
>
>  Address: a.o[0x1010] (a.o.PT_LOAD[0]..tdata + 0)

This is the current output before the change.

Yes PT_TLS can be seen as a separate address space. At runtime a TLS block is 
allocated (mmap) for each thread and they access TLS through their thread 
pointer. The address will be very different from the PT_LOAD address.


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

https://reviews.llvm.org/D65282



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

[Lldb-commits] [PATCH] D65311: [dotest] Remove multiprocessing

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

Woohoo.


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

https://reviews.llvm.org/D65311



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

[Lldb-commits] [PATCH] D65208: SymbolVendor: Move Symtab construction into the SymbolFile

[Pavel Labath via Phabricator via lldb-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL367086: SymbolVendor: Move Symtab construction into the 
SymbolFile (authored by labath, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D65208

Files:
  lldb/trunk/include/lldb/Symbol/SymbolFile.h
  lldb/trunk/include/lldb/Symbol/SymbolVendor.h
  lldb/trunk/source/Symbol/SymbolFile.cpp
  lldb/trunk/source/Symbol/SymbolVendor.cpp
  lldb/trunk/unittests/Core/CMakeLists.txt
  lldb/trunk/unittests/Core/MangledTest.cpp
  lldb/trunk/unittests/ObjectFile/ELF/CMakeLists.txt
  lldb/trunk/unittests/ObjectFile/ELF/TestObjectFileELF.cpp
  lldb/trunk/unittests/Symbol/CMakeLists.txt
  lldb/trunk/unittests/Symbol/TestDWARFCallFrameInfo.cpp
  lldb/trunk/unittests/Target/CMakeLists.txt
  lldb/trunk/unittests/Target/ModuleCacheTest.cpp

Index: lldb/trunk/unittests/ObjectFile/ELF/TestObjectFileELF.cpp
===
--- lldb/trunk/unittests/ObjectFile/ELF/TestObjectFileELF.cpp
+++ lldb/trunk/unittests/ObjectFile/ELF/TestObjectFileELF.cpp
@@ -8,7 +8,7 @@
 //===--===//
 
 #include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
-#include "Plugins/SymbolVendor/ELF/SymbolVendorELF.h"
+#include "Plugins/SymbolFile/Symtab/SymbolFileSymtab.h"
 #include "TestingSupport/TestUtilities.h"
 #include "lldb/Core/Module.h"
 #include "lldb/Core/ModuleSpec.h"
@@ -34,11 +34,11 @@
 FileSystem::Initialize();
 HostInfo::Initialize();
 ObjectFileELF::Initialize();
-SymbolVendorELF::Initialize();
+SymbolFileSymtab::Initialize();
   }
 
   void TearDown() override {
-SymbolVendorELF::Terminate();
+SymbolFileSymtab::Terminate();
 ObjectFileELF::Terminate();
 HostInfo::Terminate();
 FileSystem::Terminate();
Index: lldb/trunk/unittests/ObjectFile/ELF/CMakeLists.txt
===
--- lldb/trunk/unittests/ObjectFile/ELF/CMakeLists.txt
+++ lldb/trunk/unittests/ObjectFile/ELF/CMakeLists.txt
@@ -3,7 +3,7 @@
 
   LINK_LIBS
 lldbPluginObjectFileELF
-lldbPluginSymbolVendorELF
+lldbPluginSymbolFileSymtab
 lldbCore
 lldbUtilityHelpers
 LLVMTestingSupport
Index: lldb/trunk/unittests/Symbol/TestDWARFCallFrameInfo.cpp
===
--- lldb/trunk/unittests/Symbol/TestDWARFCallFrameInfo.cpp
+++ lldb/trunk/unittests/Symbol/TestDWARFCallFrameInfo.cpp
@@ -11,6 +11,7 @@
 
 #include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
 #include "Plugins/Process/Utility/RegisterContext_x86.h"
+#include "Plugins/SymbolFile/Symtab/SymbolFileSymtab.h"
 #include "TestingSupport/TestUtilities.h"
 
 #include "lldb/Core/Module.h"
@@ -36,9 +37,11 @@
 FileSystem::Initialize();
 HostInfo::Initialize();
 ObjectFileELF::Initialize();
+SymbolFileSymtab::Initialize();
   }
 
   void TearDown() override {
+SymbolFileSymtab::Terminate();
 ObjectFileELF::Terminate();
 HostInfo::Terminate();
 FileSystem::Terminate();
Index: lldb/trunk/unittests/Symbol/CMakeLists.txt
===
--- lldb/trunk/unittests/Symbol/CMakeLists.txt
+++ lldb/trunk/unittests/Symbol/CMakeLists.txt
@@ -13,6 +13,7 @@
 lldbPluginObjectFileELF
 lldbPluginObjectFileMachO
 lldbPluginSymbolFileDWARF
+lldbPluginSymbolFileSymtab
 LLVMTestingSupport
   )
 
Index: lldb/trunk/unittests/Core/CMakeLists.txt
===
--- lldb/trunk/unittests/Core/CMakeLists.txt
+++ lldb/trunk/unittests/Core/CMakeLists.txt
@@ -9,7 +9,7 @@
 lldbHost
 lldbSymbol
 lldbPluginObjectFileELF
-lldbPluginSymbolVendorELF
+lldbPluginSymbolFileSymtab
 lldbUtilityHelpers
 LLVMTestingSupport
   LINK_COMPONENTS
Index: lldb/trunk/unittests/Core/MangledTest.cpp
===
--- lldb/trunk/unittests/Core/MangledTest.cpp
+++ lldb/trunk/unittests/Core/MangledTest.cpp
@@ -7,7 +7,7 @@
 //===--===//
 
 #include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
-#include "Plugins/SymbolVendor/ELF/SymbolVendorELF.h"
+#include "Plugins/SymbolFile/Symtab/SymbolFileSymtab.h"
 #include "TestingSupport/TestUtilities.h"
 
 #include "lldb/Core/Mangled.h"
@@ -54,7 +54,7 @@
   FileSystem::Initialize();
   HostInfo::Initialize();
   ObjectFileELF::Initialize();
-  SymbolVendorELF::Initialize();
+  SymbolFileSymtab::Initialize();
 
   llvm::SmallString<128> Obj;
   ASSERT_NO_ERROR(llvm::sys::fs::createTemporaryFile(
@@ -146,7 +146,7 @@
   EXPECT_EQ(0, Count("undemangable", eFunctionNameTypeBase));
   EXPECT_EQ(0, Count("undemangable", eFunctionNameTypeMethod));
 
-  

[Lldb-commits] [lldb] r367086 - SymbolVendor: Move Symtab construction into the SymbolFile

[Pavel Labath via lldb-commits]

Author: labath
Date: Fri Jul 26 00:03:28 2019
New Revision: 367086

URL: http://llvm.org/viewvc/llvm-project?rev=367086=rev
Log:
SymbolVendor: Move Symtab construction into the SymbolFile

Summary:
Instead of having SymbolVendor coordinate Symtab construction between
Symbol and Object files, make the SymbolVendor function a passthrough,
and put all of the logic into the SymbolFile.

Reviewers: clayborg, JDevlieghere, jingham, espindola

Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits

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

Modified:
lldb/trunk/include/lldb/Symbol/SymbolFile.h
lldb/trunk/include/lldb/Symbol/SymbolVendor.h
lldb/trunk/source/Symbol/SymbolFile.cpp
lldb/trunk/source/Symbol/SymbolVendor.cpp
lldb/trunk/unittests/Core/CMakeLists.txt
lldb/trunk/unittests/Core/MangledTest.cpp
lldb/trunk/unittests/ObjectFile/ELF/CMakeLists.txt
lldb/trunk/unittests/ObjectFile/ELF/TestObjectFileELF.cpp
lldb/trunk/unittests/Symbol/CMakeLists.txt
lldb/trunk/unittests/Symbol/TestDWARFCallFrameInfo.cpp
lldb/trunk/unittests/Target/CMakeLists.txt
lldb/trunk/unittests/Target/ModuleCacheTest.cpp

Modified: lldb/trunk/include/lldb/Symbol/SymbolFile.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/SymbolFile.h?rev=367086=367085=367086=diff
==
--- lldb/trunk/include/lldb/Symbol/SymbolFile.h (original)
+++ lldb/trunk/include/lldb/Symbol/SymbolFile.h Fri Jul 26 00:03:28 2019
@@ -114,6 +114,8 @@ public:
   uint32_t GetNumCompileUnits();
   lldb::CompUnitSP GetCompileUnitAtIndex(uint32_t idx);
 
+  Symtab *GetSymtab();
+
   virtual lldb::LanguageType ParseLanguage(CompileUnit _unit) = 0;
   virtual size_t ParseFunctions(CompileUnit _unit) = 0;
   virtual bool ParseLineTable(CompileUnit _unit) = 0;
@@ -246,6 +248,7 @@ protected:
   ObjectFile *m_obj_file; // The object file that symbols can be extracted 
from.
   llvm::Optional> m_compile_units;
   TypeList m_type_list;
+  Symtab *m_symtab = nullptr;
   uint32_t m_abilities;
   bool m_calculated_abilities;
 

Modified: lldb/trunk/include/lldb/Symbol/SymbolVendor.h
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/SymbolVendor.h?rev=367086=367085=367086=diff
==
--- lldb/trunk/include/lldb/Symbol/SymbolVendor.h (original)
+++ lldb/trunk/include/lldb/Symbol/SymbolVendor.h Fri Jul 26 00:03:28 2019
@@ -121,9 +121,6 @@ public:
   // Get module unified section list symbol table.
   virtual Symtab *GetSymtab();
 
-  // Clear module unified section list symbol table.
-  virtual void ClearSymtab();
-
   /// Notify the SymbolVendor that the file addresses in the Sections
   /// for this module have been changed.
   virtual void SectionFileAddressesChanged();
@@ -140,8 +137,6 @@ protected:
// file)
   std::unique_ptr m_sym_file_up; // A single symbol file. 
Subclasses
  // can add more of these if 
needed.
-  Symtab *m_symtab; // Save a symtab once to not pass it through `AddSymbols` 
of
-// the symbol file each time when it is needed
 
 private:
   // For SymbolVendor only

Modified: lldb/trunk/source/Symbol/SymbolFile.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/SymbolFile.cpp?rev=367086=367085=367086=diff
==
--- lldb/trunk/source/Symbol/SymbolFile.cpp (original)
+++ lldb/trunk/source/Symbol/SymbolFile.cpp Fri Jul 26 00:03:28 2019
@@ -200,6 +200,21 @@ void SymbolFile::SetCompileUnitAtIndex(u
   (*m_compile_units)[idx] = cu_sp;
 }
 
+Symtab *SymbolFile::GetSymtab() {
+  std::lock_guard guard(GetModuleMutex());
+  if (m_symtab)
+return m_symtab;
+
+  // Fetch the symtab from the main object file.
+  m_symtab = m_obj_file->GetModule()->GetObjectFile()->GetSymtab();
+
+  // Then add our symbols to it.
+  if (m_symtab)
+AddSymbols(*m_symtab);
+
+  return m_symtab;
+}
+
 void SymbolFile::Dump(Stream ) {
   s.PutCString("Types:\n");
   m_type_list.Dump(, /*show_context*/ false);

Modified: lldb/trunk/source/Symbol/SymbolVendor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Symbol/SymbolVendor.cpp?rev=367086=367085=367086=diff
==
--- lldb/trunk/source/Symbol/SymbolVendor.cpp (original)
+++ lldb/trunk/source/Symbol/SymbolVendor.cpp Fri Jul 26 00:03:28 2019
@@ -58,7 +58,7 @@ SymbolVendor *SymbolVendor::FindPlugin(c
 
 // SymbolVendor constructor
 SymbolVendor::SymbolVendor(const lldb::ModuleSP _sp)
-: ModuleChild(module_sp), m_sym_file_up(), m_symtab() {}
+: ModuleChild(module_sp), m_sym_file_up() {}
 
 // Destructor
 SymbolVendor::~SymbolVendor() {}
@@ -384,35 +384,9 @@ FileSpec SymbolVendor::GetMainFileSpec()
 }
 
 

[Lldb-commits] [PATCH] D62931: [lldb-server] Add setting to force 'g' packet use

[Pavel Labath via Phabricator via lldb-commits]

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

LGTM. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62931



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

[Lldb-commits] [PATCH] D65282: ObjectFileELF: permit thread-local sections with overlapping file addresses

[Fangrui Song via Phabricator via lldb-commits]

MaskRay added a comment.

> It turns out this was too aggressive because thread-local

sections typically will have file addresses which apear to overlap
regular data/code. This does not cause a problem at runtime because
thread-local sections are loaded into memory using special logic, but it
can cause problems for lldb when trying to lookup objects by their file
address.

Yes :) This can happen with .tbss (SHT_NOBITS) overlapping another section 
(usually .fini_array, but .got and .data are also possible).




Comment at: lit/Modules/ELF/PT_LOAD-overlap-PT_TLS.yaml:68
+Flags:   [ SHF_ALLOC, SHF_WRITE, SHF_TLS ]
+Address: 0x1010
+AddressAlign:0x4

> .tbss 0x1000 NOBITS
>
> .tdata 0x1010 PROGBITS

Move .tdata before .tbss (0xff0) to make the example more realistic?

.tdata has a larger address than .tbss. I think this is impossible in ld.bfd, 
but you can make .tbss go before .tdata with a broken lld linker script.


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

https://reviews.llvm.org/D65282



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