[Lldb-commits] [PATCH] D83023: [lldb/ObjectFileMachO] Fetch shared cache images from our own shared cache

2020-07-15 Thread Jason Molenda via Phabricator via lldb-commits
jasonmolenda accepted this revision.
jasonmolenda added a comment.
This revision is now accepted and ready to land.

The rewrite of the ObjectFileMachO parts is very nice.  LGTM.




Comment at: lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm:462
+
+typedef unsigned char uuid_t[16];
+struct dyld_shared_cache_dylib_text_info {

not important but #include "Utility/UuidCompatibility.h" would get you this.



Comment at: lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:2347
 // process the nlist records.
-if ((m_header.flags & MH_DYLIB_IN_CACHE) == 0) {
+if (is_shared_cache_image == 0) {
   DataBufferSP strtab_data_sp(

this is a bool, maybe !is_shared_cache_image would be clearer?  The original 
code was comparing a bitfield to 0 so it made a little more sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83023



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


[Lldb-commits] [PATCH] D83425: [lldb] add printing of stdout compile errors to lldbsuite

2020-07-15 Thread Benson Li via Phabricator via lldb-commits
bbli added a comment.

Ok, I have revised the patch with the code from the first pic. I also moved the 
`decode` back to the `format_build_error` since it was there to begin with(not 
sure how much of a difference it makes). Also while we finalize this patch, is 
there another fix I can get started on?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83425



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


[Lldb-commits] [PATCH] D83023: [lldb/ObjectFileMachO] Fetch shared cache images from our own shared cache

2020-07-15 Thread Frederic Riss via Phabricator via lldb-commits
friss updated this revision to Diff 278331.
friss added a comment.
Herald added a subscriber: mgorny.

- Rebase on top of D83512 
- Change the ObjectFileMachO pieces to rewrite offsets to look like a standard 
Mach-o image instead of adding a bunch of conditionals to handle the new cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83023

Files:
  lldb/include/lldb/Host/HostInfoBase.h
  lldb/include/lldb/Host/macosx/HostInfoMacOSX.h
  lldb/source/Host/macosx/objcxx/HostInfoMacOSX.mm
  lldb/source/Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderDarwin.cpp
  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
  lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h
  lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
  lldb/unittests/Host/CMakeLists.txt
  lldb/unittests/Host/HostInfoTest.cpp

Index: lldb/unittests/Host/HostInfoTest.cpp
===
--- lldb/unittests/Host/HostInfoTest.cpp
+++ lldb/unittests/Host/HostInfoTest.cpp
@@ -7,19 +7,26 @@
 //===--===//
 
 #include "lldb/Host/HostInfo.h"
+#include "Plugins/ObjectFile/Mach-O/ObjectFileMachO.h"
 #include "TestingSupport/SubsystemRAII.h"
 #include "TestingSupport/TestUtilities.h"
+#include "lldb/Core/Module.h"
 #include "lldb/Host/FileSystem.h"
+#include "lldb/Symbol/SymbolContext.h"
 #include "lldb/lldb-defines.h"
 #include "llvm/Support/Host.h"
 #include "gtest/gtest.h"
 
+#ifdef __APPLE__
+#include 
+#endif
+
 using namespace lldb_private;
 using namespace llvm;
 
 namespace {
 class HostInfoTest : public ::testing::Test {
-  SubsystemRAII subsystems;
+  SubsystemRAII subsystems;
 };
 } // namespace
 
@@ -60,3 +67,53 @@
   EXPECT_TRUE(HostInfo::GetXcodeSDKPath(XcodeSDK("CeciNestPasUnOS.sdk")).empty());
 }
 #endif
+
+#if defined(__APPLE__)
+TEST_F(HostInfoTest, GetSharedCacheInfo) {
+  SharedCacheImageInfo image_info =
+  HostInfo::GetSharedCacheImageInfo("/usr/lib/libobjc.A.dylib");
+  EXPECT_TRUE(image_info.uuid);
+  EXPECT_TRUE(image_info.data_sp);
+
+  ModuleSpec spec(FileSpec(), UUID(), image_info.data_sp);
+  lldb::ModuleSP module = std::make_shared(spec);
+  ObjectFile *OF = module->GetObjectFile();
+  ASSERT_TRUE(llvm::isa(OF));
+  EXPECT_TRUE(
+  OF->GetArchitecture().IsCompatibleMatch(HostInfo::GetArchitecture()));
+  Symtab *symtab = OF->GetSymtab();
+  ASSERT_NE(symtab, nullptr);
+  void *libobjc = dlopen("/usr/lib/libobjc.A.dylib", RTLD_LAZY);
+  ASSERT_NE(libobjc, nullptr);
+
+  // This function checks that if we read something from the
+  // ObjectFile we get through the shared cache in-mmeory
+  // buffer, it matches what we get by reading directly the
+  // memory of the symbol.
+  auto check_symbol = [&](const char *sym_name) {
+std::vector symbol_indices;
+symtab->FindAllSymbolsWithNameAndType(ConstString(sym_name),
+  lldb::eSymbolTypeAny, symbol_indices);
+EXPECT_EQ(symbol_indices.size(), 1u);
+
+Symbol *sym = symtab->SymbolAtIndex(symbol_indices[0]);
+ASSERT_NE(sym, nullptr);
+Address base = sym->GetAddress();
+size_t size = sym->GetByteSize();
+ASSERT_NE(size, 0u);
+uint8_t buffer[size];
+EXPECT_EQ(OF->ReadSectionData(base.GetSection().get(), base.GetOffset(),
+  buffer, size),
+  size);
+
+void *sym_addr = dlsym(libobjc, sym_name);
+ASSERT_NE(sym_addr, nullptr);
+EXPECT_EQ(memcmp(buffer, sym_addr, size), 0);
+  };
+
+  // Read a symbol from the __TEXT segment...
+  check_symbol("objc_msgSend");
+  // ... and one from the __DATA segment
+  check_symbol("OBJC_CLASS_$_NSObject");
+}
+#endif
Index: lldb/unittests/Host/CMakeLists.txt
===
--- lldb/unittests/Host/CMakeLists.txt
+++ lldb/unittests/Host/CMakeLists.txt
@@ -23,7 +23,9 @@
 add_lldb_unittest(HostTests
   ${FILES}
   LINK_LIBS
+lldbCore
 lldbHost
 lldbUtilityHelpers
+lldbPluginObjectFileMachO
 LLVMTestingSupport
   )
Index: lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
===
--- lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
+++ lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
@@ -237,6 +237,30 @@
 
   Status err;
 
+  if (IsHost()) {
+// When debugging on the host, we are most likely using the same shared
+// cache as our inferior. The dylibs from the shared cache might not
+// exist on the filesystem, so let's use the images in our own memory
+// to create the modules.
+
+// Check if the requested image is in our shared cache.
+SharedCacheImageInfo image_info =
+HostInfo::GetSharedCacheImageInfo(module_spec.GetFileSpec().GetPath());
+
+// If we found it and it has the correct 

[Lldb-commits] [lldb] c14e11b - [lldb/Test] Skip async process connect tests with reproducers

2020-07-15 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2020-07-15T15:39:44-07:00
New Revision: c14e11b0bb269e3744d5858b13a6df244308f25f

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

LOG: [lldb/Test] Skip async process connect tests with reproducers

Reproducers only support synchronous mode.

Added: 


Modified: 
lldb/test/API/functionalities/gdb_remote_client/TestProcessConnect.py

Removed: 




diff  --git 
a/lldb/test/API/functionalities/gdb_remote_client/TestProcessConnect.py 
b/lldb/test/API/functionalities/gdb_remote_client/TestProcessConnect.py
index e9e6b4e38ce1..14891b24249b 100644
--- a/lldb/test/API/functionalities/gdb_remote_client/TestProcessConnect.py
+++ b/lldb/test/API/functionalities/gdb_remote_client/TestProcessConnect.py
@@ -21,6 +21,7 @@ def test_gdb_remote_sync(self):
 self.dbg.GetSelectedPlatform().DisconnectRemote()
 
 @skipIfWindows
+@skipIfReproducer # Reproducer don't support async.
 def test_gdb_remote_async(self):
 """Test the gdb-remote command in asynchronous mode"""
 try:
@@ -45,6 +46,7 @@ def test_process_connect_sync(self):
 self.dbg.GetSelectedPlatform().DisconnectRemote()
 
 @skipIfWindows
+@skipIfReproducer # Reproducer don't support async.
 def test_process_connect_async(self):
 """Test the gdb-remote command in asynchronous mode"""
 try:



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


[Lldb-commits] [lldb] b0ad73a - Add missing include

2020-07-15 Thread Adrian Prantl via lldb-commits

Author: Adrian Prantl
Date: 2020-07-15T15:38:40-07:00
New Revision: b0ad73a2a0809188dd407ee2f92f71146759f279

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

LOG: Add missing include

Added: 


Modified: 
lldb/include/lldb/Symbol/LineTable.h

Removed: 




diff  --git a/lldb/include/lldb/Symbol/LineTable.h 
b/lldb/include/lldb/Symbol/LineTable.h
index d66b58ca4c6d..b48e82f19ffb 100644
--- a/lldb/include/lldb/Symbol/LineTable.h
+++ b/lldb/include/lldb/Symbol/LineTable.h
@@ -9,6 +9,7 @@
 #ifndef LLDB_SYMBOL_LINETABLE_H
 #define LLDB_SYMBOL_LINETABLE_H
 
+#include "lldb/Core/Address.h"
 #include "lldb/Core/ModuleChild.h"
 #include "lldb/Core/Section.h"
 #include "lldb/Symbol/LineEntry.h"



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


[Lldb-commits] [lldb] 3c22996 - [LLDB] Disable lldb-vscode test_terminate_commands test on Arm

2020-07-15 Thread Muhammad Omair Javaid via lldb-commits

Author: Muhammad Omair Javaid
Date: 2020-07-16T03:33:52+05:00
New Revision: 3c2299612945caf75d5c3678ced0693ebd291819

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

LOG: [LLDB] Disable lldb-vscode test_terminate_commands test on Arm

Summary:
test_terminate_commands is flaky on LLDB Arm buildbot as well. It was already
being skipped for aarch64. I am going to mark it skipped for Arm too.

Tags: #lldb

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

Added: 


Modified: 
lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py

Removed: 




diff  --git a/lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py 
b/lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
index fb7d71872a16..b63eb6e7201c 100644
--- a/lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
+++ b/lldb/test/API/tools/lldb-vscode/launch/TestVSCode_launch.py
@@ -431,7 +431,7 @@ def test_extra_launch_commands(self):
 @skipIfWindows
 @skipIfNetBSD # Hangs on NetBSD as well
 @skipIfDarwin
-@skipIf(archs="aarch64") # Example of a flaky run 
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/5540/steps/test/logs/stdio
+@skipIf(archs=["arm", "aarch64"]) # Example of a flaky run 
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/5540/steps/test/logs/stdio
 def test_terminate_commands(self):
 '''
 Tests that the "terminateCommands", that can be passed during



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


[Lldb-commits] [PATCH] D83904: [lldb] Unify sleep and time outs in GDB remote testcases

2020-07-15 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere created this revision.
JDevlieghere added reviewers: labath, aprantl, teemperor.

Reduce sleep and time outs in GDB remote testcases to one default value for 
each. Stop passing these values around and always use the default instead.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D83904

Files:
  lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
  lldb/test/API/tools/lldb-server/TestGdbRemoteKill.py
  lldb/test/API/tools/lldb-server/TestGdbRemoteProcessInfo.py
  lldb/test/API/tools/lldb-server/TestGdbRemoteThreadsInStopReply.py
  lldb/test/API/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py
  lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
  lldb/test/API/tools/lldb-server/commandline/TestStubReverseConnect.py

Index: lldb/test/API/tools/lldb-server/commandline/TestStubReverseConnect.py
===
--- lldb/test/API/tools/lldb-server/commandline/TestStubReverseConnect.py
+++ lldb/test/API/tools/lldb-server/commandline/TestStubReverseConnect.py
@@ -14,8 +14,6 @@
 
 mydir = TestBase.compute_mydir(__file__)
 
-_DEFAULT_TIMEOUT = 20 * (10 if ('ASAN_OPTIONS' in os.environ) else 1)
-
 def setUp(self):
 # Set up the test.
 gdbremote_testcase.GdbRemoteTestCaseBase.setUp(self)
@@ -25,11 +23,11 @@
 self.assertIsNotNone(self.listener_socket)
 self.listener_port = self.listener_socket.getsockname()[1]
 
-def create_listener_socket(self, timeout_seconds=_DEFAULT_TIMEOUT):
+def create_listener_socket(self):
 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
 self.assertIsNotNone(sock)
 
-sock.settimeout(timeout_seconds)
+sock.settimeout(self.DEFAULT_TIMEOUT)
 sock.bind(("127.0.0.1", 0))
 sock.listen(1)
 
@@ -77,7 +75,7 @@
 address, stub_socket.getsockname()))
 
 # Verify we can do the handshake.  If that works, we'll call it good.
-self.do_handshake(stub_socket, timeout_seconds=self._DEFAULT_TIMEOUT)
+self.do_handshake(stub_socket)
 
 # Clean up.
 stub_socket.shutdown(socket.SHUT_RDWR)
Index: lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
===
--- lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
+++ lldb/test/API/tools/lldb-server/TestLldbGdbServer.py
@@ -642,7 +642,7 @@
 self.run_process_then_stop(run_seconds=1)
 
 # Wait at most x seconds for 3 threads to be present.
-threads = self.wait_for_thread_count(3, timeout_seconds=self._WAIT_TIMEOUT)
+threads = self.wait_for_thread_count(3)
 self.assertEqual(len(threads), 3)
 
 # verify we can $H to each thead, and $qC matches the thread we set.
@@ -723,7 +723,7 @@
 # context = self.run_process_then_stop(run_seconds=1)
 
 # Wait at most x seconds for all threads to be present.
-# threads = self.wait_for_thread_count(NUM_THREADS, timeout_seconds=5)
+# threads = self.wait_for_thread_count(NUM_THREADS)
 # self.assertEquals(len(threads), NUM_THREADS)
 
 signaled_tids = {}
@@ -739,7 +739,7 @@
 2: "thread_id"}}],
  True)
 
-context = self.expect_gdbremote_sequence(timeout_seconds=self._DEFAULT_TIMEOUT)
+context = self.expect_gdbremote_sequence()
 self.assertIsNotNone(context)
 signo = context.get("signo")
 self.assertEqual(int(signo, 16), segfault_signo)
@@ -775,8 +775,7 @@
 True)
 
 # Run the sequence.
-context = self.expect_gdbremote_sequence(
-timeout_seconds=self._DEFAULT_TIMEOUT)
+context = self.expect_gdbremote_sequence()
 self.assertIsNotNone(context)
 
 # Ensure the stop signal is the signal we delivered.
@@ -1491,7 +1490,7 @@
 self.assertIsNotNone(context)
 
 # Wait for 3 threads to be present.
-threads = self.wait_for_thread_count(3, timeout_seconds=self._WAIT_TIMEOUT)
+threads = self.wait_for_thread_count(3)
 self.assertEqual(len(threads), 3)
 
 expected_reg_values = []
Index: lldb/test/API/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py
===
--- lldb/test/API/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py
+++ lldb/test/API/tools/lldb-server/TestGdbRemote_qThreadStopInfo.py
@@ -33,7 +33,7 @@
 self.assertIsNotNone(context)
 
 # Give threads time to start up, then break.
-time.sleep(self._WAIT_TIMEOUT)
+time.sleep(self.DEFAULT_SLEEP)
 self.reset_test_sequence()
 self.test_sequence.add_log_lines(
 [
@@ -51,8 +51,7 @@
 self.assertIsNotNone(context)
 
 # Wait until all threads have started.
-

[Lldb-commits] [PATCH] D83731: Add Debug Info Size to Symbol Status

2020-07-15 Thread Adrian Prantl via Phabricator via lldb-commits
aprantl added inline comments.



Comment at: lldb/tools/lldb-vscode/JSONUtils.cpp:353
+  if (debug_info < 1024) {
+sprintf(debug_info_size, " (%lluKB)", debug_info);
+  } else if (debug_info < 1024*1024) {

clayborg wrote:
> Use the PRIu64 macro here to make sure this works on all platforms and the 
> units are wrong here, should just be "B" instead of "KB". Also use snprintf 
> for safety:
> ```
> snprintf(debug_info_size, sizeof(debug_info_size), " (%"  PRIu64 "B)", 
> debug_info);
> ```
> PRIu64 is a macro that will expand to a string that will always match a 
> uint64_t. The three strings (" (%", PRIu64, and "B)") will get combined by 
> the compiler into a single format string. 
Could we avoid snprintf altogether by switching to 
http://llvm.org/doxygen/classllvm_1_1raw__string__ostream.html ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83731



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


[Lldb-commits] [PATCH] D83840: [lldb][test] Prevent infinite loop while looking for use_lldb_suite_root.py.

2020-07-15 Thread Shafik Yaghmour via Phabricator via lldb-commits
shafik added a comment.

@labath why do we need two copies of `use_lldb_suite.py`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83840



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


[Lldb-commits] [PATCH] D83425: [lldb] add printing of stdout compile errors to lldbsuite

2020-07-15 Thread Benson Li via Phabricator via lldb-commits
bbli updated this revision to Diff 278292.
bbli added a comment.

Modified stderr output instead of concatenating the stderr and stdout output 
strings.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83425

Files:
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/packages/Python/lldbsuite/test_event/build_exception.py


Index: lldb/packages/Python/lldbsuite/test_event/build_exception.py
===
--- lldb/packages/Python/lldbsuite/test_event/build_exception.py
+++ lldb/packages/Python/lldbsuite/test_event/build_exception.py
@@ -4,8 +4,7 @@
 super(BuildError, self).__init__("Error when building test subject")
 self.command = called_process_error.lldb_extensions.get(
 "command", "")
-self.build_error = called_process_error.lldb_extensions.get(
-"stderr_content", "")
+self.build_error = 
called_process_error.lldb_extensions["stdout_content"]
 
 def __str__(self):
 return self.format_build_error(self.command, self.build_error)
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -426,7 +426,7 @@
 process = Popen(
 shellCommand,
 stdout=PIPE,
-stderr=PIPE,
+stderr=STDOUT,
 shell=True,
 **kwargs)
 pid = process.pid


Index: lldb/packages/Python/lldbsuite/test_event/build_exception.py
===
--- lldb/packages/Python/lldbsuite/test_event/build_exception.py
+++ lldb/packages/Python/lldbsuite/test_event/build_exception.py
@@ -4,8 +4,7 @@
 super(BuildError, self).__init__("Error when building test subject")
 self.command = called_process_error.lldb_extensions.get(
 "command", "")
-self.build_error = called_process_error.lldb_extensions.get(
-"stderr_content", "")
+self.build_error = called_process_error.lldb_extensions["stdout_content"]
 
 def __str__(self):
 return self.format_build_error(self.command, self.build_error)
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -426,7 +426,7 @@
 process = Popen(
 shellCommand,
 stdout=PIPE,
-stderr=PIPE,
+stderr=STDOUT,
 shell=True,
 **kwargs)
 pid = process.pid
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 8b85f68 - [lldb/Test] Remove custom tearDownHooks from GDB Remote tests

2020-07-15 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2020-07-15T13:18:06-07:00
New Revision: 8b85f68ee2ddd983c027adbda9567f06d25b3c51

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

LOG: [lldb/Test] Remove custom tearDownHooks from GDB Remote tests

Remove custom tearDownHooks from GDB Remote tests as we now cleanup
subprocesses unconditionally. This also changes the termination order to
be the reverse of the creation order. I don't think anything is relying
on that right now, but it better fits the setup/teardown paradigm.

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index b1add79e488d..25805726f9b3 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -884,8 +884,8 @@ def setAsync(self, value):
 self.addTearDownHook(lambda: self.dbg.SetAsync(old_async))
 
 def cleanupSubprocesses(self):
-# Ensure any subprocesses are cleaned up
-for p in self.subprocesses:
+# Terminate subprocesses in reverse order from how they were created.
+for p in reversed(self.subprocesses):
 p.terminate()
 del p
 del self.subprocesses[:]

diff  --git 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
index ac611bcca169..0b81912e3d3f 100644
--- 
a/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
+++ 
b/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py
@@ -402,7 +402,6 @@ def launch_debug_monitor(self, attach_pid=None, 
logfile=None):
 self.debug_monitor_exe,
 commandline_args,
 install_remote=False)
-self.addTearDownHook(self.cleanupSubprocesses)
 self.assertIsNotNone(server)
 
 # If we're receiving the stub's listening port from the named pipe, do
@@ -418,15 +417,6 @@ def connect_to_debug_monitor(self, attach_pid=None):
 server = self.launch_debug_monitor(attach_pid=attach_pid)
 self.assertIsNotNone(server)
 
-def shutdown_debug_monitor():
-try:
-server.terminate()
-except:
-logger.warning(
-"failed to terminate server for debug monitor: {}; 
ignoring".format(
-sys.exc_info()[0]))
-self.addTearDownHook(shutdown_debug_monitor)
-
 # Schedule debug monitor to be shut down during teardown.
 logger = self.logger
 
@@ -445,15 +435,6 @@ def shutdown_debug_monitor():
 # Schedule debug monitor to be shut down during teardown.
 logger = self.logger
 
-def shutdown_debug_monitor():
-try:
-server.terminate()
-except:
-logger.warning(
-"failed to terminate server for debug monitor: {}; 
ignoring".format(
-sys.exc_info()[0]))
-self.addTearDownHook(shutdown_debug_monitor)
-
 connect_attemps = 0
 MAX_CONNECT_ATTEMPTS = 10
 
@@ -506,17 +487,7 @@ def launch_process_for_attach(
 if sleep_seconds:
 args.append("sleep:%d" % sleep_seconds)
 
-inferior = self.spawnSubprocess(exe_path, args)
-
-def shutdown_process_for_attach():
-try:
-inferior.terminate()
-except:
-logger.warning(
-"failed to terminate inferior process for attach: {}; 
ignoring".format(
-sys.exc_info()[0]))
-self.addTearDownHook(shutdown_process_for_attach)
-return inferior
+return self.spawnSubprocess(exe_path, args)
 
 def prep_debug_monitor_and_inferior(
 self,



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


[Lldb-commits] [PATCH] D83900: [intel-pt] Fix building due to CMake + python changes

2020-07-15 Thread Greg Clayton via Phabricator via lldb-commits
clayborg accepted this revision.
clayborg added a comment.
This revision is now accepted and ready to land.

If this is what everyone else is doing already, then this is fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83900



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


[Lldb-commits] [PATCH] D83900: [intel-pt] Fix building due to CMake + python changes

2020-07-15 Thread walter erquinigo via Phabricator via lldb-commits
wallace created this revision.
wallace added reviewers: clayborg, aadsm.
Herald added subscribers: lldb-commits, mgorny.
Herald added a project: LLDB.

Python is now handled in CMake with different variables, thus
the intel plugin needs a corresponding update.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D83900

Files:
  lldb/tools/intel-features/CMakeLists.txt


Index: lldb/tools/intel-features/CMakeLists.txt
===
--- lldb/tools/intel-features/CMakeLists.txt
+++ lldb/tools/intel-features/CMakeLists.txt
@@ -56,7 +56,7 @@
 
   LINK_LIBS
 ${FEATURE_LIBS}
-${PYTHON_LIBRARY}
+${PYTHON_LIBRARIES}
   )
 
 # Add link dependencies for python wrapper


Index: lldb/tools/intel-features/CMakeLists.txt
===
--- lldb/tools/intel-features/CMakeLists.txt
+++ lldb/tools/intel-features/CMakeLists.txt
@@ -56,7 +56,7 @@
 
   LINK_LIBS
 ${FEATURE_LIBS}
-${PYTHON_LIBRARY}
+${PYTHON_LIBRARIES}
   )
 
 # Add link dependencies for python wrapper
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D83881: [lldb/COFF] Remove strtab zeroing hack

2020-07-15 Thread Martin Storsjö via Phabricator via lldb-commits
mstorsjo added a comment.

In D83881#2153687 , @amccarth wrote:

> Yes, getting rid of this hack looks like a good idea.  If it was actually 
> necessary, there should have been a test on it, and the comments should have 
> been clearer.


Well in general, I wouldn't agree with that logic - especially if the test 
coverage for PECOFF in lldb has been weak to begin with. However I do agree 
with the conclusion that we can try to get rid of it.

So with COFF symbol tables, you can either have a <= 8 chars symbol name 
embedded in the struct, or have an offset into the string table (where the 
first 4 bytes of the string table contains the length of the string table). Now 
the existing code seems to imply that one potentially could have a symbol with 
an all-zeros symbol name field (offset), which according to this code should be 
interpreted as an offset into the string table (but without the current hack 
would end up interpreting the binary size field as text).

I haven't heard of such symbol table entries, and 
`COFFObjectFile::getSymbolName`, 
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Object/COFFObjectFile.cpp#L994-L997,
 seems to just blindly call `COFFObjectFile::getString()`, 
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Object/COFFObjectFile.cpp#L980-L986,
 which doesn't seem to have a special case for that. So if there are object 
files out there with this pattern, COFFObjectFile wouldn't be able to handle 
them correctly either.

So with that in mind, I agree that it probably is ok to remove this hack.




Comment at: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp:642
 DataExtractor symtab_data =
 ReadImageData(m_coff_header.symoff, symbol_data_size + 4);
 lldb::offset_t offset = symbol_data_size;

amccarth wrote:
> The `+4` at the end of this expression is from the same patch.  I wonder if 
> it was an attempt to make space for the four bytes of zeros at offset 0 that 
> you're eliminating?
> 
> I suggest removing the `+4` and trying the tests again unless it's obvious to 
> you why it's still necessary.  The comment above seems like it might be 
> trying to explain it, but that comment came later.
No, the `+4` here was present before 0076e71592a6a (if viewing that commit, 
view it with a bit more than the default git context size and you'll find "// 
Include the 4 bytes string table size at the end of the symbols" existing 
already before that.

The +4 here can't be eliminated; without it, the `const uint32_t strtab_size = 
symtab_data.GetU32()` two lines below would be out of range. So this 
first reads the symbol table and the 4 byte size of the string table, and if 
the string table turns out to be nonzero in size, it also loads a separate 
DataExtractor with the string table contents, with the two DataExtractors 
overlapping for that size field. It doesn't have anything to do with 
overwriting the start, just with the code layout in general.



Comment at: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp:672
 break;
   symbol_name.assign(symbol_name_cstr, sizeof(symbol.name));
 }

Kind of unrelated question: Does this treat the assigned symbol as always 8 
bytes long, or does it scan the provided 8 bytes for potential trailing 
terminators? Object/COFFObjectFile has got a bit of extra logic to distinguish 
between those cases: 
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Object/COFFObjectFile.cpp#L999-L1004



Comment at: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp:689
   i += symbol.naux;
   offset += symbol_size;
 }

Unrelated to the patch at hand: I believe this should be `offset += symbol.naux 
* symbol_size;`. I could try to make a patch to exercise that case at some 
later time...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83881



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


[Lldb-commits] [lldb] 44b43a5 - [lldb][NFC] Add 'override' where missing in source/ and tools/

2020-07-15 Thread Logan Smith via lldb-commits

Author: Logan Smith
Date: 2020-07-15T11:34:47-07:00
New Revision: 44b43a52dc17135e43824e826862c8b35081cac0

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

LOG: [lldb][NFC] Add 'override' where missing in source/ and tools/

These were found by Clang's new -Wsuggest-override.

This patch doesn't touch any code in unittests/, since much of it intentionally 
doesn't use override to avoid massive warning spam from 
-Winconsistent-missing-override due to the use of MOCK_*** macros.

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

Added: 


Modified: 
lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_arm.h
lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_arm64.h
lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_i386.h
lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_x86_64.h
lldb/source/Plugins/Process/MacOSX-Kernel/ThreadKDP.h
lldb/source/Plugins/Process/Utility/RegisterContextMach_arm.h
lldb/source/Plugins/Process/Utility/RegisterContextMach_i386.h
lldb/source/Plugins/Process/Utility/RegisterContextMach_x86_64.h
lldb/source/Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.h
lldb/source/Symbol/FuncUnwinders.cpp
lldb/tools/debugserver/source/MacOSX/i386/DNBArchImplI386.h
lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.h

Removed: 




diff  --git a/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp 
b/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
index 2f4a8917a78a..dde25184a8c5 100644
--- a/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
+++ b/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
@@ -873,7 +873,7 @@ class CommandObjectProcessKDPPacketSend : public 
CommandObjectParsed {
   OptionGroupUInt64 m_command_byte;
   OptionGroupString m_packet_data;
 
-  virtual Options *GetOptions() { return _option_group; }
+  Options *GetOptions() override { return _option_group; }
 
 public:
   CommandObjectProcessKDPPacketSend(CommandInterpreter )
@@ -900,7 +900,7 @@ class CommandObjectProcessKDPPacketSend : public 
CommandObjectParsed {
 
   ~CommandObjectProcessKDPPacketSend() {}
 
-  bool DoExecute(Args , CommandReturnObject ) {
+  bool DoExecute(Args , CommandReturnObject ) override {
 const size_t argc = command.GetArgumentCount();
 if (argc == 0) {
   if (!m_command_byte.GetOptionValue().OptionWasSet()) {

diff  --git 
a/lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_arm.h 
b/lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_arm.h
index 616aff8afda7..35ae0d03e2bb 100644
--- a/lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_arm.h
+++ b/lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_arm.h
@@ -20,21 +20,21 @@ class RegisterContextKDP_arm : public 
RegisterContextDarwin_arm {
   virtual ~RegisterContextKDP_arm();
 
 protected:
-  virtual int DoReadGPR(lldb::tid_t tid, int flavor, GPR );
+  int DoReadGPR(lldb::tid_t tid, int flavor, GPR ) override;
 
-  int DoReadFPU(lldb::tid_t tid, int flavor, FPU );
+  int DoReadFPU(lldb::tid_t tid, int flavor, FPU ) override;
 
-  int DoReadEXC(lldb::tid_t tid, int flavor, EXC );
+  int DoReadEXC(lldb::tid_t tid, int flavor, EXC ) override;
 
-  int DoReadDBG(lldb::tid_t tid, int flavor, DBG );
+  int DoReadDBG(lldb::tid_t tid, int flavor, DBG ) override;
 
-  int DoWriteGPR(lldb::tid_t tid, int flavor, const GPR );
+  int DoWriteGPR(lldb::tid_t tid, int flavor, const GPR ) override;
 
-  int DoWriteFPU(lldb::tid_t tid, int flavor, const FPU );
+  int DoWriteFPU(lldb::tid_t tid, int flavor, const FPU ) override;
 
-  int DoWriteEXC(lldb::tid_t tid, int flavor, const EXC );
+  int DoWriteEXC(lldb::tid_t tid, int flavor, const EXC ) override;
 
-  int DoWriteDBG(lldb::tid_t tid, int flavor, const DBG );
+  int DoWriteDBG(lldb::tid_t tid, int flavor, const DBG ) override;
 
   ThreadKDP _kdp_thread;
 };

diff  --git 
a/lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_arm64.h 
b/lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_arm64.h
index 998a78a6b8af..be387d69c6bc 100644
--- a/lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_arm64.h
+++ b/lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_arm64.h
@@ -21,21 +21,21 @@ class RegisterContextKDP_arm64 : public 
RegisterContextDarwin_arm64 {
   virtual ~RegisterContextKDP_arm64();
 
 protected:
-  virtual int DoReadGPR(lldb::tid_t tid, int flavor, GPR );
+  int DoReadGPR(lldb::tid_t tid, int flavor, GPR ) override;
 
-  int DoReadFPU(lldb::tid_t tid, int flavor, FPU );
+  int DoReadFPU(lldb::tid_t tid, int flavor, FPU ) override;
 
-  int DoReadEXC(lldb::tid_t tid, int flavor, EXC );
+  int 

[Lldb-commits] [PATCH] D83847: [lldb][NFC] Add 'override' where missing in source/ and tools/

2020-07-15 Thread Logan Smith via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG44b43a52dc17: [lldb][NFC] Add override where 
missing in source/ and tools/ (authored by logan-5).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83847

Files:
  lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
  lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_arm.h
  lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_arm64.h
  lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_i386.h
  lldb/source/Plugins/Process/MacOSX-Kernel/RegisterContextKDP_x86_64.h
  lldb/source/Plugins/Process/MacOSX-Kernel/ThreadKDP.h
  lldb/source/Plugins/Process/Utility/RegisterContextMach_arm.h
  lldb/source/Plugins/Process/Utility/RegisterContextMach_i386.h
  lldb/source/Plugins/Process/Utility/RegisterContextMach_x86_64.h
  lldb/source/Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.h
  lldb/source/Symbol/FuncUnwinders.cpp
  lldb/tools/debugserver/source/MacOSX/i386/DNBArchImplI386.h
  lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.h

Index: lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.h
===
--- lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.h
+++ lldb/tools/debugserver/source/MacOSX/x86_64/DNBArchImplX86_64.h
@@ -30,39 +30,39 @@
 
   static void Initialize();
 
-  virtual bool GetRegisterValue(uint32_t set, uint32_t reg,
-DNBRegisterValue *value);
-  virtual bool SetRegisterValue(uint32_t set, uint32_t reg,
-const DNBRegisterValue *value);
-  virtual nub_size_t GetRegisterContext(void *buf, nub_size_t buf_len);
-  virtual nub_size_t SetRegisterContext(const void *buf, nub_size_t buf_len);
-  virtual uint32_t SaveRegisterState();
-  virtual bool RestoreRegisterState(uint32_t save_id);
-
-  virtual kern_return_t GetRegisterState(int set, bool force);
-  virtual kern_return_t SetRegisterState(int set);
-  virtual bool RegisterSetStateIsValid(int set) const;
-
-  virtual uint64_t GetPC(uint64_t failValue); // Get program counter
-  virtual kern_return_t SetPC(uint64_t value);
-  virtual uint64_t GetSP(uint64_t failValue); // Get stack pointer
-  virtual void ThreadWillResume();
-  virtual bool ThreadDidStop();
-  virtual bool NotifyException(MachException::Data );
-
-  virtual uint32_t NumSupportedHardwareBreakpoints();
-  virtual uint32_t NumSupportedHardwareWatchpoints();
-
-  virtual uint32_t EnableHardwareBreakpoint(nub_addr_t addr, nub_size_t size,
-bool also_set_on_task);
-  virtual bool DisableHardwareBreakpoint(uint32_t hw_break_index,
- bool also_set_on_task);
-  virtual uint32_t EnableHardwareWatchpoint(nub_addr_t addr, nub_size_t size,
-bool read, bool write,
-bool also_set_on_task);
-  virtual bool DisableHardwareWatchpoint(uint32_t hw_break_index,
- bool also_set_on_task);
-  virtual uint32_t GetHardwareWatchpointHit(nub_addr_t );
+  bool GetRegisterValue(uint32_t set, uint32_t reg,
+DNBRegisterValue *value) override;
+  bool SetRegisterValue(uint32_t set, uint32_t reg,
+const DNBRegisterValue *value) override;
+  nub_size_t GetRegisterContext(void *buf, nub_size_t buf_len) override;
+  nub_size_t SetRegisterContext(const void *buf, nub_size_t buf_len) override;
+  uint32_t SaveRegisterState() override;
+  bool RestoreRegisterState(uint32_t save_id) override;
+
+  kern_return_t GetRegisterState(int set, bool force) override;
+  kern_return_t SetRegisterState(int set) override;
+  bool RegisterSetStateIsValid(int set) const override;
+
+  uint64_t GetPC(uint64_t failValue) override; // Get program counter
+  kern_return_t SetPC(uint64_t value) override;
+  uint64_t GetSP(uint64_t failValue) override; // Get stack pointer
+  void ThreadWillResume() override;
+  bool ThreadDidStop() override;
+  bool NotifyException(MachException::Data ) override;
+
+  uint32_t NumSupportedHardwareBreakpoints() override;
+  uint32_t NumSupportedHardwareWatchpoints() override;
+
+  uint32_t EnableHardwareBreakpoint(nub_addr_t addr, nub_size_t size,
+bool also_set_on_task) override;
+  bool DisableHardwareBreakpoint(uint32_t hw_break_index,
+ bool also_set_on_task) override;
+  uint32_t EnableHardwareWatchpoint(nub_addr_t addr, nub_size_t size,
+bool read, bool write,
+bool also_set_on_task) override;
+  bool DisableHardwareWatchpoint(uint32_t hw_break_index,
+ bool also_set_on_task) override;
+  uint32_t 

[Lldb-commits] [PATCH] D83876: [lldb] Clean orphaned modules in Debugger::Destroy

2020-07-15 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor added a comment.

In D83876#2153709 , @jingham wrote:

> We certainly don't want to clear the shared module cache when the Debugger or 
> the SBDebugger is destroyed.  Most IDE's that use LLDB as a library use a 
> debugger per debugging session, and destroy the debugger when the debugging 
> session ends.  As it stands now, when the first debugging session ends we 
> don't remove any of the already parsed modules, so that the second debugging 
> session is much faster.  That would not be true if you did 
> RemoveOrphanedSharedModules in Debugger::Destroy.  99% of all the libraries 
> that get loaded by an app don't change over an Xcode run, and are in fact 
> shared among most of the targets you might debug on a given platform.  So 
> clearing the cache after every run would result in a lot of pointless 
> reparsing of system libraries.
>
> The choice to clear the shared module cache should always be left up to the 
> client.


So I guess that only leaves an explicit function for that as an option.

Also, if that's the concept then we should also delete the same code in 
DeleteTarget. I'll make a review for that.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D83876



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


[Lldb-commits] [PATCH] D83876: [lldb] Clean orphaned modules in Debugger::Destroy

2020-07-15 Thread Jim Ingham via Phabricator via lldb-commits
jingham requested changes to this revision.
jingham added a comment.

We certainly don't want to clear the shared module cache when the Debugger or 
the SBDebugger is destroyed.  Most IDE's that use LLDB as a library use a 
debugger per debugging session, and destroy the debugger when the debugging 
session ends.  As it stands now, when the first debugging session ends we don't 
remove any of the already parsed modules, so that the second debugging session 
is much faster.  That would not be true if you did RemoveOrphanedSharedModules 
in Debugger::Destroy.  99% of all the libraries that get loaded by an app don't 
change over an Xcode run, and are in fact shared among most of the targets you 
might debug on a given platform.  So clearing the cache after every run would 
result in a lot of pointless reparsing of system libraries.

The choice to clear the shared module cache should always be left up to the 
client.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D83876



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


[Lldb-commits] [PATCH] D83881: [lldb/COFF] Remove strtab zeroing hack

2020-07-15 Thread Adrian McCarthy via Phabricator via lldb-commits
amccarth added a comment.

Yes, getting rid of this hack looks like a good idea.  If it was actually 
necessary, there should have been a test on it, and the comments should have 
been clearer.

See my inline comment, though.  It looks like this might back out only part of 
the change.




Comment at: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp:642
 DataExtractor symtab_data =
 ReadImageData(m_coff_header.symoff, symbol_data_size + 4);
 lldb::offset_t offset = symbol_data_size;

The `+4` at the end of this expression is from the same patch.  I wonder if it 
was an attempt to make space for the four bytes of zeros at offset 0 that 
you're eliminating?

I suggest removing the `+4` and trying the tests again unless it's obvious to 
you why it's still necessary.  The comment above seems like it might be trying 
to explain it, but that comment came later.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83881



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


[Lldb-commits] [lldb] cf3f100 - [lldb][test] Prevent infinite loop while looking for use_lldb_suite_root.py.

2020-07-15 Thread Jordan Rupprecht via lldb-commits

Author: Jordan Rupprecht
Date: 2020-07-15T09:16:30-07:00
New Revision: cf3f100fcbf94af499501140590b322b4985c1a3

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

LOG: [lldb][test] Prevent infinite loop while looking for 
use_lldb_suite_root.py.

Several scripts (two copies of use_lldb_suite.py, and an __init__.py) look for 
use_lldb_suite_root.py by checking parent directories. If for some reason it 
doesn't exist, it keeps checking parent directories until it finds it.

However, this only breaks when the parent directory is None, but at least on 
Linux, dirname('/') == '/', so this will never be None.

This changes the lookup to stop if the dirname(lldb_root) is unchanged. This 
was previously fixed in 67f6d842fab6d3ac8c949721be8e131cf6b17578, but only in 
one copy of this script.

Additionally, this makes the failure mode more visible -- if the root is not 
found, it complains loudly instead of silently failing, and having later 
modules that need lldb_root fail.

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

Added: 


Modified: 
lldb/packages/Python/lldbsuite/__init__.py
lldb/scripts/use_lldb_suite.py
lldb/test/API/use_lldb_suite.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/__init__.py 
b/lldb/packages/Python/lldbsuite/__init__.py
index 195b2683f7b4..62f6aee71f30 100644
--- a/lldb/packages/Python/lldbsuite/__init__.py
+++ b/lldb/packages/Python/lldbsuite/__init__.py
@@ -8,14 +8,14 @@
 def find_lldb_root():
 lldb_root = os.path.dirname(inspect.getfile(inspect.currentframe()))
 while True:
-lldb_root = os.path.dirname(lldb_root)
-if lldb_root is None:
-return None
+parent = os.path.dirname(lldb_root)
+if parent == lldb_root: # dirname('/') == '/'
+raise Exception("use_lldb_suite_root.py not found")
+lldb_root = parent
 
 test_path = os.path.join(lldb_root, "use_lldb_suite_root.py")
 if os.path.isfile(test_path):
 return lldb_root
-return None
 
 # lldbsuite.lldb_root refers to the root of the git/svn source checkout
 lldb_root = find_lldb_root()

diff  --git a/lldb/scripts/use_lldb_suite.py b/lldb/scripts/use_lldb_suite.py
index a1a2e8b93679..84380f6a5592 100644
--- a/lldb/scripts/use_lldb_suite.py
+++ b/lldb/scripts/use_lldb_suite.py
@@ -8,20 +8,18 @@ def find_lldb_root():
 while True:
 parent = os.path.dirname(lldb_root)
 if parent == lldb_root: # dirname('/') == '/'
-break
+raise Exception("use_lldb_suite_root.py not found")
 lldb_root = parent
 
 test_path = os.path.join(lldb_root, "use_lldb_suite_root.py")
 if os.path.isfile(test_path):
 return lldb_root
-return None
 
 lldb_root = find_lldb_root()
-if lldb_root is not None:
-import imp
-fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
-try:
-imp.load_module("use_lldb_suite_root", fp, pathname, desc)
-finally:
-if fp:
-fp.close()
+import imp
+fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
+try:
+imp.load_module("use_lldb_suite_root", fp, pathname, desc)
+finally:
+if fp:
+fp.close()

diff  --git a/lldb/test/API/use_lldb_suite.py b/lldb/test/API/use_lldb_suite.py
index 6a8c12d81898..f1edf1d7304f 100644
--- a/lldb/test/API/use_lldb_suite.py
+++ b/lldb/test/API/use_lldb_suite.py
@@ -8,21 +8,21 @@ def find_lldb_root():
 os.path.abspath(inspect.getfile(inspect.currentframe()))
 )
 while True:
-lldb_root = os.path.dirname(lldb_root)
-if lldb_root is None:
-return None
+parent = os.path.dirname(lldb_root)
+if parent == lldb_root: # dirname('/') == '/'
+raise Exception("use_lldb_suite_root.py not found")
+lldb_root = parent
 
 test_path = os.path.join(lldb_root, "use_lldb_suite_root.py")
 if os.path.isfile(test_path):
 return lldb_root
-return None
 
 lldb_root = find_lldb_root()
-if lldb_root is not None:
-import imp
-fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
-try:
-imp.load_module("use_lldb_suite_root", fp, pathname, desc)
-finally:
-if fp:
-fp.close()
+
+import imp
+fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
+try:
+imp.load_module("use_lldb_suite_root", fp, pathname, desc)
+finally:
+if fp:
+fp.close()



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


[Lldb-commits] [lldb] 700dd17 - [lldb/Test] Remove support for forking a subprocess from the test suite.

2020-07-15 Thread Jonas Devlieghere via lldb-commits

Author: Jonas Devlieghere
Date: 2020-07-15T08:57:54-07:00
New Revision: 700dd17399bdcf2c580121e52b20e5768663dfe5

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

LOG: [lldb/Test] Remove support for forking a subprocess from the test suite.

Remove the forkSubprocess method and its bookkeeping.
TestCreateAfterAttach is the only test using the fork method and I'm not
convinced it adds enough to warrant the maintenance. Pavel suggested the
same thing in D83815.

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/lldbtest.py

lldb/test/API/functionalities/thread/create_after_attach/TestCreateAfterAttach.py

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 280e02f56f28..b1add79e488d 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -800,9 +800,6 @@ def setUp(self):
 # List of spawned subproces.Popen objects
 self.subprocesses = []
 
-# List of forked process PIDs
-self.forkedProcessPids = []
-
 # List of log files produced by the current test.
 self.log_files = []
 
@@ -892,13 +889,6 @@ def cleanupSubprocesses(self):
 p.terminate()
 del p
 del self.subprocesses[:]
-# Ensure any forked processes are cleaned up
-for pid in self.forkedProcessPids:
-try:
-os.kill(pid, signal.SIGTERM)
-except OSError:
-pass
-del self.forkedProcessPids[:]
 
 def spawnSubprocess(self, executable, args=[], install_remote=True):
 """ Creates a subprocess.Popen object with the specified executable 
and arguments,
@@ -910,23 +900,6 @@ def spawnSubprocess(self, executable, args=[], 
install_remote=True):
 self.subprocesses.append(proc)
 return proc
 
-def forkSubprocess(self, executable, args=[]):
-""" Fork a subprocess with its own group ID.
-"""
-child_pid = os.fork()
-if child_pid == 0:
-# If more I/O support is required, this can be beefed up.
-fd = os.open(os.devnull, os.O_RDWR)
-os.dup2(fd, 1)
-os.dup2(fd, 2)
-# This call causes the child to have its of group ID
-os.setpgid(0, 0)
-os.execvp(executable, [executable] + args)
-# Give the child time to get through the execvp() call
-time.sleep(0.1)
-self.forkedProcessPids.append(child_pid)
-return child_pid
-
 def HideStdout(self):
 """Hide output to stdout from the user.
 

diff  --git 
a/lldb/test/API/functionalities/thread/create_after_attach/TestCreateAfterAttach.py
 
b/lldb/test/API/functionalities/thread/create_after_attach/TestCreateAfterAttach.py
index 19c02c12a894..8ad9afe32afe 100644
--- 
a/lldb/test/API/functionalities/thread/create_after_attach/TestCreateAfterAttach.py
+++ 
b/lldb/test/API/functionalities/thread/create_after_attach/TestCreateAfterAttach.py
@@ -14,29 +14,6 @@ class CreateAfterAttachTestCase(TestBase):
 
 mydir = TestBase.compute_mydir(__file__)
 
-@skipIfFreeBSD  # Hangs.  May be the same as Linux issue llvm.org/pr16229 
but
-# not yet investigated.  Revisit once required functionality
-# is implemented for FreeBSD.
-# Occasionally hangs on Windows, may be same as other issues.
-@skipIfWindows
-@skipIfiOSSimulator
-@expectedFailureNetBSD
-def test_create_after_attach_with_popen(self):
-"""Test thread creation after process attach."""
-self.build(dictionary=self.getBuildFlags(use_cpp11=False))
-self.create_after_attach(use_fork=False)
-
-@skipIfFreeBSD  # Hangs. Revisit once required functionality is implemented
-# for FreeBSD.
-@skipIfRemote
-@skipIfWindows  # Windows doesn't have fork.
-@skipIfiOSSimulator
-@expectedFailureNetBSD
-def test_create_after_attach_with_fork(self):
-"""Test thread creation after process attach."""
-self.build(dictionary=self.getBuildFlags(use_cpp11=False))
-self.create_after_attach(use_fork=True)
-
 def setUp(self):
 # Call super's setUp().
 TestBase.setUp(self)
@@ -45,17 +22,21 @@ def setUp(self):
 self.break_2 = line_number('main.cpp', '// Set second breakpoint here')
 self.break_3 = line_number('main.cpp', '// Set third breakpoint here')
 
-def create_after_attach(self, use_fork):
+@skipIfFreeBSD  # Hangs.  May be the same as Linux issue llvm.org/pr16229 
but
+# not yet investigated.  Revisit once required functionality
+# is implemented for FreeBSD.
+# Occasionally hangs on Windows, may be same as other issues.
+

[Lldb-commits] [PATCH] D83840: [lldb][test] Prevent infinite loop while looking for use_lldb_suite_root.py.

2020-07-15 Thread Jordan Rupprecht via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcf3f100fcbf9: [lldb][test] Prevent infinite loop while 
looking for use_lldb_suite_root.py. (authored by rupprecht).

Changed prior to commit:
  https://reviews.llvm.org/D83840?vs=278042=278219#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83840

Files:
  lldb/packages/Python/lldbsuite/__init__.py
  lldb/scripts/use_lldb_suite.py
  lldb/test/API/use_lldb_suite.py


Index: lldb/test/API/use_lldb_suite.py
===
--- lldb/test/API/use_lldb_suite.py
+++ lldb/test/API/use_lldb_suite.py
@@ -8,21 +8,21 @@
 os.path.abspath(inspect.getfile(inspect.currentframe()))
 )
 while True:
-lldb_root = os.path.dirname(lldb_root)
-if lldb_root is None:
-return None
+parent = os.path.dirname(lldb_root)
+if parent == lldb_root: # dirname('/') == '/'
+raise Exception("use_lldb_suite_root.py not found")
+lldb_root = parent
 
 test_path = os.path.join(lldb_root, "use_lldb_suite_root.py")
 if os.path.isfile(test_path):
 return lldb_root
-return None
 
 lldb_root = find_lldb_root()
-if lldb_root is not None:
-import imp
-fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
-try:
-imp.load_module("use_lldb_suite_root", fp, pathname, desc)
-finally:
-if fp:
-fp.close()
+
+import imp
+fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
+try:
+imp.load_module("use_lldb_suite_root", fp, pathname, desc)
+finally:
+if fp:
+fp.close()
Index: lldb/scripts/use_lldb_suite.py
===
--- lldb/scripts/use_lldb_suite.py
+++ lldb/scripts/use_lldb_suite.py
@@ -8,20 +8,18 @@
 while True:
 parent = os.path.dirname(lldb_root)
 if parent == lldb_root: # dirname('/') == '/'
-break
+raise Exception("use_lldb_suite_root.py not found")
 lldb_root = parent
 
 test_path = os.path.join(lldb_root, "use_lldb_suite_root.py")
 if os.path.isfile(test_path):
 return lldb_root
-return None
 
 lldb_root = find_lldb_root()
-if lldb_root is not None:
-import imp
-fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
-try:
-imp.load_module("use_lldb_suite_root", fp, pathname, desc)
-finally:
-if fp:
-fp.close()
+import imp
+fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
+try:
+imp.load_module("use_lldb_suite_root", fp, pathname, desc)
+finally:
+if fp:
+fp.close()
Index: lldb/packages/Python/lldbsuite/__init__.py
===
--- lldb/packages/Python/lldbsuite/__init__.py
+++ lldb/packages/Python/lldbsuite/__init__.py
@@ -8,14 +8,14 @@
 def find_lldb_root():
 lldb_root = os.path.dirname(inspect.getfile(inspect.currentframe()))
 while True:
-lldb_root = os.path.dirname(lldb_root)
-if lldb_root is None:
-return None
+parent = os.path.dirname(lldb_root)
+if parent == lldb_root: # dirname('/') == '/'
+raise Exception("use_lldb_suite_root.py not found")
+lldb_root = parent
 
 test_path = os.path.join(lldb_root, "use_lldb_suite_root.py")
 if os.path.isfile(test_path):
 return lldb_root
-return None
 
 # lldbsuite.lldb_root refers to the root of the git/svn source checkout
 lldb_root = find_lldb_root()


Index: lldb/test/API/use_lldb_suite.py
===
--- lldb/test/API/use_lldb_suite.py
+++ lldb/test/API/use_lldb_suite.py
@@ -8,21 +8,21 @@
 os.path.abspath(inspect.getfile(inspect.currentframe()))
 )
 while True:
-lldb_root = os.path.dirname(lldb_root)
-if lldb_root is None:
-return None
+parent = os.path.dirname(lldb_root)
+if parent == lldb_root: # dirname('/') == '/'
+raise Exception("use_lldb_suite_root.py not found")
+lldb_root = parent
 
 test_path = os.path.join(lldb_root, "use_lldb_suite_root.py")
 if os.path.isfile(test_path):
 return lldb_root
-return None
 
 lldb_root = find_lldb_root()
-if lldb_root is not None:
-import imp
-fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
-try:
-imp.load_module("use_lldb_suite_root", fp, pathname, desc)
-finally:
-if fp:
-fp.close()
+
+import imp
+fp, pathname, desc = imp.find_module("use_lldb_suite_root", [lldb_root])
+try:
+imp.load_module("use_lldb_suite_root", fp, pathname, desc)
+finally:
+if fp:
+fp.close()
Index: 

[Lldb-commits] [PATCH] D83815: [lldb/Test] Use a process group for subprocesses

2020-07-15 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment.

In D83815#2153459 , @labath wrote:

> In D83815#2153438 , @JDevlieghere 
> wrote:
>
> > In D83815#2152688 , @labath wrote:
> >
> > >
> >
> >
> > Given that we were already creating a process group on fork, I'll keep the 
> > change on line 902 that kills the process group instead of just the pid.
>
>
> That seems ok -- all of those arguments (except maybe the last one) don't 
> really apply there. Though I am tempted to remove the setpgid call from the 
> forking method too (or even deleting the entire forking method). :P


You got me at "delete the entire [thing]" ;-)


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

https://reviews.llvm.org/D83815



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


[Lldb-commits] [PATCH] D83840: [lldb][test] Prevent infinite loop while looking for use_lldb_suite_root.py.

2020-07-15 Thread Jordan Rupprecht via Phabricator via lldb-commits
rupprecht added a comment.

In D83840#2152706 , @labath wrote:

> Heh I fixed the same thing back in 67f6d842fab6 for 
> `scripts/use_lldb_suite.py`, but of course I forgot to update this copy... 
> The idea is good, just please make sure both files end up using the same 
> solution.


Oh, and there's another one -- `lldb/packages/Python/lldbsuite/__init__.py`. 
I'll update it too.

> (Also, if you have any ideas on how to avoid having multiple copies of this 
> file around, then don't keep them to yourself. :) )

Not at the moment, but I have a feeling I'll be staring at these files long 
enough to come up with something.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83840



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


[Lldb-commits] [PATCH] D83815: [lldb/Test] Use a process group for subprocesses

2020-07-15 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D83815#2153438 , @JDevlieghere 
wrote:

> In D83815#2152688 , @labath wrote:
>
> >
>
>
> Given that we were already creating a process group on fork, I'll keep the 
> change on line 902 that kills the process group instead of just the pid.


That seems ok -- all of those arguments (except maybe the last one) don't 
really apply there. Though I am tempted to remove the setpgid call from the 
forking method too (or even deleting the entire forking method). :P


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

https://reviews.llvm.org/D83815



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


[Lldb-commits] [PATCH] D83767: [lldb] Use the basename of the Python test for the log name instead of the class name

2020-07-15 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere added a comment.

In D83767#2153236 , @teemperor wrote:

> Well, on Windows the file name is for some reason always 
> "lldbsuite.test.lldbtest" so I reverted this for now. Open for suggestions.


I'm on board with Pavel's suggestion of getting rid of the session dir and 
format and just adding the log to the build dir.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83767



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


[Lldb-commits] [PATCH] D83815: [lldb/Test] Use a process group for subprocesses

2020-07-15 Thread Jonas Devlieghere via Phabricator via lldb-commits
JDevlieghere abandoned this revision.
JDevlieghere added a comment.

In D83815#2152688 , @labath wrote:

> hmm... I have a lot thoughts here..
>
> - `setsid` is overkill. If you want to create process group, create a process 
> group (`setpgid`), not a session.
> - this solution does not seem very windows-friendly. In fact, I'd be 
> surprised if it works there at all.
> - going for `os.kill` will also not work with remote test suite runs. In 
> fact, the way it is implemented now means we could start killing random 
> processes on the host.
> - are these really zombies (dead but not waited-for processes) or just live 
> processes stuck in infinite loops and similar? Because if they are zombies 
> (mmm... brainz), then I doubt sending signals to them will help -- they're 
> already dead. The problem is that someone is not reaping them. I'm not sure 
> what can be done about that, as normally init should take care of this...
> - even if they are live processes, I am doubtful that this will make a 
> difference. I don't think many of the processes we spawn create additional 
> subprocesses. In fact, the only one I know of is `TestChangeProcessGroup.py`, 
> which also creates a new process group... so this test would need special 
> handling anyway.
> - creating lots of process groups can actually cause us to leak _more_ 
> processes in case the test run is interrupted with ^C or similar (SIGINT goes 
> to the foreground process group)


You make some compelling arguments :-) Given that we were already creating a 
process group on fork, I'll keep the change on line 902 that kills the process 
group instead of just the pid.

> Overall, I think we should try to understand the problem a bit better before 
> we start shotgun debugging this. Which tests are creating these zombies? 
> What's special about them? Do they always do that or only occasionally? etc.

I and many people on the team have already tried that and so far we've come up 
with nothing. We don't know which tests are leaking the zombies. It doesn't 
happen when you just run the test suite over and over again. But by the end of 
the week you suddenly have a few hundred... I have a machine that I only SSH in 
and rarely reboot. It's not uncommon for it to have more than a 1000 zombies.

> PS: When we were running a mac bot (it seems only macs are vulnerable to 
> zombie infestations), we configured it to reboot itself each midnight. Not 
> the most elegant solution, but if the problem really is about init refusing 
> to reap zombies, then it may be the only thing that we can do...

GreenDragon has a "zombie detector" which periodically checks the number and 
reboots when it exceeds a certain value.


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

https://reviews.llvm.org/D83815



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


[Lldb-commits] [PATCH] D83881: [lldb/COFF] Remove strtab zeroing hack

2020-07-15 Thread Pavel Labath via Phabricator via lldb-commits
labath created this revision.
labath added reviewers: amccarth, markmentovai.
Herald added a project: LLDB.

This code (recently responsible for a unaligned access sanitizer
failure) claims that the string table offset zero should result in an
empty string.

I cannot find any mention of this detail in the Microsoft COFF
documentation, and the llvm COFF parser also does not handle offset zero
specially. This code was introduced in 0076e7159, which also does not go
into specifics, citing "various bugfixes".

Given that this is obviously a hack, and does not cause tests to fail, I
think we should just delete it.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D83881

Files:
  lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp


Index: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
===
--- lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
@@ -543,12 +543,6 @@
   if (m_data.ValidOffsetForDataOfSize(offset, size))
 return DataExtractor(m_data, offset, size);
 
-  if (m_file) {
-// A bit of a hack, but we intend to write to this buffer, so we can't
-// mmap it.
-auto buffer_sp = MapFileData(m_file, size, offset);
-return DataExtractor(buffer_sp, GetByteOrder(), GetAddressByteSize());
-  }
   ProcessSP process_sp(m_process_wp.lock());
   DataExtractor data;
   if (process_sp) {
@@ -652,12 +646,6 @@
   DataExtractor strtab_data = ReadImageData(
   m_coff_header.symoff + symbol_data_size, strtab_size);
 
-  // First 4 bytes should be zeroed after strtab_size has been read,
-  // because it is used as offset 0 to encode a NULL string.
-  uint32_t *strtab_data_start = const_cast(
-  reinterpret_cast(strtab_data.GetDataStart()));
-  ::memset(_data_start[0], 0, sizeof(uint32_t));
-
   offset = 0;
   std::string symbol_name;
   Symbol *symbols = m_symtab_up->Resize(num_syms);


Index: lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
===
--- lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
+++ lldb/source/Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.cpp
@@ -543,12 +543,6 @@
   if (m_data.ValidOffsetForDataOfSize(offset, size))
 return DataExtractor(m_data, offset, size);
 
-  if (m_file) {
-// A bit of a hack, but we intend to write to this buffer, so we can't
-// mmap it.
-auto buffer_sp = MapFileData(m_file, size, offset);
-return DataExtractor(buffer_sp, GetByteOrder(), GetAddressByteSize());
-  }
   ProcessSP process_sp(m_process_wp.lock());
   DataExtractor data;
   if (process_sp) {
@@ -652,12 +646,6 @@
   DataExtractor strtab_data = ReadImageData(
   m_coff_header.symoff + symbol_data_size, strtab_size);
 
-  // First 4 bytes should be zeroed after strtab_size has been read,
-  // because it is used as offset 0 to encode a NULL string.
-  uint32_t *strtab_data_start = const_cast(
-  reinterpret_cast(strtab_data.GetDataStart()));
-  ::memset(_data_start[0], 0, sizeof(uint32_t));
-
   offset = 0;
   std::string symbol_name;
   Symbol *symbols = m_symtab_up->Resize(num_syms);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [PATCH] D83858: [lldb] Desugar template specializations

2020-07-15 Thread Jaroslav Sevcik via Phabricator via lldb-commits
jarin updated this revision to Diff 278200.
jarin added a comment.

Undo the infinite loop detection.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83858

Files:
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/test/API/lang/cpp/template-specialization-type/Makefile
  
lldb/test/API/lang/cpp/template-specialization-type/TestTemplateSpecializationType.py
  lldb/test/API/lang/cpp/template-specialization-type/main.cpp


Index: lldb/test/API/lang/cpp/template-specialization-type/main.cpp
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization-type/main.cpp
@@ -0,0 +1,9 @@
+template  struct TestObj {
+  int f;
+  T g;
+};
+
+int main() {
+  TestObj t{42, 21};
+  return t.f + t.g; // break here
+}
Index: 
lldb/test/API/lang/cpp/template-specialization-type/TestTemplateSpecializationType.py
===
--- /dev/null
+++ 
lldb/test/API/lang/cpp/template-specialization-type/TestTemplateSpecializationType.py
@@ -0,0 +1,30 @@
+"""
+Test value with a template specialization type.
+"""
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TemplateSpecializationTypeTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_template_specialization_cast_children(self):
+self.build()
+lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.cpp", False))
+
+v = self.frame().EvaluateExpression("t")
+self.assertEquals(2, v.GetNumChildren())
+self.assertEquals("42", v.GetChildAtIndex(0).GetValue())
+self.assertEquals("21", v.GetChildAtIndex(1).GetValue())
+
+# Test a value of the TemplateSpecialization type. We turn
+# RecordType into TemplateSpecializationType by casting and
+# dereferencing a pointer to a record.
+v = self.frame().EvaluateExpression("*((TestObj*))")
+self.assertEquals(2, v.GetNumChildren())
+self.assertEquals("42", v.GetChildAtIndex(0).GetValue())
+self.assertEquals("21", v.GetChildAtIndex(1).GetValue())
Index: lldb/test/API/lang/cpp/template-specialization-type/Makefile
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization-type/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules
Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -2501,6 +2501,7 @@
 case clang::Type::Decltype:
 case clang::Type::Elaborated:
 case clang::Type::Paren:
+case clang::Type::TemplateSpecialization:
 case clang::Type::Typedef:
 case clang::Type::TypeOf:
 case clang::Type::TypeOfExpr:


Index: lldb/test/API/lang/cpp/template-specialization-type/main.cpp
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization-type/main.cpp
@@ -0,0 +1,9 @@
+template  struct TestObj {
+  int f;
+  T g;
+};
+
+int main() {
+  TestObj t{42, 21};
+  return t.f + t.g; // break here
+}
Index: lldb/test/API/lang/cpp/template-specialization-type/TestTemplateSpecializationType.py
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization-type/TestTemplateSpecializationType.py
@@ -0,0 +1,30 @@
+"""
+Test value with a template specialization type.
+"""
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TemplateSpecializationTypeTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_template_specialization_cast_children(self):
+self.build()
+lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.cpp", False))
+
+v = self.frame().EvaluateExpression("t")
+self.assertEquals(2, v.GetNumChildren())
+self.assertEquals("42", v.GetChildAtIndex(0).GetValue())
+self.assertEquals("21", v.GetChildAtIndex(1).GetValue())
+
+# Test a value of the TemplateSpecialization type. We turn
+# RecordType into TemplateSpecializationType by casting and
+# dereferencing a pointer to a record.
+v = self.frame().EvaluateExpression("*((TestObj*))")
+self.assertEquals(2, v.GetNumChildren())
+self.assertEquals("42", v.GetChildAtIndex(0).GetValue())
+self.assertEquals("21", v.GetChildAtIndex(1).GetValue())
Index: lldb/test/API/lang/cpp/template-specialization-type/Makefile

[Lldb-commits] [PATCH] D83876: [lldb] Clean orphaned modules in Debugger::Destroy

2020-07-15 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor planned changes to this revision.
teemperor added a comment.

I'm actually thinking that this maybe should go into the SBDebugger::Destroy 
functions. This way we also get all lldb::ModuleSP instances that are freed by 
the Debugger destructor.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D83876



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


[Lldb-commits] [PATCH] D83876: [lldb] Clean orphaned modules in Debugger::Destroy

2020-07-15 Thread Pavel Labath via Phabricator via lldb-commits
labath added a reviewer: jingham.
labath added a comment.

I have no opinion on this. Jim may have one...


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D83876



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


[Lldb-commits] [PATCH] D83876: [lldb] Clean orphaned modules in Debugger::Destroy

2020-07-15 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor created this revision.
teemperor added reviewers: JDevlieghere, labath, LLDB.

Right now the only places in the SB API where lldb:: ModuleSP instances are 
destroyed are in SBDebugger::MemoryPressureDetected
(where it's just attempted but not guaranteed) and in SBDebugger::DeleteTarget. 
Tests that directly create an lldb::ModuleSP and
never create a target therefore currently leak lldb::Module instances. This 
triggers the sanity checks in lldbtest that make sure
that the global module list is empty after a test.

This patch makes that also SBDebugger::Destroy is cleaning orphaned lldb:: 
ModuleSP instances. It also moves that sanity
check behind the SBDebugger::Destroy in our test suite to make this work.

This fixes TestUnicodeSymbols.py when D83865  
is applied (which makes that the sanity checks actually fail the test).


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D83876

Files:
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/source/Core/Debugger.cpp


Index: lldb/source/Core/Debugger.cpp
===
--- lldb/source/Core/Debugger.cpp
+++ lldb/source/Core/Debugger.cpp
@@ -600,10 +600,14 @@
 for (pos = g_debugger_list_ptr->begin(); pos != end; ++pos) {
   if ((*pos).get() == debugger_sp.get()) {
 g_debugger_list_ptr->erase(pos);
-return;
+break;
   }
 }
   }
+
+  // Clean any modules that are orphaned.
+  bool mandatory = true;
+  ModuleList::RemoveOrphanSharedModules(mandatory);
 }
 
 DebuggerSP Debugger::FindDebuggerWithInstanceName(ConstString instance_name) {
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1058,6 +1058,13 @@
 lldb.SBDebugger.Destroy(self.dbg)
 del self.dbg
 
+# Modules are not orphaned during reproducer replay because they're
+# leaked on purpose.
+if not configuration.is_reproducer():
+# Assert that the global module cache is empty.
+self.assertEqual(lldb.SBModule.GetNumberAllocatedModules(), 0)
+
+
 # =
 # Various callbacks to allow introspection of test progress
 # =
@@ -2021,13 +2028,9 @@
 for target in targets:
 self.dbg.DeleteTarget(target)
 
-# Modules are not orphaned during reproducer replay because they're
-# leaked on purpose.
 if not configuration.is_reproducer():
 # Assert that all targets are deleted.
-assert self.dbg.GetNumTargets() == 0
-# Assert that the global module cache is empty.
-assert lldb.SBModule.GetNumberAllocatedModules() == 0
+self.assertEqual(self.dbg.GetNumTargets(), 0)
 
 # Do this last, to make sure it's in reverse order from how we setup.
 Base.tearDown(self)


Index: lldb/source/Core/Debugger.cpp
===
--- lldb/source/Core/Debugger.cpp
+++ lldb/source/Core/Debugger.cpp
@@ -600,10 +600,14 @@
 for (pos = g_debugger_list_ptr->begin(); pos != end; ++pos) {
   if ((*pos).get() == debugger_sp.get()) {
 g_debugger_list_ptr->erase(pos);
-return;
+break;
   }
 }
   }
+
+  // Clean any modules that are orphaned.
+  bool mandatory = true;
+  ModuleList::RemoveOrphanSharedModules(mandatory);
 }
 
 DebuggerSP Debugger::FindDebuggerWithInstanceName(ConstString instance_name) {
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -1058,6 +1058,13 @@
 lldb.SBDebugger.Destroy(self.dbg)
 del self.dbg
 
+# Modules are not orphaned during reproducer replay because they're
+# leaked on purpose.
+if not configuration.is_reproducer():
+# Assert that the global module cache is empty.
+self.assertEqual(lldb.SBModule.GetNumberAllocatedModules(), 0)
+
+
 # =
 # Various callbacks to allow introspection of test progress
 # =
@@ -2021,13 +2028,9 @@
 for target in targets:
 self.dbg.DeleteTarget(target)
 
-# Modules are not orphaned during reproducer replay because they're
-# leaked on purpose.
 if not configuration.is_reproducer():
 # Assert that all targets are deleted.
-assert self.dbg.GetNumTargets() == 0
-# Assert that the global module cache is empty.
-assert 

[Lldb-commits] [PATCH] D83767: [lldb] Use the basename of the Python test for the log name instead of the class name

2020-07-15 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor reopened this revision.
teemperor added a comment.
This revision is now accepted and ready to land.

Well, on Windows the file name is for some reason always 
"lldbsuite.test.lldbtest" so I reverted this for now. Open for suggestions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83767



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


[Lldb-commits] [lldb] 9c1c6a3 - Revert "[lldb] Use the basename of the Python test for the log name instead of the class name"

2020-07-15 Thread Raphael Isemann via lldb-commits

Author: Raphael Isemann
Date: 2020-07-15T16:26:37+02:00
New Revision: 9c1c6a3fcca840b75a0ae818ac4e24e7460c397b

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

LOG: Revert "[lldb] Use the basename of the Python test for the log name 
instead of the class name"

This reverts commit 29aab9b5c748b28b231e2ca0f9b95453638ade1a.

It seems on Windows the file name is just always "lldbsuite.test.lldbtest" for
all tests and that breaks pretty much everything. Reverting until we have
a better solution.

Added: 


Modified: 
lldb/test/API/CMakeLists.txt

Removed: 




diff  --git a/lldb/test/API/CMakeLists.txt b/lldb/test/API/CMakeLists.txt
index 23b211e14cfa..34f3522c8dfe 100644
--- a/lldb/test/API/CMakeLists.txt
+++ b/lldb/test/API/CMakeLists.txt
@@ -38,7 +38,7 @@ set(LLDB_TEST_USER_ARGS
 set(LLDB_TEST_COMMON_ARGS
   -s
   ${CMAKE_BINARY_DIR}/lldb-test-traces
-  -S fm
+  -S nm
   -u CXXFLAGS
   -u CFLAGS
   )



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


[Lldb-commits] [PATCH] D83858: [lldb] Desugar template specializations

2020-07-15 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor accepted this revision.
teemperor added a comment.

I think your comment got broken by Phabricator. I actually think the old code 
was fine. It's a generic bug that also applies to `Decltype` (which is already 
implemented), so someone just has to fix the whole function in a follow up 
patch (your current code just fixes the TemplateSpecializationType but not 
Decltype). I can do that, but finding a good testing strategy for this is a bit 
of a pain (it's a lot of boilerplate to make a dependent type by hand and not 
sure if we have a good way to reach this from a normal LLDB API).

Just revert the RemoveWrappingTypes to the old implementation and then this is 
ready to go IMHO.


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

https://reviews.llvm.org/D83858



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


[Lldb-commits] [PATCH] D83858: [lldb] Desugar template specializations

2020-07-15 Thread Jaroslav Sevcik via Phabricator via lldb-commits
jarin added a comment.

In D83858#2152772 , @teemperor wrote:

> This could cause that `RemoveWrappingTypes` goes into an infinite loop under 
> some situations. Usually this function is reserved for types that are always 
> 'sugar', but TemplateSpecializationTypes are not always sugar (e.g., 
> dependent types are not sugar). And for types that are not sugar, 
> `getLocallyUnqualifiedSingleStepDesugaredType` will return the type that was 
> passed in. So that will make the loop in that function just keep spinning 
> forever.


That sounds some what worrisome indeed. I changed the code to special case the 
TemplateSpecialization case to return if the type cannot be desugared. There 
are two other options:

1. Special case TemplateSpecialization to always return 
`type->getLocallyUnqualifiedSingleStepDesugaredType()`.
2. No special case, but always early return if the type was unchanged. I am 
imagining something like

  



> However I'm not sure though if there is actually a way to get a dependent 
> type into that logic with the normal LLDB APIs. Also Decltype is already 
> suffering from the same problem so I don't think this patch should be blocked 
> over this.
> 
> So beside some minor nits in the inline comments this LGTM, thanks!




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

https://reviews.llvm.org/D83858



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


[Lldb-commits] [lldb] 313fca6 - [lldb/test] Remove JOIN_CMD from Makefile.rules

2020-07-15 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2020-07-15T16:03:45+02:00
New Revision: 313fca6520b43d95abb73e7c78a252a60ee4cf48

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

LOG: [lldb/test] Remove JOIN_CMD from Makefile.rules

It's possible to achieve the same effect by providing multi-step recipe
instead of a single-step recipe where the step happens to contain
multiple commands.

Added: 


Modified: 
lldb/packages/Python/lldbsuite/test/make/Makefile.rules

Removed: 




diff  --git a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules 
b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
index 5316c51899c7..b9a6937650d0 100644
--- a/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
+++ b/lldb/packages/Python/lldbsuite/test/make/Makefile.rules
@@ -82,11 +82,9 @@ endif
 # we strictly required double-quotes
 #--
 ifeq "$(HOST_OS)" "Windows_NT"
-   JOIN_CMD = &
QUOTE = "
FIXUP_SYNTAX_HIGHLIGHTING_IN_MY_EDITOR = "
 else
-   JOIN_CMD = ;
QUOTE = '
FIXUP_SYNTAX_HIGHLIGHTING_IN_MY_EDITOR = '
 endif
@@ -729,28 +727,28 @@ endif
 # and the -MM option will list all non-system dependencies.
 #--
 %.d: %.c
-   @rm -f $@ $(JOIN_CMD) \
-   $(CC) -M $(CFLAGS) $< > $@.tmp && \
-   sed $(QUOTE)s,\($*\)\.o[ :]*,\1.o $@ : ,g$(QUOTE) < $@.tmp > $@ 
$(JOIN_CMD) \
-   rm -f $@.tmp
+   @rm -f $@
+   @$(CC) -M $(CFLAGS) $< > $@.tmp && \
+   sed $(QUOTE)s,\($*\)\.o[ :]*,\1.o $@ : ,g$(QUOTE) < $@.tmp > $@
+   @rm -f $@.tmp
 
 %.d: %.cpp
-   @rm -f $@ $(JOIN_CMD) \
-   $(CXX) -M $(CXXFLAGS) $< > $@.tmp && \
-   sed $(QUOTE)s,\($*\)\.o[ :]*,\1.o $@ : ,g$(QUOTE) < $@.tmp > $@ 
$(JOIN_CMD) \
-   rm -f $@.tmp
+   @rm -f $@
+   @$(CXX) -M $(CXXFLAGS) $< > $@.tmp && \
+   sed $(QUOTE)s,\($*\)\.o[ :]*,\1.o $@ : ,g$(QUOTE) < $@.tmp > $@
+   @rm -f $@.tmp
 
 %.d: %.m
-   @rm -f $@ $(JOIN_CMD) \
-   $(CC) -M $(CFLAGS) $< > $@.tmp && \
-   sed $(QUOTE)s,\($*\)\.o[ :]*,\1.o $@ : ,g$(QUOTE) < $@.tmp > $@ 
$(JOIN_CMD) \
-   rm -f $@.tmp
+   @rm -f $@
+   @$(CC) -M $(CFLAGS) $< > $@.tmp && \
+   sed $(QUOTE)s,\($*\)\.o[ :]*,\1.o $@ : ,g$(QUOTE) < $@.tmp > $@
+   @rm -f $@.tmp
 
 %.d: %.mm
-   @rm -f $@ $(JOIN_CMD) \
-   $(CXX) -M $(CXXFLAGS) $< > $@.tmp && \
-   sed $(QUOTE)s,\($*\)\.o[ :]*,\1.o $@ : ,g$(QUOTE) < $@.tmp > $@ 
$(JOIN_CMD) \
-   rm -f $@.tmp
+   @rm -f $@
+   @$(CXX) -M $(CXXFLAGS) $< > $@.tmp && \
+   sed $(QUOTE)s,\($*\)\.o[ :]*,\1.o $@ : ,g$(QUOTE) < $@.tmp > $@
+   @rm -f $@.tmp
 
 #--
 # Include all of the makefiles for each source file so we don't have



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


[Lldb-commits] [PATCH] D83858: [lldb] Desugar template specializations

2020-07-15 Thread Jaroslav Sevcik via Phabricator via lldb-commits
jarin updated this revision to Diff 278173.
jarin marked 3 inline comments as done.
jarin added a comment.

Addressed review comments.


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

https://reviews.llvm.org/D83858

Files:
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/test/API/lang/cpp/template-specialization-type/Makefile
  
lldb/test/API/lang/cpp/template-specialization-type/TestTemplateSpecializationType.py
  lldb/test/API/lang/cpp/template-specialization-type/main.cpp


Index: lldb/test/API/lang/cpp/template-specialization-type/main.cpp
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization-type/main.cpp
@@ -0,0 +1,9 @@
+template  struct TestObj {
+  int f;
+  T g;
+};
+
+int main() {
+  TestObj t{42, 21};
+  return t.f + t.g; // break here
+}
Index: 
lldb/test/API/lang/cpp/template-specialization-type/TestTemplateSpecializationType.py
===
--- /dev/null
+++ 
lldb/test/API/lang/cpp/template-specialization-type/TestTemplateSpecializationType.py
@@ -0,0 +1,30 @@
+"""
+Test value with a template specialization type.
+"""
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TemplateSpecializationTypeTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_template_specialization_cast_children(self):
+self.build()
+lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.cpp", False))
+
+v = self.frame().EvaluateExpression("t")
+self.assertEquals(2, v.GetNumChildren())
+self.assertEquals("42", v.GetChildAtIndex(0).GetValue())
+self.assertEquals("21", v.GetChildAtIndex(1).GetValue())
+
+# Test a value of the TemplateSpecialization type. We turn
+# RecordType into TemplateSpecializationType by casting and
+# dereferencing a pointer to a record.
+v = self.frame().EvaluateExpression("*((TestObj*))")
+self.assertEquals(2, v.GetNumChildren())
+self.assertEquals("42", v.GetChildAtIndex(0).GetValue())
+self.assertEquals("21", v.GetChildAtIndex(1).GetValue())
Index: lldb/test/API/lang/cpp/template-specialization-type/Makefile
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization-type/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules
Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -2506,6 +2506,13 @@
 case clang::Type::TypeOfExpr:
   type = type->getLocallyUnqualifiedSingleStepDesugaredType();
   break;
+case clang::Type::TemplateSpecialization: {
+  auto ty = cast(type);
+  if (!ty->isSugared())
+return type;
+  type = ty->desugar();
+  break;
+}
 default:
   return type;
 }


Index: lldb/test/API/lang/cpp/template-specialization-type/main.cpp
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization-type/main.cpp
@@ -0,0 +1,9 @@
+template  struct TestObj {
+  int f;
+  T g;
+};
+
+int main() {
+  TestObj t{42, 21};
+  return t.f + t.g; // break here
+}
Index: lldb/test/API/lang/cpp/template-specialization-type/TestTemplateSpecializationType.py
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization-type/TestTemplateSpecializationType.py
@@ -0,0 +1,30 @@
+"""
+Test value with a template specialization type.
+"""
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TemplateSpecializationTypeTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_template_specialization_cast_children(self):
+self.build()
+lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.cpp", False))
+
+v = self.frame().EvaluateExpression("t")
+self.assertEquals(2, v.GetNumChildren())
+self.assertEquals("42", v.GetChildAtIndex(0).GetValue())
+self.assertEquals("21", v.GetChildAtIndex(1).GetValue())
+
+# Test a value of the TemplateSpecialization type. We turn
+# RecordType into TemplateSpecializationType by casting and
+# dereferencing a pointer to a record.
+v = self.frame().EvaluateExpression("*((TestObj*))")
+self.assertEquals(2, v.GetNumChildren())
+self.assertEquals("42", v.GetChildAtIndex(0).GetValue())
+self.assertEquals("21", 

[Lldb-commits] [lldb] f819d25 - [lldb] Delete useless assertion

2020-07-15 Thread Pavel Labath via lldb-commits

Author: Pavel Labath
Date: 2020-07-15T15:42:53+02:00
New Revision: f819d257982e6c3f1fb57de4252b46bdfaa9415a

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

LOG: [lldb] Delete useless assertion

It served a puprose while we were using the test name to provide a name
for the created file. Now that the files are created in memory, we don't
need that.

Added: 


Modified: 
lldb/unittests/TestingSupport/TestUtilities.cpp

Removed: 




diff  --git a/lldb/unittests/TestingSupport/TestUtilities.cpp 
b/lldb/unittests/TestingSupport/TestUtilities.cpp
index 4d369bd0968a..34f49e5862a7 100644
--- a/lldb/unittests/TestingSupport/TestUtilities.cpp
+++ b/lldb/unittests/TestingSupport/TestUtilities.cpp
@@ -27,8 +27,6 @@ std::string lldb_private::GetInputFilePath(const llvm::Twine 
) {
 }
 
 llvm::Expected TestFile::fromYaml(llvm::StringRef Yaml) {
-  assert(testing::UnitTest::GetInstance()->current_test_info());
-
   std::string Buffer;
   llvm::raw_string_ostream OS(Buffer);
   llvm::yaml::Input YIn(Yaml);



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


[Lldb-commits] [PATCH] D83425: [lldb] add printing of stdout compile errors to lldbsuite

2020-07-15 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D83425#2151003 , @bbli wrote:

> Yeah so in this pic, F12338615: original.png 
> , you can see in the code that both 
> stdout and stderr point to PIPE, and what gets printed out is the 
> concatenation of the two.  However, in F12338626: stderr_as_stdout.png 
> , where stderr now points to stdout, and 
> I just print the stdout output, the "clang-11: error" messages from stderr 
> gets mixed up with the results from stdout,


Yes, that's exactly what I wanted! :) It matches the output I would get when 
running that command in the terminal and it makes the error come out right 
after the compiler command which produced it (it more complex makefiles it may 
not be so clear which compiler command produced what error).

The fact that the first "random flag" error seemingly comes out before any 
compiler command is weird but not related to this problem. That happens because 
our makefile runs a silent (without echoing the command) compiler invocation to 
build the dependency file. We may possibly want to echo that too, but it 
doesn't matter that much -- in more realistic scenarios, the error will not be 
as simple as a missing flag, and the dependency command will succeed, but the 
error will come from the compilation step.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83425



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


[Lldb-commits] [PATCH] D82064: [ARM64] Add QEMU testing environment setup guide for SVE testing

2020-07-15 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

In D82064#2152807 , @omjavaid wrote:

> Updated after incorporating review comments.
>
> @rovka I gave your idea a thought about moving included scripts to 
> lldb/utils. IMO these scripts have no relationship with LLDB and no such 
> precedent exist where we uploaded such tools or utilities in LLDB source 
> tree. Lets have other opinions and finalize.


The relationship to lldb is that it can be used to setup lldb for 
cross-testing. And I personally don't see a difference between a standalone 
bash script stashed somewhere inside the repo, and having that script embedded 
inside a `.txt` file. The bar for stashing a script into the repo is fairly 
low, and this seems useful enough to cross it, particularly if it can handle 
architectures other than arm (I do like the idea of making the description 
generic, and then mention arm/sve specific in a separate section or file).




Comment at: lldb/docs/lldb-qemu-aarch64-sve-howto.txt:39-40
+RFS_IMG_NAME=$1
+shift
+RFS_IMG_SIZE_GB=$1
+shift

Why not just `RFS_IMG_SIZE_GB=$2`, etc., without all the shifts?


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

https://reviews.llvm.org/D82064



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


[Lldb-commits] [PATCH] D83180: Set generic error in SBError SetErrorToGenericError

2020-07-15 Thread Konrad Wilhelm Kleine via Phabricator via lldb-commits
kwk added a comment.

LGTM but a test would indeed be nice.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83180



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


[Lldb-commits] [PATCH] D77047: AArch64 SVE register infos and core file support

2020-07-15 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

At this point, I think I (finally) have a good understanding of both how this 
patch works and interacts with the rest of the world. I have one more batch of 
comments, but hopefully none are too controversial, and I really do hope this 
is the last iteration.




Comment at: lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp:289
+
+lldb_private::RegisterInfo *new_reg_info_p = reg_info_ref.data();
+

I think all uses of `new_reg_info_p` could just be replaced by `reg_info_ref`



Comment at: 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp:63-66
+m_sve_note_payload.resize(m_sveregset.GetByteSize());
+::memcpy(GetSVEBuffer(), m_sveregset.GetDataStart(),
+ m_sveregset.GetByteSize());
+::memcpy(_sve_header, m_sveregset.GetDataStart(), sizeof(m_sve_header));

What's up with this copying? We already have the data in the `m_sveregset` 
DataExtractor. What's the reason for copying it into the `m_sve_note_payload` 
vector? Also, `m_sve_header` seems like it could just be a `reinterpret_cast`ed 
pointer into that buffer instead of a copy. (Maybe not even a pointer, just a 
utility function which performs the cast when called).

Actually, when I think about casts and data extractors, I am reminded of 
endianness. This will access those fields using host endianness, which is most 
likely not what we want to do. So, probably the best/simplest solution would be 
to indeed declare a `user_sve_header` struct, but don't populate it via memcpy, 
but rather via the appropriate DataExtractor extraction methods. Since the only 
field of the user_sve_header used outside this function is the `vl` field, 
perhaps the struct could be a local variable and only the vector length would 
be persisted. That would be consistent with how the `flags` field is decoded 
and stored into the `m_sve_state` field.

(If the struct fields are always little-endian (if that's true, I thought arm 
has BE variants) then you could also stick to the `reinterpret_cast` idea, but 
change the types of the struct fields to `llvm::support::ulittleXX_t` to read 
them as LE independently of the host.)



Comment at: 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp:84-86
+  const uint32_t reg = reg_info->kinds[lldb::eRegisterKindLLDB];
+  if (reg == LLDB_INVALID_REGNUM)
+return false;

This is already checked by ReadRegister and the false -> uint32_t conversion is 
dodgy. An assertion would completely suffice here.



Comment at: 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp:140
+  offset -= GetGPRSize();
+  if (IsFPR(reg) && offset < m_fpregset.GetByteSize()) {
+value.SetFromMemoryData(reg_info, m_fpregset.GetDataStart() + offset,

This `IsFPR` check is now redundant.



Comment at: 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp:152-153
+sve_reg_num = reg_info->value_regs[0];
+  else if (reg == GetRegNumFPCR() || reg == GetRegNumFPSR())
+sve_reg_num = reg;
+  if (sve_reg_num != LLDB_INVALID_REGNUM) {

These two registers are special-cased both here and in the 
`CalculateSVEOffset`. Given that both functions also do a switch over the sve 
"states", it makes following the code quite challenging. What if we moved the 
handling of these registers completely up-front, and removed their handling 
from `CalculateSVEOffset` completely?
I'm thinking of something like:
```
if (reg == GetRegNumFPCR() && m_sve_state != SVEState::Disabled) {
  src = GetSVEBuffer() + GetFPCROffset(); // Or maybe just inline GetFPCROffset 
here
} else if (reg == GetRegNumFPSR() && m_sve_state != SVEState::Disabled) {
  src = ...;
} if (IsFPR(reg)) {
  // as usual, only you can assume that FP[CS]R are already handled if SVE is 
enabled
}
```



Comment at: 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp:161-162
+  } else if (IsSVEVG(reg)) {
+sve_vg = GetSVERegVG();
+src = (uint8_t *)_vg;
+  } else if (IsSVE(reg)) {

This also looks endian-incorrect. Maybe `value = GetSVERegVG(); return true;` ?



Comment at: 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp:164
+  } else if (IsSVE(reg)) {
+if (m_sve_state != SVEState::Disabled) {
+  if (m_sve_state == SVEState::FPSIMD) {

A switch over possible `m_sve_state` values would likely be cleaner.



Comment at: 
lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp:174
+  ::memcpy(sve_reg_non_live.data(),
+   (const uint8_t *)GetSVEBuffer() + offset, 16);
+}

I guess it would be better to do the cast inside GetSVEBuffer. (and please make 
that a c++ reinterpret_cast).



[Lldb-commits] [lldb] 10fd550 - [lldb] Make expect_expr fall back to the dummy target if no target is selected

2020-07-15 Thread Raphael Isemann via lldb-commits

Author: Raphael Isemann
Date: 2020-07-15T13:56:00+02:00
New Revision: 10fd550d308d5dbcf7a3068f1f76d5f0f1a56661

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

LOG: [lldb] Make expect_expr fall back to the dummy target if no target is 
selected

Summary:

Currently expect_expr will not run the expression if no target is selected. This
patch changes this behavior so that expect_expr will instead fall back to the
dummy target similar to what the `expression` command is doing. This way we
don't have to compile an empty executable to be able to use `expect_expr` (which
is a waste of resources for tests that just test generic type system features).

As a test I modernized the TestTypeOfDeclTypeExpr into a Python test +
expect_expr (as it relied on the dummy target fallback of the expression
command).

Reviewers: labath, JDevlieghere

Reviewed By: labath

Subscribers: abidh

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

Added: 
lldb/test/API/lang/cpp/typeof/TestTypeOfDeclTypeExpr.py

Modified: 
lldb/packages/Python/lldbsuite/test/lldbtest.py

Removed: 
lldb/test/Shell/Expr/TestTypeOfDeclTypeExpr.test



diff  --git a/lldb/packages/Python/lldbsuite/test/lldbtest.py 
b/lldb/packages/Python/lldbsuite/test/lldbtest.py
index 9c32bdb42e28..280e02f56f28 100644
--- a/lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ b/lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -2456,7 +2456,12 @@ def expect_expr(
 options.SetLanguage(frame.GuessLanguage())
 eval_result = self.frame().EvaluateExpression(expr, options)
 else:
-eval_result = self.target().EvaluateExpression(expr, options)
+target = self.target()
+# If there is no selected target, run the expression in the dummy
+# target.
+if not target.IsValid():
+target = self.dbg.GetDummyTarget()
+eval_result = target.EvaluateExpression(expr, options)
 
 self.assertSuccess(eval_result.GetError())
 

diff  --git a/lldb/test/API/lang/cpp/typeof/TestTypeOfDeclTypeExpr.py 
b/lldb/test/API/lang/cpp/typeof/TestTypeOfDeclTypeExpr.py
new file mode 100644
index ..9c5289c4fa79
--- /dev/null
+++ b/lldb/test/API/lang/cpp/typeof/TestTypeOfDeclTypeExpr.py
@@ -0,0 +1,14 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@no_debug_info_test
+def test(self):
+self.expect_expr("int i; __typeof__(i) j = 1; j", result_type="typeof 
(i)", result_value="1")
+self.expect_expr("int i; typeof(i) j = 1; j", result_type="typeof 
(i)", result_value="1")
+self.expect_expr("int i; decltype(i) j = 1; j", 
result_type="decltype(i)", result_value="1")

diff  --git a/lldb/test/Shell/Expr/TestTypeOfDeclTypeExpr.test 
b/lldb/test/Shell/Expr/TestTypeOfDeclTypeExpr.test
deleted file mode 100644
index c156ae556a71..
--- a/lldb/test/Shell/Expr/TestTypeOfDeclTypeExpr.test
+++ /dev/null
@@ -1,13 +0,0 @@
-# RUN: %lldb -b -s %s | FileCheck %s
-
-expression int i; __typeof__(i) j = 1; j
-# CHECK: (lldb) expression int i; __typeof__(i) j = 1; j
-# CHECK-NEXT: (typeof (i)) {{.*}} = 1
-
-expression int i; typeof(i) j = 1; j
-# CHECK: (lldb) expression int i; typeof(i) j = 1; j
-# CHECK-NEXT: (typeof (i)) {{.*}} = 1
-
-expression int i; decltype(i) j = 1; j
-# CHECK: (lldb) expression int i; decltype(i) j = 1; j
-# CHECK-NEXT: (decltype(i)) {{.*}} = 1



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


[Lldb-commits] [PATCH] D83388: [lldb] Make expect_expr fall back to the dummy target if no target is selected

2020-07-15 Thread Raphael Isemann via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG10fd550d308d: [lldb] Make expect_expr fall back to the dummy 
target if no target is selected (authored by teemperor).
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83388

Files:
  lldb/packages/Python/lldbsuite/test/lldbtest.py
  lldb/test/API/lang/cpp/typeof/TestTypeOfDeclTypeExpr.py
  lldb/test/Shell/Expr/TestTypeOfDeclTypeExpr.test


Index: lldb/test/Shell/Expr/TestTypeOfDeclTypeExpr.test
===
--- lldb/test/Shell/Expr/TestTypeOfDeclTypeExpr.test
+++ /dev/null
@@ -1,13 +0,0 @@
-# RUN: %lldb -b -s %s | FileCheck %s
-
-expression int i; __typeof__(i) j = 1; j
-# CHECK: (lldb) expression int i; __typeof__(i) j = 1; j
-# CHECK-NEXT: (typeof (i)) {{.*}} = 1
-
-expression int i; typeof(i) j = 1; j
-# CHECK: (lldb) expression int i; typeof(i) j = 1; j
-# CHECK-NEXT: (typeof (i)) {{.*}} = 1
-
-expression int i; decltype(i) j = 1; j
-# CHECK: (lldb) expression int i; decltype(i) j = 1; j
-# CHECK-NEXT: (decltype(i)) {{.*}} = 1
Index: lldb/test/API/lang/cpp/typeof/TestTypeOfDeclTypeExpr.py
===
--- /dev/null
+++ lldb/test/API/lang/cpp/typeof/TestTypeOfDeclTypeExpr.py
@@ -0,0 +1,14 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@no_debug_info_test
+def test(self):
+self.expect_expr("int i; __typeof__(i) j = 1; j", result_type="typeof 
(i)", result_value="1")
+self.expect_expr("int i; typeof(i) j = 1; j", result_type="typeof 
(i)", result_value="1")
+self.expect_expr("int i; decltype(i) j = 1; j", 
result_type="decltype(i)", result_value="1")
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -2456,7 +2456,12 @@
 options.SetLanguage(frame.GuessLanguage())
 eval_result = self.frame().EvaluateExpression(expr, options)
 else:
-eval_result = self.target().EvaluateExpression(expr, options)
+target = self.target()
+# If there is no selected target, run the expression in the dummy
+# target.
+if not target.IsValid():
+target = self.dbg.GetDummyTarget()
+eval_result = target.EvaluateExpression(expr, options)
 
 self.assertSuccess(eval_result.GetError())
 


Index: lldb/test/Shell/Expr/TestTypeOfDeclTypeExpr.test
===
--- lldb/test/Shell/Expr/TestTypeOfDeclTypeExpr.test
+++ /dev/null
@@ -1,13 +0,0 @@
-# RUN: %lldb -b -s %s | FileCheck %s
-
-expression int i; __typeof__(i) j = 1; j
-# CHECK: (lldb) expression int i; __typeof__(i) j = 1; j
-# CHECK-NEXT: (typeof (i)) {{.*}} = 1
-
-expression int i; typeof(i) j = 1; j
-# CHECK: (lldb) expression int i; typeof(i) j = 1; j
-# CHECK-NEXT: (typeof (i)) {{.*}} = 1
-
-expression int i; decltype(i) j = 1; j
-# CHECK: (lldb) expression int i; decltype(i) j = 1; j
-# CHECK-NEXT: (decltype(i)) {{.*}} = 1
Index: lldb/test/API/lang/cpp/typeof/TestTypeOfDeclTypeExpr.py
===
--- /dev/null
+++ lldb/test/API/lang/cpp/typeof/TestTypeOfDeclTypeExpr.py
@@ -0,0 +1,14 @@
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+class TestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+@no_debug_info_test
+def test(self):
+self.expect_expr("int i; __typeof__(i) j = 1; j", result_type="typeof (i)", result_value="1")
+self.expect_expr("int i; typeof(i) j = 1; j", result_type="typeof (i)", result_value="1")
+self.expect_expr("int i; decltype(i) j = 1; j", result_type="decltype(i)", result_value="1")
Index: lldb/packages/Python/lldbsuite/test/lldbtest.py
===
--- lldb/packages/Python/lldbsuite/test/lldbtest.py
+++ lldb/packages/Python/lldbsuite/test/lldbtest.py
@@ -2456,7 +2456,12 @@
 options.SetLanguage(frame.GuessLanguage())
 eval_result = self.frame().EvaluateExpression(expr, options)
 else:
-eval_result = self.target().EvaluateExpression(expr, options)
+target = self.target()
+# If there is no selected target, run the expression in the dummy
+# target.
+if not target.IsValid():
+target = self.dbg.GetDummyTarget()
+ 

[Lldb-commits] [PATCH] D83767: [lldb] Use the basename of the Python test for the log name instead of the class name

2020-07-15 Thread Raphael Isemann via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG29aab9b5c748: [lldb] Use the basename of the Python test for 
the log name instead of the… (authored by teemperor).
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83767

Files:
  lldb/test/API/CMakeLists.txt


Index: lldb/test/API/CMakeLists.txt
===
--- lldb/test/API/CMakeLists.txt
+++ lldb/test/API/CMakeLists.txt
@@ -38,7 +38,7 @@
 set(LLDB_TEST_COMMON_ARGS
   -s
   ${CMAKE_BINARY_DIR}/lldb-test-traces
-  -S nm
+  -S fm
   -u CXXFLAGS
   -u CFLAGS
   )


Index: lldb/test/API/CMakeLists.txt
===
--- lldb/test/API/CMakeLists.txt
+++ lldb/test/API/CMakeLists.txt
@@ -38,7 +38,7 @@
 set(LLDB_TEST_COMMON_ARGS
   -s
   ${CMAKE_BINARY_DIR}/lldb-test-traces
-  -S nm
+  -S fm
   -u CXXFLAGS
   -u CFLAGS
   )
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 29aab9b - [lldb] Use the basename of the Python test for the log name instead of the class name

2020-07-15 Thread Raphael Isemann via lldb-commits

Author: Raphael Isemann
Date: 2020-07-15T13:54:43+02:00
New Revision: 29aab9b5c748b28b231e2ca0f9b95453638ade1a

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

LOG: [lldb] Use the basename of the Python test for the log name instead of the 
class name

Summary:

>From what I know we already have the restriction that every test in the test
suite needs to have a unique file name as that's used for generating the unique
build directory for a test. It seems there is also a restriction that every test
case class in the test suite needs to have a unique name as that's used to
generate the unique log file name for the test run.

This changes the log file format to use the basename of the test file instead so
that we only have to keep worrying about the 'unique file name' restriction from
now on.

This came up because I started naming the test classes "TestCase" (as repeating
the file name in the test class seems like redudant information that just makes
renaming tests a pain).

Reviewers: labath, JDevlieghere

Reviewed By: labath

Subscribers: mgorny, abidh

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

Added: 


Modified: 
lldb/test/API/CMakeLists.txt

Removed: 




diff  --git a/lldb/test/API/CMakeLists.txt b/lldb/test/API/CMakeLists.txt
index 34f3522c8dfe..23b211e14cfa 100644
--- a/lldb/test/API/CMakeLists.txt
+++ b/lldb/test/API/CMakeLists.txt
@@ -38,7 +38,7 @@ set(LLDB_TEST_USER_ARGS
 set(LLDB_TEST_COMMON_ARGS
   -s
   ${CMAKE_BINARY_DIR}/lldb-test-traces
-  -S nm
+  -S fm
   -u CXXFLAGS
   -u CFLAGS
   )



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


[Lldb-commits] [PATCH] D82064: [ARM64] Add QEMU testing environment setup guide for SVE testing

2020-07-15 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 278128.
omjavaid added a comment.

Updated after incorporating review comments.

@rovka I gave your idea a thought about moving included scripts to lldb/utils. 
IMO these scripts have no relationship with LLDB and no such precedent exist 
where we uploaded such tools or utilities in LLDB source tree. Lets have other 
opinions and finalize.


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

https://reviews.llvm.org/D82064

Files:
  lldb/docs/lldb-qemu-aarch64-sve-howto.txt

Index: lldb/docs/lldb-qemu-aarch64-sve-howto.txt
===
--- /dev/null
+++ lldb/docs/lldb-qemu-aarch64-sve-howto.txt
@@ -0,0 +1,233 @@
+
+LLDB Testing on AArch64 SVE Linux using QEMU system mode emulation
+
+
+QEMU can be used to test LLDB in an emulation environment in the absence of
+actual hardware. This write up will help setup a QEMU environment for testing
+AArch64 features like SVE, MTE, Pointer Authentication etc. This write can be
+used as reference to setup similar testing environment for other architectures
+supported by QEMU emulator.
+
+Ubuntu Bionic/Focal x86_64 host was used to test all the instructions in this
+document. Please update it according to your host distribution/architecture.
+
+# STEP 1
+
+# Bash script for creating Debian/Ubuntu Linux RootFS for QEMU system emulation
+# Example usage:
+# To create an img file of size 8 GB containing Ubuntu Bionic arm64 rootFS
+# > bash create-qemu-rootfs.sh bionic-arm64 8G bionic arm64
+
+#!/bin/bash
+
+# Prerequisites:
+sudo apt-get install debootstrap qemu-user-static schroot qemu-utils
+
+if [ $# -gt 3 ]; then
+  echo "Your command line contains $# arguments"
+else
+  echo "Invalid or no arguments"
+  echo "Usage example: create-rootfs-qemu.sh focal-arm64 8G focal arm64"
+  echo "focal-arm64 is image name"
+  echo "8G is image size in Gigabytes"
+  echo "focal is distro name"
+  echo "arm64 is rootFS architecture"
+  exit
+fi
+
+RFS_IMG_NAME=$1
+shift
+RFS_IMG_SIZE_GB=$1
+shift
+BOOTSTRAP_DISTRO=$1
+shift
+BOOTSTRAP_ARCH=$1
+
+echo "Root FS image name ... $RFS_IMG_NAME"
+echo "Root FS size in GB ... $RFS_IMG_SIZE_GB"
+echo "Root FS bootstrap distro name ... $BOOTSTRAP_DISTRO"
+echo "Root FS bootstrap distro architecture... $BOOTSTRAP_ARCH"
+
+qemu-img create $RFS_IMG_NAME.img $RFS_IMG_SIZE_GB
+
+mkfs.ext4 $RFS_IMG_NAME.img
+mkdir $RFS_IMG_NAME.dir
+sudo mount -o loop $RFS_IMG_NAME.img $RFS_IMG_NAME.dir
+
+sudo qemu-debootstrap --arch $BOOTSTRAP_ARCH $BOOTSTRAP_DISTRO $RFS_IMG_NAME.dir
+
+sudo chroot $RFS_IMG_NAME.dir locale-gen en_US.UTF-8
+
+sudo chroot $RFS_IMG_NAME.dir sed -i \
+'s/main/main restricted multiverse universe/g' /etc/apt/sources.list
+
+sudo chroot $RFS_IMG_NAME.dir sed -i '$ a\nameserver 8.8.8.8' /etc/resolv.conf
+
+sudo chroot $RFS_IMG_NAME.dir apt update
+sudo chroot $RFS_IMG_NAME.dir apt -y install ssh bash-completion
+sudo chroot $RFS_IMG_NAME.dir adduser --gecos "" $USER
+sudo chroot $RFS_IMG_NAME.dir adduser $USER sudo
+sudo umount $RFS_IMG_NAME.dir
+rmdir $RFS_IMG_NAME.dir
+
+
+#  End of STEP 1
+
+
+
+# STEP 2
+#
+# Build QEMU from source for AArch64 system-mode emulation
+#
+# Please visit https://wiki.qemu.org/Hosts/Linux for instructions
+# on how to build QEMU from source.
+#
+# In order to enable AArch64 system by QEMU please run configure QEMU resources
+# with following arguments: ./configure --target-list=aarch64-softmmu
+#
+# Please run ./configure --help inside QEMU source directory for a complete
+# list of supported emulation targets.
+
+
+# Install dependencies
+sudo apt-get build-dep qemu
+sudo apt install libsdl2-dev
+
+# Checkout source code
+git clone git://git.qemu.org/qemu.git qemu.git
+
+# Configure and build
+cd qemu.git
+./configure --target-list=aarch64-softmmu
+make
+
+
+# STEP 3
+#
+# Cross compile Linux kernel
+
+
+# Install dependencies
+sudo apt install gcc-arm-linux-gnueabihf gcc-aarch64-linux-gnu
+
+# Checkout source code, select branch and clean up source directory
+git clone  \

[Lldb-commits] [PATCH] D79699: Add ptrace register access for AArch64 SVE registers

2020-07-15 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 278127.
omjavaid added a comment.

Updated and re-based after changes in core file patch


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

https://reviews.llvm.org/D79699

Files:
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp
  lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
  
lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/Makefile
  
lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
  
lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c

Index: lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
===
--- /dev/null
+++ lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/main.c
@@ -0,0 +1,5 @@
+int main() {
+  asm volatile("ptrue p0.s\n\t");
+  asm volatile("fcpy  z0.s, p0/m, #5.\n\t");
+  return 0; // Set a break point here.
+}
\ No newline at end of file
Index: lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
===
--- /dev/null
+++ lldb/test/API/commands/register/register/aarch64_sve_registers/rw_access_static_config/TestSVERegisters.py
@@ -0,0 +1,142 @@
+"""
+Test the AArch64 SVE registers.
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class RegisterCommandsTestCase(TestBase):
+
+def check_sve_register_size(self, set, name, expected):
+reg_value = set.GetChildMemberWithName(name)
+self.assertTrue(reg_value.IsValid(),
+'Verify we have a register named "%s"' % (name))
+self.assertEqual(reg_value.GetByteSize(), expected,
+ 'Verify "%s" == %i' % (name, expected))
+
+mydir = TestBase.compute_mydir(__file__)
+
+@skipIf
+def test_sve_registers_configuration(self):
+"""Test AArch64 SVE registers size configuration."""
+self.build()
+self.line = line_number('main.c', '// Set a break point here.')
+
+exe = self.getBuildArtifact("a.out")
+self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
+
+lldbutil.run_break_set_by_file_and_line(
+self, "main.c", self.line, num_expected_locations=1)
+self.runCmd("run", RUN_SUCCEEDED)
+
+self.expect("thread backtrace", STOPPED_DUE_TO_BREAKPOINT,
+substrs=["stop reason = breakpoint 1."])
+
+target = self.dbg.GetSelectedTarget()
+process = target.GetProcess()
+thread = process.GetThreadAtIndex(0)
+currentFrame = thread.GetFrameAtIndex(0)
+
+has_sve = False
+for registerSet in currentFrame.GetRegisters():
+if 'Scalable Vector Extension Registers' in registerSet.GetName():
+has_sve = True
+
+if not has_sve:
+self.skipTest('SVE registers must be supported.')
+
+registerSets = process.GetThreadAtIndex(
+0).GetFrameAtIndex(0).GetRegisters()
+
+sve_registers = registerSets.GetValueAtIndex(2)
+
+vg_reg = sve_registers.GetChildMemberWithName("vg")
+
+vg_reg_value = sve_registers.GetChildMemberWithName(
+"vg").GetValueAsUnsigned()
+
+z_reg_size = vg_reg_value * 8
+
+p_reg_size = z_reg_size / 8
+
+for i in range(32):
+self.check_sve_register_size(
+sve_registers, 'z%i' % (i), z_reg_size)
+
+for i in range(16):
+self.check_sve_register_size(
+sve_registers, 'p%i' % (i), p_reg_size)
+
+self.check_sve_register_size(sve_registers, 'ffr', p_reg_size)
+
+mydir = TestBase.compute_mydir(__file__)
+@no_debug_info_test
+@skipIf
+def test_sve_registers_read_write(self):
+"""Test AArch64 SVE registers read and write."""
+self.build()
+self.line = line_number('main.c', '// Set a break point here.')
+
+exe = self.getBuildArtifact("a.out")
+self.runCmd("file " + exe, CURRENT_EXECUTABLE_SET)
+
+lldbutil.run_break_set_by_file_and_line(
+self, "main.c", self.line, num_expected_locations=1)
+self.runCmd("run", RUN_SUCCEEDED)
+
+self.expect("thread backtrace", STOPPED_DUE_TO_BREAKPOINT,
+substrs=["stop reason = breakpoint 1."])
+
+target = self.dbg.GetSelectedTarget()
+process = target.GetProcess()
+thread = process.GetThreadAtIndex(0)
+currentFrame = 

[Lldb-commits] [PATCH] D77047: AArch64 SVE register infos and core file support

2020-07-15 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 278124.
omjavaid added a comment.

Minor fix removing GetRegNumP0 which is no longer needed.


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

https://reviews.llvm.org/D77047

Files:
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_arm64_sve.h
  lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
  lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
  lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
  lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
  lldb/test/API/functionalities/postmortem/elf-core/linux-aarch64-sve.c
  lldb/test/API/functionalities/postmortem/elf-core/linux-aarch64-sve.core

Index: lldb/test/API/functionalities/postmortem/elf-core/linux-aarch64-sve.c
===
--- /dev/null
+++ lldb/test/API/functionalities/postmortem/elf-core/linux-aarch64-sve.c
@@ -0,0 +1,24 @@
+// compile with -march=armv8-a+sve on compatible aarch64 compiler
+// linux-aarch64-sve.core was generated by: aarch64-linux-gnu-gcc-8
+// commandline: -march=armv8-a+sve -nostdlib -static -g linux-aarch64-sve.c
+static void bar(char *boom) {
+  char F = 'b';
+  asm volatile("ptrue p0.s\n\t");
+  asm volatile("fcpy  z0.s, p0/m, #7.5\n\t");
+  asm volatile("ptrue p1.s\n\t");
+  asm volatile("fcpy  z1.s, p1/m, #11.5\n\t");
+  asm volatile("ptrue p3.s\n\t");
+  asm volatile("fcpy  z3.s, p3/m, #15.5\n\t");
+
+  *boom = 47; // Frame bar
+}
+
+static void foo(char *boom, void (*boomer)(char *)) {
+  char F = 'f';
+  boomer(boom); // Frame foo
+}
+
+void _start(void) {
+  char F = '_';
+  foo(0, bar); // Frame _start
+}
Index: lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
===
--- lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -323,6 +323,48 @@
 
 self.expect("register read --all")
 
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("AArch64")
+def test_aarch64_sve_regs(self):
+# check 64 bit ARM core files
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-aarch64-sve.core")
+
+values = {}
+values["fp"] = "0xfc1ff4f0"
+values["lr"] = "0x00400170"
+values["sp"] = "0xfc1ff4d0"
+values["pc"] = "0x0040013c"
+values["v0"] = "{0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40}"
+values["v1"] = "{0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41}"
+values["v2"] = "{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}"
+values["v3"] = "{0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41}"
+values["s0"] = "7.5"
+values["s1"] = "11.5"
+values["s2"] = "0"
+values["s3"] = "15.5"
+values["d0"] = "65536.0158538818"
+values["d1"] = "1572864.25476074"
+values["d2"] = "0"
+values["d3"] = "25165828.0917969"
+values["vg"] = "0x0004"
+values["z0"] = "{0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40}"
+values["z1"] = "{0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41}"
+values["z2"] = "{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}"
+values["z3"] = "{0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41}"
+values["p0"] = "{0x11 0x11 0x11 0x11}"
+values["p1"] = "{0x11 0x11 0x11 0x11}"
+values["p2"] = "{0x00 0x00 0x00 0x00}"
+values["p3"] = "{0x11 0x11 0x11 0x11}"
+values["p4"] = "{0x00 0x00 0x00 0x00}"
+
+for regname, value in values.items():
+self.expect("register read {}".format(regname),
+substrs=["{} = {}".format(regname, value)])
+
+self.expect("register read --all")
+
 @skipIf(triple='^mips')
 @skipIfLLVMTargetMissing("ARM")
 def test_arm_core(self):
Index: lldb/source/Plugins/Process/elf-core/RegisterUtilities.h

[Lldb-commits] [PATCH] D83858: [lldb] Desugar template specializations

2020-07-15 Thread Raphael Isemann via Phabricator via lldb-commits
teemperor accepted this revision.
teemperor added a comment.
This revision is now accepted and ready to land.

This could cause that `RemoveWrappingTypes` goes into an infinite loop under 
some situations. Usually this function is reserved for types that are always 
'sugar', but TemplateSpecializationTypes are not always sugar (e.g., dependent 
types are not sugar). And for types that are not sugar, 
`getLocallyUnqualifiedSingleStepDesugaredType` will return the type that was 
passed in. So that will make the loop in that function just keep spinning 
forever.

However I'm not sure though if there is actually a way to get a dependent type 
into that logic with the normal LLDB APIs. Also Decltype is already suffering 
from the same problem so I don't think this patch should be blocked over this.

So beside some minor nits in the inline comments this LGTM, thanks!




Comment at: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp:2507
 case clang::Type::TypeOfExpr:
+case clang::Type::TemplateSpecialization:
   type = type->getLocallyUnqualifiedSingleStepDesugaredType();

Nit: this is supposed to be in alphabetical order.



Comment at: 
lldb/test/API/lang/cpp/template-specialization/TestTemplateSpecialization.py:1
+"""
+Test evaluating an expression with a cast to a pointer to a template

I think this test should be just called `template-specialization-type` as it's 
mainly testing that we do the right thing this this specific type.



Comment at: 
lldb/test/API/lang/cpp/template-specialization/TestTemplateSpecialization.py:25
+
+v = self.frame().EvaluateExpression("*((TestObj*))")
+self.assertEquals(2, v.GetNumChildren())

Maybe add a comment that this turns the RecordType into a 
TemplateSpecializationType.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83858



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


[Lldb-commits] [PATCH] D77047: AArch64 SVE register infos and core file support

2020-07-15 Thread Muhammad Omair Javaid via Phabricator via lldb-commits
omjavaid updated this revision to Diff 278113.
omjavaid added a comment.

This update address issues highlighted in last iteration and also minimizes the 
use of SVE_PT macros by using RegisterInfo.byte_size and byte_offset where 
possible.

@labath What do you think ?


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

https://reviews.llvm.org/D77047

Files:
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterContextPOSIX_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.cpp
  lldb/source/Plugins/Process/Utility/RegisterInfoPOSIX_arm64.h
  lldb/source/Plugins/Process/Utility/RegisterInfos_arm64_sve.h
  lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.cpp
  lldb/source/Plugins/Process/elf-core/RegisterContextPOSIXCore_arm64.h
  lldb/source/Plugins/Process/elf-core/RegisterUtilities.h
  lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
  lldb/test/API/functionalities/postmortem/elf-core/linux-aarch64-sve.c
  lldb/test/API/functionalities/postmortem/elf-core/linux-aarch64-sve.core

Index: lldb/test/API/functionalities/postmortem/elf-core/linux-aarch64-sve.c
===
--- /dev/null
+++ lldb/test/API/functionalities/postmortem/elf-core/linux-aarch64-sve.c
@@ -0,0 +1,24 @@
+// compile with -march=armv8-a+sve on compatible aarch64 compiler
+// linux-aarch64-sve.core was generated by: aarch64-linux-gnu-gcc-8
+// commandline: -march=armv8-a+sve -nostdlib -static -g linux-aarch64-sve.c
+static void bar(char *boom) {
+  char F = 'b';
+  asm volatile("ptrue p0.s\n\t");
+  asm volatile("fcpy  z0.s, p0/m, #7.5\n\t");
+  asm volatile("ptrue p1.s\n\t");
+  asm volatile("fcpy  z1.s, p1/m, #11.5\n\t");
+  asm volatile("ptrue p3.s\n\t");
+  asm volatile("fcpy  z3.s, p3/m, #15.5\n\t");
+
+  *boom = 47; // Frame bar
+}
+
+static void foo(char *boom, void (*boomer)(char *)) {
+  char F = 'f';
+  boomer(boom); // Frame foo
+}
+
+void _start(void) {
+  char F = '_';
+  foo(0, bar); // Frame _start
+}
Index: lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
===
--- lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
+++ lldb/test/API/functionalities/postmortem/elf-core/TestLinuxCore.py
@@ -323,6 +323,48 @@
 
 self.expect("register read --all")
 
+@skipIf(triple='^mips')
+@skipIfLLVMTargetMissing("AArch64")
+def test_aarch64_sve_regs(self):
+# check 64 bit ARM core files
+target = self.dbg.CreateTarget(None)
+self.assertTrue(target, VALID_TARGET)
+process = target.LoadCore("linux-aarch64-sve.core")
+
+values = {}
+values["fp"] = "0xfc1ff4f0"
+values["lr"] = "0x00400170"
+values["sp"] = "0xfc1ff4d0"
+values["pc"] = "0x0040013c"
+values["v0"] = "{0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40}"
+values["v1"] = "{0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41}"
+values["v2"] = "{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}"
+values["v3"] = "{0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41}"
+values["s0"] = "7.5"
+values["s1"] = "11.5"
+values["s2"] = "0"
+values["s3"] = "15.5"
+values["d0"] = "65536.0158538818"
+values["d1"] = "1572864.25476074"
+values["d2"] = "0"
+values["d3"] = "25165828.0917969"
+values["vg"] = "0x0004"
+values["z0"] = "{0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40 0x00 0x00 0xf0 0x40}"
+values["z1"] = "{0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41 0x00 0x00 0x38 0x41}"
+values["z2"] = "{0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}"
+values["z3"] = "{0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41 0x00 0x00 0x78 0x41}"
+values["p0"] = "{0x11 0x11 0x11 0x11}"
+values["p1"] = "{0x11 0x11 0x11 0x11}"
+values["p2"] = "{0x00 0x00 0x00 0x00}"
+values["p3"] = "{0x11 0x11 0x11 0x11}"
+values["p4"] = "{0x00 0x00 0x00 0x00}"
+
+for regname, value in values.items():
+self.expect("register read {}".format(regname),
+substrs=["{} = {}".format(regname, value)])
+
+self.expect("register read --all")
+
 @skipIf(triple='^mips')
 

[Lldb-commits] [PATCH] D83840: [lldb][test] Prevent infinite loop while looking for use_lldb_suite_root.py.

2020-07-15 Thread Pavel Labath via Phabricator via lldb-commits
labath accepted this revision.
labath added a comment.
This revision is now accepted and ready to land.

Heh I fixed the same thing back in 67f6d842fab6 for 
`scripts/use_lldb_suite.py`, but of course I forgot to update this copy... The 
idea is good, just please make sure both files end up using the same solution.

(Also, if you have any ideas on how to avoid having multiple copies of this 
file around, then don't keep them to yourself. :) )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83840



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


[Lldb-commits] [PATCH] D83815: [lldb/Test] Use a process group for subprocesses

2020-07-15 Thread Pavel Labath via Phabricator via lldb-commits
labath added a comment.

hmm... I have a lot thoughts here..

- `setsid` is overkill. If you want to create process group, create a process 
group (`setpgid`), not a session.
- this solution does not seem very windows-friendly. In fact, I'd be surprised 
if it works there at all.
- going for `os.kill` will also not work with remote test suite runs. In fact, 
the way it is implemented now means we could start killing random processes on 
the host.
- are these really zombies (dead but not waited-for processes) or just live 
processes stuck in infinite loops and similar? Because if they are zombies 
(mmm... brainz), then I doubt sending signals to them will help -- they're 
already dead. The problem is that someone is not reaping them. I'm not sure 
what can be done about that, as normally init should take care of this...
- even if they are live processes, I am doubtful that this will make a 
difference. I don't think many of the processes we spawn create additional 
subprocesses. In fact, the only one I know of is `TestChangeProcessGroup.py`, 
which also creates a new process group... so this test would need special 
handling anyway.
- creating lots of process groups can actually cause us to leak _more_ 
processes in case the test run is interrupted with ^C or similar (SIGINT goes 
to the foreground process group)

Overall, I think we should try to understand the problem a bit better before we 
start shotgun debugging this. Which tests are creating these zombies? What's 
special about them? Do they always do that or only occasionally? etc.

PS: When we were running a mac bot (it seems only macs are vulnerable to zombie 
infestations), we configured it to reboot itself each midnight. Not the most 
elegant solution, but if the problem really is about init refusing to reap 
zombies, then it may be the only thing that we can do...




Comment at: lldb/packages/Python/lldbsuite/test/lldbtest.py:894
+try:
+os.kill(os.getpgid(p.pid), signal.SIGTERM)
+except OSError:

Right this is pretty much equivalent to what we've had before. I guess you 
wanted to say `os.killpg(os.getpgid(pid), SIGTERM)`. 
`os.kill(-os.getpgid(pid))` might also work, but the first one seems more 
explicit.


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

https://reviews.llvm.org/D83815



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


[Lldb-commits] [lldb] 001c78d - [lldb][formatters] Add support for printing NSConstantDate and fix distantPast value

2020-07-15 Thread Raphael Isemann via lldb-commits

Author: Raphael Isemann
Date: 2020-07-15T10:28:10+02:00
New Revision: 001c78de35cc0637eb58b3d855bc9897acccdc64

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

LOG: [lldb][formatters] Add support for printing NSConstantDate and fix 
distantPast value

Summary:

Certain `NSDate` constructors return a special `NSConstantDate` class which
currently ends up being unformatted as it's not in the list of supported classes
for the NSDate formatter. This patch adds that class to the supported class list
so LLDB produces a summary for it.

One of these special constructors is `[NSDate distantPast]` which returns the
date for `0001-01-01 00:00:00 UTC`. LLDB has a special case for formatting this
date but for some reason we did hardcode the wrong summary string in that
special case. Maybe the summary string was correct back when the code was
written but it isn't correct anymore (`distantPast` isn't actually defined to be
a special date but just some 'a guaranteed temporal boundary.' so maybe someone
changed the value in the last 10 years).

If someone else is wondering why we even have this special case for
`distantPast` but not for the future. The reason seems to be that our date
formatting for really old dates is off by 24 hours. So for example, adding one
second to `distantPast` will cause LLDB to print `-12-30 00:00:01 UTC`
(which is 24 hours behind the expected result). So to make our code appear to be
correct it seems we just hardcoded the most common NSDate result from that time
span. I'll replace that logic with a generic solution in a probably more
invasive follow up patch.

I also took the freedom to replace the magic value `-63114076800` with some
constant + documentation. I heard there are some people that don't know from the
top of their head that there are 63114076800 seconds between 1. Jan 0001 and 1.
January 2001 in whatever calendar system NSDate is using.

Reviewers: mib, davide

Reviewed By: mib

Subscribers: JDevlieghere

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

Added: 


Modified: 
lldb/source/Plugins/Language/ObjC/Cocoa.cpp

lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m

Removed: 




diff  --git a/lldb/source/Plugins/Language/ObjC/Cocoa.cpp 
b/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
index da910f48e59a..648fc4adf24f 100644
--- a/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
+++ b/lldb/source/Plugins/Language/ObjC/Cocoa.cpp
@@ -818,13 +818,14 @@ bool lldb_private::formatters::NSDateSummaryProvider(
   static const ConstString g___NSDate("__NSDate");
   static const ConstString g___NSTaggedDate("__NSTaggedDate");
   static const ConstString g_NSCalendarDate("NSCalendarDate");
+  static const ConstString g_NSConstantDate("NSConstantDate");
 
   if (class_name.IsEmpty())
 return false;
 
   uint64_t info_bits = 0, value_bits = 0;
   if ((class_name == g_NSDate) || (class_name == g___NSDate) ||
-  (class_name == g___NSTaggedDate)) {
+  (class_name == g___NSTaggedDate) || (class_name == g_NSConstantDate)) {
 if (descriptor->GetTaggedPointerInfo(_bits, _bits)) {
   date_value_bits = ((value_bits << 8) | (info_bits << 4));
   memcpy(_value, _value_bits, sizeof(date_value_bits));
@@ -850,8 +851,14 @@ bool lldb_private::formatters::NSDateSummaryProvider(
   } else
 return false;
 
-  if (date_value == -63114076800) {
-stream.Printf("0001-12-30 00:00:00 +");
+  // FIXME: It seems old dates are not formatted according to NSDate's calendar
+  // so we hardcode distantPast's value so that it looks like LLDB is doing
+  // the right thing.
+
+  // The relative time in seconds from Cocoa Epoch to [NSDate distantPast].
+  const double RelSecondsFromCocoaEpochToNSDateDistantPast = -63114076800;
+  if (date_value == RelSecondsFromCocoaEpochToNSDateDistantPast) {
+stream.Printf("0001-01-01 00:00:00 UTC");
 return true;
   }
 

diff  --git 
a/lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
 
b/lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
index 61394c05f5d5..cdce4798e986 100644
--- 
a/lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
+++ 
b/lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
@@ -67,3 +67,6 @@ def nsdate_data_formatter_commands(self):
 substrs=[
 '(CFMutableBitVectorRef) mut_bv = ',
 '1110 0110 1011  1101 1010 1000  0011 0101 1101 0001 
00'])
+
+self.expect_expr("distant_past", result_summary="0001-01-01 00:00:00 
UTC")
+

[Lldb-commits] [PATCH] D83217: [lldb][formatters] Add support for printing NSConstantDate and fix distantPast value

2020-07-15 Thread Raphael Isemann via Phabricator via lldb-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG001c78de35cc: [lldb][formatters] Add support for printing 
NSConstantDate and fix distantPast… (authored by teemperor).
Herald added a project: LLDB.
Herald added a subscriber: lldb-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83217

Files:
  lldb/source/Plugins/Language/ObjC/Cocoa.cpp
  
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
  lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m


Index: lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m
+++ lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m
@@ -663,6 +663,9 @@
   NSDate *date_1970_plus_05 = [NSDate dateWithTimeIntervalSince1970:0.5];
   NSDate *date_1970_plus_04 = [NSDate dateWithTimeIntervalSince1970:0.4];
 
+  NSDate *distant_past = [NSDate distantPast];
+  NSDate *distant_future = [NSDate distantFuture];
+
   CFAbsoluteTime date1_abs = CFDateGetAbsoluteTime(date1);
   CFAbsoluteTime date2_abs = CFDateGetAbsoluteTime(date2);
   CFAbsoluteTime date3_abs = CFDateGetAbsoluteTime(date3);
Index: 
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
===
--- 
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
+++ 
lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
@@ -67,3 +67,6 @@
 substrs=[
 '(CFMutableBitVectorRef) mut_bv = ',
 '1110 0110 1011  1101 1010 1000  0011 0101 1101 0001 
00'])
+
+self.expect_expr("distant_past", result_summary="0001-01-01 00:00:00 
UTC")
+self.expect_expr("distant_future", result_summary="4001-01-01 00:00:00 
UTC")
Index: lldb/source/Plugins/Language/ObjC/Cocoa.cpp
===
--- lldb/source/Plugins/Language/ObjC/Cocoa.cpp
+++ lldb/source/Plugins/Language/ObjC/Cocoa.cpp
@@ -818,13 +818,14 @@
   static const ConstString g___NSDate("__NSDate");
   static const ConstString g___NSTaggedDate("__NSTaggedDate");
   static const ConstString g_NSCalendarDate("NSCalendarDate");
+  static const ConstString g_NSConstantDate("NSConstantDate");
 
   if (class_name.IsEmpty())
 return false;
 
   uint64_t info_bits = 0, value_bits = 0;
   if ((class_name == g_NSDate) || (class_name == g___NSDate) ||
-  (class_name == g___NSTaggedDate)) {
+  (class_name == g___NSTaggedDate) || (class_name == g_NSConstantDate)) {
 if (descriptor->GetTaggedPointerInfo(_bits, _bits)) {
   date_value_bits = ((value_bits << 8) | (info_bits << 4));
   memcpy(_value, _value_bits, sizeof(date_value_bits));
@@ -850,8 +851,14 @@
   } else
 return false;
 
-  if (date_value == -63114076800) {
-stream.Printf("0001-12-30 00:00:00 +");
+  // FIXME: It seems old dates are not formatted according to NSDate's calendar
+  // so we hardcode distantPast's value so that it looks like LLDB is doing
+  // the right thing.
+
+  // The relative time in seconds from Cocoa Epoch to [NSDate distantPast].
+  const double RelSecondsFromCocoaEpochToNSDateDistantPast = -63114076800;
+  if (date_value == RelSecondsFromCocoaEpochToNSDateDistantPast) {
+stream.Printf("0001-01-01 00:00:00 UTC");
 return true;
   }
 


Index: lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m
+++ lldb/test/API/functionalities/data-formatter/data-formatter-objc/main.m
@@ -663,6 +663,9 @@
   NSDate *date_1970_plus_05 = [NSDate dateWithTimeIntervalSince1970:0.5];
   NSDate *date_1970_plus_04 = [NSDate dateWithTimeIntervalSince1970:0.4];
 
+  NSDate *distant_past = [NSDate distantPast];
+  NSDate *distant_future = [NSDate distantFuture];
+
   CFAbsoluteTime date1_abs = CFDateGetAbsoluteTime(date1);
   CFAbsoluteTime date2_abs = CFDateGetAbsoluteTime(date2);
   CFAbsoluteTime date3_abs = CFDateGetAbsoluteTime(date3);
Index: lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
===
--- lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
+++ lldb/test/API/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjCNSDate.py
@@ -67,3 +67,6 @@
 substrs=[
 '(CFMutableBitVectorRef) mut_bv = ',
 '1110 0110 1011  1101 1010 1000  0011 0101 1101 0001 00'])

[Lldb-commits] [PATCH] D83858: [lldb] Desugar template specializations

2020-07-15 Thread Jaroslav Sevcik via Phabricator via lldb-commits
jarin created this revision.
jarin added a reviewer: teemperor.
jarin added a project: LLDB.
Herald added a subscriber: lldb-commits.

Template specializations are not handled in many of the
TypeSystemClang methods. For example, GetNumChildren does not handle
the TemplateSpecialization type class, so template specializations
always look like empty objects.

This patch just desugars template specialization in the existing
RemoveWrappingTypes desugaring helper.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D83858

Files:
  lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
  lldb/test/API/lang/cpp/template-specialization/Makefile
  lldb/test/API/lang/cpp/template-specialization/TestTemplateSpecialization.py
  lldb/test/API/lang/cpp/template-specialization/main.cpp


Index: lldb/test/API/lang/cpp/template-specialization/main.cpp
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization/main.cpp
@@ -0,0 +1,9 @@
+template  struct TestObj {
+  int f;
+  T g;
+};
+
+int main() {
+  TestObj t{42, 21};
+  return t.f + t.g; // break here
+}
Index: 
lldb/test/API/lang/cpp/template-specialization/TestTemplateSpecialization.py
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization/TestTemplateSpecialization.py
@@ -0,0 +1,28 @@
+"""
+Test evaluating an expression with a cast to a pointer to a template
+specialization.
+"""
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TemplateSpecializationTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_template_specialization_cast_children(self):
+self.build()
+lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.cpp", False))
+
+v = self.frame().EvaluateExpression("t")
+self.assertEquals(2, v.GetNumChildren())
+self.assertEquals("42", v.GetChildAtIndex(0).GetValue())
+self.assertEquals("21", v.GetChildAtIndex(1).GetValue())
+
+v = self.frame().EvaluateExpression("*((TestObj*))")
+self.assertEquals(2, v.GetNumChildren())
+self.assertEquals("42", v.GetChildAtIndex(0).GetValue())
+self.assertEquals("21", v.GetChildAtIndex(1).GetValue())
Index: lldb/test/API/lang/cpp/template-specialization/Makefile
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization/Makefile
@@ -0,0 +1,3 @@
+CXX_SOURCES := main.cpp
+
+include Makefile.rules
Index: lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
===
--- lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
+++ lldb/source/Plugins/TypeSystem/Clang/TypeSystemClang.cpp
@@ -2504,6 +2504,7 @@
 case clang::Type::Typedef:
 case clang::Type::TypeOf:
 case clang::Type::TypeOfExpr:
+case clang::Type::TemplateSpecialization:
   type = type->getLocallyUnqualifiedSingleStepDesugaredType();
   break;
 default:


Index: lldb/test/API/lang/cpp/template-specialization/main.cpp
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization/main.cpp
@@ -0,0 +1,9 @@
+template  struct TestObj {
+  int f;
+  T g;
+};
+
+int main() {
+  TestObj t{42, 21};
+  return t.f + t.g; // break here
+}
Index: lldb/test/API/lang/cpp/template-specialization/TestTemplateSpecialization.py
===
--- /dev/null
+++ lldb/test/API/lang/cpp/template-specialization/TestTemplateSpecialization.py
@@ -0,0 +1,28 @@
+"""
+Test evaluating an expression with a cast to a pointer to a template
+specialization.
+"""
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TemplateSpecializationTestCase(TestBase):
+
+mydir = TestBase.compute_mydir(__file__)
+
+def test_template_specialization_cast_children(self):
+self.build()
+lldbutil.run_to_source_breakpoint(self, '// break here',
+lldb.SBFileSpec("main.cpp", False))
+
+v = self.frame().EvaluateExpression("t")
+self.assertEquals(2, v.GetNumChildren())
+self.assertEquals("42", v.GetChildAtIndex(0).GetValue())
+self.assertEquals("21", v.GetChildAtIndex(1).GetValue())
+
+v = self.frame().EvaluateExpression("*((TestObj*))")
+self.assertEquals(2, v.GetNumChildren())
+self.assertEquals("42", v.GetChildAtIndex(0).GetValue())
+self.assertEquals("21", v.GetChildAtIndex(1).GetValue())
Index: lldb/test/API/lang/cpp/template-specialization/Makefile
===
--- /dev/null
+++