Re: [Lldb-commits] [lldb] r348319 - [build.py] Disable tests on non-Windows.

[Pavel Labath via lldb-commits]

On 05/12/2018 00:56, Zachary Turner via lldb-commits wrote:

Author: zturner
Date: Tue Dec  4 15:56:25 2018
New Revision: 348319

URL: http://llvm.org/viewvc/llvm-project?rev=348319&view=rev
Log:
[build.py] Disable tests on non-Windows.

This won't work until we get the GCC / clang builder implemented.

Modified:
 lldb/trunk/lit/BuildScript/modes.test
 lldb/trunk/lit/BuildScript/script-args.test

Modified: lldb/trunk/lit/BuildScript/modes.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/BuildScript/modes.test?rev=348319&r1=348318&r2=348319&view=diff
==
--- lldb/trunk/lit/BuildScript/modes.test (original)
+++ lldb/trunk/lit/BuildScript/modes.test Tue Dec  4 15:56:25 2018
@@ -1,3 +1,5 @@
+REQUIRES: system-windows
+
  RUN: %build -n --verbose --arch=32 --mode=compile --compiler=any -o 
%t/foo.out foobar.c \
  RUN:| FileCheck --check-prefix=COMPILE %s
  


Modified: lldb/trunk/lit/BuildScript/script-args.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/BuildScript/script-args.test?rev=348319&r1=348318&r2=348319&view=diff
==
--- lldb/trunk/lit/BuildScript/script-args.test (original)
+++ lldb/trunk/lit/BuildScript/script-args.test Tue Dec  4 15:56:25 2018
@@ -1,3 +1,5 @@
+REQUIRES: system-windows
+
  RUN: %build -n --verbose --arch=32 --mode=compile --compiler=any -o 
%t/foo.out foobar.c \
  RUN:| FileCheck %s
  RUN: %build -n --verbose --arch=32 --mode=compile --compiler=any --outdir %t 
foo.c bar.c \


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



The toolchain-clang-cl.test fails for me too during printing of the 
execution environment for the compile commands. This happens because 
(unsurprisingly) we cannot find the VS installation, and the environment 
happens to be None.



Traceback (most recent call last):
  File "/home/pavelo/ll/lldb/lit/helper/build.py", line 723, in 
build(cmds)
  File "/home/pavelo/ll/lldb/lit/helper/build.py", line 621, in build
print_environment(env)
  File "/home/pavelo/ll/lldb/lit/helper/build.py", line 154, in 
print_environment

for e in env:
TypeError: 'NoneType' object is not iterable

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

[Lldb-commits] [PATCH] D55214: Introduce ObjectFileBreakpad

[Pavel Labath via Phabricator via lldb-commits]

labath updated this revision to Diff 176781.
labath marked 17 inline comments as done.
labath added a comment.

Updated according to review comments.

Also added a couple of tests for invalid inputs.


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

https://reviews.llvm.org/D55214

Files:
  include/lldb/Symbol/ObjectFile.h
  lit/Modules/Breakpad/Inputs/bad-module-id-1.syms
  lit/Modules/Breakpad/Inputs/bad-module-id-2.syms
  lit/Modules/Breakpad/Inputs/bad-module-id-3.syms
  lit/Modules/Breakpad/Inputs/identification-linux.syms
  lit/Modules/Breakpad/Inputs/identification-macosx.syms
  lit/Modules/Breakpad/Inputs/identification-windows.syms
  lit/Modules/Breakpad/breakpad-identification.test
  lit/Modules/Breakpad/lit.local.cfg
  source/API/SystemInitializerFull.cpp
  source/Plugins/ObjectFile/Breakpad/CMakeLists.txt
  source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.cpp
  source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.h
  source/Plugins/ObjectFile/CMakeLists.txt
  source/Symbol/ObjectFile.cpp
  tools/lldb-test/SystemInitializerTest.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
@@ -724,6 +724,14 @@
 ModuleSpec Spec{FileSpec(File)};
 
 auto ModulePtr = std::make_shared(Spec);
+
+ObjectFile *ObjectPtr = ModulePtr->GetObjectFile();
+if (!ObjectPtr) {
+  WithColor::error() << File << " not recognised as an object file\n";
+  HadErrors = 1;
+  continue;
+}
+
 // Fetch symbol vendor before we get the section list to give the symbol
 // vendor a chance to populate it.
 ModulePtr->GetSymbolVendor();
@@ -734,9 +742,14 @@
   continue;
 }
 
+Printer.formatLine("Plugin name: {0}", ObjectPtr->GetPluginName());
 Printer.formatLine("Architecture: {0}",
ModulePtr->GetArchitecture().GetTriple().getTriple());
 Printer.formatLine("UUID: {0}", ModulePtr->GetUUID().GetAsString());
+Printer.formatLine("Executable: {0}", ObjectPtr->IsExecutable());
+Printer.formatLine("Stripped: {0}", ObjectPtr->IsStripped());
+Printer.formatLine("Type: {0}", ObjectPtr->GetType());
+Printer.formatLine("Strata: {0}", ObjectPtr->GetStrata());
 
 size_t Count = Sections->GetNumSections(0);
 Printer.formatLine("Showing {0} sections", Count);
Index: tools/lldb-test/SystemInitializerTest.cpp
===
--- tools/lldb-test/SystemInitializerTest.cpp
+++ tools/lldb-test/SystemInitializerTest.cpp
@@ -52,6 +52,7 @@
 #include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h"
 #include "Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h"
 #include "Plugins/MemoryHistory/asan/MemoryHistoryASan.h"
+#include "Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.h"
 #include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
 #include "Plugins/ObjectFile/Mach-O/ObjectFileMachO.h"
 #include "Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h"
@@ -116,6 +117,7 @@
   if (auto e = SystemInitializerCommon::Initialize(options))
 return e;
 
+  breakpad::ObjectFileBreakpad::Initialize();
   ObjectFileELF::Initialize();
   ObjectFileMachO::Initialize();
   ObjectFilePECOFF::Initialize();
@@ -331,6 +333,7 @@
   PlatformDarwinKernel::Terminate();
 #endif
 
+  breakpad::ObjectFileBreakpad::Terminate();
   ObjectFileELF::Terminate();
   ObjectFileMachO::Terminate();
   ObjectFilePECOFF::Terminate();
Index: source/Symbol/ObjectFile.cpp
===
--- source/Symbol/ObjectFile.cpp
+++ source/Symbol/ObjectFile.cpp
@@ -688,3 +688,63 @@
  uint64_t Offset) {
   return FileSystem::Instance().CreateDataBuffer(file.GetPath(), Size, Offset);
 }
+
+void llvm::format_provider::format(
+const ObjectFile::Type &type, raw_ostream &OS, StringRef Style) {
+  switch (type) {
+  case ObjectFile::eTypeInvalid:
+OS << "invalid";
+break;
+  case ObjectFile::eTypeCoreFile:
+OS << "core file";
+break;
+  case ObjectFile::eTypeExecutable:
+OS << "executable";
+break;
+  case ObjectFile::eTypeDebugInfo:
+OS << "debug info";
+break;
+  case ObjectFile::eTypeDynamicLinker:
+OS << "dynamic linker";
+break;
+  case ObjectFile::eTypeObjectFile:
+OS << "object file";
+break;
+  case ObjectFile::eTypeSharedLibrary:
+OS << "shared library";
+break;
+  case ObjectFile::eTypeStubLibrary:
+OS << "stub library";
+break;
+  case ObjectFile::eTypeJIT:
+OS << "jit";
+break;
+  case ObjectFile::eTypeUnknown:
+OS << "unknown";
+break;
+  }
+}
+
+void llvm::format_provider::format(
+const ObjectFile::Strata &strata, raw_ostream &OS, StringRef Style) {
+  switch (strata) {
+  case ObjectFile::eStrataInvalid:
+OS << "invalid";
+break;
+  case ObjectF

[Lldb-commits] [PATCH] D55214: Introduce ObjectFileBreakpad

[Pavel Labath via Phabricator via lldb-commits]

labath added inline comments.



Comment at: lit/Modules/Breakpad/lit.local.cfg:1
+config.suffixes = ['.test']

zturner wrote:
> This shouldn't be necessary, the top-level `lit.cfg.py` already recognizes 
> `.test` extension.  You only need a lit.local.cfg if you're changing 
> something.
Yes, but then `lit/Modules/lit.local.cfg` overrides it by specifying it's own 
list of suffixes. I could fix that by adding `.test.` to that file, or by 
making that file use `+=`, but it's not clear to me whether that is better than 
just being explicit here.

If you have any preference, let me know.



Comment at: source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.cpp:20-43
+static llvm::Triple::OSType toOS(llvm::StringRef str) {
+  using llvm::Triple;
+  return llvm::StringSwitch(str)
+  .Case("Linux", Triple::Linux)
+  .Case("mac", Triple::MacOSX)
+  .Case("windows", Triple::Win32)
+  .Default(Triple::UnknownOS);

zturner wrote:
> LLVM already has these functions in `Triple.cpp`, but they are hidden as 
> private implementations in the CPP file.  Perhaps we should expose them from 
> headers in Triple.h.
I've already checked out the available functions in `llvm::Triple`, and 
unfortunately each of them uses a slightly different form for some of the 
values. For example, `getArchTypeNameForLLVMName` uses `x86-64` instead of 
`x86_64`, `parseArch` uses `i386` instead of `x86`, `parseOS` uses `linux` 
instead of `Linux`, and so on...

Since this particular encoding is specific to the breakpad format, it made 
sense to me to have the parsing functions live here (as opposed to adding new 
cases to the `Triple` functions for instance), and leave everything else 
working with the "canonical" forms.



Comment at: source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.cpp:53
+  static_assert(sizeof(data) == 20, "");
+  if (str.size() < 33 || str.size() > 40)
+return UUID();

lemo wrote:
> these magic integer literals make it hard to follow the intent - what's 
> special about 33, 40, 8, 16, ... ? (symbolic constants might help)
I've rewritten this to gradually chop bytes off from the start of the string, 
instead of always indexing into the original one. That should reduce the number 
of magic numbers (and hopefully reduce confusion).



Comment at: source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.cpp:56-59
+  if (to_integer(str.substr(0, 8), t, 16))
+data.uuid1 = t;
+  else
+return UUID();

zturner wrote:
> Consider using `StringRef::consumeInteger()` here.
I don't think consumeInteger can help, as these "fields" are not delimited here 
in any way, so that function will happily try to parse the whole string. If you 
had a specific patter in mind let me know (but hopefully the new implementation 
won't be so bad either).



Comment at: source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.cpp:160-161
+  }
+  llvm::StringRef text(reinterpret_cast(data_sp->GetBytes()),
+   data_sp->GetByteSize());
+

zturner wrote:
> We have `GetData()` which returns an `ArrayRef`, and another function 
> `toStringRef` which converts an `ArrayRef` to a `StringRef`.  So this might 
> be cleaner to write as `auto text = llvm::toStringRef(data_sp->GetData());`
Cool, I didn't know about that. Thanks.



Comment at: source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.h:74
+
+  bool IsStripped() override { return false; }
+

zturner wrote:
> Is this always true for breakpad files?
Well.. the whole point of these files is to provide symbol information, so it 
would be weird if they were stripped. The breakpad `dump_syms` allows you to 
omit generating unwind information, but I don't think that's enough to call 
this "stripped". It is certainly possible to create a file by hand which 
contains just a `MODULE` directive and nothing else, but I would say that is a 
(non-stripped) file which describes an empty module, and not a stripped file.

In reality, this doesn't really matter, as this function is called from just 
one place 
, 
and I don't think that will be relevant for breakpad files.



Comment at: source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.h:98
+
+private:
+  struct Header {

zturner wrote:
> lemo wrote:
> > Nit: I personally prefer not to mix data, type and function members in the 
> > same "access" section - is there an LLVM/LLDB guideline which requires 
> > everything in the same place?
> > 
> > If not, can you please add a private section for the destructor, followed 
> > by a section for the private data members?
> Given that we don't actually store an instance of the header anywhere, we 
> just use it as a constructor parameter, perhaps we could go one step further 
> and move

[Lldb-commits] [lldb] r348360 - [CMake] Fix side-effect from LLDB_VERSION change in r346668 for framework-enabled builds

[Stefan Granitz via lldb-commits]

Author: stefan.graenitz
Date: Wed Dec  5 04:18:44 2018
New Revision: 348360

URL: http://llvm.org/viewvc/llvm-project?rev=348360&view=rev
Log:
[CMake] Fix side-effect from LLDB_VERSION change in r346668 for 
framework-enabled builds

Modified:
lldb/trunk/CMakeLists.txt
lldb/trunk/cmake/modules/LLDBFramework.cmake

Modified: lldb/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/CMakeLists.txt?rev=348360&r1=348359&r2=348360&view=diff
==
--- lldb/trunk/CMakeLists.txt (original)
+++ lldb/trunk/CMakeLists.txt Wed Dec  5 04:18:44 2018
@@ -56,7 +56,7 @@ if(LLDB_BUILD_FRAMEWORK)
   # the framework, and must be defined before building liblldb.
   set(PRODUCT_NAME "LLDB")
   set(EXECUTABLE_NAME "LLDB")
-  set(CURRENT_PROJECT_VERSION "${LLDB_VERSION}")
+  set(CURRENT_PROJECT_VERSION 
"${LLDB_VERSION_MAJOR}.${LLDB_VERSION_MINOR}.${LLDB_VERSION_PATCH}")
   set(LLDB_SUITE_TARGET lldb-framework)
 
   set(LLDB_FRAMEWORK_DIR

Modified: lldb/trunk/cmake/modules/LLDBFramework.cmake
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/cmake/modules/LLDBFramework.cmake?rev=348360&r1=348359&r2=348360&view=diff
==
--- lldb/trunk/cmake/modules/LLDBFramework.cmake (original)
+++ lldb/trunk/cmake/modules/LLDBFramework.cmake Wed Dec  5 04:18:44 2018
@@ -27,7 +27,7 @@ if (NOT IOS)
   add_custom_command(TARGET lldb-framework POST_BUILD
 COMMAND ${CMAKE_COMMAND} -E create_symlink Versions/Current/Headers 
${LLDB_FRAMEWORK_DIR}/LLDB.framework/Headers
 COMMAND ${CMAKE_COMMAND} -E create_symlink ${LLDB_FRAMEWORK_VERSION} 
${LLDB_FRAMEWORK_DIR}/LLDB.framework/Versions/Current
-COMMAND ${CMAKE_COMMAND} -E copy_directory 
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/clang/${LLDB_VERSION} 
$/Resources/Clang
+COMMAND ${CMAKE_COMMAND} -E copy_directory 
${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/clang/${LLVM_VERSION_MAJOR}.${LLVM_VERSION_MINOR}.${LLVM_VERSION_PATCH}
 $/Resources/Clang
   )
 endif()
 


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

[Lldb-commits] [PATCH] D55316: [CMake] Add support for NO_INSTALL_RPATH argument in llvm_add_library()

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

sgraenitz created this revision.
sgraenitz added reviewers: aprantl, JDevlieghere, davide, friss.
Herald added a subscriber: mgorny.

Allow clients to suppress setup of default RPATHs in designated library 
targets. This is used in LLDB when emitting liblldb as a framework bundle, 
which itself doesn't load further RPATH-dependent libraries.
This follows the approach in add_llvm_executable().


Repository:
  rL LLVM

https://reviews.llvm.org/D55316

Files:
  cmake/modules/AddLLVM.cmake


Index: cmake/modules/AddLLVM.cmake
===
--- cmake/modules/AddLLVM.cmake
+++ cmake/modules/AddLLVM.cmake
@@ -377,7 +377,7 @@
 #   )
 function(llvm_add_library name)
   cmake_parse_arguments(ARG
-"MODULE;SHARED;STATIC;OBJECT;DISABLE_LLVM_LINK_LLVM_DYLIB;SONAME"
+
"MODULE;SHARED;STATIC;OBJECT;DISABLE_LLVM_LINK_LLVM_DYLIB;SONAME;NO_INSTALL_RPATH"
 "OUTPUT_NAME;PLUGIN_TOOL"
 "ADDITIONAL_HEADERS;DEPENDS;LINK_COMPONENTS;LINK_LIBS;OBJLIBS"
 ${ARGN})
@@ -448,17 +448,19 @@
 
   if(ARG_MODULE)
 add_library(${name} MODULE ${ALL_FILES})
-llvm_setup_rpath(${name})
   elseif(ARG_SHARED)
 add_windows_version_resource_file(ALL_FILES ${ALL_FILES})
 add_library(${name} SHARED ${ALL_FILES})
-
-llvm_setup_rpath(${name})
-
   else()
 add_library(${name} STATIC ${ALL_FILES})
   endif()
 
+  if(NOT ARG_NO_INSTALL_RPATH)
+if(ARG_MODULE OR ARG_SHARED)
+  llvm_setup_rpath(${name})
+endif()
+  endif()
+
   setup_dependency_debugging(${name} ${LLVM_COMMON_DEPENDS})
 
   if(DEFINED windows_resource_file)


Index: cmake/modules/AddLLVM.cmake
===
--- cmake/modules/AddLLVM.cmake
+++ cmake/modules/AddLLVM.cmake
@@ -377,7 +377,7 @@
 #   )
 function(llvm_add_library name)
   cmake_parse_arguments(ARG
-"MODULE;SHARED;STATIC;OBJECT;DISABLE_LLVM_LINK_LLVM_DYLIB;SONAME"
+"MODULE;SHARED;STATIC;OBJECT;DISABLE_LLVM_LINK_LLVM_DYLIB;SONAME;NO_INSTALL_RPATH"
 "OUTPUT_NAME;PLUGIN_TOOL"
 "ADDITIONAL_HEADERS;DEPENDS;LINK_COMPONENTS;LINK_LIBS;OBJLIBS"
 ${ARGN})
@@ -448,17 +448,19 @@
 
   if(ARG_MODULE)
 add_library(${name} MODULE ${ALL_FILES})
-llvm_setup_rpath(${name})
   elseif(ARG_SHARED)
 add_windows_version_resource_file(ALL_FILES ${ALL_FILES})
 add_library(${name} SHARED ${ALL_FILES})
-
-llvm_setup_rpath(${name})
-
   else()
 add_library(${name} STATIC ${ALL_FILES})
   endif()
 
+  if(NOT ARG_NO_INSTALL_RPATH)
+if(ARG_MODULE OR ARG_SHARED)
+  llvm_setup_rpath(${name})
+endif()
+  endif()
+
   setup_dependency_debugging(${name} ${LLVM_COMMON_DEPENDS})
 
   if(DEFINED windows_resource_file)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D55084: [CMake] Add RPATHS parameter to llvm_add_executable/library

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

sgraenitz abandoned this revision.
sgraenitz added a comment.

More requirements for RPATH handling in LLDB came up. We will do it manually 
over there instead of adding support in LLVM. Added D55316 
 to avoid the need for reverting default 
settings.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D55084



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

[Lldb-commits] [PATCH] D55317: [CMake] Aggregate options for LLDB in LLDBConfig.cmake

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

sgraenitz created this revision.
sgraenitz added reviewers: JDevlieghere, aprantl, xiaobai.
Herald added subscribers: mgorny, srhines.

In preparation for LLDB.framework changes, collect options for LLDB in 
LLDBConfig.cmake (used for both, standalone and in-tree builds).


https://reviews.llvm.org/D55317

Files:
  CMakeLists.txt
  cmake/modules/LLDBConfig.cmake

Index: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ cmake/modules/LLDBConfig.cmake
@@ -10,28 +10,42 @@
   set(LLDB_LINKER_SUPPORTS_GROUPS ON)
 endif()
 
-set(LLDB_DEFAULT_DISABLE_PYTHON 0)
-set(LLDB_DEFAULT_DISABLE_CURSES 0)
-
-if ( CMAKE_SYSTEM_NAME MATCHES "Windows" )
-  set(LLDB_DEFAULT_DISABLE_CURSES 1)
-elseif (CMAKE_SYSTEM_NAME MATCHES "Android" )
-  set(LLDB_DEFAULT_DISABLE_PYTHON 1)
-  set(LLDB_DEFAULT_DISABLE_CURSES 1)
-elseif(IOS)
-  set(LLDB_DEFAULT_DISABLE_PYTHON 1)
-endif()
+set(default_disable_python OFF)
+set(default_disable_curses OFF)
+set(default_disable_libedit OFF)
 
-set(LLDB_DISABLE_PYTHON ${LLDB_DEFAULT_DISABLE_PYTHON} CACHE BOOL
-  "Disables the Python scripting integration.")
-set(LLDB_DISABLE_CURSES ${LLDB_DEFAULT_DISABLE_CURSES} CACHE BOOL
-  "Disables the Curses integration.")
+if(DEFINED LLVM_ENABLE_LIBEDIT AND NOT LLVM_ENABLE_LIBEDIT)
+  set(default_disable_libedit ON)
+endif()
 
-set(LLDB_RELOCATABLE_PYTHON 0 CACHE BOOL
-  "Causes LLDB to use the PYTHONHOME environment variable to locate Python.")
+if(CMAKE_SYSTEM_NAME MATCHES "Windows")
+  set(default_disable_curses ON)
+  set(default_disable_libedit ON)
+elseif(CMAKE_SYSTEM_NAME MATCHES "Android")
+  set(default_disable_python ON)
+  set(default_disable_curses ON)
+  set(default_disable_libedit ON)
+elseif(IOS)
+  set(default_disable_python ON)
+endif()
 
-set(LLDB_USE_SYSTEM_SIX 0 CACHE BOOL
-  "Use six.py shipped with system and do not install a copy of it")
+option(LLDB_DISABLE_PYTHON "Disable Python scripting integration." ${default_disable_python})
+option(LLDB_DISABLE_CURSES "Disable Curses integration." ${default_disable_curses})
+option(LLDB_DISABLE_LIBEDIT "Disable the use of editline." ${default_disable_libedit})
+option(LLDB_RELOCATABLE_PYTHON "Use the PYTHONHOME environment variable to locate Python." OFF)
+option(LLDB_USE_SYSTEM_SIX "Use six.py shipped with system and do not install a copy of it" OFF)
+option(LLDB_BUILD_FRAMEWORK "Build LLDB.framework (Darwin only)" OFF)
+option(LLDB_USE_ENTITLEMENTS "When codesigning, use entitlements if available" ON)
+
+if(LLDB_BUILD_FRAMEWORK)
+  if(NOT APPLE)
+message(FATAL_ERROR "LLDB.framework can only be generated when targeting Apple platforms")
+  endif()
+  # CMake 3.6 did not correctly emit POST_BUILD commands for Apple Framework targets
+  if(CMAKE_VERSION VERSION_LESS 3.7)
+message(FATAL_ERROR "LLDB_BUILD_FRAMEWORK is not supported on CMake < 3.7")
+  endif()
+endif()
 
 if (NOT CMAKE_SYSTEM_NAME MATCHES "Windows")
   set(LLDB_EXPORT_ALL_SYMBOLS 0 CACHE BOOL
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -18,15 +18,6 @@
   add_definitions( -DLLDB_CONFIGURATION_RELEASE )
 endif()
 
-if (CMAKE_SYSTEM_NAME MATCHES "Windows|Android")
-  set(LLDB_DEFAULT_DISABLE_LIBEDIT 1)
-else()
-  set(LLDB_DEFAULT_DISABLE_LIBEDIT 0)
-endif ()
-
-# We need libedit support to go down both the source and
-# the scripts directories.
-set(LLDB_DISABLE_LIBEDIT ${LLDB_DEFAULT_DISABLE_LIBEDIT} CACHE BOOL "Disables the use of editline.")
 if (LLDB_DISABLE_LIBEDIT)
   add_definitions( -DLLDB_DISABLE_LIBEDIT )
 else()
@@ -42,16 +33,9 @@
 add_custom_target(lldb-suite)
 set(LLDB_SUITE_TARGET lldb-suite)
 
-option(LLDB_BUILD_FRAMEWORK "Build the Darwin LLDB.framework" Off)
 if(LLDB_BUILD_FRAMEWORK)
-  if (CMAKE_VERSION VERSION_LESS 3.7)
-message(FATAL_ERROR "LLDB_BUILD_FRAMEWORK is not supported on CMake < 3.7")
-  endif()
-  if (NOT APPLE)
-message(FATAL_ERROR "LLDB.framework can only be generated when targeting Apple platforms")
-  endif()
-
   add_custom_target(lldb-framework)
+
   # These are used to fill out LLDB-Info.plist. These are relevant when building
   # the framework, and must be defined before building liblldb.
   set(PRODUCT_NAME "LLDB")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D55318: [Expressions] Add support of expressions evaluation in some object's context

[Aleksandr Urakov via Phabricator via lldb-commits]

aleksandr.urakov created this revision.
aleksandr.urakov added reviewers: teemperor, clayborg, jingham, zturner, 
labath, davide, spyffe.
aleksandr.urakov added a project: LLDB.
Herald added subscribers: lldb-commits, abidh.

This patch adds support of expression evaluation in a context of some object. 
Consider the following example:

  struct S {
int a = 11;
int b = 12;
  };
  
  int main() {
S s;
int a = 1;
int b = 2;
// We have stopped here
return 0;
  }

This patch allows to do something like that:

  lldb.frame.FindVariable("s").EvaluateExpression("a + b")

and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be 
used (not locals `a` and `b`).

This is achieved by replacing of `this` type and object for the expression. 
This has some limitations: an expression can be evaluated only for values 
located in the debuggee process memory (they must have an address of 
`eAddressTypeLoad` type).

Our company needs this functionality to implement some UI visualization of 
variables in our IDEs. I understand that the community may be not interested in 
this functionality, and I'll just abandon it if so. But if the community is 
interested in this, we can save some time on merging in the future :)


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D55318

Files:
  include/lldb/API/SBValue.h
  include/lldb/Expression/ExpressionSourceCode.h
  include/lldb/Expression/UserExpression.h
  include/lldb/Symbol/ClangASTContext.h
  include/lldb/Symbol/TypeSystem.h
  include/lldb/Target/Target.h
  packages/Python/lldbsuite/test/expression_command/context-object/Makefile
  
packages/Python/lldbsuite/test/expression_command/context-object/TestContextObject.py
  packages/Python/lldbsuite/test/expression_command/context-object/main.cpp
  scripts/interface/SBValue.i
  source/API/SBValue.cpp
  source/Breakpoint/BreakpointLocation.cpp
  source/Breakpoint/Watchpoint.cpp
  source/Commands/CommandObjectExpression.cpp
  source/Expression/ExpressionSourceCode.cpp
  source/Expression/UserExpression.cpp
  source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp
  source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.h
  source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
  source/Plugins/ExpressionParser/Clang/ClangUserExpression.h
  source/Plugins/ExpressionParser/Clang/ClangUtilityFunction.cpp
  source/Symbol/ClangASTContext.cpp
  source/Target/Target.cpp

Index: source/Target/Target.cpp
===
--- source/Target/Target.cpp
+++ source/Target/Target.cpp
@@ -2198,7 +2198,8 @@
 UserExpression *Target::GetUserExpressionForLanguage(
 llvm::StringRef expr, llvm::StringRef prefix, lldb::LanguageType language,
 Expression::ResultType desired_type,
-const EvaluateExpressionOptions &options, Status &error) {
+const EvaluateExpressionOptions &options,
+const lldb::ValueObjectSP &ctx_obj, Status &error) {
   Status type_system_error;
 
   TypeSystem *type_system =
@@ -2214,7 +2215,7 @@
   }
 
   user_expr = type_system->GetUserExpression(expr, prefix, language,
- desired_type, options);
+ desired_type, options, ctx_obj);
   if (!user_expr)
 error.SetErrorStringWithFormat(
 "Could not create an expression for language %s",
@@ -2355,7 +2356,8 @@
 ExpressionResults Target::EvaluateExpression(
 llvm::StringRef expr, ExecutionContextScope *exe_scope,
 lldb::ValueObjectSP &result_valobj_sp,
-const EvaluateExpressionOptions &options, std::string *fixed_expression) {
+const EvaluateExpressionOptions &options, std::string *fixed_expression,
+const lldb::ValueObjectSP &ctx_obj) {
   result_valobj_sp.reset();
 
   ExpressionResults execution_results = eExpressionSetupError;
@@ -2396,7 +2398,9 @@
 execution_results = UserExpression::Evaluate(exe_ctx, options, expr, prefix,
  result_valobj_sp, error,
  0, // Line Number
- fixed_expression);
+ fixed_expression,
+ nullptr, // Module
+ ctx_obj);
   }
 
   m_suppress_stop_hooks = old_suppress_value;
Index: source/Symbol/ClangASTContext.cpp
===
--- source/Symbol/ClangASTContext.cpp
+++ source/Symbol/ClangASTContext.cpp
@@ -10294,13 +10294,14 @@
 UserExpression *ClangASTContextForExpressions::GetUserExpression(
 llvm::StringRef expr, llvm::StringRef prefix, lldb::LanguageType language,
 Expression::ResultType desired_type,
-const EvaluateExpressionOptions &options) {
+const EvaluateExpressionOptions &options,
+const lldb::ValueObjectSP &ctx_obj) {
   TargetSP target_sp = 

[Lldb-commits] [PATCH] D55319: [CMake] Proposal: Prefer LLDB_VERSION over plist value in EmbedAppleVersion.cmake

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

sgraenitz created this revision.
sgraenitz added reviewers: aprantl, friss.
Herald added a subscriber: mgorny.

LLDB_VERSION works analogous to CLANG_VERSION, with the exception that it 
includes the optional LLDB_VERSION_SUFFIX. Thus it should be equal to 
LLDB_VERSION_STRING and we could use it instead of extracting the plist value.

My preference would be to streamline version handling completely, including the 
code using it:

  if(APPLE)
set(apple_version_inc "${CMAKE_CURRENT_BINARY_DIR}/AppleVersion.inc")
set(apple_version_script 
"${LLDB_SOURCE_DIR}/cmake/modules/EmbedAppleVersion.cmake")
set(info_plist ${LLDB_SOURCE_DIR}/resources/LLDB-Info.plist)
  
# Create custom target to generate the VC revision include.
add_custom_command(OUTPUT "${apple_version_inc}"
  DEPENDS "${apple_version_script}" "${info_plist}"
  COMMAND
  ${CMAKE_COMMAND} "-DLLDB_INFO_PLIST=${info_plist}"
   "-DHEADER_FILE=${apple_version_inc}"
   -P "${apple_version_script}")
  
# Mark the generated header as being generated.
set_source_files_properties("${apple_version_inc}"
  PROPERTIES GENERATED TRUE
 HEADER_FILE_ONLY TRUE)
  
# Tell Version.cpp that it needs to build with -DHAVE_SVN_VERSION_INC.
set_property(SOURCE lldb.cpp APPEND PROPERTY 
 COMPILE_DEFINITIONS "HAVE_APPLE_VERSION_INC")
list(APPEND lldbBase_SOURCES ${apple_version_inc})
  else()

What do you think?


https://reviews.llvm.org/D55319

Files:
  cmake/modules/EmbedAppleVersion.cmake


Index: cmake/modules/EmbedAppleVersion.cmake
===
--- cmake/modules/EmbedAppleVersion.cmake
+++ cmake/modules/EmbedAppleVersion.cmake
@@ -1,6 +1,10 @@
-execute_process(COMMAND /usr/libexec/PlistBuddy -c "Print:CFBundleVersion" 
${LLDB_INFO_PLIST}
-OUTPUT_VARIABLE BundleVersion
-OUTPUT_STRIP_TRAILING_WHITESPACE)
+if(LLDB_VERSION)
+  set(LLDB_VERSION_STRING ${LLDB_VERSION})
+else()
+  execute_process(COMMAND /usr/libexec/PlistBuddy -c "Print:CFBundleVersion" 
${LLDB_INFO_PLIST}
+  OUTPUT_VARIABLE BundleVersion
+  OUTPUT_STRIP_TRAILING_WHITESPACE)
+endif()
 
 file(APPEND "${HEADER_FILE}.tmp"
 "#define LLDB_VERSION_STRING lldb-${BundleVersion}\n")


Index: cmake/modules/EmbedAppleVersion.cmake
===
--- cmake/modules/EmbedAppleVersion.cmake
+++ cmake/modules/EmbedAppleVersion.cmake
@@ -1,6 +1,10 @@
-execute_process(COMMAND /usr/libexec/PlistBuddy -c "Print:CFBundleVersion" ${LLDB_INFO_PLIST}
-OUTPUT_VARIABLE BundleVersion
-OUTPUT_STRIP_TRAILING_WHITESPACE)
+if(LLDB_VERSION)
+  set(LLDB_VERSION_STRING ${LLDB_VERSION})
+else()
+  execute_process(COMMAND /usr/libexec/PlistBuddy -c "Print:CFBundleVersion" ${LLDB_INFO_PLIST}
+  OUTPUT_VARIABLE BundleVersion
+  OUTPUT_STRIP_TRAILING_WHITESPACE)
+endif()
 
 file(APPEND "${HEADER_FILE}.tmp"
 "#define LLDB_VERSION_STRING lldb-${BundleVersion}\n")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D55320: [CMake] Move debugserver options to separate debugserverConfig.cmake

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

sgraenitz created this revision.
sgraenitz added reviewers: JDevlieghere, aprantl, xiaobai.
Herald added a subscriber: mgorny.

One place for debugserver options, analog to LLDBConfig for LLDB options (see 
D55317 ). It was discussed in earlier reviews 
already, e.g. D55013 .


https://reviews.llvm.org/D55320

Files:
  cmake/modules/debugserverConfig.cmake
  tools/debugserver/CMakeLists.txt


Index: tools/debugserver/CMakeLists.txt
===
--- tools/debugserver/CMakeLists.txt
+++ tools/debugserver/CMakeLists.txt
@@ -10,6 +10,7 @@
 )
 
   include(LLDBStandalone)
+  include(debugserverConfig)
   include(AddLLDB)
 
   set(LLDB_SOURCE_DIR "${CMAKE_SOURCE_DIR}/../../")
@@ -19,15 +20,6 @@
   # libraries for building a fully-functioning liblldb.
   add_custom_target(lldb-suite)
   set(LLDB_SUITE_TARGET lldb-suite)
-
-  # Duplicate options from LLDBConfig that are relevant for debugserver.
-  option(LLDB_USE_ENTITLEMENTS "When code signing, use entitlements if 
available" ON)
-  set(LLDB_CODESIGN_IDENTITY lldb_codesign CACHE STRING
-  "Identity for code signing debugserver (Darwin only)")
-
-  if(LLDB_CODESIGN_IDENTITY)
-set(LLVM_CODESIGNING_IDENTITY ${LLDB_CODESIGN_IDENTITY} CACHE STRING "" 
FORCE)
-  endif()
 endif()
 
 add_subdirectory(source)
Index: cmake/modules/debugserverConfig.cmake
===
--- /dev/null
+++ cmake/modules/debugserverConfig.cmake
@@ -0,0 +1,25 @@
+# Duplicate options from LLDBConfig that are relevant for debugserver 
Standalone builds.
+
+option(LLDB_USE_ENTITLEMENTS "When code signing, use entitlements if 
available" ON)
+set(LLDB_CODESIGN_IDENTITY lldb_codesign CACHE STRING
+"Identity for code signing debugserver (Darwin only)")
+
+if(LLDB_CODESIGN_IDENTITY)
+  set(LLVM_CODESIGNING_IDENTITY ${LLDB_CODESIGN_IDENTITY} CACHE STRING "" 
FORCE)
+endif()
+
+# If LLDB_VERSION_* is specified, use it, if not use LLVM_VERSION_*.
+if(NOT DEFINED LLDB_VERSION_MAJOR)
+  set(LLDB_VERSION_MAJOR ${LLVM_VERSION_MAJOR})
+endif()
+if(NOT DEFINED LLDB_VERSION_MINOR)
+  set(LLDB_VERSION_MINOR ${LLVM_VERSION_MINOR})
+endif()
+if(NOT DEFINED LLDB_VERSION_PATCH)
+  set(LLDB_VERSION_PATCH ${LLVM_VERSION_PATCH})
+endif()
+if(NOT DEFINED LLDB_VERSION_SUFFIX)
+  set(LLDB_VERSION_SUFFIX ${LLVM_VERSION_SUFFIX})
+endif()
+set(LLDB_VERSION 
"${LLDB_VERSION_MAJOR}.${LLDB_VERSION_MINOR}.${LLDB_VERSION_PATCH}${LLDB_VERSION_SUFFIX}")
+message(STATUS "LLDB version: ${LLDB_VERSION}")


Index: tools/debugserver/CMakeLists.txt
===
--- tools/debugserver/CMakeLists.txt
+++ tools/debugserver/CMakeLists.txt
@@ -10,6 +10,7 @@
 )
 
   include(LLDBStandalone)
+  include(debugserverConfig)
   include(AddLLDB)
 
   set(LLDB_SOURCE_DIR "${CMAKE_SOURCE_DIR}/../../")
@@ -19,15 +20,6 @@
   # libraries for building a fully-functioning liblldb.
   add_custom_target(lldb-suite)
   set(LLDB_SUITE_TARGET lldb-suite)
-
-  # Duplicate options from LLDBConfig that are relevant for debugserver.
-  option(LLDB_USE_ENTITLEMENTS "When code signing, use entitlements if available" ON)
-  set(LLDB_CODESIGN_IDENTITY lldb_codesign CACHE STRING
-  "Identity for code signing debugserver (Darwin only)")
-
-  if(LLDB_CODESIGN_IDENTITY)
-set(LLVM_CODESIGNING_IDENTITY ${LLDB_CODESIGN_IDENTITY} CACHE STRING "" FORCE)
-  endif()
 endif()
 
 add_subdirectory(source)
Index: cmake/modules/debugserverConfig.cmake
===
--- /dev/null
+++ cmake/modules/debugserverConfig.cmake
@@ -0,0 +1,25 @@
+# Duplicate options from LLDBConfig that are relevant for debugserver Standalone builds.
+
+option(LLDB_USE_ENTITLEMENTS "When code signing, use entitlements if available" ON)
+set(LLDB_CODESIGN_IDENTITY lldb_codesign CACHE STRING
+"Identity for code signing debugserver (Darwin only)")
+
+if(LLDB_CODESIGN_IDENTITY)
+  set(LLVM_CODESIGNING_IDENTITY ${LLDB_CODESIGN_IDENTITY} CACHE STRING "" FORCE)
+endif()
+
+# If LLDB_VERSION_* is specified, use it, if not use LLVM_VERSION_*.
+if(NOT DEFINED LLDB_VERSION_MAJOR)
+  set(LLDB_VERSION_MAJOR ${LLVM_VERSION_MAJOR})
+endif()
+if(NOT DEFINED LLDB_VERSION_MINOR)
+  set(LLDB_VERSION_MINOR ${LLVM_VERSION_MINOR})
+endif()
+if(NOT DEFINED LLDB_VERSION_PATCH)
+  set(LLDB_VERSION_PATCH ${LLVM_VERSION_PATCH})
+endif()
+if(NOT DEFINED LLDB_VERSION_SUFFIX)
+  set(LLDB_VERSION_SUFFIX ${LLVM_VERSION_SUFFIX})
+endif()
+set(LLDB_VERSION "${LLDB_VERSION_MAJOR}.${LLDB_VERSION_MINOR}.${LLDB_VERSION_PATCH}${LLDB_VERSION_SUFFIX}")
+message(STATUS "LLDB version: ${LLDB_VERSION}")
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D54942: [PDB] Make PDB lit tests use the new builder

[Aleksandr Urakov via Phabricator via lldb-commits]

aleksandr.urakov added a comment.

It seems that all the reviews this one depends on are already in. Can we 
proceed with it?


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

https://reviews.llvm.org/D54942



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

Re: [Lldb-commits] [lldb] r348319 - [build.py] Disable tests on non-Windows.

[Zachary Turner via lldb-commits]

If you can commit the same fix I did for the other two that would be great,
otherwise I’ll get to it when i get into the office in ~2 hours
On Wed, Dec 5, 2018 at 3:03 AM Pavel Labath  wrote:

> On 05/12/2018 00:56, Zachary Turner via lldb-commits wrote:
> > Author: zturner
> > Date: Tue Dec  4 15:56:25 2018
> > New Revision: 348319
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=348319&view=rev
> > Log:
> > [build.py] Disable tests on non-Windows.
> >
> > This won't work until we get the GCC / clang builder implemented.
> >
> > Modified:
> >  lldb/trunk/lit/BuildScript/modes.test
> >  lldb/trunk/lit/BuildScript/script-args.test
> >
> > Modified: lldb/trunk/lit/BuildScript/modes.test
> > URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/BuildScript/modes.test?rev=348319&r1=348318&r2=348319&view=diff
> >
> ==
> > --- lldb/trunk/lit/BuildScript/modes.test (original)
> > +++ lldb/trunk/lit/BuildScript/modes.test Tue Dec  4 15:56:25 2018
> > @@ -1,3 +1,5 @@
> > +REQUIRES: system-windows
> > +
> >   RUN: %build -n --verbose --arch=32 --mode=compile --compiler=any -o
> %t/foo.out foobar.c \
> >   RUN:| FileCheck --check-prefix=COMPILE %s
> >
> >
> > Modified: lldb/trunk/lit/BuildScript/script-args.test
> > URL:
> http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/BuildScript/script-args.test?rev=348319&r1=348318&r2=348319&view=diff
> >
> ==
> > --- lldb/trunk/lit/BuildScript/script-args.test (original)
> > +++ lldb/trunk/lit/BuildScript/script-args.test Tue Dec  4 15:56:25 2018
> > @@ -1,3 +1,5 @@
> > +REQUIRES: system-windows
> > +
> >   RUN: %build -n --verbose --arch=32 --mode=compile --compiler=any -o
> %t/foo.out foobar.c \
> >   RUN:| FileCheck %s
> >   RUN: %build -n --verbose --arch=32 --mode=compile --compiler=any
> --outdir %t foo.c bar.c \
> >
> >
> > ___
> > lldb-commits mailing list
> > lldb-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
> >
>
> The toolchain-clang-cl.test fails for me too during printing of the
> execution environment for the compile commands. This happens because
> (unsurprisingly) we cannot find the VS installation, and the environment
> happens to be None.
>
>
> Traceback (most recent call last):
>File "/home/pavelo/ll/lldb/lit/helper/build.py", line 723, in 
>  build(cmds)
>File "/home/pavelo/ll/lldb/lit/helper/build.py", line 621, in build
>  print_environment(env)
>File "/home/pavelo/ll/lldb/lit/helper/build.py", line 154, in
> print_environment
>  for e in env:
> TypeError: 'NoneType' object is not iterable
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D54942: [PDB] Make PDB lit tests use the new builder

[Zachary Turner via lldb-commits]

Yes, if the tests pass for you with current builder, please commit
On Wed, Dec 5, 2018 at 6:06 AM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:

> aleksandr.urakov added a comment.
>
> It seems that all the reviews this one depends on are already in. Can we
> proceed with it?
>
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D54942/new/
>
> https://reviews.llvm.org/D54942
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D55214: Introduce ObjectFileBreakpad

[Mark Mentovai via Phabricator via lldb-commits]

markmentovai added inline comments.



Comment at: source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.h:74
+
+  bool IsStripped() override { return false; }
+

labath wrote:
> zturner wrote:
> > Is this always true for breakpad files?
> Well.. the whole point of these files is to provide symbol information, so it 
> would be weird if they were stripped. The breakpad `dump_syms` allows you to 
> omit generating unwind information, but I don't think that's enough to call 
> this "stripped". It is certainly possible to create a file by hand which 
> contains just a `MODULE` directive and nothing else, but I would say that is 
> a (non-stripped) file which describes an empty module, and not a stripped 
> file.
> 
> In reality, this doesn't really matter, as this function is called from just 
> one place 
> ,
>  and I don't think that will be relevant for breakpad files.
Correct, "stripped" isn't really useful for Breakpad dump_syms output. What 
does LLDB do with the result of IsStripped()?

Stripped dump_syms output would be what you get from running dump_syms on a 
stripped module. I can't imagine why anyone would do this intentionally, but 
you'd also be hard-pressed to tell that's what had happened given only the 
dumped symbol file.


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

https://reviews.llvm.org/D55214



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

[Lldb-commits] [PATCH] D55214: Introduce ObjectFileBreakpad

[Pavel Labath via Phabricator via lldb-commits]

labath marked 3 inline comments as done.
labath added inline comments.



Comment at: source/Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.h:74
+
+  bool IsStripped() override { return false; }
+

markmentovai wrote:
> labath wrote:
> > zturner wrote:
> > > Is this always true for breakpad files?
> > Well.. the whole point of these files is to provide symbol information, so 
> > it would be weird if they were stripped. The breakpad `dump_syms` allows 
> > you to omit generating unwind information, but I don't think that's enough 
> > to call this "stripped". It is certainly possible to create a file by hand 
> > which contains just a `MODULE` directive and nothing else, but I would say 
> > that is a (non-stripped) file which describes an empty module, and not a 
> > stripped file.
> > 
> > In reality, this doesn't really matter, as this function is called from 
> > just one place 
> > ,
> >  and I don't think that will be relevant for breakpad files.
> Correct, "stripped" isn't really useful for Breakpad dump_syms output. What 
> does LLDB do with the result of IsStripped()?
> 
> Stripped dump_syms output would be what you get from running dump_syms on a 
> stripped module. I can't imagine why anyone would do this intentionally, but 
> you'd also be hard-pressed to tell that's what had happened given only the 
> dumped symbol file.
Not much. The only relevant use is linked to above. I don't fully understand 
that code, but my rough idea is the following: we create a "synthetic" symbol 
in the main object file when we know some symbol must be at the given address, 
but we don't know it's name. Then when we are looking up an address and it 
resolves to this synthetic symbol (and the object file is marked as stripped), 
we go to the symbol file (if we have one) to see if it can provide us with a 
name for it.

So this isn't even relevant for breakpad files, as they will never be the 
"main" object file, but I had to put something here, and "false" seems the best 
option.


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

https://reviews.llvm.org/D55214



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

Re: [Lldb-commits] [lldb] r348319 - [build.py] Disable tests on non-Windows.

[Pavel Labath via lldb-commits]

On 05/12/2018 16:03, Zachary Turner wrote:
If you can commit the same fix I did for the other two that would be 
great, otherwise I’ll get to it when i get into the office in ~2 hours



The thing is, I'm not sure if that's the right fix here. I mean, this 
script should be able to compile with clang-cl on linux, right?


The easiest way to fix this would be to check env is not None before 
printing it out, but it wasn't clear to me whether you intended for it 
to be (possibly) None at this point in the code, so I figured its best 
to let you figure that out.

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

Re: [Lldb-commits] [lldb] r348319 - [build.py] Disable tests on non-Windows.

[Zachary Turner via lldb-commits]

It should be, but I haven’t tested any of the non Windows paths at all yet,
so while that seems like a logical fix, there’s probably something else
that would break, like not having a clang-cl environment. So the thinking
was to just disable them until i can implement and test support for other
platforms
On Wed, Dec 5, 2018 at 7:35 AM Pavel Labath  wrote:

> On 05/12/2018 16:03, Zachary Turner wrote:
> > If you can commit the same fix I did for the other two that would be
> > great, otherwise I’ll get to it when i get into the office in ~2 hours
>
>
> The thing is, I'm not sure if that's the right fix here. I mean, this
> script should be able to compile with clang-cl on linux, right?
>
> The easiest way to fix this would be to check env is not None before
> printing it out, but it wasn't clear to me whether you intended for it
> to be (possibly) None at this point in the code, so I figured its best
> to let you figure that out.
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D55328: [CMake] Revised LLDB.framework builds

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

sgraenitz created this revision.
sgraenitz added reviewers: xiaobai, JDevlieghere, aprantl, davide, beanz.
Herald added a subscriber: mgorny.

Add features to LLDB CMake builds that have so far only been available in 
Xcode. Clean up a few inconveniences and prepare further improvements.

Options:

- `LLDB_FRAMEWORK_BUILD_DIR` determines target directory (in build-tree)
- `LLDB_FRAMEWORK_INSTALL_DIR` **only** determines target directory in 
install-tree
- `LLVM_EXTERNALIZE_DEBUGINFO` allows externalized debug info (dSYM on Darwin, 
emitted to `bin`)
- `LLDB_FRAMEWORK_TOOLS` determines which executables will be copied to the 
framework's Resources (dropped symlinking, removed INCLUDE_IN_SUITE, removed 
dummy targets)

Other changes:

- clean up `add_lldb_executable()`
- include `LLDBFramework.cmake` from `source/API/CMakeLists.txt`
- use `*.plist.in` files, which are typical for CMake and independent from Xcode
- add clang headers to the framework bundle


https://reviews.llvm.org/D55328

Files:
  CMakeLists.txt
  cmake/modules/AddLLDB.cmake
  cmake/modules/LLDBConfig.cmake
  cmake/modules/LLDBFramework.cmake
  resources/LLDB-Info.plist.in
  source/API/CMakeLists.txt
  test/CMakeLists.txt
  tools/argdumper/CMakeLists.txt
  tools/darwin-debug/CMakeLists.txt
  tools/debugserver/CMakeLists.txt
  tools/debugserver/source/CMakeLists.txt
  tools/driver/CMakeLists.txt
  tools/lldb-server/CMakeLists.txt

Index: tools/lldb-server/CMakeLists.txt
===
--- tools/lldb-server/CMakeLists.txt
+++ tools/lldb-server/CMakeLists.txt
@@ -42,7 +42,7 @@
   list(APPEND LLDB_PLUGINS lldbPluginObjectFileELF)
 endif()
 
-add_lldb_tool(lldb-server INCLUDE_IN_SUITE
+add_lldb_tool(lldb-server
 Acceptor.cpp
 lldb-gdbserver.cpp
 lldb-platform.cpp
Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -19,7 +19,6 @@
 endif()
 
 add_dependencies(lldb
-  ${LLDB_SUITE_TARGET}
   LLDBOptionsTableGen
   ${tablegen_deps}
 )
Index: tools/debugserver/source/CMakeLists.txt
===
--- tools/debugserver/source/CMakeLists.txt
+++ tools/debugserver/source/CMakeLists.txt
@@ -240,7 +240,7 @@
  COMPILE_DEFINITIONS HAVE_LIBCOMPRESSION)
   endif()
   set(LLVM_OPTIONAL_SOURCES ${lldbDebugserverCommonSources})
-  add_lldb_tool(debugserver INCLUDE_IN_SUITE
+  add_lldb_tool(debugserver
 debugserver.cpp
 
 LINK_LIBS
Index: tools/debugserver/CMakeLists.txt
===
--- tools/debugserver/CMakeLists.txt
+++ tools/debugserver/CMakeLists.txt
@@ -15,11 +15,6 @@
 
   set(LLDB_SOURCE_DIR "${CMAKE_SOURCE_DIR}/../../")
   include_directories(${LLDB_SOURCE_DIR}/include)
-
-  # lldb-suite is a dummy target that encompasses all the necessary tools and
-  # libraries for building a fully-functioning liblldb.
-  add_custom_target(lldb-suite)
-  set(LLDB_SUITE_TARGET lldb-suite)
 endif()
 
 add_subdirectory(source)
Index: tools/darwin-debug/CMakeLists.txt
===
--- tools/darwin-debug/CMakeLists.txt
+++ tools/darwin-debug/CMakeLists.txt
@@ -1,3 +1,3 @@
-add_lldb_tool(darwin-debug INCLUDE_IN_SUITE
+add_lldb_tool(darwin-debug
   darwin-debug.cpp
   )
Index: tools/argdumper/CMakeLists.txt
===
--- tools/argdumper/CMakeLists.txt
+++ tools/argdumper/CMakeLists.txt
@@ -1,4 +1,4 @@
-add_lldb_tool(lldb-argdumper INCLUDE_IN_SUITE
+add_lldb_tool(lldb-argdumper
   argdumper.cpp
 
   LINK_LIBS
Index: test/CMakeLists.txt
===
--- test/CMakeLists.txt
+++ test/CMakeLists.txt
@@ -79,7 +79,13 @@
 endif()
 
 if(LLDB_BUILD_FRAMEWORK)
-  list(APPEND LLDB_TEST_COMMON_ARGS --framework ${LLDB_FRAMEWORK_DIR}/LLDB.framework)
+  # The $ generator expression
+  # provides this value, but LLDB_DOTEST_ARGS needs it at configuration-time.
+  get_filename_component(
+framework_target_dir ${LLDB_FRAMEWORK_BUILD_DIR} ABSOLUTE
+BASE_DIR ${CMAKE_BINARY_DIR}/${CMAKE_CFG_INTDIR}
+  )
+  list(APPEND LLDB_TEST_COMMON_ARGS --framework ${framework_target_dir}/LLDB.framework)
 endif()
 
 if (NOT ${CMAKE_SYSTEM_NAME} MATCHES "Windows|Darwin")
Index: source/API/CMakeLists.txt
===
--- source/API/CMakeLists.txt
+++ source/API/CMakeLists.txt
@@ -91,24 +91,25 @@
 Support
   )
 
-add_dependencies(lldb-suite liblldb)
+if(LLDB_WRAP_PYTHON)
+  add_dependencies(liblldb swig_wrapper)
 
-if (MSVC)
-  set_property(SOURCE ${LLDB_WRAP_PYTHON} APPEND_STRING PROPERTY COMPILE_FLAGS " /W0")
-else()
-  set_property(SOURCE ${LLDB_WRAP_PYTHON} APPEND_STRING PROPERTY COMPILE_FLAGS " -w")
-endif()
+  if (MSVC)
+set_property(SOURCE ${LLDB_WRAP_PYTHON} APP

[Lldb-commits] [PATCH] D55319: [CMake] Proposal: Prefer LLDB_VERSION over plist value in EmbedAppleVersion.cmake

[Frederic Riss via Phabricator via lldb-commits]

friss added a comment.

Wouldn't it make even more sense to to inject LLDB_VERSION into the Info.plist? 
We will use the Info.plist afterwards, right?


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

https://reviews.llvm.org/D55319



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

[Lldb-commits] [PATCH] D44072: [lldb] Retrieve currently handled Obj-C exception via __cxa_current_exception_type and add GetCurrentExceptionBacktrace SB ABI

[Kuba (Brecka) Mracek via Phabricator via lldb-commits]

kubamracek added a comment.

Ping.


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

https://reviews.llvm.org/D44072



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

[Lldb-commits] [PATCH] D55330: [CMake] Revised RPATH handling

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

sgraenitz created this revision.
sgraenitz added reviewers: xiaobai, JDevlieghere, aprantl, clayborg.
Herald added subscribers: mgorny, ki.stfu.

If we build LLDB.framework, dependant tools need appropriate RPATHs in both 
locations, the build-tree (for testing) and the install-tree (for deployment). 
Luckily, CMake can handle it for us: 
https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling.

- In the build-tree, tools use the absolute path to the framework's actual 
output location.
- In the install-tree, tools get a list of RPATHs to look for the framework 
when deployed.

`LLDB_FRAMEWORK_INSTALL_DIR` is added to the `CMAKE_INSTALL_PREFIX` to change 
the relative location of LLDB.framework in the install-tree. If it is not 
empty, it will be added as an additional RPATH to all dependant tools (so they 
are functional in the install-tree). If it is empty, LLDB.framework goes to the 
root of the install-tree. Tools will not be functional in the direcoty 
structure of the LLVM install-tree. 
For historical reasons `LLDB_FRAMEWORK_INSTALL_DIR` defaults to 
"Library/Frameworks".


https://reviews.llvm.org/D55330

Files:
  cmake/modules/AddLLDB.cmake
  cmake/modules/LLDBConfig.cmake
  tools/driver/CMakeLists.txt
  tools/lldb-mi/CMakeLists.txt
  tools/lldb-vscode/CMakeLists.txt

Index: tools/lldb-vscode/CMakeLists.txt
===
--- tools/lldb-vscode/CMakeLists.txt
+++ tools/lldb-vscode/CMakeLists.txt
@@ -28,3 +28,7 @@
   LINK_COMPONENTS
 Support
   )
+
+if(LLDB_BUILD_FRAMEWORK)
+  lldb_setup_rpaths_framework(lldb-vscode)
+endif()
Index: tools/lldb-mi/CMakeLists.txt
===
--- tools/lldb-mi/CMakeLists.txt
+++ tools/lldb-mi/CMakeLists.txt
@@ -93,3 +93,7 @@
   LINK_COMPONENTS
 Support
   )
+
+if(LLDB_BUILD_FRAMEWORK)
+  lldb_setup_rpaths_framework(lldb-mi)
+endif()
Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -22,3 +22,7 @@
   LLDBOptionsTableGen
   ${tablegen_deps}
 )
+
+if(LLDB_BUILD_FRAMEWORK)
+  lldb_setup_rpaths_framework(lldb)
+endif()
Index: cmake/modules/LLDBConfig.cmake
===
--- cmake/modules/LLDBConfig.cmake
+++ cmake/modules/LLDBConfig.cmake
@@ -47,6 +47,7 @@
 option(LLDB_RELOCATABLE_PYTHON "Use the PYTHONHOME environment variable to locate Python." OFF)
 option(LLDB_USE_SYSTEM_SIX "Use six.py shipped with system and do not install a copy of it" OFF)
 option(LLDB_BUILD_FRAMEWORK "Build LLDB.framework (Darwin only)" OFF)
+option(LLDB_NO_INSTALL_DEFAULT_RPATH "Disable default RPATH settings in binaries" OFF)
 option(LLDB_USE_ENTITLEMENTS "When codesigning, use entitlements if available" ON)
 
 set(LLDB_CODESIGN_IDENTITY lldb_codesign CACHE STRING
Index: cmake/modules/AddLLDB.cmake
===
--- cmake/modules/AddLLDB.cmake
+++ cmake/modules/AddLLDB.cmake
@@ -44,9 +44,15 @@
   if (PARAM_OBJECT)
 add_library(${name} ${libkind} ${srcs})
   else()
-llvm_add_library(${name} ${libkind} ${srcs} LINK_LIBS
-${PARAM_LINK_LIBS}
-DEPENDS ${PARAM_DEPENDS})
+if(LLDB_NO_INSTALL_DEFAULT_RPATH)
+  set(pass_NO_INSTALL_RPATH NO_INSTALL_RPATH)
+endif()
+
+llvm_add_library(${name} ${libkind} ${srcs}
+  LINK_LIBS ${PARAM_LINK_LIBS}
+  DEPENDS ${PARAM_DEPENDS}
+  ${pass_NO_INSTALL_RPATH}
+)
 
 if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ${name} STREQUAL "liblldb")
   if (PARAM_SHARED)
@@ -98,8 +104,15 @@
 ${ARGN}
 )
 
+  if(LLDB_NO_INSTALL_DEFAULT_RPATH)
+set(pass_NO_INSTALL_RPATH NO_INSTALL_RPATH)
+  endif()
+
   list(APPEND LLVM_LINK_COMPONENTS ${ARG_LINK_COMPONENTS})
-  add_llvm_executable(${name} ${ARG_UNPARSED_ARGUMENTS} ENTITLEMENTS ${ARG_ENTITLEMENTS})
+  add_llvm_executable(${name} ${ARG_UNPARSED_ARGUMENTS}
+ENTITLEMENTS ${ARG_ENTITLEMENTS}
+${pass_NO_INSTALL_RPATH}
+  )
 
   target_link_libraries(${name} PRIVATE ${ARG_LINK_LIBS})
   set_target_properties(${name} PROPERTIES FOLDER "lldb executables")
@@ -135,3 +148,29 @@
   # Now set them onto the target.
   set_target_properties(${target_name} PROPERTIES LINK_FLAGS ${new_link_flags})
 endfunction()
+
+# Account for different directory structures of build-tree and install-tree with
+# LLDB_BUILD_FRAMEWORK, replacing default RPATH settings (see llvm_setup_rpath),
+# so that we emit correct load commands for tools that dynamically link to the
+# framework bundle.
+function(lldb_setup_rpaths_framework name)
+  # In the build-tree, we know the exact path to the binary in the framework.
+  set(rpath_build_tree "$")
+
+  # The installed framework is relocatable and can be in different locations.
+  set(rpaths_install_tree "@loader_path/../../../SharedFrameworks")
+ 

[Lldb-commits] [PATCH] D55328: [CMake] Revised LLDB.framework builds

[Greg Clayton via Phabricator via lldb-commits]

clayborg added a comment.

I like seeing all of the cmake modifications for the LLDB.framework. Are we 
planning on trying to get rid of the Xcode project at some point soon and use 
the auto generated one made by cmake?


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

https://reviews.llvm.org/D55328



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

[Lldb-commits] [PATCH] D55319: [CMake] Proposal: Prefer LLDB_VERSION over plist value in EmbedAppleVersion.cmake

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

sgraenitz added a comment.

In order to reduce the risk of breaking the Xcode build, I use a separate 
`resources/LLDB-Info.plist.in` 
(https://reviews.llvm.org/D55328#change-SBZDFQxftWtU) for the framework. I did 
not yet change which plist is used here, but yes writing the correct version 
would be ideal I belief.


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

https://reviews.llvm.org/D55319



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

[Lldb-commits] [PATCH] D55332: [CMake] Python bindings generation polishing

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

sgraenitz created this revision.
sgraenitz added reviewers: JDevlieghere, aprantl, stella.stamenova, beanz, 
zturner.
Herald added a subscriber: mgorny.

Simplify SWIG invocation and handling of generated files.

The `swig_wrapper` target can generate `LLDBWrapPython.cpp` and `lldb.py` in 
its own binary directory, so we can get rid of a few global variables and their 
logic. `$` can be used to refer to it.
For the moment we still need `LLDB_PYTHON_BINARY_DIR` (global property now) as 
a workaround for `set_source_files_properties(), which apparently doesn't work 
with generator expressions.


https://reviews.llvm.org/D55332

Files:
  CMakeLists.txt
  scripts/CMakeLists.txt
  source/API/CMakeLists.txt

Index: source/API/CMakeLists.txt
===
--- source/API/CMakeLists.txt
+++ source/API/CMakeLists.txt
@@ -4,6 +4,15 @@
 
 get_property(LLDB_ALL_PLUGINS GLOBAL PROPERTY LLDB_PLUGINS)
 
+if(NOT LLDB_DISABLE_PYTHON)
+  # We could get this path from $
+  # but set_source_files_properties() doesn't accept generator expressions.
+  get_property(lldb_python_dir GLOBAL PROPERTY LLDB_PYTHON_BINARY_DIR)
+
+  set(lldb_python_wrapper ${lldb_python_dir}/LLDBWrapPython.cpp)
+  set_source_files_properties(${lldb_python_wrapper} PROPERTIES GENERATED ON)
+endif()
+
 add_lldb_library(liblldb SHARED
   SBAddress.cpp
   SBAttachInfo.cpp
@@ -72,7 +81,7 @@
   SBWatchpoint.cpp
   SBUnixSignals.cpp
   SystemInitializerFull.cpp
-  ${LLDB_WRAP_PYTHON}
+  ${lldb_python_wrapper}
 
   LINK_LIBS
 lldbBase
@@ -91,22 +100,22 @@
 Support
   )
 
-if(LLDB_WRAP_PYTHON)
+if(lldb_python_wrapper)
   add_dependencies(liblldb swig_wrapper)
 
   if (MSVC)
-set_property(SOURCE ${LLDB_WRAP_PYTHON} APPEND_STRING PROPERTY COMPILE_FLAGS " /W0")
+set_property(SOURCE ${lldb_python_wrapper} APPEND_STRING PROPERTY COMPILE_FLAGS " /W0")
   else()
-set_property(SOURCE ${LLDB_WRAP_PYTHON} APPEND_STRING PROPERTY COMPILE_FLAGS " -w")
+set_property(SOURCE ${lldb_python_wrapper} APPEND_STRING PROPERTY COMPILE_FLAGS " -w")
   endif()
 
   if (CLANG_CL)
-set_property(SOURCE ${LLDB_WRAP_PYTHON} APPEND_STRING
+set_property(SOURCE ${lldb_python_wrapper} APPEND_STRING
   PROPERTY COMPILE_FLAGS " -Wno-unused-function")
   endif()
   if (LLVM_COMPILER_IS_GCC_COMPATIBLE AND
   NOT "${CMAKE_SYSTEM_NAME}" MATCHES "Darwin")
-set_property(SOURCE ${LLDB_WRAP_PYTHON} APPEND_STRING
+set_property(SOURCE ${lldb_python_wrapper} APPEND_STRING
   PROPERTY COMPILE_FLAGS " -Wno-sequence-point -Wno-cast-qual")
   endif ()
 endif()
Index: scripts/CMakeLists.txt
===
--- scripts/CMakeLists.txt
+++ scripts/CMakeLists.txt
@@ -11,31 +11,14 @@
 
 include(FindPythonInterp)
 
-if (NOT CMAKE_SYSTEM_NAME MATCHES "Windows")
-  set(SWIG_PYTHON_DIR
-${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR})
-else()
-  set(SWIG_PYTHON_DIR ${CMAKE_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/site-packages)
-endif()
-
-set(SWIG_INSTALL_DIR lib${LLVM_LIBDIR_SUFFIX})
-
-# Generating the LLDB framework correctly is a bit complicated because the
-# framework depends on the swig output.
 if(LLDB_BUILD_FRAMEWORK)
   set(framework_arg --framework --target-platform Darwin)
-  set(SWIG_PYTHON_DIR
-${LLDB_PYTHON_TARGET_DIR}/${LLDB_FRAMEWORK_RESOURCE_DIR}/Python)
-  set(SWIG_INSTALL_DIR
-${LLDB_FRAMEWORK_INSTALL_DIR}/${LLDB_FRAMEWORK_RESOURCE_DIR})
 endif()
 
-get_filename_component(CFGBLDDIR ${LLDB_WRAP_PYTHON} DIRECTORY)
-
 find_package(SWIG REQUIRED)
 add_custom_command(
-  OUTPUT ${LLDB_WRAP_PYTHON}
-  OUTPUT ${LLDB_PYTHON_TARGET_DIR}/lldb.py
+  OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
+  OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
   DEPENDS ${SWIG_SOURCES}
   DEPENDS ${SWIG_INTERFACES}
   DEPENDS ${SWIG_HEADERS}
@@ -44,19 +27,36 @@
   COMMAND ${PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/prepare_bindings.py
   ${framework_arg}
   --srcRoot=${LLDB_SOURCE_DIR}
-  --targetDir=${LLDB_PYTHON_TARGET_DIR}
-  --cfgBldDir=${CFGBLDDIR}
+  --targetDir=${CMAKE_CURRENT_BINARY_DIR}
+  --cfgBldDir=${CMAKE_CURRENT_BINARY_DIR}
   --prefix=${CMAKE_BINARY_DIR}
   --swigExecutable=${SWIG_EXECUTABLE}
   VERBATIM
   COMMENT "Python script building LLDB Python wrapper")
-add_custom_target(swig_wrapper ALL DEPENDS ${LLDB_WRAP_PYTHON})
 
-set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/lldb.py PROPERTIES GENERATED 1)
+add_custom_target(swig_wrapper ALL DEPENDS
+  ${CMAKE_CURRENT_BINARY_DIR}/LLDBWrapPython.cpp
+  ${CMAKE_CURRENT_BINARY_DIR}/lldb.py
+)
+
+# For the liblldb target we need to mark LLDBWrapPython.cpp generated. Doing it
+# here has no effect as set_source_files_properties are visible only to targets
+# added in the same directory.
+set_property(GLOBAL PROPERTY LLDB_PYTHON_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR})
 
+if(NOT LLDB_BUILD_FRAMEWORK)
+  if(CMAK

[Lldb-commits] [PATCH] D55328: [CMake] Revised LLDB.framework builds

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

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

I am still running some remaining tests, but please let me know what you think 
about it in the meantime. In case you want to try this patch yourself, please 
checkout together with the related revisions (see Stack).




Comment at: cmake/modules/LLDBConfig.cmake:74
+
+  # Set decicated directory for all dSYMs. Essentially, this emits the
+  # framework's dSYM outside of the framework directory.

designated


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

https://reviews.llvm.org/D55328



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

[Lldb-commits] [PATCH] D55332: [CMake] Python bindings generation polishing

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

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



Comment at: CMakeLists.txt:143
-DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/scripts/finishSwigWrapperClasses.py
-DEPENDS ${LLDB_PYTHON_TARGET_DIR}/lldb.py
 COMMENT "Python script sym-linking LLDB Python API")

We depend on `swig_wrapper` which depends on it/generates it.


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

https://reviews.llvm.org/D55332



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

[Lldb-commits] [PATCH] D55328: [CMake] Revised LLDB.framework builds

[Frederic Riss via Phabricator via lldb-commits]

friss added a comment.

In D55328#1320267 , @clayborg wrote:

> I like seeing all of the cmake modifications for the LLDB.framework. Are we 
> planning on trying to get rid of the Xcode project at some point soon and use 
> the auto generated one made by cmake?


While there are no immediate plans to do so, we want to be able to do it and 
thus we need feature parity. Maintaining the Xcode project over a variety of 
branches is really expensive.


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

https://reviews.llvm.org/D55328



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

[Lldb-commits] [PATCH] D55320: [CMake] Move debugserver options to separate debugserverConfig.cmake

[Adrian Prantl via Phabricator via lldb-commits]

aprantl accepted this revision.
aprantl added inline comments.
This revision is now accepted and ready to land.



Comment at: cmake/modules/debugserverConfig.cmake:2
+# Duplicate options from LLDBConfig that are relevant for debugserver 
Standalone builds.
+
+option(LLDB_USE_ENTITLEMENTS "When code signing, use entitlements if 
available" ON)

I don't know CMake enough, but would it be feasible to have both file #include 
a fragment with the shared code?


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

https://reviews.llvm.org/D55320



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

[Lldb-commits] [PATCH] D55317: [CMake] Aggregate options for LLDB in LLDBConfig.cmake

[Adrian Prantl via Phabricator via lldb-commits]

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

Looks more organized.


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

https://reviews.llvm.org/D55317



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

[Lldb-commits] [PATCH] D55316: [CMake] Add support for NO_INSTALL_RPATH argument in llvm_add_library()

[Adrian Prantl via Phabricator via lldb-commits]

aprantl accepted this revision.
aprantl added inline comments.
This revision is now accepted and ready to land.



Comment at: cmake/modules/AddLLVM.cmake:458
 
+  if(NOT ARG_NO_INSTALL_RPATH)
+if(ARG_MODULE OR ARG_SHARED)

Any kind of comment that we could add here that explains why this is happening? 
This looks quite mysterious to the casual reader otherwise :-)


Repository:
  rL LLVM

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

https://reviews.llvm.org/D55316



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

[Lldb-commits] [lldb] r348386 - [PDB] Make PDB lit tests use the new builder

[Aleksandr Urakov via lldb-commits]

Author: aleksandr.urakov
Date: Wed Dec  5 09:35:30 2018
New Revision: 348386

URL: http://llvm.org/viewvc/llvm-project?rev=348386&view=rev
Log:
[PDB] Make PDB lit tests use the new builder

Reviewers: zturner, stella.stamenova

Reviewed By: zturner

Tags: #lldb

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

Modified:
lldb/trunk/lit/SymbolFile/PDB/ast-restore.test
lldb/trunk/lit/SymbolFile/PDB/calling-conventions.test
lldb/trunk/lit/SymbolFile/PDB/class-layout.test
lldb/trunk/lit/SymbolFile/PDB/compilands.test
lldb/trunk/lit/SymbolFile/PDB/enums-layout.test
lldb/trunk/lit/SymbolFile/PDB/expressions.test
lldb/trunk/lit/SymbolFile/PDB/func-symbols.test
lldb/trunk/lit/SymbolFile/PDB/function-nested-block.test
lldb/trunk/lit/SymbolFile/PDB/pointers.test
lldb/trunk/lit/SymbolFile/PDB/type-quals.test
lldb/trunk/lit/SymbolFile/PDB/typedefs.test
lldb/trunk/lit/SymbolFile/PDB/udt-layout.test
lldb/trunk/lit/SymbolFile/PDB/variables-locations.test
lldb/trunk/lit/SymbolFile/PDB/variables.test
lldb/trunk/lit/SymbolFile/PDB/vbases.test

Modified: lldb/trunk/lit/SymbolFile/PDB/ast-restore.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/PDB/ast-restore.test?rev=348386&r1=348385&r2=348386&view=diff
==
--- lldb/trunk/lit/SymbolFile/PDB/ast-restore.test (original)
+++ lldb/trunk/lit/SymbolFile/PDB/ast-restore.test Wed Dec  5 09:35:30 2018
@@ -1,6 +1,5 @@
-REQUIRES: system-windows
-RUN: %msvc_cl /Zi /GS- /c %S/Inputs/AstRestoreTest.cpp /Fo%t.obj
-RUN: %msvc_link /debug:full /nodefaultlib /entry:main %t.obj /out:%t.exe
+REQUIRES: system-windows, msvc
+RUN: %build --compiler=msvc --nodefaultlib --output=%t.exe 
%S/Inputs/AstRestoreTest.cpp
 RUN: lldb-test symbols -dump-ast %t.exe | FileCheck --check-prefix=ENUM %s
 RUN: lldb-test symbols -dump-ast %t.exe | FileCheck --check-prefix=GLOBAL %s
 RUN: lldb-test symbols -dump-ast %t.exe | FileCheck --check-prefix=BASE %s

Modified: lldb/trunk/lit/SymbolFile/PDB/calling-conventions.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/PDB/calling-conventions.test?rev=348386&r1=348385&r2=348386&view=diff
==
--- lldb/trunk/lit/SymbolFile/PDB/calling-conventions.test (original)
+++ lldb/trunk/lit/SymbolFile/PDB/calling-conventions.test Wed Dec  5 09:35:30 
2018
@@ -1,6 +1,5 @@
 REQUIRES: system-windows, lld
-RUN: %clang_cl -m32 /Zi /GS- /c %S/Inputs/CallingConventionsTest.cpp /o %t.obj
-RUN: lld-link /debug:full /nodefaultlib /entry:main %t.obj /out:%t.exe
+RUN: %build --compiler=clang-cl --arch=32 --nodefaultlib --output=%t.exe 
%S/Inputs/CallingConventionsTest.cpp
 RUN: lldb-test symbols -dump-ast %t.exe | FileCheck %s
 
 CHECK: Module: {{.*}}

Modified: lldb/trunk/lit/SymbolFile/PDB/class-layout.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/PDB/class-layout.test?rev=348386&r1=348385&r2=348386&view=diff
==
--- lldb/trunk/lit/SymbolFile/PDB/class-layout.test (original)
+++ lldb/trunk/lit/SymbolFile/PDB/class-layout.test Wed Dec  5 09:35:30 2018
@@ -1,6 +1,6 @@
-REQUIRES: msvc
-RUN: %clang_cl -m32 /Z7 /c /GS- %S/Inputs/ClassLayoutTest.cpp /o 
%T/ClassLayoutTest.cpp.obj
-RUN: %msvc_link %T/ClassLayoutTest.cpp.obj /DEBUG /nodefaultlib /ENTRY:main 
/OUT:%T/ClassLayoutTest.cpp.exe
+REQUIRES: system-windows, msvc
+RUN: %build --compiler=clang-cl --mode=compile --arch=32 --nodefaultlib 
--output=%T/ClassLayoutTest.cpp.obj %S/Inputs/ClassLayoutTest.cpp
+RUN: %build --compiler=msvc --mode=link --arch=32 --nodefaultlib 
--output=%T/ClassLayoutTest.cpp.exe %T/ClassLayoutTest.cpp.obj
 RUN: lldb-test symbols %T/ClassLayoutTest.cpp.exe | FileCheck %s
 RUN: lldb-test symbols %T/ClassLayoutTest.cpp.exe | FileCheck 
--check-prefix=ENUM %s
 RUN: lldb-test symbols %T/ClassLayoutTest.cpp.exe | FileCheck 
--check-prefix=UNION %s

Modified: lldb/trunk/lit/SymbolFile/PDB/compilands.test
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/lit/SymbolFile/PDB/compilands.test?rev=348386&r1=348385&r2=348386&view=diff
==
--- lldb/trunk/lit/SymbolFile/PDB/compilands.test (original)
+++ lldb/trunk/lit/SymbolFile/PDB/compilands.test Wed Dec  5 09:35:30 2018
@@ -1,6 +1,6 @@
 REQUIRES: system-windows, msvc
-RUN: %clang_cl /Z7 /c %S/Inputs/CompilandsTest.cpp /o %T/CompilandsTest.cpp.obj
-RUN: %msvc_link /debug:full /nodefaultlib /entry:main 
%T/CompilandsTest.cpp.obj /out:%T/CompilandsTest.cpp.exe
+RUN: %build --compiler=clang-cl --mode=compile --arch=32 --nodefaultlib 
--output=%T/CompilandsTest.cpp.obj %S/Inputs/CompilandsTest.cpp
+RUN: %build --compiler=msvc --mode=link --arch=32 --nodefaultlib 
--output=%T/CompilandsTest.cpp.exe %T/CompilandsTest.cpp.obj
 RUN: lldb-test symbols %T

[Lldb-commits] [PATCH] D54942: [PDB] Make PDB lit tests use the new builder

[Aleksandr Urakov via Phabricator via lldb-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rL348386: [PDB] Make PDB lit tests use the new builder 
(authored by aleksandr.urakov, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D54942?vs=176611&id=176845#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D54942

Files:
  lldb/trunk/lit/SymbolFile/PDB/ast-restore.test
  lldb/trunk/lit/SymbolFile/PDB/calling-conventions.test
  lldb/trunk/lit/SymbolFile/PDB/class-layout.test
  lldb/trunk/lit/SymbolFile/PDB/compilands.test
  lldb/trunk/lit/SymbolFile/PDB/enums-layout.test
  lldb/trunk/lit/SymbolFile/PDB/expressions.test
  lldb/trunk/lit/SymbolFile/PDB/func-symbols.test
  lldb/trunk/lit/SymbolFile/PDB/function-nested-block.test
  lldb/trunk/lit/SymbolFile/PDB/pointers.test
  lldb/trunk/lit/SymbolFile/PDB/type-quals.test
  lldb/trunk/lit/SymbolFile/PDB/typedefs.test
  lldb/trunk/lit/SymbolFile/PDB/udt-layout.test
  lldb/trunk/lit/SymbolFile/PDB/variables-locations.test
  lldb/trunk/lit/SymbolFile/PDB/variables.test
  lldb/trunk/lit/SymbolFile/PDB/vbases.test

Index: lldb/trunk/lit/SymbolFile/PDB/pointers.test
===
--- lldb/trunk/lit/SymbolFile/PDB/pointers.test
+++ lldb/trunk/lit/SymbolFile/PDB/pointers.test
@@ -1,6 +1,6 @@
 REQUIRES: system-windows, msvc
-RUN: %clang_cl -m32 /Z7 /c /GS- %S/Inputs/PointerTypeTest.cpp /o %T/PointerTypeTest.cpp.obj
-RUN: %msvc_link %T/PointerTypeTest.cpp.obj /DEBUG /nodefaultlib /ENTRY:main /OUT:%T/PointerTypeTest.cpp.exe
+RUN: %build --compiler=clang-cl --mode=compile --arch=32 --nodefaultlib --output=%T/PointerTypeTest.cpp.obj %S/Inputs/PointerTypeTest.cpp
+RUN: %build --compiler=msvc --mode=link --arch=32 --nodefaultlib --output=%T/PointerTypeTest.cpp.exe %T/PointerTypeTest.cpp.obj
 RUN: lldb-test symbols %T/PointerTypeTest.cpp.exe | FileCheck %s
 RUN: lldb-test symbols %T/PointerTypeTest.cpp.exe | FileCheck --check-prefix=MAIN-ST-F %s
 RUN: lldb-test symbols %T/PointerTypeTest.cpp.exe | FileCheck --check-prefix=MAIN-ST %s
Index: lldb/trunk/lit/SymbolFile/PDB/enums-layout.test
===
--- lldb/trunk/lit/SymbolFile/PDB/enums-layout.test
+++ lldb/trunk/lit/SymbolFile/PDB/enums-layout.test
@@ -1,6 +1,5 @@
 REQUIRES: system-windows, msvc
-RUN: %clang_cl -m32 /Z7 /c /GS- %S/Inputs/SimpleTypesTest.cpp /o %T/SimpleTypesTest.cpp.enums.obj
-RUN: %msvc_link %T/SimpleTypesTest.cpp.enums.obj /DEBUG /nodefaultlib /ENTRY:main /OUT:%T/SimpleTypesTest.cpp.enums.exe
+RUN: %build --compiler=msvc --arch=32 --nodefaultlib --output=%T/SimpleTypesTest.cpp.enums.exe %S/Inputs/SimpleTypesTest.cpp
 RUN: lldb-test symbols %T/SimpleTypesTest.cpp.enums.exe | FileCheck %s
 
 ; FIXME: PDB does not have information about scoped enumeration (Enum class) so the  
@@ -8,35 +7,35 @@
 
 CHECK: Module [[CU:.*]]
 CHECK-DAG: {{^[0-9A-F]+}}: SymbolVendor ([[CU]])
-CHECK:  Type{{.*}} , name = "Enum", size = 4, decl = SimpleTypesTest.cpp:19, compiler_type = {{.*}} enum Enum {
+CHECK:  Type{{.*}} , name = "Enum", size = 4, decl = simpletypestest.cpp:19, compiler_type = {{.*}} enum Enum {
 CHECK-NEXT:RED,
 CHECK-NEXT:GREEN,
 CHECK-NEXT:BLUE
 CHECK-NEXT:}
 
-CHECK:  Type{{.*}} , name = "EnumConst", size = 4,  decl = SimpleTypesTest.cpp:22, compiler_type = {{.*}} enum EnumConst {
+CHECK:  Type{{.*}} , name = "EnumConst", size = 4,  decl = simpletypestest.cpp:22, compiler_type = {{.*}} enum EnumConst {
 CHECK-NEXT:LOW,
 CHECK-NEXT:NORMAL,
 CHECK-NEXT:HIGH
 CHECK-NEXT:}
 
-CHECK:  Type{{.*}} , name = "EnumEmpty", size = 4,  decl = SimpleTypesTest.cpp:25, compiler_type = {{.*}} enum EnumEmpty {
+CHECK:  Type{{.*}} , name = "EnumEmpty", size = 4,  decl = simpletypestest.cpp:25, compiler_type = {{.*}} enum EnumEmpty {
 CHECK-NEXT:}
 
-CHECK:  Type{{.*}} , name = "EnumUChar", size = 1,  decl = SimpleTypesTest.cpp:28, compiler_type = {{.*}} enum EnumUChar {
+CHECK:  Type{{.*}} , name = "EnumUChar", size = 1,  decl = simpletypestest.cpp:28, compiler_type = {{.*}} enum EnumUChar {
 CHECK-NEXT:ON,
 CHECK-NEXT:OFF,
 CHECK-NEXT:AUTO
 CHECK-NEXT:}
 
 ; Note that `enum EnumClass` is tested instead of `enum class EnumClass`
-CHECK:  Type{{.*}} , name = "EnumClass", size = 4,  decl = SimpleTypesTest.cpp:32, compiler_type = {{.*}} enum EnumClass {
+CHECK:  Type{{.*}} , name = "EnumClass", size = 4,  decl = simpletypestest.cpp:32, compiler_type = {{.*}} enum EnumClass {
 CHECK-NEXT:YES,
 CHECK-NEXT:NO,
 CHECK-NEXT:DEFAULT
 CHECK-NEXT:}
 
-CHECK:  Type{{.*}} , name = "EnumStruct", size = 4,  decl = SimpleTypesTest.cpp:35, compiler_type = {{.*}} enum EnumStruct {
+CHECK:  Type{{.*}} , name = "EnumStruct", size = 4,  decl

Re: [Lldb-commits] [PATCH] D54942: [PDB] Make PDB lit tests use the new builder

[Aleksandr Urakov via lldb-commits]

Ok, thanks!

On Wed, Dec 5, 2018 at 6:06 PM Zachary Turner  wrote:

> Yes, if the tests pass for you with current builder, please commit
> On Wed, Dec 5, 2018 at 6:06 AM Aleksandr Urakov via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> aleksandr.urakov added a comment.
>>
>> It seems that all the reviews this one depends on are already in. Can we
>> proceed with it?
>>
>>
>> CHANGES SINCE LAST ACTION
>>   https://reviews.llvm.org/D54942/new/
>>
>> https://reviews.llvm.org/D54942
>>
>>
>>
>>

-- 
Aleksandr Urakov
Software Developer
JetBrains
http://www.jetbrains.com
The Drive to Develop
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D55318: [Expressions] Add support of expressions evaluation in some object's context

[Aleksandr Urakov via Phabricator via lldb-commits]

aleksandr.urakov added a comment.

Btw, it can be useful if there ever would be a declarative format for pretty 
printers in LLDB.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D55318



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

[Lldb-commits] [PATCH] D55142: Minidump debugging using the native PDB reader

[Leonard Mosescu via Phabricator via lldb-commits]

lemo marked 9 inline comments as done.
lemo added a comment.

In D55142#1316153 , @labath wrote:

> I don't see any tests :(.
>  Also, the three bullet points in the description sound like rather 
> independent pieces of functionality. Would it be possible to split them up 
> into separate patches? That would make things easier to review, particularly 
> for those who don't look at this code very often :).


I agree with both comments. The intention is to add some tests but I wanted to 
get the review out early to surface concerns, if any. I also needed more time 
to investigate a few complex failures uncovered by this change (ex. 
https://bugs.llvm.org/show_bug.cgi?id=39882 and 
https://bugs.llvm.org/show_bug.cgi?id=39897)

Yes, this change can also be split in three parts: the reason it's bundled up 
in this review is that all three parts are required to enable the basic 
functionality (and overall it's a relatively small change). Maybe it was better 
if I sent out the parts separately, but right now I'd like to preserve the 
continuity in the review comments. 
I'm about to send out a new revision and once this review satisfies all the 
comments I'll split it out and send individual reviews.




Comment at: source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp:132-135
+if (so.segment == 0) {
+  lldbassert(so.offset == 0);
+  continue;
+}

zturner wrote:
> What kind of symbols have a segment and offset of 0?
68 | S_LDATA32 [size = 44] `trace_event_unique_atomic140`
 type = 0x0013 (__int64), addr = :
   112 | S_LDATA32 [size = 44] `trace_event_unique_atomic171`
 type = 0x0013 (__int64), addr = :
   156 | S_LDATA32 [size = 44] `trace_event_unique_atomic196`
 type = 0x0013 (__int64), addr = :
...

Tracked by : https://bugs.llvm.org/show_bug.cgi?id=39882




Comment at: source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp:150-157
 // The odds of an error in some function such as GetSegmentAndOffset or
 // MakeVirtualAddress are much higher than the odds of encountering bad
 // debug info, so assert that this item was inserted in the map as opposed
 // to having already been there.
-lldbassert(insert_result.second);
+//
+// TODO: revisit this check since it fires for apparently valid PDBs
+//

zturner wrote:
> If we're going to comment it out, then just delete the code IMO.
> 
> Do you have some llvm-pdbutil output that demonstrates this on a valid PDB?  
> I guess we'd be looking for 2 symbols with the same Virtual Address.  Seems 
> odd to have that, but maybe an example of where it's happening would make it 
> clear whether this is actually a valid case.
I spent more time to investigate this and opened a bug to track it: 
https://bugs.llvm.org/show_bug.cgi?id=39897

With very large PDBs it's not easy to have a definitive verdict so a 2nd 
opinion is welcome, but as I noted in the bug is seems that ICF is one case 
where we can end up with multiple symbols at the same address. This means that 
the data structure needs to be revisited.

For now, I think it's better to suppress the assert so we can exercise the rest 
of the native PDB reader (I updated the comment to point to the new bug I just 
opened)



Comment at: source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:106
 static std::unique_ptr
-loadMatchingPDBFile(std::string exe_path, llvm::BumpPtrAllocator &allocator) {
-  // Try to find a matching PDB for an EXE.
+loadMatchingPDBFile(lldb_private::ObjectFile *obj_file,
+llvm::BumpPtrAllocator &allocator) {

zturner wrote:
> Perhaps `obj_file` should be a reference just to clarify that it can't be 
> null.
That would make sense. Unfortunately, obj_file can't be const 
(ObjectFile::GetUUID() is non const and it's not easy to surgically fix it)

So we'd have to pass by non-const ref, which would read "out-parameter", which 
IMO is more confusing than the non-null part is worth.



Comment at: source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp:114-115
 
-  auto *obj = llvm::dyn_cast(binary.getBinary());
-  if (!obj)
-return nullptr;
-  const llvm::codeview::DebugInfo *pdb_info = nullptr;
+  auto expected_binary = createBinary(obj_file->GetFileSpec().GetPath());
+  if (expected_binary) {
+OwningBinary binary = std::move(*expected_binary);

zturner wrote:
> Instead of trying to load it as a PE/COFF fail and then trying something else 
> if it fails (hoping that it's a minidump), perhaps we could use 
> `llvm::identify_magic()` to figure out what it is actually is first.  That 
> function currently cannot detect a Windows minidump, but we coudl teach it to 
> support that.  I think that would make this code more logical.  
> 
> ```
> if (type == exe) {
> } else if (type == minidump) {
> } else {
>   // actual er

[Lldb-commits] [PATCH] D55142: Minidump debugging using the native PDB reader

[Leonard Mosescu via Phabricator via lldb-commits]

lemo updated this revision to Diff 176853.
lemo marked an inline comment as done.

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

https://reviews.llvm.org/D55142

Files:
  source/Plugins/Process/minidump/MinidumpParser.cpp
  source/Plugins/Process/minidump/MinidumpParser.h
  source/Plugins/Process/minidump/ProcessMinidump.cpp
  source/Plugins/SymbolFile/NativePDB/CompileUnitIndex.cpp
  source/Plugins/SymbolFile/NativePDB/CompileUnitIndex.h
  source/Plugins/SymbolFile/NativePDB/PdbIndex.cpp
  source/Plugins/SymbolFile/NativePDB/PdbIndex.h
  source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp

Index: source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
===
--- source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
+++ source/Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.cpp
@@ -30,6 +30,7 @@
 #include "lldb/Symbol/SymbolVendor.h"
 #include "lldb/Symbol/Variable.h"
 #include "lldb/Symbol/VariableList.h"
+#include "lldb/Utility/UUID.h"
 
 #include "llvm/DebugInfo/CodeView/CVRecord.h"
 #include "llvm/DebugInfo/CodeView/CVTypeVisitor.h"
@@ -102,33 +103,59 @@
 }
 
 static std::unique_ptr
-loadMatchingPDBFile(std::string exe_path, llvm::BumpPtrAllocator &allocator) {
-  // Try to find a matching PDB for an EXE.
+loadMatchingPDBFile(lldb_private::ObjectFile *obj_file,
+llvm::BumpPtrAllocator &allocator) {
   using namespace llvm::object;
-  auto expected_binary = createBinary(exe_path);
 
-  // If the file isn't a PE/COFF executable, fail.
-  if (!expected_binary) {
-llvm::consumeError(expected_binary.takeError());
-return nullptr;
-  }
-  OwningBinary binary = std::move(*expected_binary);
+  // Try to find a matching PDB for an EXE.
+  std::string pdb_file;
+  llvm::codeview::GUID guid;
 
-  auto *obj = llvm::dyn_cast(binary.getBinary());
-  if (!obj)
-return nullptr;
-  const llvm::codeview::DebugInfo *pdb_info = nullptr;
+  auto expected_binary = createBinary(obj_file->GetFileSpec().GetPath());
+  if (expected_binary) {
+OwningBinary binary = std::move(*expected_binary);
 
-  // If it doesn't have a debug directory, fail.
-  llvm::StringRef pdb_file;
-  auto ec = obj->getDebugPDBInfo(pdb_info, pdb_file);
-  if (ec)
-return nullptr;
+auto *obj = llvm::dyn_cast(binary.getBinary());
+if (!obj)
+  return nullptr;
+
+const llvm::codeview::DebugInfo *pdb_info = nullptr;
+llvm::StringRef pdb_file_name_ref;
+if (obj->getDebugPDBInfo(pdb_info, pdb_file_name_ref)) {
+  // If it doesn't have a debug directory, fail.
+  return nullptr;
+}
+pdb_file = pdb_file_name_ref;
+
+// Extract the debug GUID from the debug directory
+memcpy(&guid, pdb_info->PDB70.Signature, sizeof(guid));
+  } else {
+// If the file isn't a PE/COFF executable, look for the PDB in the
+// current directory. This provides a basic solution for debugging minidumps
+// although it's only a stop-gap (until we implement a SymbolVendor)
+//
+// TODO: Implement a SymbolVendor for PDBs.
+//
+llvm::consumeError(expected_binary.takeError());
+pdb_file = obj_file->GetFileSpec()
+   .GetFileNameStrippingExtension()
+   .GetStringRef()
+   .str();
+pdb_file += ".pdb";
+
+// Extract the debug GUID from the ObjectFile
+lldb_private::UUID uuid;
+obj_file->GetUUID(&uuid);
+auto uuid_bytes = uuid.GetBytes();
+if (uuid_bytes.size() != sizeof(llvm::codeview::GUID) + 4) // CvRecordPdb70
+  return nullptr;
+memcpy(&guid, uuid_bytes.data(), sizeof(guid));
+  }
 
   // if the file doesn't exist, is not a pdb, or doesn't have a matching guid,
   // fail.
   llvm::file_magic magic;
-  ec = llvm::identify_magic(pdb_file, magic);
+  auto ec = llvm::identify_magic(pdb_file, magic);
   if (ec || magic != llvm::file_magic::pdb)
 return nullptr;
   std::unique_ptr pdb = loadPDBFile(pdb_file, allocator);
@@ -140,11 +167,11 @@
 llvm::consumeError(expected_info.takeError());
 return nullptr;
   }
-  llvm::codeview::GUID guid;
-  memcpy(&guid, pdb_info->PDB70.Signature, 16);
 
+  // TODO: we need to compare the age, in addition to the GUID
   if (expected_info->getGuid() != guid)
 return nullptr;
+
   return pdb;
 }
 
@@ -521,7 +548,7 @@
   if (!m_index) {
 // Lazily load and match the PDB file, but only do this once.
 std::unique_ptr file_up =
-loadMatchingPDBFile(m_obj_file->GetFileSpec().GetPath(), m_allocator);
+loadMatchingPDBFile(m_obj_file, m_allocator);
 
 if (!file_up) {
   auto module_sp = m_obj_file->GetModule();
@@ -1459,11 +1486,10 @@
 llvm::Optional modi = m_index->GetModuleIndexForVa(file_addr);
 if (!modi)
   return 0;
-CompilandIndexItem *cci = m_index->compilands().GetCompiland(*modi);
-if (!cci)
+if (!m_index->compilands().HasCompilandInfo(*modi))
   return 0;
-
-sc.comp_unit = GetOrCreateCo

[Lldb-commits] [PATCH] D55230: [lit] Multiple build outputs and default target bitness

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

LLDB :: BuildScript/toolchain-clang-cl.test is failing on Linux.

  2018-12-05T17:59:42.1570845Z Command Output (stderr):
  2018-12-05T17:59:42.1582271Z --
  2018-12-05T17:59:42.1593369Z Traceback (most recent call last):
  2018-12-05T17:59:42.1604689Z   File 
"/home/e2admin/vstsdrive/_work/51/s/llvm/tools/lldb/lit/helper/build.py", line 
723, in 
  2018-12-05T17:59:42.1615962Z build(cmds)
  2018-12-05T17:59:42.1627379Z   File 
"/home/e2admin/vstsdrive/_work/51/s/llvm/tools/lldb/lit/helper/build.py", line 
621, in build
  2018-12-05T17:59:42.1794738Z print_environment(env)
  2018-12-05T17:59:42.1806250Z   File 
"/home/e2admin/vstsdrive/_work/51/s/llvm/tools/lldb/lit/helper/build.py", line 
154, in print_environment
  2018-12-05T17:59:42.1817473Z for e in env:
  2018-12-05T17:59:42.1837821Z TypeError: 'NoneType' object is not iterable
  2018-12-05T17:59:42.1850161Z 
/home/e2admin/vstsdrive/_work/51/s/llvm/tools/lldb/lit/BuildScript/toolchain-clang-cl.test:13:11:
 error: CHECK-32: expected string not found in input
  2018-12-05T17:59:42.1861865Z CHECK-32: Output: 
{{.*}}toolchain-clang-cl.test.tmp\foo.exe
  2018-12-05T17:59:42.1872878Z   ^
  2018-12-05T17:59:42.1883892Z :5:2: note: scanning from here
  2018-12-05T17:59:42.1895337Z  Output: 
/home/e2admin/vstsdrive/_work/51/b/LLVMBuild/tools/lldb/lit/BuildScript/Output/toolchain-clang-cl.test.tmp/foo.exe
  2018-12-05T17:59:42.1906629Z  ^
  2018-12-05T17:59:42.1917610Z :5:82: note: possible intended match here
  2018-12-05T17:59:42.1929075Z  Output: 
/home/e2admin/vstsdrive/_work/51/b/LLVMBuild/tools/lldb/lit/BuildScript/Output/toolchain-clang-cl.test.tmp/foo.exe
  2018-12-05T17:59:42.1940723Z  
^
  2018-12-05T17:59:42.1946391Z 
  2018-12-05T17:59:42.1957310Z --


Repository:
  rL LLVM

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

https://reviews.llvm.org/D55230



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

[Lldb-commits] [PATCH] D54942: [PDB] Make PDB lit tests use the new builder

[Stella Stamenova via Phabricator via lldb-commits]

stella.stamenova added a comment.

enums-layout.test is now failing on Windows:

http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/1938/steps/test/logs/stdio


Repository:
  rL LLVM

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

https://reviews.llvm.org/D54942



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

[Lldb-commits] [PATCH] D54942: [PDB] Make PDB lit tests use the new builder

[Aleksandr Urakov via Phabricator via lldb-commits]

aleksandr.urakov added a comment.

It looks strange. The compiler can't open the object file. And in the next 
build it is ok - may be it was some server failure (e.g. full disk)?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D54942



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

[Lldb-commits] [PATCH] D55142: Minidump debugging using the native PDB reader

[Mark Mentovai via Phabricator via lldb-commits]

markmentovai added a comment.

This seems like a step in the right direction.


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

https://reviews.llvm.org/D55142



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

[Lldb-commits] [PATCH] D54942: [PDB] Make PDB lit tests use the new builder

[Aleksandr Urakov via Phabricator via lldb-commits]

aleksandr.urakov added a subscriber: zturner.
aleksandr.urakov added a comment.

The similar problem with `typedefs.test` is here: 
http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/1940/steps/test/logs/stdio

I have an assumption about the cause of the problem. Are the tests running in 
parallel? In this case `typedefs.test` and `enums-layout.test` are writing to 
the same object file together, because they both are compiled from the same 
source.

@zturner Is it possible to specify object file's name in `compile-and-link` 
mode? Then we can specify different names in different tests for both object 
files and executables. But I think that splitting the source or combining the 
tests would be a better idea.

I will fix it only tomorrow, because I'm already at home today. Feel free to 
revert it if needed.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D54942



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

Re: [Lldb-commits] [PATCH] D54942: [PDB] Make PDB lit tests use the new builder

[Zachary Turner via lldb-commits]

It is not possible to specify object file name in compile and link mode.
But perhaps we can just change the default object file name to include
something from the output file as well
On Wed, Dec 5, 2018 at 12:26 PM Aleksandr Urakov via Phabricator <
revi...@reviews.llvm.org> wrote:

> aleksandr.urakov added a subscriber: zturner.
> aleksandr.urakov added a comment.
>
> The similar problem with `typedefs.test` is here:
> http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/1940/steps/test/logs/stdio
>
> I have an assumption about the cause of the problem. Are the tests running
> in parallel? In this case `typedefs.test` and `enums-layout.test` are
> writing to the same object file together, because they both are compiled
> from the same source.
>
> @zturner Is it possible to specify object file's name in
> `compile-and-link` mode? Then we can specify different names in different
> tests for both object files and executables. But I think that splitting the
> source or combining the tests would be a better idea.
>
> I will fix it only tomorrow, because I'm already at home today. Feel free
> to revert it if needed.
>
>
> Repository:
>   rL LLVM
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D54942/new/
>
> https://reviews.llvm.org/D54942
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D55318: [Expressions] Add support of expressions evaluation in some object's context

[Jim Ingham via Phabricator via lldb-commits]

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

This is a little bit odd, but it does make it easy to call methods on a value 
you got from FindVariable without having to cons up an expression.  That seems 
worthwhile.

It would be good to add a little more explanation of what this is doing in the 
docs: "in the context of the object" is a little vague.

You should add some tests where the operation doesn't make sense, for instance 
what if the SBValue is a scalar?  Or what if it is an expression result so it's 
not in memory.  You have some error handling in the patch but your test doesn't 
exercise it.  Be good to make sure that actually works.

You also only test the case where the value is a struct, can you test a pointer 
to a struct and an ObjC class?  They both should work but you don't have tests 
for them.

As an implementation detail, the fact that lldb has to get local variable 
lookup right by textually injecting the local variables declarations into the 
expression is a bug, these should be provided on demand from the ASTSource.  
But that doesn't work correctly at present - the AST source gets asked AFTER 
looking in the class context which is to late - and we have do the local 
variable insertion trick instead.  So if we ever fix the bug in clang lookup, 
your implementation will break, and you will have to interfere in that lookup 
instead.  But that's for the future.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D55318



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

Re: [Lldb-commits] [PATCH] D54942: [PDB] Make PDB lit tests use the new builder

[Aleksandr Urakov via lldb-commits]

With such solution there would be even no need to change the current
commit. But I'm not sure that it's trivial to do - the output file name may
contain path with directories. May be we can replace slashes with
underscores in the output file path and concatenate it with the object file
name? Or even replace slashes in the source file path and concatenate it
with the output file path - so object files will be located in the same
place as the output file.

Am Mi., 5. Dez. 2018, 23:30 hat Zachary Turner 
geschrieben:

> It is not possible to specify object file name in compile and link mode.
> But perhaps we can just change the default object file name to include
> something from the output file as well
> On Wed, Dec 5, 2018 at 12:26 PM Aleksandr Urakov via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> aleksandr.urakov added a subscriber: zturner.
>> aleksandr.urakov added a comment.
>>
>> The similar problem with `typedefs.test` is here:
>> http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/1940/steps/test/logs/stdio
>>
>> I have an assumption about the cause of the problem. Are the tests
>> running in parallel? In this case `typedefs.test` and `enums-layout.test`
>> are writing to the same object file together, because they both are
>> compiled from the same source.
>>
>> @zturner Is it possible to specify object file's name in
>> `compile-and-link` mode? Then we can specify different names in different
>> tests for both object files and executables. But I think that splitting the
>> source or combining the tests would be a better idea.
>>
>> I will fix it only tomorrow, because I'm already at home today. Feel free
>> to revert it if needed.
>>
>>
>> Repository:
>>   rL LLVM
>>
>> CHANGES SINCE LAST ACTION
>>   https://reviews.llvm.org/D54942/new/
>>
>> https://reviews.llvm.org/D54942
>>
>>
>>
>>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Re: [Lldb-commits] [PATCH] D54942: [PDB] Make PDB lit tests use the new builder

[Stella Stamenova via lldb-commits]

I think with all the tests running in parallel we should err on the side of 
having unique names for everything automatically generated.

From: Aleksandr Urakov 
Sent: Wednesday, December 5, 2018 12:48 PM
To: Zachary Turner 
Cc: reviews+d54942+public+2603ca548f36d...@reviews.llvm.org; Stella Stamenova 
; llvm-comm...@lists.llvm.org; abidh@gmail.com; 
teempe...@gmail.com; lldb-commits@lists.llvm.org; sani...@subpath.org; 
chi...@raincode.com; b.gia...@gmail.com
Subject: Re: [PATCH] D54942: [PDB] Make PDB lit tests use the new builder

With such solution there would be even no need to change the current commit. 
But I'm not sure that it's trivial to do - the output file name may contain 
path with directories. May be we can replace slashes with underscores in the 
output file path and concatenate it with the object file name? Or even replace 
slashes in the source file path and concatenate it with the output file path - 
so object files will be located in the same place as the output file.
Am Mi., 5. Dez. 2018, 23:30 hat Zachary Turner 
mailto:ztur...@google.com>> geschrieben:
It is not possible to specify object file name in compile and link mode. But 
perhaps we can just change the default object file name to include something 
from the output file as well
On Wed, Dec 5, 2018 at 12:26 PM Aleksandr Urakov via Phabricator 
mailto:revi...@reviews.llvm.org>> wrote:
aleksandr.urakov added a subscriber: zturner.
aleksandr.urakov added a comment.

The similar problem with `typedefs.test` is here: 
http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/1940/steps/test/logs/stdio

I have an assumption about the cause of the problem. Are the tests running in 
parallel? In this case `typedefs.test` and `enums-layout.test` are writing to 
the same object file together, because they both are compiled from the same 
source.

@zturner Is it possible to specify object file's name in `compile-and-link` 
mode? Then we can specify different names in different tests for both object 
files and executables. But I think that splitting the source or combining the 
tests would be a better idea.

I will fix it only tomorrow, because I'm already at home today. Feel free to 
revert it if needed.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D54942


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

Re: [Lldb-commits] [PATCH] D54942: [PDB] Make PDB lit tests use the new builder

[Zachary Turner via lldb-commits]

I was thinking that we could just automatically compute the output file
names as:

os.path.join(out_dir, basename(output_file) + '.' + basename(input_file) +
'.obj')

Currently it's just

os.path.join(out_dir, basename(input_file) + '.obj')

which is why I think the problem occurs.

On Wed, Dec 5, 2018 at 12:47 PM Aleksandr Urakov <
aleksandr.ura...@jetbrains.com> wrote:

> With such solution there would be even no need to change the current
> commit. But I'm not sure that it's trivial to do - the output file name may
> contain path with directories. May be we can replace slashes with
> underscores in the output file path and concatenate it with the object file
> name? Or even replace slashes in the source file path and concatenate it
> with the output file path - so object files will be located in the same
> place as the output file.
>
> Am Mi., 5. Dez. 2018, 23:30 hat Zachary Turner 
> geschrieben:
>
>> It is not possible to specify object file name in compile and link mode.
>> But perhaps we can just change the default object file name to include
>> something from the output file as well
>> On Wed, Dec 5, 2018 at 12:26 PM Aleksandr Urakov via Phabricator <
>> revi...@reviews.llvm.org> wrote:
>>
>>> aleksandr.urakov added a subscriber: zturner.
>>> aleksandr.urakov added a comment.
>>>
>>> The similar problem with `typedefs.test` is here:
>>> http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/1940/steps/test/logs/stdio
>>>
>>> I have an assumption about the cause of the problem. Are the tests
>>> running in parallel? In this case `typedefs.test` and `enums-layout.test`
>>> are writing to the same object file together, because they both are
>>> compiled from the same source.
>>>
>>> @zturner Is it possible to specify object file's name in
>>> `compile-and-link` mode? Then we can specify different names in different
>>> tests for both object files and executables. But I think that splitting the
>>> source or combining the tests would be a better idea.
>>>
>>> I will fix it only tomorrow, because I'm already at home today. Feel
>>> free to revert it if needed.
>>>
>>>
>>> Repository:
>>>   rL LLVM
>>>
>>> CHANGES SINCE LAST ACTION
>>>   https://reviews.llvm.org/D54942/new/
>>>
>>> https://reviews.llvm.org/D54942
>>>
>>>
>>>
>>>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

[Lldb-commits] [PATCH] D44072: [lldb] Retrieve currently handled Obj-C exception via __cxa_current_exception_type and add GetCurrentExceptionBacktrace SB ABI

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

This looks good.  Can you add two more tests:

1. Can you add a step to your tests that shows fetching the current exception 
object from a thread that doesn't have an exception does the right thing (i.e. 
nothing).
2. Since C++ and ObjC exceptions use the same mechanism can you test that at 
abort after an uncaught C++ exception, getting the exception for the thread 
also does nothing (i.e. doesn't crash or produce some mangled object).


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

https://reviews.llvm.org/D44072



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

[Lldb-commits] [lldb] r348435 - [lldbsuite] Disable TestStopPCs when there's no XML support

[Stella Stamenova via lldb-commits]

Author: stella.stamenova
Date: Wed Dec  5 16:11:17 2018
New Revision: 348435

URL: http://llvm.org/viewvc/llvm-project?rev=348435&view=rev
Log:
[lldbsuite] Disable TestStopPCs when there's no XML support

The test relies on xml support to setup the correct registers. If there's no 
XML support, the test is going to fail.

Modified:

lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py

Modified: 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py?rev=348435&r1=348434&r2=348435&view=diff
==
--- 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
 (original)
+++ 
lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestStopPCs.py
 Wed Dec  5 16:11:17 2018
@@ -6,6 +6,8 @@ from gdbclientutils import *
 
 
 class TestStopPCs(GDBRemoteTestBase):
+
+@skipIfXmlSupportMissing
 def test(self):
 class MyResponder(MockGDBServerResponder):
 def haltReason(self):


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

[Lldb-commits] [lldb] r348440 - Add a unit test for ArchSpec matching to document how it behaves (and test it).

[Adrian Prantl via lldb-commits]

Author: adrian
Date: Wed Dec  5 16:43:55 2018
New Revision: 348440

URL: http://llvm.org/viewvc/llvm-project?rev=348440&view=rev
Log:
Add a unit test for ArchSpec matching to document how it behaves (and test it).

Modified:
lldb/trunk/source/Utility/ArchSpec.cpp
lldb/trunk/unittests/Utility/ArchSpecTest.cpp

Modified: lldb/trunk/source/Utility/ArchSpec.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Utility/ArchSpec.cpp?rev=348440&r1=348439&r2=348440&view=diff
==
--- lldb/trunk/source/Utility/ArchSpec.cpp (original)
+++ lldb/trunk/source/Utility/ArchSpec.cpp Wed Dec  5 16:43:55 2018
@@ -1019,7 +1019,7 @@ bool ArchSpec::IsCompatibleMatch(const A
   return IsEqualTo(rhs, false);
 }
 
-static bool isCompatibleEnvironment(llvm::Triple::EnvironmentType lhs,
+static bool IsCompatibleEnvironment(llvm::Triple::EnvironmentType lhs,
 llvm::Triple::EnvironmentType rhs) {
   if (lhs == rhs)
 return true;
@@ -1096,7 +1096,7 @@ bool ArchSpec::IsEqualTo(const ArchSpec
 const llvm::Triple::EnvironmentType rhs_triple_env =
 rhs_triple.getEnvironment();
 
-if (!isCompatibleEnvironment(lhs_triple_env, rhs_triple_env))
+if (!IsCompatibleEnvironment(lhs_triple_env, rhs_triple_env))
   return false;
 return true;
   }

Modified: lldb/trunk/unittests/Utility/ArchSpecTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Utility/ArchSpecTest.cpp?rev=348440&r1=348439&r2=348440&view=diff
==
--- lldb/trunk/unittests/Utility/ArchSpecTest.cpp (original)
+++ lldb/trunk/unittests/Utility/ArchSpecTest.cpp Wed Dec  5 16:43:55 2018
@@ -171,3 +171,53 @@ TEST(ArchSpecTest, MergeFromMachOUnknown
   A.MergeFrom(B);
   ASSERT_EQ(A.GetCore(), ArchSpec::eCore_uknownMach64);
 }
+
+TEST(ArchSpecTest, Compatibility) {
+  {
+ArchSpec A("x86_64-apple-macosx10.12");
+ArchSpec B("x86_64-apple-macosx10.12");
+ASSERT_TRUE(A.IsExactMatch(B));
+ASSERT_TRUE(A.IsCompatibleMatch(B));
+  }
+  {
+// The version information is auxiliary to support availablity but
+// doesn't affect compatibility.
+ArchSpec A("x86_64-apple-macosx10.11");
+ArchSpec B("x86_64-apple-macosx10.12");
+ASSERT_TRUE(A.IsExactMatch(B));
+ASSERT_TRUE(A.IsCompatibleMatch(B));
+  }
+  {
+ArchSpec A("x86_64-apple-macosx10.13");
+ArchSpec B("x86_64h-apple-macosx10.13");
+ASSERT_FALSE(A.IsExactMatch(B));
+ASSERT_TRUE(A.IsCompatibleMatch(B));
+  }
+  {
+ArchSpec A("x86_64-apple-macosx");
+ArchSpec B("x86_64-apple-ios-simulator");
+ASSERT_FALSE(A.IsExactMatch(B));
+ASSERT_FALSE(A.IsCompatibleMatch(B));
+  }
+  {
+ArchSpec A("x86_64-*-*");
+ArchSpec B("x86_64-apple-ios-simulator");
+ASSERT_FALSE(A.IsExactMatch(B));
+ASSERT_FALSE(A.IsCompatibleMatch(B));
+  }
+  {
+ArchSpec A("arm64-*-*");
+ArchSpec B("arm64-apple-ios");
+ASSERT_FALSE(A.IsExactMatch(B));
+// FIXME: This looks unintuitive and we should investigate whether
+// thi is the desired behavior.
+ASSERT_FALSE(A.IsCompatibleMatch(B));
+  }
+  {
+ArchSpec A("x86_64-*-*");
+ArchSpec B("x86_64-apple-ios-simulator");
+ASSERT_FALSE(A.IsExactMatch(B));
+// FIXME: See above, though the extra environment complicates things.
+ASSERT_FALSE(A.IsCompatibleMatch(B));
+  }
+}


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