[Lldb-commits] [PATCH] D80659: [lldb-vscode] Redirect stderr and stdout to DAPs console message

2020-09-29 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Sorry, I confused this with the patch that was wrapping stderr into DAP 
messages.

Having python output break the protocol is definitely not good. Fixing it would 
be nice, but the solution should work on windows as well.

One possibility I'd consider is making this fix at the python level (as this is 
a python problem). We already are trying to do some stdin/out/err redirection 
there, but it seems it's not good enough. It seems it should be easy enough 
(though hacky, but all of this is going to be hacky anyway) to replace 
`sys.stdin/out/err` with a custom wrapper object.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80659

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


[Lldb-commits] [PATCH] D88229: Reland "[lldb] Don't send invalid region addresses to lldb server"

2020-09-29 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.

Thanks for tracking this down.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88229

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


[Lldb-commits] [PATCH] D88249: [lldb] Make protected ctor and method of SBAddress take a const reference instead of a pointer.

2020-09-29 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

cool




Comment at: lldb/source/API/SBValue.cpp:1359
 
-  return LLDB_RECORD_RESULT(SBAddress(new Address(addr)));
+  return LLDB_RECORD_RESULT(SBAddress(Address(addr)));
 }

the `Address(` part is redundant.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88249

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


[Lldb-commits] [PATCH] D88266: Check that the "StructuredData Plugin weak pointer" is good before trying to turn it into a shared pointer

2020-09-29 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/include/lldb/Core/StructuredDataImpl.h:72-74
+lldb::StructuredDataPluginSP plugin_sp;
+if (!m_plugin_wp.expired())
+  plugin_sp = lldb::StructuredDataPluginSP(m_plugin_wp);

This is racy. The right way to do that is to call `m_plugin_wp.lock()` and then 
check the validity of the returned shared_ptr.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88266

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


[Lldb-commits] [PATCH] D88375: Fix MIPS and MIPS64 ABI to use ConstString in thier register info arrays.

2020-09-29 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

Not long ago. I added a `MCBasedABI` class which makes this goo mostly 
disappear as it gets its information from llvm MC layer. I haven't converted 
the mips abi due to a combination of being preempted by higher priority task, 
not having a mips machine to test on, and this code not being particularly 
egregious.

But if anyone wants to try this (and better yet, has ability to test it), I 
would strongly encourage converting these classes to an MCBasedABI. The only 
gotcha there is that the names of registers used by llvm mc and lldb/other 
tools don't always match, so it's sometimes necessary to write a small 
translation function. But that's still better than hundreds of lines of goo.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88375

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


[Lldb-commits] [PATCH] D88483: Add possibility to get module from SBType

2020-09-29 Thread Ilya Bukonkin via Phabricator via lldb-commits
fallkrum created this revision.
fallkrum added reviewers: jingham, LLDB.
fallkrum added a project: LLDB.
Herald added subscribers: lldb-commits, JDevlieghere.
Herald added a reviewer: JDevlieghere.
fallkrum requested review of this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88483

Files:
  lldb/bindings/interface/SBType.i
  lldb/include/lldb/API/SBModule.h
  lldb/include/lldb/API/SBType.h
  lldb/include/lldb/Symbol/Type.h
  lldb/source/API/SBType.cpp
  lldb/source/Symbol/Type.cpp

Index: lldb/source/Symbol/Type.cpp
===
--- lldb/source/Symbol/Type.cpp
+++ lldb/source/Symbol/Type.cpp
@@ -727,6 +727,15 @@
   return ModuleSP();
 }
 
+ModuleSP Type::GetExeModule() {
+if (m_compiler_type) {
+SymbolFile *symbol_file =
+m_compiler_type.GetTypeSystem()->GetSymbolFile();
+return symbol_file->GetObjectFile()->GetModule();
+}
+return ModuleSP();
+}
+
 TypeAndOrName::TypeAndOrName(TypeSP &in_type_sp) {
   if (in_type_sp) {
 m_compiler_type = in_type_sp->GetForwardCompilerType();
@@ -821,7 +830,8 @@
 void TypeImpl::SetType(const lldb::TypeSP &type_sp) {
   if (type_sp) {
 m_static_type = type_sp->GetForwardCompilerType();
-m_module_wp = type_sp->GetModule();
+  m_exe_module_wp = type_sp->GetExeModule();
+  m_module_wp = type_sp->GetModule();
   } else {
 m_static_type.Clear();
 m_module_wp = lldb::ModuleWP();
@@ -847,6 +857,14 @@
 }
 
 bool TypeImpl::CheckModule(lldb::ModuleSP &module_sp) const {
+return CheckModuleCommon(m_module_wp, module_sp);
+}
+
+bool TypeImpl::CheckExeModule(lldb::ModuleSP &module_sp) const {
+return CheckModuleCommon(m_exe_module_wp, module_sp);
+}
+
+bool TypeImpl::CheckModuleCommon(const lldb::ModuleWP &input_module_wp, lldb::ModuleSP &module_sp) const {
   // Check if we have a module for this type. If we do and the shared pointer
   // is can be successfully initialized with m_module_wp, return true. Else
   // return false if we didn't have a module, or if we had a module and it has
@@ -855,7 +873,7 @@
   // this function returns true. If we have a module, the "module_sp" will be
   // filled in with a strong reference to the module so that the module will at
   // least stay around long enough for the type query to succeed.
-  module_sp = m_module_wp.lock();
+  module_sp = input_module_wp.lock();
   if (!module_sp) {
 lldb::ModuleWP empty_module_wp;
 // If either call to "std::weak_ptr::owner_before(...) value returns true,
@@ -863,9 +881,9 @@
 // reference to a valid shared pointer. This helps us know if we had a
 // valid reference to a section which is now invalid because the module it
 // was in was deleted
-if (empty_module_wp.owner_before(m_module_wp) ||
-m_module_wp.owner_before(empty_module_wp)) {
-  // m_module_wp had a valid reference to a module, but all strong
+if (empty_module_wp.owner_before(input_module_wp) ||
+input_module_wp.owner_before(empty_module_wp)) {
+  // input_module_wp had a valid reference to a module, but all strong
   // references have been released and the module has been deleted
   return false;
 }
@@ -899,6 +917,13 @@
   m_dynamic_type.Clear();
 }
 
+ModuleSP TypeImpl::GetModule() {
+lldb::ModuleSP module_sp;
+if(CheckExeModule(module_sp))
+return module_sp;
+return nullptr;
+}
+
 ConstString TypeImpl::GetName() const {
   ModuleSP module_sp;
   if (CheckModule(module_sp)) {
Index: lldb/source/API/SBType.cpp
===
--- lldb/source/API/SBType.cpp
+++ lldb/source/API/SBType.cpp
@@ -17,6 +17,7 @@
 #include "lldb/Symbol/TypeSystem.h"
 #include "lldb/Utility/ConstString.h"
 #include "lldb/Utility/Stream.h"
+#include "lldb/API/SBModule.h"
 
 #include "llvm/ADT/APSInt.h"
 
@@ -495,6 +496,17 @@
   return m_opaque_sp->GetCompilerType(true).GetTypeInfo();
 }
 
+lldb::SBModule SBType::GetModule() {
+LLDB_RECORD_METHOD_NO_ARGS(lldb::SBModule, SBType, GetModule);
+
+lldb::SBModule sb_module;
+if (!IsValid())
+return sb_module;
+
+sb_module.SetSP(m_opaque_sp->GetModule());
+return sb_module;
+}
+
 const char *SBType::GetName() {
   LLDB_RECORD_METHOD_NO_ARGS(const char *, SBType, GetName);
 
@@ -950,6 +962,7 @@
(uint32_t));
   LLDB_REGISTER_METHOD(bool, SBType, IsTypeComplete, ());
   LLDB_REGISTER_METHOD(uint32_t, SBType, GetTypeFlags, ());
+LLDB_REGISTER_METHOD(lldb::SBModule, SBType, GetModule, ());
   LLDB_REGISTER_METHOD(const char *, SBType, GetName, ());
   LLDB_REGISTER_METHOD(const char *, SBType, GetDisplayTypeName, ());
   LLDB_REGISTER_METHOD(lldb::TypeClass, SBType, GetTypeClass, ());
Index: lldb/include/lldb/Symbol/Type.h
===
--- lldb/include/lldb/Symbol/Type.h
+++ lldb/include/lldb/Symbol/Type.h
@@ -114,6 +114,14 @@
 

[Lldb-commits] [PATCH] D87172: Check if debug line sequences are starting after the first code segment

2020-09-29 Thread Pavel Labath via Phabricator via lldb-commits
labath added inline comments.



Comment at: lldb/unittests/SymbolFile/DWARF/SymbolFileDWARFTests.cpp:349-369
+
+TEST_F(SymbolFileDWARFTests, EnsureLineEntriesExistInAfterFirstCodeSection) {
+  auto ExpectedFile = TestFile::fromYamlFile("test-invalid-addresses.yaml");
+  ASSERT_THAT_EXPECTED(ExpectedFile, llvm::Succeeded());
+
+  lldb::ModuleSP module_sp =
+  std::make_shared(ExpectedFile->moduleSpec());

aadsm wrote:
> labath wrote:
> > I think this would be better as a shell test (if for nothing else, then 
> > because other line table tests are written that way). `image lookup` is 
> > pretty much a direct equivalent to `ResolveSymbolContext`, but its output 
> > is more readable, and its easier to fiddle with these kinds of tests.
> I think what you describe is an end to end test but here I explicitly want to 
> test the SymbolFileDWARF code because that's what I changed, it's more like a 
> unit test.
> I would prefer to stay away from an end to end test for this particular 
> change because 1) knowing that `image lookup` calls `ResolveSymbolContext` is 
> an implementation detail 2) The output of `image lookup` could change over 
> time, 3) Other bugs unrelated to this could be introduced that will make 
> `image lookup` show a different content as well and fail the test.
On most days I am a proponent of unit tests, so I feel slightly odd for writing 
this, but here it goes...

I think you'll find that a lot of people in the llvm community (which now has a 
pretty big (but not as big as I'd like) intersection with the lldb community) 
are not very enthusiastic about (c++) unit tests. They concede they have their 
place, but are generally trying to avoid it. Some would rather create a brand 
new command line tool wrapping an api (and then test that via lit) than to 
write a unit test for it. Some effects of that can be seen in the design of the 
lldb-test tool.

Although this approach, when taken to extremes, can be bad, I believe it has 
it's advantages, for several reasons:
- changing the test does not require recompilation
- due to more people using it, more people are aware of how these tests work 
(easier for them to inspect/modify it)
- for similar reasons, the infrastructure supporting these tests is better. 
E.g., for the lit test, I can choose whether to generate the test binary via 
yaml2obj, llvm-mc, clang, or something completely different. unit tests only 
have yaml2obj available and for a long time it was implemented by shelling out 
to the external binary.

Your points about the issues with lit tests are not untrue, but I wouldn't say 
they are more true for this test than they are for any other of our lit tests, 
so I don't see a need to treat this test specially.

It's definitely true that the lit test will be more broad that this unit test, 
but it's still pretty far from a end-to-end test. A lot of our end-to-end tests 
for dwarf features start by compiling some c++ codes (hoping it produces the 
right dwarf), running the code, and then inspecting the running process. That's 
something I'm trying to change (not very successfully). Compared to that, 
"image lookup" is peanuts. Although you the fact that it's implemented by 
`ResolveSymbolContext` is kind of an implementation detail, I would say that if 
it was *not* implemented this way (and e.g. reimplemented some of that 
functionality) that we have bigger problems.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87172

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


[Lldb-commits] [PATCH] D88483: Add possibility to get module from SBType

2020-09-29 Thread Med Ismail Bennani via Phabricator via lldb-commits
mib added a comment.

Spotted some little things here and there ... This patch lacks a test and would 
need some reformatting (`git clang-format HEAD~`) but other than that, looks ok 
to me.




Comment at: lldb/include/lldb/Symbol/Type.h:118
+/*
+ GetModule may return module for compile uint's object file.
+ GetExeModule returns module for executable object file that contains

Typo



Comment at: lldb/source/API/SBType.cpp:504
+if (!IsValid())
+return sb_module;
+

It would be nice to record the return value for the reproducers.



Comment at: lldb/source/API/SBType.cpp:507
+sb_module.SetSP(m_opaque_sp->GetModule());
+return sb_module;
+}

Same here


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88483

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


[Lldb-commits] [PATCH] D88483: Add possibility to get module from SBType

2020-09-29 Thread Ilya Bukonkin via Phabricator via lldb-commits
fallkrum added a comment.

In D88483#2300716 , @mib wrote:

> Spotted some little things here and there ... This patch lacks a test and 
> would need some reformatting (`git clang-format HEAD~`) but other than that, 
> looks ok to me.

Can I format and add tests in the very end? The issue of getting module from 
type turned out a bit tricky and I'm not sure I'v done it the right way. Would 
like to see opinions first so as not to format and rewrite tests in vain.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88483

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


[Lldb-commits] [PATCH] D87442: [lldb] Show flags for memory regions

2020-09-29 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

I think this patch for its test coverage.

The thing I'm not so sure about is the verbatim passing of the os-specific 
flags. That's nice for the purpose of displaying them to the user, but it can 
make things messy for programatic use, particularly if multiple platforms start 
using these. What's do you intend to do with these flags? Like how many of them 
are you going to actually use, and for what purpose?




Comment at: lldb/source/API/SBMemoryRegionInfo.cpp:127
+  Stream &strm = flags.ref();
+  strm.Printf("%s", m_opaque_up->GetFlags().c_str());
+

`strm << m_opaque_up->GetFlags()`



Comment at: lldb/source/Commands/CommandObjectMemory.cpp:1736
+result.AppendMessageWithFormatv("flags: {0}",
+range_info.GetFlags().c_str());
+  }

drop `.c_str()`



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1308
+  m_mem_region_cache.emplace_back(Info, file_spec);
+  Result = ST;
+  return true;

Is this needed. Given that the parsing will stop at the first error, `Result` 
should always be empty (success) at this point)...



Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:1319
+  // Linux kernel since 2.6.14 has /proc/{pid}/smaps
+  // if CONFIG_PROC_PAGE_MONITOR is enabled
+  auto BufferOrError = getProcFile(GetID(), "smaps");

Just for my own education: Does this mean that we will need to maintain both 
branches in perpetuity, as it is always possible to build kernels which don't 
have /smaps ?



Comment at: lldb/source/Plugins/Process/Utility/LinuxProcMaps.cpp:134
+  // Note: llvm::regex doesn't do character classes
+  RegularExpression expr("^[ ]*([A-za-z0-9_]+)[ ]*:(.*)");
+  if (expr.Execute(line, &matches)) {

Compiling the regex for each line is pretty wasteful. I don't think a regex is 
really needed here. I think you could just split the line on the first `:` 
character and check that lhs does not contain spaces.



Comment at: lldb/source/Plugins/Process/Utility/LinuxProcMaps.cpp:19
 
+enum MapKind { eMaps, eSMaps };
+

omjavaid wrote:
> May be consider converting this into a class enum.
And get rid of the leading `e`.



Comment at: 
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp:2498
+  response.PutCString("flags:");
+  response.PutCString(flags_str.c_str());
+  response.PutChar(';');

drop `.c_str()`



Comment at: lldb/source/Target/MemoryRegionInfo.cpp:21
+  while (flags.size()) {
+flags = flags.drop_while(iswspace);
+std::tie(flag, flags) = flags.split(' ');

`flags = flags.ltrim();`



Comment at: lldb/unittests/Process/Utility/CMakeLists.txt:5
+  LINK_LIBS
+ lldbPluginProcessLinux
+  )

Why is this needed?



Comment at: lldb/unittests/Process/Utility/CMakeLists.txt:8-9
+
+target_include_directories(LinuxProcMapsTests PRIVATE
+  ${LLDB_SOURCE_DIR}/source/Plugins/Process/Utility)

Just include the file as `Plugins/Process/Utility/LinuxProcMaps.h`



Comment at: lldb/unittests/Process/Utility/LinuxProcMapsTest.cpp:38
+  void SetUp() override {
+callback = [&](const MemoryRegionInfo &Info, const Status &ST) {
+  if (ST.Success()) {

`&`-capture here is dangerous. Capture what you need (this?) explicitly.



Comment at: lldb/unittests/Process/Utility/LinuxProcMapsTest.cpp:50-51
+  void check_regions(LinuxProcMapsTestParams params) {
+ASSERT_EQ(std::get<1>(params).size(), regions.size());
+ASSERT_EQ(std::get<1>(params), regions);
+ASSERT_EQ(std::get<2>(params), err_str);

`ASSERT_THAT(std::get<1>(params), testing::ContainerEq(regions));`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87442

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


[Lldb-commits] [lldb] d0ed45d - [lldb] Configure LLDB_FRAMEWORK_DIR in multi-generator builds

2020-09-29 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2020-09-29T08:56:31-07:00
New Revision: d0ed45dc920004bb7b6642d6086b4722443eeba2

URL: 
https://github.com/llvm/llvm-project/commit/d0ed45dc920004bb7b6642d6086b4722443eeba2
DIFF: 
https://github.com/llvm/llvm-project/commit/d0ed45dc920004bb7b6642d6086b4722443eeba2.diff

LOG: [lldb] Configure LLDB_FRAMEWORK_DIR in multi-generator builds

Added: 


Modified: 
lldb/test/API/CMakeLists.txt
lldb/utils/lldb-dotest/CMakeLists.txt
lldb/utils/lldb-dotest/lldb-dotest.in

Removed: 




diff  --git a/lldb/test/API/CMakeLists.txt b/lldb/test/API/CMakeLists.txt
index f07370adb5c2..6c7f54e39123 100644
--- a/lldb/test/API/CMakeLists.txt
+++ b/lldb/test/API/CMakeLists.txt
@@ -139,6 +139,7 @@ if(LLDB_BUILT_STANDALONE)
   string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} 
config_runtime_output_dir ${LLVM_RUNTIME_OUTPUT_INTDIR})
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_DOTEST_ARGS "${LLDB_DOTEST_ARGS}")
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_SOURCE_DIR "${LLDB_SOURCE_DIR}")
+  string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_FRAMEWORK_DIR "${LLDB_FRAMEWORK_DIR}")
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_BUILD_DIRECTORY "${LLDB_TEST_BUILD_DIRECTORY}")
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_EXECUTABLE "${LLDB_TEST_EXECUTABLE}")
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_COMPILER "${LLDB_TEST_COMPILER}")

diff  --git a/lldb/utils/lldb-dotest/CMakeLists.txt 
b/lldb/utils/lldb-dotest/CMakeLists.txt
index e5a73c2b1dec..2f9ba72d7b22 100644
--- a/lldb/utils/lldb-dotest/CMakeLists.txt
+++ b/lldb/utils/lldb-dotest/CMakeLists.txt
@@ -21,6 +21,7 @@ if(LLDB_BUILT_STANDALONE)
 string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} 
config_runtime_output_dir ${LLVM_RUNTIME_OUTPUT_INTDIR})
 string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_DOTEST_ARGS_CONFIGURED "${LLDB_DOTEST_ARGS}")
 string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_SOURCE_DIR_CONFIGURED "${LLDB_SOURCE_DIR}")
+string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_FRAMEWORK_DIR_CONFIGURED "${LLDB_FRAMEWORK_DIR}")
 string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_BUILD_DIRECTORY_CONFIGURED "${LLDB_TEST_BUILD_DIRECTORY}")
 string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_EXECUTABLE_CONFIGURED "${LLDB_TEST_EXECUTABLE}")
 string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_COMPILER_CONFIGURED "${LLDB_TEST_COMPILER}")
@@ -33,6 +34,7 @@ if(LLDB_BUILT_STANDALONE)
   # Multi-configuration generator like Xcode (with a matching config).
   string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} 
LLDB_DOTEST_ARGS_CONFIGURED "${LLDB_DOTEST_ARGS}")
   string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} 
LLDB_SOURCE_DIR_CONFIGURED "${LLDB_SOURCE_DIR}")
+  string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} 
LLDB_FRAMEWORK_DIR_CONFIGURED "${LLDB_FRAMEWORK_DIR}")
   string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} 
LLDB_TEST_BUILD_DIRECTORY_CONFIGURED "${LLDB_TEST_BUILD_DIRECTORY}")
   string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} 
LLDB_TEST_EXECUTABLE_CONFIGURED "${LLDB_TEST_EXECUTABLE}")
   string(REPLACE ${CMAKE_CFG_INTDIR} ${config_type} 
LLDB_TEST_COMPILER_CONFIGURED "${LLDB_TEST_COMPILER}")
@@ -44,6 +46,7 @@ if(LLDB_BUILT_STANDALONE)
   # Single-configuration generator like Ninja.
   string(REPLACE ${CMAKE_CFG_INTDIR} "." LLDB_DOTEST_ARGS_CONFIGURED 
"${LLDB_DOTEST_ARGS}")
   string(REPLACE ${CMAKE_CFG_INTDIR} "." LLDB_SOURCE_DIR_CONFIGURED 
"${LLDB_SOURCE_DIR}")
+  string(REPLACE ${CMAKE_CFG_INTDIR} "." LLDB_FRAMEWORK_DIR_CONFIGURED 
"${LLDB_FRAMEWORK_DIR}")
   string(REPLACE ${CMAKE_CFG_INTDIR} "." 
LLDB_TEST_BUILD_DIRECTORY_CONFIGURED "${LLDB_TEST_BUILD_DIRECTORY}")
   string(REPLACE ${CMAKE_CFG_INTDIR} "." LLDB_TEST_EXECUTABLE_CONFIGURED 
"${LLDB_TEST_EXECUTABLE}")
   string(REPLACE ${CMAKE_CFG_INTDIR} "." LLDB_TEST_COMPILER_CONFIGURED 
"${LLDB_TEST_COMPILER}")
@@ -63,6 +66,7 @@ elseif(NOT "${CMAKE_CFG_INTDIR}" STREQUAL ".")
 string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_DOTEST_DIR 
${LLVM_RUNTIME_OUTPUT_INTDIR})
 string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} 
LLDB_DOTEST_ARGS_CONFIGURED "${LLDB_DOTEST_ARGS}")
 string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} 
LLDB_SOURCE_DIR_CONFIGURED "${LLDB_SOURCE_DIR}")
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} 
LLDB_FRAMEWORK_DIR_CONFIGURED "${LLDB_FRAMEWORK_DIR}")
 string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} 
LLDB_TEST_BUILD

[Lldb-commits] [lldb] ccbb982 - [lldb] Also configure lldb_framework_dir in the lit.site.cfg.py

2020-09-29 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2020-09-29T09:13:26-07:00
New Revision: ccbb9827db4c30c93b92a204aeb2b98f9f3a723a

URL: 
https://github.com/llvm/llvm-project/commit/ccbb9827db4c30c93b92a204aeb2b98f9f3a723a
DIFF: 
https://github.com/llvm/llvm-project/commit/ccbb9827db4c30c93b92a204aeb2b98f9f3a723a.diff

LOG: [lldb] Also configure lldb_framework_dir in the lit.site.cfg.py

Configuring the variable in CMake isn't enought, because the build mode
can't be resolved until execution time, which requires the build mode to
be substituted by lit.

Added: 


Modified: 
lldb/test/API/lit.site.cfg.py.in

Removed: 




diff  --git a/lldb/test/API/lit.site.cfg.py.in 
b/lldb/test/API/lit.site.cfg.py.in
index f2e1f855fe39..144d17965b9a 100644
--- a/lldb/test/API/lit.site.cfg.py.in
+++ b/lldb/test/API/lit.site.cfg.py.in
@@ -59,6 +59,7 @@ try:
 config.dsymutil = config.dsymutil % lit_config.params
 config.filecheck = config.filecheck % lit_config.params
 config.yaml2obj = config.yaml2obj % lit_config.params
+config.lldb_framework_dir = config.lldb_framework_dir % lit_config.params
 config.dotest_args_str = config.dotest_args_str % lit_config.params
 except KeyError as e:
 key, = e.args



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


[Lldb-commits] [lldb] b4968c7 - [lldb] Remove redundant ctor call (NFC)

2020-09-29 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2020-09-29T10:05:12-07:00
New Revision: b4968c7001c2d7e2e607bef1bb11ae8f076e47e0

URL: 
https://github.com/llvm/llvm-project/commit/b4968c7001c2d7e2e607bef1bb11ae8f076e47e0
DIFF: 
https://github.com/llvm/llvm-project/commit/b4968c7001c2d7e2e607bef1bb11ae8f076e47e0.diff

LOG: [lldb] Remove redundant ctor call (NFC)

As pointed out by Pavel in D88249.

Added: 


Modified: 
lldb/source/API/SBValue.cpp

Removed: 




diff  --git a/lldb/source/API/SBValue.cpp b/lldb/source/API/SBValue.cpp
index 63518b4c4e3e..0a95cf41263d 100644
--- a/lldb/source/API/SBValue.cpp
+++ b/lldb/source/API/SBValue.cpp
@@ -1356,7 +1356,7 @@ lldb::SBAddress SBValue::GetAddress() {
 }
   }
 
-  return LLDB_RECORD_RESULT(SBAddress(Address(addr)));
+  return LLDB_RECORD_RESULT(SBAddress(addr));
 }
 
 lldb::SBData SBValue::GetPointeeData(uint32_t item_idx, uint32_t item_count) {



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


[Lldb-commits] [PATCH] D87172: Check if debug line sequences are starting after the first code segment

2020-09-29 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added inline comments.



Comment at: lldb/unittests/SymbolFile/DWARF/SymbolFileDWARFTests.cpp:369
+  EXPECT_EQ(section_sp->GetType(), eSectionTypeCode);
+}

I would rather deal with an  C++ unit test any day. Trying to track down what 
set of convoluted command line commands reproduce some lit test is quite 
annoying and takes me a lot more time to debug. I think this test is targeted 
and tests what is needed. I would vote to keep this one over converting to a 
text dump test. My main reasoning is that it isn't possible to re-create a 
compilable test case that will survive any compiler that it used (past, present 
and future), and all symbol resolution is done bone using this call in all 
cases. When something goes wrong, very easy to compile the binary and debug.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87172

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


[Lldb-commits] [PATCH] D87172: Check if debug line sequences are starting after the first code segment

2020-09-29 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added inline comments.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:437
+  m_supports_DW_AT_APPLE_objc_complete_type(eLazyBoolCalculate) {
+  auto first_code_section_sp =
+  m_objfile_sp->GetModule()->GetSectionList()->FindSectionByType(

labath wrote:
> This is really the _first_ text section (as listed in the section headers), 
> is it not? But, I assume you really want the section with the lowest file 
> address?
> 
> The linkers (and other producers) will normally output the sections in 
> ascending address order (because it's the simplest thing to do). However, I 
> don't believe that is actually required by anything, and I /think/ it should 
> be possible (with a moderately funky linker script) to produce a fully 
> functional executable which does not have the sections listed in this order.
We do need to iterate over all sections and find the one with the lowest 
address, good catch. No sorting is required in object files.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp:441
+  if (first_code_section_sp)
+m_first_code_address = first_code_section_sp->GetFileAddress();
+}

And doing the work in InitializeObject() is better.



Comment at: lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h:520
   std::vector m_lldb_cu_to_dwarf_unit;
+  /// Many linkers will concatenate all available DWARF, even if parts of that 
DWARF
+  /// should have been dead stripped. Some linkers will place tombstone values 
in for

Fine to reword this to not appear hostile toward the linkers. If any judgement 
should be passed, it should be on the DWARF format itself and how unfriendly it 
is to link!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87172

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


[Lldb-commits] [PATCH] D88266: Check that the "StructuredData Plugin weak pointer" is good before trying to turn it into a shared pointer

2020-09-29 Thread Jim Ingham via Phabricator via lldb-commits
jingham added inline comments.



Comment at: lldb/include/lldb/Core/StructuredDataImpl.h:72-74
+lldb::StructuredDataPluginSP plugin_sp;
+if (!m_plugin_wp.expired())
+  plugin_sp = lldb::StructuredDataPluginSP(m_plugin_wp);

labath wrote:
> This is racy. The right way to do that is to call `m_plugin_wp.lock()` and 
> then check the validity of the returned shared_ptr.
I tried that, but at least on the version of the STL on the latest macOS if the 
weak pointer has just been default initialized if you call lock on it it 
crashes.  expired was the only call I could make that didn't crash.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88266

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


[Lldb-commits] [lldb] 1b1d981 - Revert "Revert "Add the ability to write target stop-hooks using the ScriptInterpreter.""

2020-09-29 Thread Jim Ingham via lldb-commits

Author: Jim Ingham
Date: 2020-09-29T12:01:14-07:00
New Revision: 1b1d9815987a753f2f3524cfad050b85972dae5b

URL: 
https://github.com/llvm/llvm-project/commit/1b1d9815987a753f2f3524cfad050b85972dae5b
DIFF: 
https://github.com/llvm/llvm-project/commit/1b1d9815987a753f2f3524cfad050b85972dae5b.diff

LOG: Revert "Revert "Add the ability to write target stop-hooks using the 
ScriptInterpreter.""

This reverts commit f775fe59640a2e837ad059a8f40e26989d4f9831.

I fixed a return type error in the original patch that was causing a test 
failure.
Also added a REQUIRES: python to the shell test so we'll skip this for
people who build lldb w/o Python.
Also added another test for the error printing.

Added: 
lldb/test/API/commands/target/stop-hooks/TestStopHookScripted.py
lldb/test/API/commands/target/stop-hooks/stop_hook.py
lldb/test/Shell/Commands/Inputs/stop_hook.py
lldb/test/Shell/Commands/command-stop-hook-output.test

Modified: 
lldb/bindings/python/python-swigsafecast.swig
lldb/bindings/python/python-wrapper.swig
lldb/docs/use/python-reference.rst
lldb/include/lldb/Interpreter/ScriptInterpreter.h
lldb/include/lldb/Symbol/SymbolContext.h
lldb/include/lldb/Target/Target.h
lldb/source/Commands/CommandObjectTarget.cpp
lldb/source/Commands/Options.td
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp
lldb/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPythonImpl.h
lldb/source/Symbol/SymbolContext.cpp
lldb/source/Target/Target.cpp
lldb/test/API/commands/target/stop-hooks/TestStopHooks.py
lldb/test/API/commands/target/stop-hooks/main.c
lldb/unittests/ScriptInterpreter/Python/PythonTestSuite.cpp

Removed: 




diff  --git a/lldb/bindings/python/python-swigsafecast.swig 
b/lldb/bindings/python/python-swigsafecast.swig
index d5cafbfa67cb..091fc29b1057 100644
--- a/lldb/bindings/python/python-swigsafecast.swig
+++ b/lldb/bindings/python/python-swigsafecast.swig
@@ -152,3 +152,10 @@ SBTypeToSWIGWrapper (lldb::SBSymbolContext* sym_ctx_sb)
 {
 return SWIG_NewPointerObj((void *) sym_ctx_sb, 
SWIGTYPE_p_lldb__SBSymbolContext, 0);
 }
+
+template <>
+PyObject*
+SBTypeToSWIGWrapper (lldb::SBStream* stream_sb)
+{
+return SWIG_NewPointerObj((void *) stream_sb, SWIGTYPE_p_lldb__SBStream, 
0);
+}

diff  --git a/lldb/bindings/python/python-wrapper.swig 
b/lldb/bindings/python/python-wrapper.swig
index 516590ed5771..c00deba6073b 100644
--- a/lldb/bindings/python/python-wrapper.swig
+++ b/lldb/bindings/python/python-wrapper.swig
@@ -468,6 +468,127 @@ LLDBSwigPythonCallBreakpointResolver
 return ret_val;
 }
 
+SWIGEXPORT void *
+LLDBSwigPythonCreateScriptedStopHook
+(
+lldb::TargetSP target_sp,
+const char *python_class_name,
+const char *session_dictionary_name,
+lldb_private::StructuredDataImpl *args_impl,
+Status &error
+)
+{
+if (python_class_name == NULL || python_class_name[0] == '\0') {
+error.SetErrorString("Empty class name.");
+Py_RETURN_NONE;
+}
+if (!session_dictionary_name) {
+  error.SetErrorString("No session dictionary");
+  Py_RETURN_NONE;
+}
+
+PyErr_Cleaner py_err_cleaner(true);
+
+auto dict = 
+PythonModule::MainModule().ResolveName(
+session_dictionary_name);
+auto pfunc = 
+PythonObject::ResolveNameWithDictionary(
+python_class_name, dict);
+
+if (!pfunc.IsAllocated()) {
+error.SetErrorStringWithFormat("Could not find class: %s.", 
+   python_class_name);
+return nullptr;
+}
+
+lldb::SBTarget *target_val 
+= new lldb::SBTarget(target_sp);
+
+PythonObject target_arg(PyRefType::Owned, SBTypeToSWIGWrapper(target_val));
+
+lldb::SBStructuredData *args_value = new lldb::SBStructuredData(args_impl);
+PythonObject args_arg(PyRefType::Owned, SBTypeToSWIGWrapper(args_value));
+
+PythonObject result = pfunc(target_arg, args_arg, dict);
+
+if (result.IsAllocated())
+{
+// Check that the handle_stop callback is defined:
+auto callback_func = result.ResolveName("handle_stop");
+if (callback_func.IsAllocated()) {
+  if (auto args_info = callback_func.GetArgInfo()) {
+size_t num_args = (*args_info).max_positional_args; 
+if (num_args != 2) {
+  error.SetErrorStringWithFormat("Wrong number of args for "
+  "handle_stop callback, should be 2 (excluding self), got: %d", 
+  num_args);
+  Py_RETURN_NONE;
+} else
+  return result.release();
+  } else {
+error.SetErrorString("Couldn't get num arguments for handle_stop "
+ "callback.");
+Py_RETURN_NONE;
+  }
+  return result.release();
+}
+else {
+  error

[Lldb-commits] [lldb] 5d19eb5 - [lldb/docs] Remove manual codesigning documentation

2020-09-29 Thread Dave Lee via lldb-commits

Author: Dave Lee
Date: 2020-09-29T12:50:45-07:00
New Revision: 5d19eb542db40fc5fe9f37c46246785ba5ae1e10

URL: 
https://github.com/llvm/llvm-project/commit/5d19eb542db40fc5fe9f37c46246785ba5ae1e10
DIFF: 
https://github.com/llvm/llvm-project/commit/5d19eb542db40fc5fe9f37c46246785ba5ae1e10.diff

LOG: [lldb/docs] Remove manual codesigning documentation

The `macos-setup-codesign.sh` script has been in place for over two years. If 
there are no known issues, it's a good time to drop the manual steps from the 
docs.

Reviewed By: JDevlieghere

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

Added: 


Modified: 
lldb/docs/resources/build.rst

Removed: 




diff  --git a/lldb/docs/resources/build.rst b/lldb/docs/resources/build.rst
index 579f7574dac5..e22db7f6d8f9 100644
--- a/lldb/docs/resources/build.rst
+++ b/lldb/docs/resources/build.rst
@@ -575,8 +575,11 @@ Code Signing on macOS
 
 To use the in-tree debug server on macOS, lldb needs to be code signed. The
 Debug, DebugClang and Release builds are set to code sign using a code signing
-certificate named ``lldb_codesign``. This document explains how to set up the
-signing certificate.
+certificate named ``lldb_codesign``.
+
+Automatic setup, run:
+
+* ``scripts/macos-setup-codesign.sh``
 
 Note that it's possible to build and use lldb on macOS without setting up code
 signing by using the system's debug server. To configure lldb in this way with
@@ -589,56 +592,6 @@ build folders that contained old signed items. The darwin 
kernel will cache
 code signing using the executable's file system node, so you will need to
 delete the file so the kernel clears its cache.
 
-Automatic setup:
-
-* Run ``scripts/macos-setup-codesign.sh``
-
-Manual setup steps:
-
-* Launch /Applications/Utilities/Keychain Access.app
-* In Keychain Access select the ``login`` keychain in the ``Keychains`` list in
-  the upper left hand corner of the window.
-* Select the following menu item: Keychain Access->Certificate 
Assistant->Create a Certificate...
-* Set the following settings
-
-::
-
-   Name = lldb_codesign
-   Identity Type = Self Signed Root
-   Certificate Type = Code Signing
-
-* Click Create
-* Click Continue
-* Click Done
-* Click on the "My Certificates"
-* Double click on your new ``lldb_codesign`` certificate
-* Turn down the "Trust" disclosure triangle, scroll to the "Code Signing" trust
-  pulldown menu and select "Always Trust" and authenticate as needed using your
-  username and password.
-* Drag the new ``lldb_codesign`` code signing certificate (not the public or
-  private keys of the same name) from the ``login`` keychain to the ``System``
-  keychain in the Keychains pane on the left hand side of the main Keychain
-  Access window. This will move this certificate to the ``System`` keychain.
-  You'll have to authorize a few more times, set it to be "Always trusted" when
-  asked.
-* Remove ``~/Desktop/lldb_codesign.cer`` file on your desktop if there is one.
-* In the Keychain Access GUI, click and drag ``lldb_codesign`` in the
-  ``System`` keychain onto the desktop. The drag will create a
-  ``Desktop/lldb_codesign.cer`` file used in the next step.
-* Switch to Terminal, and run the following:
-
-::
-
-  sudo security add-trust -d -r trustRoot -p basic -p codeSign -k 
/Library/Keychains/System.keychain ~/Desktop/lldb_codesign.cer
-  rm -f ~/Desktop/lldb_codesign.cer
-
-* Drag the ``lldb_codesign`` certificate from the ``System`` keychain back into
-  the ``login`` keychain
-* Quit Keychain Access
-* Reboot
-* Clean by removing all previously creating code signed binaries and rebuild
-  lldb and you should be able to debug.
-
 When you build your LLDB for the first time, the Xcode GUI will prompt you for
 permission to use the ``lldb_codesign`` keychain. Be sure to click "Always
 Allow" on your first build. From here on out, the ``lldb_codesign`` will be



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


[Lldb-commits] [PATCH] D88257: [lldb/docs] Remove manual codesigning documentation

2020-09-29 Thread Dave Lee via Phabricator via lldb-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5d19eb542db4: [lldb/docs] Remove manual codesigning 
documentation (authored by kastiglione).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88257

Files:
  lldb/docs/resources/build.rst


Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -575,8 +575,11 @@
 
 To use the in-tree debug server on macOS, lldb needs to be code signed. The
 Debug, DebugClang and Release builds are set to code sign using a code signing
-certificate named ``lldb_codesign``. This document explains how to set up the
-signing certificate.
+certificate named ``lldb_codesign``.
+
+Automatic setup, run:
+
+* ``scripts/macos-setup-codesign.sh``
 
 Note that it's possible to build and use lldb on macOS without setting up code
 signing by using the system's debug server. To configure lldb in this way with
@@ -589,56 +592,6 @@
 code signing using the executable's file system node, so you will need to
 delete the file so the kernel clears its cache.
 
-Automatic setup:
-
-* Run ``scripts/macos-setup-codesign.sh``
-
-Manual setup steps:
-
-* Launch /Applications/Utilities/Keychain Access.app
-* In Keychain Access select the ``login`` keychain in the ``Keychains`` list in
-  the upper left hand corner of the window.
-* Select the following menu item: Keychain Access->Certificate 
Assistant->Create a Certificate...
-* Set the following settings
-
-::
-
-   Name = lldb_codesign
-   Identity Type = Self Signed Root
-   Certificate Type = Code Signing
-
-* Click Create
-* Click Continue
-* Click Done
-* Click on the "My Certificates"
-* Double click on your new ``lldb_codesign`` certificate
-* Turn down the "Trust" disclosure triangle, scroll to the "Code Signing" trust
-  pulldown menu and select "Always Trust" and authenticate as needed using your
-  username and password.
-* Drag the new ``lldb_codesign`` code signing certificate (not the public or
-  private keys of the same name) from the ``login`` keychain to the ``System``
-  keychain in the Keychains pane on the left hand side of the main Keychain
-  Access window. This will move this certificate to the ``System`` keychain.
-  You'll have to authorize a few more times, set it to be "Always trusted" when
-  asked.
-* Remove ``~/Desktop/lldb_codesign.cer`` file on your desktop if there is one.
-* In the Keychain Access GUI, click and drag ``lldb_codesign`` in the
-  ``System`` keychain onto the desktop. The drag will create a
-  ``Desktop/lldb_codesign.cer`` file used in the next step.
-* Switch to Terminal, and run the following:
-
-::
-
-  sudo security add-trust -d -r trustRoot -p basic -p codeSign -k 
/Library/Keychains/System.keychain ~/Desktop/lldb_codesign.cer
-  rm -f ~/Desktop/lldb_codesign.cer
-
-* Drag the ``lldb_codesign`` certificate from the ``System`` keychain back into
-  the ``login`` keychain
-* Quit Keychain Access
-* Reboot
-* Clean by removing all previously creating code signed binaries and rebuild
-  lldb and you should be able to debug.
-
 When you build your LLDB for the first time, the Xcode GUI will prompt you for
 permission to use the ``lldb_codesign`` keychain. Be sure to click "Always
 Allow" on your first build. From here on out, the ``lldb_codesign`` will be


Index: lldb/docs/resources/build.rst
===
--- lldb/docs/resources/build.rst
+++ lldb/docs/resources/build.rst
@@ -575,8 +575,11 @@
 
 To use the in-tree debug server on macOS, lldb needs to be code signed. The
 Debug, DebugClang and Release builds are set to code sign using a code signing
-certificate named ``lldb_codesign``. This document explains how to set up the
-signing certificate.
+certificate named ``lldb_codesign``.
+
+Automatic setup, run:
+
+* ``scripts/macos-setup-codesign.sh``
 
 Note that it's possible to build and use lldb on macOS without setting up code
 signing by using the system's debug server. To configure lldb in this way with
@@ -589,56 +592,6 @@
 code signing using the executable's file system node, so you will need to
 delete the file so the kernel clears its cache.
 
-Automatic setup:
-
-* Run ``scripts/macos-setup-codesign.sh``
-
-Manual setup steps:
-
-* Launch /Applications/Utilities/Keychain Access.app
-* In Keychain Access select the ``login`` keychain in the ``Keychains`` list in
-  the upper left hand corner of the window.
-* Select the following menu item: Keychain Access->Certificate Assistant->Create a Certificate...
-* Set the following settings
-
-::
-
-	Name = lldb_codesign
-	Identity Type = Self Signed Root
-	Certificate Type = Code Signing
-
-* Click Create
-* Click Continue
-* Click Done
-* Click on the "My Certificates"
-* Double clic

[Lldb-commits] [lldb] 92e1ebe - [trace] Fix destructor declaration

2020-09-29 Thread Walter Erquinigo via lldb-commits

Author: Walter Erquinigo
Date: 2020-09-29T13:09:52-07:00
New Revision: 92e1ebeaa1fe0e5461327d071c55167733834e60

URL: 
https://github.com/llvm/llvm-project/commit/92e1ebeaa1fe0e5461327d071c55167733834e60
DIFF: 
https://github.com/llvm/llvm-project/commit/92e1ebeaa1fe0e5461327d071c55167733834e60.diff

LOG: [trace] Fix destructor declaration

The destructor must be defined in the implementation class so that it
can be called, as Vedant Kumar pointed out in:

'''
What were your thoughts, re:

+class Trace : public PluginInterface {
+public:
+  ~Trace() override = default;

   Does this need to be `virtual ~Trace() = ...`?

  Otherwise, when a std::shared_ptr is destroyed, the
  destructor for the derived TraceIntelPT instance won't run.
'''

Added: 


Modified: 
lldb/include/lldb/Target/Trace.h
lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h

Removed: 




diff  --git a/lldb/include/lldb/Target/Trace.h 
b/lldb/include/lldb/Target/Trace.h
index e4e9b1aa88a7..0aa2da7dbad4 100644
--- a/lldb/include/lldb/Target/Trace.h
+++ b/lldb/include/lldb/Target/Trace.h
@@ -35,8 +35,6 @@ namespace lldb_private {
 /// this information.
 class Trace : public PluginInterface {
 public:
-  ~Trace() override = default;
-
   /// Dump the trace data that this plug-in has access to.
   ///
   /// This function will dump all of the trace data for all threads in a user

diff  --git a/lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h 
b/lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
index edc781e08ad4..d221caff3c18 100644
--- a/lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
+++ b/lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
@@ -20,6 +20,8 @@ class TraceIntelPT : public lldb_private::Trace {
 public:
   void Dump(lldb_private::Stream *s) const override;
 
+  ~TraceIntelPT() override = default;
+
   /// PluginInterface protocol
   /// \{
   lldb_private::ConstString GetPluginName() override;



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


[Lldb-commits] [lldb] 3c7070f - [lldb] Hoist --server argument out of LLDB_TEST_COMMON_ARGS (NFC)

2020-09-29 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2020-09-29T13:27:29-07:00
New Revision: 3c7070f1a6b89277fce042a943cd83fa65507a67

URL: 
https://github.com/llvm/llvm-project/commit/3c7070f1a6b89277fce042a943cd83fa65507a67
DIFF: 
https://github.com/llvm/llvm-project/commit/3c7070f1a6b89277fce042a943cd83fa65507a67.diff

LOG: [lldb] Hoist --server argument out of LLDB_TEST_COMMON_ARGS (NFC)

Give the server argument its own variable (LLDB_TEST_SERVER) so that we
can configure it in lit.site.cfg.py if we so desire.

Added: 


Modified: 
lldb/test/API/CMakeLists.txt
lldb/test/API/lit.cfg.py
lldb/test/API/lit.site.cfg.py.in
lldb/utils/lldb-dotest/CMakeLists.txt
lldb/utils/lldb-dotest/lldb-dotest.in

Removed: 




diff  --git a/lldb/test/API/CMakeLists.txt b/lldb/test/API/CMakeLists.txt
index 6c7f54e39123..fe92012e3767 100644
--- a/lldb/test/API/CMakeLists.txt
+++ b/lldb/test/API/CMakeLists.txt
@@ -119,12 +119,12 @@ if(CMAKE_HOST_APPLE)
   elseif(TARGET debugserver)
 set(debugserver_path ${LLVM_RUNTIME_OUTPUT_INTDIR}/debugserver)
 message(STATUS "LLDB Tests use just-built debugserver: 
${debugserver_path}")
-list(APPEND LLDB_TEST_COMMON_ARGS --server ${debugserver_path})
+set(LLDB_TEST_SERVER ${debugserver_path})
 add_lldb_test_dependency(debugserver)
   elseif(TARGET lldb-server)
 set(lldb_server_path ${LLVM_RUNTIME_OUTPUT_INTDIR}/lldb-server)
 message(STATUS "LLDB Tests use just-built lldb-server: 
${lldb_server_path}")
-list(APPEND LLDB_TEST_COMMON_ARGS --server ${lldb_server_path})
+set(LLDB_TEST_SERVER ${lldb_server_path})
 add_lldb_test_dependency(lldb-server)
   else()
 message(WARNING "LLDB Tests enabled, but no server available")
@@ -146,6 +146,7 @@ if(LLDB_BUILT_STANDALONE)
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_DSYMUTIL "${LLDB_TEST_DSYMUTIL}")
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_FILECHECK "${LLDB_TEST_FILECHECK}")
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_YAML2OBJ "${LLDB_TEST_YAML2OBJ}")
+  string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_SERVER "${LLDB_TEST_SERVER}")
 
   # Remaining ones must be paths to the provided LLVM build-tree.
   if(LLVM_CONFIGURATION_TYPES)
@@ -174,6 +175,7 @@ string(REPLACE ${CMAKE_CFG_INTDIR} 
${dotest_args_replacement} LLDB_TEST_COMPILER
 string(REPLACE ${CMAKE_CFG_INTDIR} ${dotest_args_replacement} 
LLDB_TEST_DSYMUTIL "${LLDB_TEST_DSYMUTIL}")
 string(REPLACE ${CMAKE_CFG_INTDIR} ${dotest_args_replacement} 
LLDB_TEST_FILECHECK "${LLDB_TEST_FILECHECK}")
 string(REPLACE ${CMAKE_CFG_INTDIR} ${dotest_args_replacement} 
LLDB_TEST_YAML2OBJ "${LLDB_TEST_YAML2OBJ}")
+string(REPLACE ${CMAKE_CFG_INTDIR} ${dotest_args_replacement} LLDB_TEST_SERVER 
"${LLDB_TEST_SERVER}")
 
 # Configure the API test suite.
 configure_lit_site_cfg(

diff  --git a/lldb/test/API/lit.cfg.py b/lldb/test/API/lit.cfg.py
index 893418cc16d3..d78a1aae5467 100644
--- a/lldb/test/API/lit.cfg.py
+++ b/lldb/test/API/lit.cfg.py
@@ -200,6 +200,9 @@ def delete_module_cache(path):
 if is_configured('yaml2obj'):
   dotest_cmd += ['--yaml2obj', config.yaml2obj]
 
+if is_configured('server'):
+  dotest_cmd += ['--server', config.server]
+
 if is_configured('lldb_libs_dir'):
   dotest_cmd += ['--lldb-libs-dir', config.lldb_libs_dir]
 

diff  --git a/lldb/test/API/lit.site.cfg.py.in 
b/lldb/test/API/lit.site.cfg.py.in
index 144d17965b9a..271faf371f9d 100644
--- a/lldb/test/API/lit.site.cfg.py.in
+++ b/lldb/test/API/lit.site.cfg.py.in
@@ -31,6 +31,7 @@ config.test_compiler = '@LLDB_TEST_COMPILER@'
 config.dsymutil = '@LLDB_TEST_DSYMUTIL@'
 config.filecheck = '@LLDB_TEST_FILECHECK@'
 config.yaml2obj = '@LLDB_TEST_YAML2OBJ@'
+config.server = '@LLDB_TEST_SERVER@'
 # The API tests use their own module caches.
 config.lldb_module_cache = os.path.join("@LLDB_TEST_MODULE_CACHE_LLDB@", 
"lldb-api")
 config.clang_module_cache = os.path.join("@LLDB_TEST_MODULE_CACHE_CLANG@", 
"lldb-api")
@@ -59,6 +60,7 @@ try:
 config.dsymutil = config.dsymutil % lit_config.params
 config.filecheck = config.filecheck % lit_config.params
 config.yaml2obj = config.yaml2obj % lit_config.params
+config.server = config.server % lit_config.params
 config.lldb_framework_dir = config.lldb_framework_dir % lit_config.params
 config.dotest_args_str = config.dotest_args_str % lit_config.params
 except KeyError as e:

diff  --git a/lldb/utils/lldb-dotest/CMakeLists.txt 
b/lldb/utils/lldb-dotest/CMakeLists.txt
index 2f9ba72d7b22..1001fbf04ebe 100644
--- a/lldb/utils/lldb-dotest/CMakeLists.txt
+++ b/lldb/utils/lldb-dotest/CMakeLists.txt
@@ -28,6 +28,7 @@ if(LLDB_BUILT_STANDALONE)
 string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_DSYMUTIL_CONFIGURED "${LLDB_TEST_DSYMUTIL}")
 string(REPL

[Lldb-commits] [PATCH] D88513: [lldb-vscode] Allow an empty 'breakpoints' field to clear breakpoints.

2020-09-29 Thread Jordan Rupprecht via Phabricator via lldb-commits
rupprecht created this revision.
rupprecht added reviewers: wallace, clayborg, labath.
Herald added a reviewer: JDevlieghere.
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.
rupprecht requested review of this revision.

Per the DAP spec for SetBreakpoints [1], the way to clear breakpoints is: `To 
clear all breakpoint for a source, specify an empty array.`

However, leaving the breakpoints field unset is also a well formed request 
(note the `breakpoints?:` in the `SetBreakpointsArguments` definition). If it's 
unset, we have a couple choices:

1. Crash (current behavior)
2. Clear breakpoints
3. Return an error response that the breakpoints field is missing.

I propose we do (2) instead of (1), and treat an unset breakpoints field the 
same as an empty breakpoints field.

[1] 
https://microsoft.github.io/debug-adapter-protocol/specification#Requests_SetBreakpoints


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D88513

Files:
  lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
  lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
  lldb/tools/lldb-vscode/lldb-vscode.cpp

Index: lldb/tools/lldb-vscode/lldb-vscode.cpp
===
--- lldb/tools/lldb-vscode/lldb-vscode.cpp
+++ lldb/tools/lldb-vscode/lldb-vscode.cpp
@@ -1936,27 +1936,32 @@
 
   // Decode the source breakpoint infos for this "setBreakpoints" request
   SourceBreakpointMap request_bps;
-  for (const auto &bp : *breakpoints) {
-auto bp_obj = bp.getAsObject();
-if (bp_obj) {
-  SourceBreakpoint src_bp(*bp_obj);
-  request_bps[src_bp.line] = src_bp;
-
-  // We check if this breakpoint already exists to update it
-  auto existing_source_bps = g_vsc.source_breakpoints.find(path);
-  if (existing_source_bps != g_vsc.source_breakpoints.end()) {
-const auto &existing_bp = existing_source_bps->second.find(src_bp.line);
-if (existing_bp != existing_source_bps->second.end()) {
-  existing_bp->second.UpdateBreakpoint(src_bp);
-  AppendBreakpoint(existing_bp->second.bp, response_breakpoints, path,
-   src_bp.line);
-  continue;
+  // "breakpoints" may be unset, in which case we treat it the same as being set
+  // to an empty array.
+  if (breakpoints) {
+for (const auto &bp : *breakpoints) {
+  auto bp_obj = bp.getAsObject();
+  if (bp_obj) {
+SourceBreakpoint src_bp(*bp_obj);
+request_bps[src_bp.line] = src_bp;
+
+// We check if this breakpoint already exists to update it
+auto existing_source_bps = g_vsc.source_breakpoints.find(path);
+if (existing_source_bps != g_vsc.source_breakpoints.end()) {
+  const auto &existing_bp =
+  existing_source_bps->second.find(src_bp.line);
+  if (existing_bp != existing_source_bps->second.end()) {
+existing_bp->second.UpdateBreakpoint(src_bp);
+AppendBreakpoint(existing_bp->second.bp, response_breakpoints, path,
+ src_bp.line);
+continue;
+  }
 }
+// At this point the breakpoint is new
+src_bp.SetBreakpoint(path.data());
+AppendBreakpoint(src_bp.bp, response_breakpoints, path, src_bp.line);
+g_vsc.source_breakpoints[path][src_bp.line] = std::move(src_bp);
   }
-  // At this point the breakpoint is new
-  src_bp.SetBreakpoint(path.data());
-  AppendBreakpoint(src_bp.bp, response_breakpoints, path, src_bp.line);
-  g_vsc.source_breakpoints[path][src_bp.line] = std::move(src_bp);
 }
   }
 
Index: lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
===
--- lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
+++ lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py
@@ -219,6 +219,47 @@
 self.assertTrue(breakpoint['verified'],
 "expect breakpoint still verified")
 
+@skipIfWindows
+@skipIfRemote
+def test_clear_breakpoints_unset_breakpoints(self):
+'''Test clearing breakpoints like test_set_and_clear, but clear
+   breakpoints by omitting the breakpoints array instead of sending an
+   empty one.'''
+lines = [line_number('main.cpp', 'break 12')]
+
+# Visual Studio Code Debug Adaptors have no way to specify the file
+# without launching or attaching to a process, so we must start a
+# process in order to be able to set breakpoints.
+program = self.getBuildArtifact("a.out")
+self.build_and_launch(program)
+
+# Set one breakpoint and verify that it got set correctly.
+response = self.vscode.request_setBreakpoints(self.main_path, lines)
+line_to_id = {}
+breakpoints = response['body']['breakpoints']
+self.assertE

[Lldb-commits] [PATCH] D88266: Check that the "StructuredData Plugin weak pointer" is good before trying to turn it into a shared pointer

2020-09-29 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added inline comments.



Comment at: lldb/include/lldb/Core/StructuredDataImpl.h:72-74
+lldb::StructuredDataPluginSP plugin_sp;
+if (!m_plugin_wp.expired())
+  plugin_sp = lldb::StructuredDataPluginSP(m_plugin_wp);

jingham wrote:
> labath wrote:
> > This is racy. The right way to do that is to call `m_plugin_wp.lock()` and 
> > then check the validity of the returned shared_ptr.
> I tried that, but at least on the version of the STL on the latest macOS if 
> the weak pointer has just been default initialized if you call lock on it it 
> crashes.  expired was the only call I could make that didn't crash.
> I tried that, but at least on the version of the STL on the latest macOS if 
> the weak pointer has just been default initialized if you call lock on it it 
> crashes.  expired was the only call I could make that didn't crash.

that seems like a pretty serious bug?! This should be fixed or any use of 
std::weak_ptr would crash?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88266

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


[Lldb-commits] [PATCH] D88266: Check that the "StructuredData Plugin weak pointer" is good before trying to turn it into a shared pointer

2020-09-29 Thread Greg Clayton via Phabricator via lldb-commits
clayborg added a comment.

Jim: were you able to repro this with a simple a.out program? Is there 
something worse going on here like maybe incompatible libc++/libstdc++ 
implementations?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88266

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


[Lldb-commits] [PATCH] D88516: [lldb] Add a "design" section to the documentation.

2020-09-29 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere created this revision.
JDevlieghere added a reviewer: LLDB.
Herald added a subscriber: arphaman.
JDevlieghere requested review of this revision.

Create a "Design" section for the LLDB documentation. The goal would be to have 
design documents that describe how the LLDB internals work. Currently they're 
mixed together under the "Development" section which hurts discoverability and 
makes it harder to understand where a new page should go. The existing pages 
describing the reproducers, the structured data plugins, and the SB API could 
be housed here but I'd love to see more pages being added here in the future.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D88516

Files:
  lldb/docs/.htaccess
  lldb/docs/design/reproducers.rst
  lldb/docs/design/sbapi.rst
  lldb/docs/design/structureddataplugins.md
  lldb/docs/index.rst
  lldb/docs/resources/reproducers.rst
  lldb/docs/resources/sbapi.rst
  lldb/docs/resources/structureddataplugins.md


Index: lldb/docs/index.rst
===
--- lldb/docs/index.rst
+++ lldb/docs/index.rst
@@ -145,11 +145,18 @@
resources/build
resources/test
resources/bots
-   resources/reproducers
-   resources/structureddataplugins
-   resources/sbapi
resources/caveats
 
+
+.. toctree::
+   :hidden:
+   :maxdepth: 1
+   :caption: Design
+
+   design/reproducers
+   design/structureddataplugins
+   design/sbapi
+
 .. toctree::
:hidden:
:maxdepth: 1
Index: lldb/docs/.htaccess
===
--- lldb/docs/.htaccess
+++ lldb/docs/.htaccess
@@ -9,6 +9,8 @@
 Redirect 301 /source.html https://lldb.llvm.org/resources/contributing.html
 Redirect 301 /tutorial.html https://lldb.llvm.org/use/tutorial.html
 Redirect 301 /varformats.html https://lldb.llvm.org/use/variable.html
+Redirect 301 /resources/reproducers.html 
https://lldb.llvm.org/design/reproducers.html
+Redirect 301 /resources/sbapi.html https://lldb.llvm.org/design/sbapi.html
 
 # Sphinx redirects
 Redirect 301 /resources/source.html 
https://lldb.llvm.org/resources/contributing.html


Index: lldb/docs/index.rst
===
--- lldb/docs/index.rst
+++ lldb/docs/index.rst
@@ -145,11 +145,18 @@
resources/build
resources/test
resources/bots
-   resources/reproducers
-   resources/structureddataplugins
-   resources/sbapi
resources/caveats
 
+
+.. toctree::
+   :hidden:
+   :maxdepth: 1
+   :caption: Design
+
+   design/reproducers
+   design/structureddataplugins
+   design/sbapi
+
 .. toctree::
:hidden:
:maxdepth: 1
Index: lldb/docs/.htaccess
===
--- lldb/docs/.htaccess
+++ lldb/docs/.htaccess
@@ -9,6 +9,8 @@
 Redirect 301 /source.html https://lldb.llvm.org/resources/contributing.html
 Redirect 301 /tutorial.html https://lldb.llvm.org/use/tutorial.html
 Redirect 301 /varformats.html https://lldb.llvm.org/use/variable.html
+Redirect 301 /resources/reproducers.html https://lldb.llvm.org/design/reproducers.html
+Redirect 301 /resources/sbapi.html https://lldb.llvm.org/design/sbapi.html
 
 # Sphinx redirects
 Redirect 301 /resources/source.html https://lldb.llvm.org/resources/contributing.html
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D88513: [lldb-vscode] Allow an empty 'breakpoints' field to clear breakpoints.

2020-09-29 Thread walter erquinigo via Phabricator via lldb-commits
wallace accepted this revision.
wallace added a comment.
This revision is now accepted and ready to land.

Very good! Thank you




Comment at: 
lldb/test/API/tools/lldb-vscode/breakpoint/TestVSCode_setBreakpoints.py:228
+   empty one.'''
+lines = [line_number('main.cpp', 'break 12')]
+

you might want to add one additional breakpoint here to make the test more 
robust


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88513

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


[Lldb-commits] [lldb] 2f95c50 - Fix use of wrong printf format specifier for size_t argument.

2020-09-29 Thread Richard Smith via lldb-commits

Author: Richard Smith
Date: 2020-09-29T16:02:08-07:00
New Revision: 2f95c50a8b713970c5134dabc246270111a48c6d

URL: 
https://github.com/llvm/llvm-project/commit/2f95c50a8b713970c5134dabc246270111a48c6d
DIFF: 
https://github.com/llvm/llvm-project/commit/2f95c50a8b713970c5134dabc246270111a48c6d.diff

LOG: Fix use of wrong printf format specifier for size_t argument.

This causes a build break under -Werror=format.

Added: 


Modified: 
lldb/bindings/python/python-wrapper.swig

Removed: 




diff  --git a/lldb/bindings/python/python-wrapper.swig 
b/lldb/bindings/python/python-wrapper.swig
index c00deba6073b..443ddfb8dd20 100644
--- a/lldb/bindings/python/python-wrapper.swig
+++ b/lldb/bindings/python/python-wrapper.swig
@@ -521,7 +521,7 @@ LLDBSwigPythonCreateScriptedStopHook
 size_t num_args = (*args_info).max_positional_args; 
 if (num_args != 2) {
   error.SetErrorStringWithFormat("Wrong number of args for "
-  "handle_stop callback, should be 2 (excluding self), got: %d", 
+  "handle_stop callback, should be 2 (excluding self), got: %zu",
   num_args);
   Py_RETURN_NONE;
 } else



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


[Lldb-commits] [PATCH] D86670: [intel-pt] Add a basic implementation of the dump command

2020-09-29 Thread walter erquinigo via Phabricator via lldb-commits
wallace updated this revision to Diff 295145.
wallace added a comment.
Herald added a reviewer: JDevlieghere.

Rebased and did some code cleanup. The output of the dump command looks like 
this

Settings directory:

  
/home/wallace/llvm-sand/external/llvm-project/lldb/test/API/commands/trace/intelpt-trace

Trace files:

  pid: '1234', tid: '3842849', trace file: 
/home/wallace/llvm-sand/external/llvm-project/lldb/test/API/commands/trace/intelpt-trace/3842849.trace

Modules:

  uuid: 6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A, load address: 
0x0040, file: 
/home/wallace/llvm-sand/external/llvm-project/lldb/test/API/commands/trace/intelpt-trace/a.out


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86670

Files:
  lldb/include/lldb/Target/Target.h
  lldb/include/lldb/Target/Trace.h
  lldb/source/Commands/CommandObjectTrace.cpp
  lldb/source/Commands/Options.td
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
  lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
  lldb/source/Target/Target.cpp
  lldb/source/Target/Trace.cpp
  lldb/source/Target/TraceSettingsParser.cpp
  lldb/test/API/commands/trace/TestTraceDump.py
  lldb/test/API/commands/trace/TestTraceLoad.py
  lldb/test/API/commands/trace/intelpt-trace/trace2.json

Index: lldb/test/API/commands/trace/intelpt-trace/trace2.json
===
--- /dev/null
+++ lldb/test/API/commands/trace/intelpt-trace/trace2.json
@@ -0,0 +1,53 @@
+{
+  "trace": {
+"type": "intel-pt",
+"pt_cpu": {
+  "vendor": "intel",
+  "family": 6,
+  "model": 79,
+  "stepping": 1
+}
+  },
+  "processes": [
+{
+  "pid": 1,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 11,
+  "traceFile": "3842849.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x0040",
+  "uuid": "6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A"
+}
+  ]
+},
+{
+  "pid": 2,
+  "triple": "x86_64-*-linux",
+  "threads": [
+{
+  "tid": 21,
+  "traceFile": "3842849.trace"
+},
+{
+  "tid": 22,
+  "traceFile": "3842849.trace"
+}
+  ],
+  "modules": [
+{
+  "file": "a.out",
+  "systemPath": "a.out",
+  "loadAddress": "0x0040",
+  "uuid": "6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A"
+}
+  ]
+}
+  ]
+}
Index: lldb/test/API/commands/trace/TestTraceLoad.py
===
--- lldb/test/API/commands/trace/TestTraceLoad.py
+++ lldb/test/API/commands/trace/TestTraceLoad.py
@@ -92,3 +92,5 @@
 self.expect("trace load -v " + os.path.join(src_dir, "intelpt-trace", "trace_bad3.json"), error=True,
 substrs=['error: missing value at settings.processes[1].pid'])
 self.assertEqual(self.dbg.GetNumTargets(), 0)
+
+self.expect("trace dump", substrs=["error: no trace data in this target"])
Index: lldb/test/API/commands/trace/TestTraceDump.py
===
--- /dev/null
+++ lldb/test/API/commands/trace/TestTraceDump.py
@@ -0,0 +1,49 @@
+import lldb
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+from lldbsuite.test.decorators import *
+
+class TestTraceDump(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+NO_DEBUG_INFO_TESTCASE = True
+
+def setUp(self):
+TestBase.setUp(self)
+if 'intel-pt' not in configuration.enabled_plugins:
+self.skipTest("The intel-pt test plugin is not enabled")
+
+
+def testDumpTrace(self):
+self.expect("trace dump", substrs=["error: no trace data in this target"])
+
+src_dir = self.getSourceDir()
+trace_definition_file = os.path.join(src_dir, "intelpt-trace", "trace2.json")
+self.expect("trace load " + trace_definition_file)
+
+# An invalid thread id should show an error message
+self.expect("trace dump -t 5678", substrs=['error: the thread id "5678" does not exist in this target'])
+
+# Only the specified thread should be printed
+self.expect("trace dump -t 22", substrs=["Trace files"],
+  patterns=["pid: '2', tid: '22', trace file: .*/test/API/commands/trace/intelpt-trace/3842849.trace",
+"Modules:\n  uuid: 6AA9A4E2-6F28-2F33-377D-59FECE874C71-5B41261A, load address: 0x0040, file: .*intelpt-trace/a.out"])
+
+# Verbose should output the entire JSON settings besides the thread specific information
+self.expect("trace dump -t 22 -v",
+  substrs=["Settings", "3842849.trace", "intel-pt", "Settings directory"],
+  patterns=["pid: '2', tid: '22', trace file:

[Lldb-commits] [lldb] bd14d6e - [lldb] Hoist -s (trace directory) argument out of LLDB_TEST_COMMON_ARGS (NFC)

2020-09-29 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2020-09-29T17:23:33-07:00
New Revision: bd14d6ea1517c93ceecaec29dad016d9a122fa1b

URL: 
https://github.com/llvm/llvm-project/commit/bd14d6ea1517c93ceecaec29dad016d9a122fa1b
DIFF: 
https://github.com/llvm/llvm-project/commit/bd14d6ea1517c93ceecaec29dad016d9a122fa1b.diff

LOG: [lldb] Hoist -s (trace directory) argument out of LLDB_TEST_COMMON_ARGS 
(NFC)

Give the trace directory argument its own variable
(LLDB_TEST_TRACE_DIRECTORY) so that we can configure it in
lit.site.cfg.py if we so desire.

Added: 


Modified: 
lldb/test/API/CMakeLists.txt
lldb/test/API/lit.cfg.py
lldb/test/API/lit.site.cfg.py.in
lldb/utils/lldb-dotest/CMakeLists.txt
lldb/utils/lldb-dotest/lldb-dotest.in

Removed: 




diff  --git a/lldb/test/API/CMakeLists.txt b/lldb/test/API/CMakeLists.txt
index fe92012e3767..f4802e2f5ca2 100644
--- a/lldb/test/API/CMakeLists.txt
+++ b/lldb/test/API/CMakeLists.txt
@@ -36,13 +36,14 @@ set(LLDB_TEST_USER_ARGS
 # hash of filename and .text section, there *will* be conflicts inside
 # the build directory.
 set(LLDB_TEST_COMMON_ARGS
-  -s
-  ${CMAKE_BINARY_DIR}/lldb-test-traces
   -S nm
   -u CXXFLAGS
   -u CFLAGS
   )
 
+# Configure the traces directory.
+set(LLDB_TEST_TRACE_DIRECTORY "${PROJECT_BINARY_DIR}/lldb-test-traces" CACHE 
PATH "The test traces directory.")
+
 # Set the path to the default lldb test executable.
 set(LLDB_DEFAULT_TEST_EXECUTABLE 
"${LLVM_RUNTIME_OUTPUT_INTDIR}/lldb${CMAKE_EXECUTABLE_SUFFIX}")
 
@@ -141,6 +142,7 @@ if(LLDB_BUILT_STANDALONE)
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_SOURCE_DIR "${LLDB_SOURCE_DIR}")
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_FRAMEWORK_DIR "${LLDB_FRAMEWORK_DIR}")
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_BUILD_DIRECTORY "${LLDB_TEST_BUILD_DIRECTORY}")
+  string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_TRACE_DIRECTORY "${LLDB_TEST_TRACE_DIRECTORY}")
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_EXECUTABLE "${LLDB_TEST_EXECUTABLE}")
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_COMPILER "${LLDB_TEST_COMPILER}")
   string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_TEST_DSYMUTIL "${LLDB_TEST_DSYMUTIL}")
@@ -170,6 +172,7 @@ endif()
 string(REPLACE ${CMAKE_CFG_INTDIR} ${dotest_args_replacement} LLDB_DOTEST_ARGS 
"${LLDB_DOTEST_ARGS}")
 string(REPLACE ${CMAKE_CFG_INTDIR} ${dotest_args_replacement} LLDB_SOURCE_DIR 
"${LLDB_SOURCE_DIR}")
 string(REPLACE ${CMAKE_CFG_INTDIR} ${dotest_args_replacement} 
LLDB_TEST_BUILD_DIRECTORY "${LLDB_TEST_BUILD_DIRECTORY}")
+string(REPLACE ${CMAKE_CFG_INTDIR} ${dotest_args_replacement} 
LLDB_TEST_TRACE_DIRECTORY "${LLDB_TEST_TRACE_DIRECTORY}")
 string(REPLACE ${CMAKE_CFG_INTDIR} ${dotest_args_replacement} 
LLDB_TEST_EXECUTABLE "${LLDB_TEST_EXECUTABLE}")
 string(REPLACE ${CMAKE_CFG_INTDIR} ${dotest_args_replacement} 
LLDB_TEST_COMPILER "${LLDB_TEST_COMPILER}")
 string(REPLACE ${CMAKE_CFG_INTDIR} ${dotest_args_replacement} 
LLDB_TEST_DSYMUTIL "${LLDB_TEST_DSYMUTIL}")

diff  --git a/lldb/test/API/lit.cfg.py b/lldb/test/API/lit.cfg.py
index d78a1aae5467..a4d4d83fd366 100644
--- a/lldb/test/API/lit.cfg.py
+++ b/lldb/test/API/lit.cfg.py
@@ -177,6 +177,9 @@ def delete_module_cache(path):
 if is_configured('lldb_build_directory'):
   dotest_cmd += ['--build-dir', config.lldb_build_directory]
 
+if is_configured('lldb_trace_directory'):
+  dotest_cmd += ['-s', config.lldb_trace_directory]
+
 if is_configured('lldb_module_cache'):
   delete_module_cache(config.lldb_module_cache)
   dotest_cmd += ['--lldb-module-cache-dir', config.lldb_module_cache]

diff  --git a/lldb/test/API/lit.site.cfg.py.in 
b/lldb/test/API/lit.site.cfg.py.in
index 271faf371f9d..0481e8fecc73 100644
--- a/lldb/test/API/lit.site.cfg.py.in
+++ b/lldb/test/API/lit.site.cfg.py.in
@@ -19,6 +19,7 @@ config.shared_libs = @LLVM_ENABLE_SHARED_LIBS@
 config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
 config.target_triple = "@TARGET_TRIPLE@"
 config.lldb_build_directory = "@LLDB_TEST_BUILD_DIRECTORY@"
+config.lldb_trace_directory = "@LLDB_TEST_TRACE_DIRECTORY@"
 config.lldb_reproducer_directory = os.path.join("@LLDB_TEST_BUILD_DIRECTORY@", 
"reproducers")
 config.python_executable = "@Python3_EXECUTABLE@"
 config.dotest_args_str = "@LLDB_DOTEST_ARGS@"

diff  --git a/lldb/utils/lldb-dotest/CMakeLists.txt 
b/lldb/utils/lldb-dotest/CMakeLists.txt
index 1001fbf04ebe..cba04f3499b9 100644
--- a/lldb/utils/lldb-dotest/CMakeLists.txt
+++ b/lldb/utils/lldb-dotest/CMakeLists.txt
@@ -23,6 +23,7 @@ if(LLDB_BUILT_STANDALONE)
 string(REPLACE ${LLVM_RUNTIME_OUTPUT_INTDIR} ${config_runtime_output_dir} 
LLDB_SOURCE_DIR_CONFIGURED "${LLDB_SOURCE_DIR}")
 string(REPLACE ${LL

[Lldb-commits] [PATCH] D88266: Check that the "StructuredData Plugin weak pointer" is good before trying to turn it into a shared pointer

2020-09-29 Thread Jim Ingham via Phabricator via lldb-commits
jingham added a comment.

In D88266#2301934 , @clayborg wrote:

> Jim: were you able to repro this with a simple a.out program? Is there 
> something worse going on here like maybe incompatible libc++/libstdc++ 
> implementations?

The crash is pretty easy to repro.  This is pretty much what the code in 
question was doing:

  #include 
  
  class Foo {
  public:
int first = 10;
int second = 20;
std::weak_ptr my_wp;
  
Foo() : first(10), second(20), my_wp() {}
virtual int doSomething() {
  return first * second;
}
  };
  
  int
  main()
  {
Foo my_foo;
std::shared_ptr my_sp(my_foo.my_wp);
return my_sp.get() ? 0 : 1 ;
  }

Compile and run that on at least on macOS and you get:

   > ./tryit
  libc++abi.dylib: terminating with uncaught exception of type 
std::__1::bad_weak_ptr: bad_weak_ptr

And looking at the implementation, the SP constructor from a WP explicitly 
throws if the weak pointer's __cntrl is null.  I'm not sure why that is 
desirable, but it's clearly intended.

However, looking at the code again, the weak_ptr::lock call really should 
succeed, just returning an empty shared pointer.  And indeed, I can't reproduce 
that crash anymore.  I must have had some other changes I had made in the 
course of investigation lying around that were confusing the issue.

I've resubmitted the patch with the same set of changes, but making the SP by 
calling lock on the WP rather than calling the SP from WP constructor.




Comment at: lldb/include/lldb/Core/StructuredDataImpl.h:72-74
+lldb::StructuredDataPluginSP plugin_sp;
+if (!m_plugin_wp.expired())
+  plugin_sp = lldb::StructuredDataPluginSP(m_plugin_wp);

jingham wrote:
> labath wrote:
> > This is racy. The right way to do that is to call `m_plugin_wp.lock()` and 
> > then check the validity of the returned shared_ptr.
> I tried that, but at least on the version of the STL on the latest macOS if 
> the weak pointer has just been default initialized if you call lock on it it 
> crashes.  expired was the only call I could make that didn't crash.
To be clear.  I started looking at this because SBStructuredData.GetDescription 
was crashing at this line:

  plugin_sp = lldb::StructuredDataPluginSP(m_plugin_wp);

trying to lock the wp, in the case where m_plugin_wp is default initialized.  I 
also tried calling lock directly and unsurprisingly that also crashed.



Comment at: lldb/include/lldb/Core/StructuredDataImpl.h:72-74
+lldb::StructuredDataPluginSP plugin_sp;
+if (!m_plugin_wp.expired())
+  plugin_sp = lldb::StructuredDataPluginSP(m_plugin_wp);

jingham wrote:
> jingham wrote:
> > labath wrote:
> > > This is racy. The right way to do that is to call `m_plugin_wp.lock()` 
> > > and then check the validity of the returned shared_ptr.
> > I tried that, but at least on the version of the STL on the latest macOS if 
> > the weak pointer has just been default initialized if you call lock on it 
> > it crashes.  expired was the only call I could make that didn't crash.
> To be clear.  I started looking at this because 
> SBStructuredData.GetDescription was crashing at this line:
> 
>   plugin_sp = lldb::StructuredDataPluginSP(m_plugin_wp);
> 
> trying to lock the wp, in the case where m_plugin_wp is default initialized.  
> I also tried calling lock directly and unsurprisingly that also crashed.
What actually happens is that the lock call throws a "bad weak pointer" 
exception.  So maybe the correct programming approach it to try the lock and 
catch the exception?  But we build with rtti off and apparently w/o that you 
can't do try/catch (or at least that's what clang told me...)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88266

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


[Lldb-commits] [PATCH] D88266: Check that the "StructuredData Plugin weak pointer" is good before trying to turn it into a shared pointer

2020-09-29 Thread Jim Ingham via Phabricator via lldb-commits
jingham updated this revision to Diff 295156.
jingham added a comment.

Use std::weak_ptr::lock to make the shared pointer, rather than 
std::shared_ptr::shared_ptr(std::weak_ptr) (sort of), as the latter throws.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88266

Files:
  lldb/include/lldb/Core/StructuredDataImpl.h
  lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py


Index: lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
===
--- lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
+++ lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
@@ -35,6 +35,13 @@
 # Tests for invalid data type
 self.invalid_struct_test(example)
 
+# Test that GetDescription works:
+s.Clear()
+error = example.GetDescription(s)
+self.assertTrue(error.Success(), "GetDescription works")
+if not "key_float" in s.GetData():
+self.fail("FAILED: could not find key_float in description output")
+
 dict_struct = lldb.SBStructuredData()
 dict_struct = example.GetValueForKey("key_dict")
 
Index: lldb/include/lldb/Core/StructuredDataImpl.h
===
--- lldb/include/lldb/Core/StructuredDataImpl.h
+++ lldb/include/lldb/Core/StructuredDataImpl.h
@@ -68,14 +68,18 @@
   return error;
 }
 
-// Grab the plugin.
-auto plugin_sp = lldb::StructuredDataPluginSP(m_plugin_wp);
+// Grab the plugin
+lldb::StructuredDataPluginSP plugin_sp = m_plugin_wp.lock();
+
+// If there's no plugin, call underlying data's dump method:
 if (!plugin_sp) {
-  error.SetErrorString("Cannot pretty print structured data: "
-   "plugin doesn't exist.");
+  if (!m_data_sp) {
+error.SetErrorString("No data to describe.");
+return error;
+  }
+  m_data_sp->Dump(stream, true);
   return error;
 }
-
 // Get the data's description.
 return plugin_sp->GetDescription(m_data_sp, stream);
   }


Index: lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
===
--- lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
+++ lldb/test/API/python_api/sbstructureddata/TestStructuredDataAPI.py
@@ -35,6 +35,13 @@
 # Tests for invalid data type
 self.invalid_struct_test(example)
 
+# Test that GetDescription works:
+s.Clear()
+error = example.GetDescription(s)
+self.assertTrue(error.Success(), "GetDescription works")
+if not "key_float" in s.GetData():
+self.fail("FAILED: could not find key_float in description output")
+
 dict_struct = lldb.SBStructuredData()
 dict_struct = example.GetValueForKey("key_dict")
 
Index: lldb/include/lldb/Core/StructuredDataImpl.h
===
--- lldb/include/lldb/Core/StructuredDataImpl.h
+++ lldb/include/lldb/Core/StructuredDataImpl.h
@@ -68,14 +68,18 @@
   return error;
 }
 
-// Grab the plugin.
-auto plugin_sp = lldb::StructuredDataPluginSP(m_plugin_wp);
+// Grab the plugin
+lldb::StructuredDataPluginSP plugin_sp = m_plugin_wp.lock();
+
+// If there's no plugin, call underlying data's dump method:
 if (!plugin_sp) {
-  error.SetErrorString("Cannot pretty print structured data: "
-   "plugin doesn't exist.");
+  if (!m_data_sp) {
+error.SetErrorString("No data to describe.");
+return error;
+  }
+  m_data_sp->Dump(stream, true);
   return error;
 }
-
 // Get the data's description.
 return plugin_sp->GetDescription(m_data_sp, stream);
   }
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 154860a - [lldb] Use config.lldb_src_root in lit_config.load_config (NFC)

2020-09-29 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2020-09-29T23:05:12-07:00
New Revision: 154860af338f7b0c82cb04e91d6f199aa72cfdff

URL: 
https://github.com/llvm/llvm-project/commit/154860af338f7b0c82cb04e91d6f199aa72cfdff
DIFF: 
https://github.com/llvm/llvm-project/commit/154860af338f7b0c82cb04e91d6f199aa72cfdff.diff

LOG: [lldb] Use config.lldb_src_root in lit_config.load_config (NFC)

Rather than relaying on CMake to substitute the full path to the lldb
source root, use the  value set in config.lldb_src_root. This makes it
slightly easier to write a custom lit.site.cfg.py.

Added: 


Modified: 
lldb/test/API/lit.site.cfg.py.in
lldb/test/Shell/lit.site.cfg.py.in
lldb/test/Unit/lit.site.cfg.py.in

Removed: 




diff  --git a/lldb/test/API/lit.site.cfg.py.in 
b/lldb/test/API/lit.site.cfg.py.in
index 0481e8fecc73..ce2ff8e21d0b 100644
--- a/lldb/test/API/lit.site.cfg.py.in
+++ b/lldb/test/API/lit.site.cfg.py.in
@@ -69,4 +69,4 @@ except KeyError as e:
 lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" % 
(key,key))
 
 # Let the main config do the real work.
-lit_config.load_config(config, "@LLDB_SOURCE_DIR@/test/API/lit.cfg.py")
+lit_config.load_config(config, os.path.join(config.lldb_src_root, "test", 
"API", "lit.cfg.py"))

diff  --git a/lldb/test/Shell/lit.site.cfg.py.in 
b/lldb/test/Shell/lit.site.cfg.py.in
index ff4de9d527de..6cddd3937628 100644
--- a/lldb/test/Shell/lit.site.cfg.py.in
+++ b/lldb/test/Shell/lit.site.cfg.py.in
@@ -6,6 +6,7 @@ config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
 config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
 config.llvm_shlib_dir = "@SHLIBDIR@"
 config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
+config.lldb_src_root = "@LLDB_SOURCE_DIR@"
 config.lldb_obj_root = "@LLDB_BINARY_DIR@"
 config.lldb_libs_dir = "@LLDB_LIBS_DIR@"
 config.lldb_tools_dir = "@LLDB_TOOLS_DIR@"
@@ -42,4 +43,4 @@ import lit.llvm
 lit.llvm.initialize(lit_config, config)
 
 # Let the main config do the real work.
-lit_config.load_config(config, "@LLDB_SOURCE_DIR@/test/Shell/lit.cfg.py")
+lit_config.load_config(config, os.path.join(config.lldb_src_root, "test", 
"Shell", "lit.cfg.py"))

diff  --git a/lldb/test/Unit/lit.site.cfg.py.in 
b/lldb/test/Unit/lit.site.cfg.py.in
index e2035d678cd9..c0627b772362 100644
--- a/lldb/test/Unit/lit.site.cfg.py.in
+++ b/lldb/test/Unit/lit.site.cfg.py.in
@@ -26,4 +26,4 @@ import lit.llvm
 lit.llvm.initialize(lit_config, config)
 
 # Let the main config do the real work.
-lit_config.load_config(config, "@LLDB_SOURCE_DIR@/test/Unit/lit.cfg.py")
+lit_config.load_config(config, os.path.join(config.lldb_src_root, "test", 
"Unit", "lit.cfg.py"))



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