Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
labath added a comment.
I think we should make one more iteration on this, as there is still some room
for improvement.
In http://reviews.llvm.org/D19998#438756, @zturner wrote:
> Should this be disabled by default unless explicitly requested? Seems like
> "run the entire test suite N times" should be opt in, not opt out.
I think it makes sense to run multiple variants of some tests, as "gmodules" is
a regular debugger feature and we want to make sure we support that feature.
What I think is a problem here is the "whole test suite" part, as I think a lot
of tests (think, all process control and thread tests) don't (or shouldn't)
depend on debug info (see discussion early on in this thread). My feeling is
that we should start restricting the duplication more aggressively, and then it
won't matter that **some** tests get run multiple times.
That said, if you as the windows maintainer say that you don't want to support
gmodules debugging on windows at the moment, then I think it's fine to skip
those tests on this platform.
Comment at: packages/Python/lldbsuite/support/gmodules.py:19
@@ -19,2 +19,2 @@
compiler = os.path.basename(compiler_path)
if "clang" not in compiler:
This diff looks broken. This appears to be a new file (I certainly don't have
it in my tree), and it is being shown as a diff. Could you reupload a correct
diff against the current top of tree?
Comment at: packages/Python/lldbsuite/support/gmodules.py:22
@@ -21,3 +21,3 @@
return False
-clang_help = os.popen("%s --help" % compiler_path).read()
-return GMODULES_HELP_REGEX.search(clang_help, re.DOTALL) is not None
+elif os.name == "nt":
+# gmodules support is broken on Windows
This check should be folded into `test_categories.is_supported_on_platform`.
(Also, it is incorrect as it should presumably be checking against the target
platform and not the host.)
Comment at: packages/Python/lldbsuite/test/decorators.py:527
@@ -525,3 +526,3 @@
-def skipUnlessClangModules():
+def skipUnlessClangModules(func):
"""Decorate the item to skip test unless Clang -gmodules flag is
supported."""
This whole decorator can be removed. It's invocations can be replaced with
`add_test_categories(["gmodules"])` (cf. `lldbtest.py:1453`, it will avoid
duplicating the test if it is already annotated with categories).
Comment at:
packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py:13
@@ -12,1 +12,3 @@
+@skipUnlessClangModules
def test_specialized_typedef_from_pch(self):
+self.buildGModules()
replace these two decorators with `add_test_categories(["gmodules"])`
Comment at: packages/Python/lldbsuite/test/lldbinline.py:148
@@ +147,3 @@
+self.BuildMakefile()
+self.buildDwarf()
+self.do_test()
`buildGModules()` ?
http://reviews.llvm.org/D19998
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r270684 - Add unit tests for ModuleCache
Author: labath
Date: Wed May 25 05:48:16 2016
New Revision: 270684
URL: http://llvm.org/viewvc/llvm-project?rev=270684&view=rev
Log:
Add unit tests for ModuleCache
Reviewers: ovyalov, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20570
Added:
lldb/trunk/unittests/Utility/Inputs/
lldb/trunk/unittests/Utility/Inputs/TestModule.c
lldb/trunk/unittests/Utility/Inputs/TestModule.so
lldb/trunk/unittests/Utility/ModuleCacheTest.cpp
Modified:
lldb/trunk/unittests/Utility/CMakeLists.txt
Modified: lldb/trunk/unittests/Utility/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Utility/CMakeLists.txt?rev=270684&r1=270683&r2=270684&view=diff
==
--- lldb/trunk/unittests/Utility/CMakeLists.txt (original)
+++ lldb/trunk/unittests/Utility/CMakeLists.txt Wed May 25 05:48:16 2016
@@ -1,5 +1,8 @@
add_lldb_unittest(UtilityTests
+ ModuleCacheTest.cpp
StringExtractorTest.cpp
TaskPoolTest.cpp
UriParserTest.cpp
)
+
+add_unittest_inputs(UtilityTests TestModule.so)
Added: lldb/trunk/unittests/Utility/Inputs/TestModule.c
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Utility/Inputs/TestModule.c?rev=270684&view=auto
==
--- lldb/trunk/unittests/Utility/Inputs/TestModule.c (added)
+++ lldb/trunk/unittests/Utility/Inputs/TestModule.c Wed May 25 05:48:16 2016
@@ -0,0 +1,10 @@
+// Compile with $CC -nostdlib -shared TestModule.c -o TestModule.so
+// The actual contents of the test module is not important here. I am using
this because it
+// produces an extremely tiny (but still perfectly valid) module.
+
+void
+boom(void)
+{
+char *BOOM;
+*BOOM = 47;
+}
Added: lldb/trunk/unittests/Utility/Inputs/TestModule.so
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Utility/Inputs/TestModule.so?rev=270684&view=auto
==
Binary files lldb/trunk/unittests/Utility/Inputs/TestModule.so (added) and
lldb/trunk/unittests/Utility/Inputs/TestModule.so Wed May 25 05:48:16 2016
differ
Added: lldb/trunk/unittests/Utility/ModuleCacheTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/unittests/Utility/ModuleCacheTest.cpp?rev=270684&view=auto
==
--- lldb/trunk/unittests/Utility/ModuleCacheTest.cpp (added)
+++ lldb/trunk/unittests/Utility/ModuleCacheTest.cpp Wed May 25 05:48:16 2016
@@ -0,0 +1,179 @@
+#include "gtest/gtest.h"
+
+#include "llvm/ADT/SmallString.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Path.h"
+
+#include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
+#include "Utility/ModuleCache.h"
+#include "lldb/Core/Module.h"
+#include "lldb/Core/ModuleSpec.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Symbol/SymbolContext.h"
+
+extern const char *TestMainArgv0;
+
+using namespace lldb_private;
+using namespace lldb;
+
+namespace
+{
+
+class ModuleCacheTest : public testing::Test
+{
+public:
+static void
+SetUpTestCase();
+
+static void
+TearDownTestCase();
+
+protected:
+static FileSpec s_cache_dir;
+static llvm::SmallString<128> s_test_executable;
+
+void
+TryGetAndPut(const FileSpec &cache_dir, const char *hostname, bool
expect_download);
+};
+}
+
+FileSpec ModuleCacheTest::s_cache_dir;
+llvm::SmallString<128> ModuleCacheTest::s_test_executable;
+
+static const char dummy_hostname[] = "dummy_hostname";
+static const char dummy_remote_dir[] = "bin";
+static const char module_name[] = "TestModule.so";
+static const char module_uuid[] =
"F4E7E991-9B61-6AD4-0073-561AC3D9FA10-C043A476";
+static const uint32_t uuid_bytes = 20;
+static const size_t module_size = 5602;
+
+static FileSpec
+GetDummyRemotePath()
+{
+FileSpec fs("/", false, FileSpec::ePathSyntaxPosix);
+fs.AppendPathComponent(dummy_remote_dir);
+fs.AppendPathComponent(module_name);
+return fs;
+}
+
+static FileSpec
+GetUuidView(FileSpec spec)
+{
+spec.AppendPathComponent(".cache");
+spec.AppendPathComponent(module_uuid);
+spec.AppendPathComponent(module_name);
+return spec;
+}
+
+static FileSpec
+GetSysrootView(FileSpec spec, const char *hostname)
+{
+spec.AppendPathComponent(hostname);
+spec.AppendPathComponent(dummy_remote_dir);
+spec.AppendPathComponent(module_name);
+return spec;
+}
+
+void
+ModuleCacheTest::SetUpTestCase()
+{
+HostInfo::Initialize();
+ObjectFileELF::Initialize();
+
+FileSpec tmpdir_spec;
+HostInfo::GetLLDBPath(lldb::ePathTypeLLDBTempSystemDir, s_cache_dir);
+
+llvm::StringRef exe_folder = llvm::sys::path::parent_path(TestMainArgv0);
+s_test_executable = exe_folder;
+llvm::sys::path::append(s_test_executable, "Inputs", module_name);
+}
+
+void
+ModuleCacheTest::TearDownTestCase()
+{
+ObjectFileELF:
Re: [Lldb-commits] [PATCH] D20570: Add unit tests for ModuleCache
This revision was automatically updated to reflect the committed changes.
Closed by commit rL270684: Add unit tests for ModuleCache (authored by labath).
Changed prior to commit:
http://reviews.llvm.org/D20570?vs=58244&id=58400#toc
Repository:
rL LLVM
http://reviews.llvm.org/D20570
Files:
lldb/trunk/unittests/Utility/CMakeLists.txt
lldb/trunk/unittests/Utility/Inputs/TestModule.c
lldb/trunk/unittests/Utility/Inputs/TestModule.so
lldb/trunk/unittests/Utility/ModuleCacheTest.cpp
Index: lldb/trunk/unittests/Utility/Inputs/TestModule.c
===
--- lldb/trunk/unittests/Utility/Inputs/TestModule.c
+++ lldb/trunk/unittests/Utility/Inputs/TestModule.c
@@ -0,0 +1,10 @@
+// Compile with $CC -nostdlib -shared TestModule.c -o TestModule.so
+// The actual contents of the test module is not important here. I am using this because it
+// produces an extremely tiny (but still perfectly valid) module.
+
+void
+boom(void)
+{
+char *BOOM;
+*BOOM = 47;
+}
Index: lldb/trunk/unittests/Utility/CMakeLists.txt
===
--- lldb/trunk/unittests/Utility/CMakeLists.txt
+++ lldb/trunk/unittests/Utility/CMakeLists.txt
@@ -1,5 +1,8 @@
add_lldb_unittest(UtilityTests
+ ModuleCacheTest.cpp
StringExtractorTest.cpp
TaskPoolTest.cpp
UriParserTest.cpp
)
+
+add_unittest_inputs(UtilityTests TestModule.so)
Index: lldb/trunk/unittests/Utility/ModuleCacheTest.cpp
===
--- lldb/trunk/unittests/Utility/ModuleCacheTest.cpp
+++ lldb/trunk/unittests/Utility/ModuleCacheTest.cpp
@@ -0,0 +1,179 @@
+#include "gtest/gtest.h"
+
+#include "llvm/ADT/SmallString.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Path.h"
+
+#include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
+#include "Utility/ModuleCache.h"
+#include "lldb/Core/Module.h"
+#include "lldb/Core/ModuleSpec.h"
+#include "lldb/Host/HostInfo.h"
+#include "lldb/Symbol/SymbolContext.h"
+
+extern const char *TestMainArgv0;
+
+using namespace lldb_private;
+using namespace lldb;
+
+namespace
+{
+
+class ModuleCacheTest : public testing::Test
+{
+public:
+static void
+SetUpTestCase();
+
+static void
+TearDownTestCase();
+
+protected:
+static FileSpec s_cache_dir;
+static llvm::SmallString<128> s_test_executable;
+
+void
+TryGetAndPut(const FileSpec &cache_dir, const char *hostname, bool expect_download);
+};
+}
+
+FileSpec ModuleCacheTest::s_cache_dir;
+llvm::SmallString<128> ModuleCacheTest::s_test_executable;
+
+static const char dummy_hostname[] = "dummy_hostname";
+static const char dummy_remote_dir[] = "bin";
+static const char module_name[] = "TestModule.so";
+static const char module_uuid[] = "F4E7E991-9B61-6AD4-0073-561AC3D9FA10-C043A476";
+static const uint32_t uuid_bytes = 20;
+static const size_t module_size = 5602;
+
+static FileSpec
+GetDummyRemotePath()
+{
+FileSpec fs("/", false, FileSpec::ePathSyntaxPosix);
+fs.AppendPathComponent(dummy_remote_dir);
+fs.AppendPathComponent(module_name);
+return fs;
+}
+
+static FileSpec
+GetUuidView(FileSpec spec)
+{
+spec.AppendPathComponent(".cache");
+spec.AppendPathComponent(module_uuid);
+spec.AppendPathComponent(module_name);
+return spec;
+}
+
+static FileSpec
+GetSysrootView(FileSpec spec, const char *hostname)
+{
+spec.AppendPathComponent(hostname);
+spec.AppendPathComponent(dummy_remote_dir);
+spec.AppendPathComponent(module_name);
+return spec;
+}
+
+void
+ModuleCacheTest::SetUpTestCase()
+{
+HostInfo::Initialize();
+ObjectFileELF::Initialize();
+
+FileSpec tmpdir_spec;
+HostInfo::GetLLDBPath(lldb::ePathTypeLLDBTempSystemDir, s_cache_dir);
+
+llvm::StringRef exe_folder = llvm::sys::path::parent_path(TestMainArgv0);
+s_test_executable = exe_folder;
+llvm::sys::path::append(s_test_executable, "Inputs", module_name);
+}
+
+void
+ModuleCacheTest::TearDownTestCase()
+{
+ObjectFileELF::Terminate();
+HostInfo::Terminate();
+}
+
+static void
+VerifyDiskState(const FileSpec &cache_dir, const char *hostname)
+{
+FileSpec uuid_view = GetUuidView(cache_dir);
+EXPECT_TRUE(uuid_view.Exists()) << "uuid_view is: " << uuid_view.GetCString();
+EXPECT_EQ(module_size, uuid_view.GetByteSize());
+
+FileSpec sysroot_view = GetSysrootView(cache_dir, hostname);
+EXPECT_TRUE(sysroot_view.Exists()) << "sysroot_view is: " << sysroot_view.GetCString();
+EXPECT_EQ(module_size, sysroot_view.GetByteSize());
+}
+
+void
+ModuleCacheTest::TryGetAndPut(const FileSpec &cache_dir, const char *hostname, bool expect_download)
+{
+ModuleCache mc;
+ModuleSpec module_spec;
+module_spec.GetFileSpec() = GetDummyRemotePath();
+module_spec.GetUUID().SetFromCString(module_uuid, uuid_bytes);
+module_spec.SetObjectSize(module_size);
+ModuleSP module_sp;
+bool did_create;
+bool download_called = fals
Re: [Lldb-commits] [PATCH] D20570: Add unit tests for ModuleCache
labath added inline comments.
Comment at: unittests/Utility/ModuleCacheTest.cpp:74
@@ +73,3 @@
+{
+HostInfo::Initialize();
+ObjectFileELF::Initialize();
ovyalov wrote:
> If it's one-off initialization can we use setUpTestCase for these purposes
> (for HostInfo::Initialize and ObjectFileELF::Initialize)?
Good point. I have moved this to the static method (including the variable
initialization below, as they are not modified). I have also added the
corresponding tearDown method.
Repository:
rL LLVM
http://reviews.llvm.org/D20570
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D20567: Avoid using stdio in TestVirtual
labath updated this revision to Diff 58418.
labath added a comment.
New version, which does not rely on pretty-printers.
http://reviews.llvm.org/D20567
Files:
packages/Python/lldbsuite/test/lang/cpp/virtual/TestVirtual.py
packages/Python/lldbsuite/test/lang/cpp/virtual/main.cpp
Index: packages/Python/lldbsuite/test/lang/cpp/virtual/main.cpp
===
--- packages/Python/lldbsuite/test/lang/cpp/virtual/main.cpp
+++ packages/Python/lldbsuite/test/lang/cpp/virtual/main.cpp
@@ -84,17 +84,20 @@
C *c_as_C = new C();
A *c_as_A = c_as_C;
-printf ("a_as_A->a() = '%s'\n", a_as_A->a());
-printf ("a_as_A->b() = '%s'\n", a_as_A->b());
-printf ("a_as_A->c() = '%s'\n", a_as_A->c());
-printf ("b_as_A->a() = '%s'\n", b_as_A->a());
-printf ("b_as_A->b() = '%s'\n", b_as_A->b());
-printf ("b_as_A->c() = '%s'\n", b_as_A->c());
-printf ("b_as_B->aa() = '%s'\n", b_as_B->aa());
-printf ("c_as_A->a() = '%s'\n", c_as_A->a());
-printf ("c_as_A->b() = '%s'\n", c_as_A->b());
-printf ("c_as_A->c() = '%s'\n", c_as_A->c());
-printf ("c_as_C->aa() = '%s'\n", c_as_C->aa());
+char golden[4096];
+char *p = golden;
+char *end = p + sizeof golden;
+p += snprintf(p, end-p, "a_as_A->a() = '%s'\n", a_as_A->a());
+p += snprintf(p, end-p, "a_as_A->b() = '%s'\n", a_as_A->b());
+p += snprintf(p, end-p, "a_as_A->c() = '%s'\n", a_as_A->c());
+p += snprintf(p, end-p, "b_as_A->a() = '%s'\n", b_as_A->a());
+p += snprintf(p, end-p, "b_as_A->b() = '%s'\n", b_as_A->b());
+p += snprintf(p, end-p, "b_as_A->c() = '%s'\n", b_as_A->c());
+p += snprintf(p, end-p, "b_as_B->aa() = '%s'\n", b_as_B->aa());
+p += snprintf(p, end-p, "c_as_A->a() = '%s'\n", c_as_A->a());
+p += snprintf(p, end-p, "c_as_A->b() = '%s'\n", c_as_A->b());
+p += snprintf(p, end-p, "c_as_A->c() = '%s'\n", c_as_A->c());
+p += snprintf(p, end-p, "c_as_C->aa() = '%s'\n", c_as_C->aa());
puts("");// Set first breakpoint here.
// then evaluate:
// expression a_as_A->a()
Index: packages/Python/lldbsuite/test/lang/cpp/virtual/TestVirtual.py
===
--- packages/Python/lldbsuite/test/lang/cpp/virtual/TestVirtual.py
+++ packages/Python/lldbsuite/test/lang/cpp/virtual/TestVirtual.py
@@ -22,9 +22,6 @@
# printf() stmts (see main.cpp).
pattern = re.compile("^([^=]*) = '([^=]*)'$")
-# Assert message.
-PRINTF_OUTPUT_GROKKED = "The printf output from compiled code is parsed
correctly"
-
def setUp(self):
# Call super's setUp().
TestBase.setUp(self)
@@ -58,11 +55,13 @@
thread = lldbutil.get_stopped_thread(process,
lldb.eStopReasonBreakpoint)
self.assertTrue(thread.IsValid(), "There should be a thread stopped
due to breakpoint condition")
-# First, capture the golden output from the program itself from the
-# series of printf statements.
-stdout = process.GetSTDOUT(1024)
-
-self.assertIsNotNone(stdout, "Encountered an error reading the
process's output")
+# First, capture the golden output from the program itself.
+golden = thread.GetFrameAtIndex(0).FindVariable("golden")
+self.assertTrue(golden.IsValid(), "Encountered an error reading the
process's golden variable")
+error = lldb.SBError()
+golden_str =
process.ReadCStringFromMemory(golden.AddressOf().GetValueAsUnsigned(), 4096,
error);
+self.assertTrue(error.Success())
+self.assertTrue("c_as_C" in golden_str)
# This golden list contains a list of "my_expr = 'value' pairs
extracted
# from the golden output.
@@ -72,7 +71,7 @@
#
# my_expr = 'value'
#
-for line in stdout.split(os.linesep):
+for line in golden_str.split(os.linesep):
match = self.pattern.search(line)
if match:
my_expr, val = match.group(1), match.group(2)
Index: packages/Python/lldbsuite/test/lang/cpp/virtual/main.cpp
===
--- packages/Python/lldbsuite/test/lang/cpp/virtual/main.cpp
+++ packages/Python/lldbsuite/test/lang/cpp/virtual/main.cpp
@@ -84,17 +84,20 @@
C *c_as_C = new C();
A *c_as_A = c_as_C;
-printf ("a_as_A->a() = '%s'\n", a_as_A->a());
-printf ("a_as_A->b() = '%s'\n", a_as_A->b());
-printf ("a_as_A->c() = '%s'\n", a_as_A->c());
-printf ("b_as_A->a() = '%s'\n", b_as_A->a());
-printf ("b_as_A->b() = '%s'\n", b_as_A->b());
-printf ("b_as_A->c() = '%s'\n", b_as_A->c());
-printf ("b_as_B->aa() = '%s'\n", b_as_B->aa());
-printf ("c_as_A->a() = '%s'\n", c_as_A->a());
-printf ("c_as_A->b() = '%s'\n", c_as_A->b());
-printf ("c_as_A->c() = '%s'\n", c_as_A->c());
-printf ("c_as_C->aa() = '%s'\n", c_as_C->aa());
+char golden[4096];
+char *p = golden;
+
[Lldb-commits] [PATCH] D20623: [cmake] Add ability to customize (and skip) debugserver codesign
labath created this revision.
labath added reviewers: sas, tberghammer.
labath added a subscriber: lldb-commits.
This adds the ability to customize the debugserver codesign process via cmake
cache variable. The
user can set the codesign indentity (with the default being the customary
lldb_codesign), and if
the identity is set to a empty string, the codesign step is skipped completely.
We needed the last feature to enable building lldb on buildservers which do not
have the right
certificates installed.
http://reviews.llvm.org/D20623
Files:
tools/debugserver/source/MacOSX/CMakeLists.txt
Index: tools/debugserver/source/MacOSX/CMakeLists.txt
===
--- tools/debugserver/source/MacOSX/CMakeLists.txt
+++ tools/debugserver/source/MacOSX/CMakeLists.txt
@@ -59,29 +59,31 @@
target_link_libraries(debugserver ${DEBUGSERVER_USED_LIBS})
-# Sign the debugserver binary
-set (CODESIGN_IDENTITY lldb_codesign)
-execute_process(
- COMMAND xcrun -f codesign_allocate
- OUTPUT_STRIP_TRAILING_WHITESPACE
- OUTPUT_VARIABLE CODESIGN_ALLOCATE
- )
-# Older cmake versions don't support "-E env".
-if (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} LESS 3.2)
- add_custom_command(TARGET debugserver
-POST_BUILD
-# Note: --entitlements option removed, as it causes errors when debugging.
-# was: COMMAND CODESIGN_ALLOCATE=${CODESIGN_ALLOCATE} codesign
--entitlements ${CMAKE_CURRENT_SOURCE_DIR}/../debugserver-entitlements.plist
--force --sign ${CODESIGN_IDENTITY} debugserver
-COMMAND CODESIGN_ALLOCATE=${CODESIGN_ALLOCATE} codesign --force --sign
${CODESIGN_IDENTITY} debugserver
-WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/bin
- )
-else()
- add_custom_command(TARGET debugserver
-POST_BUILD
-# Note: --entitlements option removed (see comment above).
-COMMAND ${CMAKE_COMMAND} -E env CODESIGN_ALLOCATE=${CODESIGN_ALLOCATE}
codesign --force --sign ${CODESIGN_IDENTITY} debugserver
-WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/bin
- )
+set(LLDB_CODESIGN_IDENTITY "lldb_codesign"
+ CACHE STRING "Identity used for code signing. Set to empty string to skip
the signing step.")
+if (NOT ("${LLDB_CODESIGN_IDENTITY}" STREQUAL ""))
+ execute_process(
+COMMAND xcrun -f codesign_allocate
+OUTPUT_STRIP_TRAILING_WHITESPACE
+OUTPUT_VARIABLE CODESIGN_ALLOCATE
+)
+ # Older cmake versions don't support "-E env".
+ if (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} LESS 3.2)
+add_custom_command(TARGET debugserver
+ POST_BUILD
+ # Note: --entitlements option removed, as it causes errors when
debugging.
+ # was: COMMAND CODESIGN_ALLOCATE=${CODESIGN_ALLOCATE} codesign
--entitlements ${CMAKE_CURRENT_SOURCE_DIR}/../debugserver-entitlements.plist
--force --sign ${LLDB_CODESIGN_IDENTITY} debugserver
+ COMMAND CODESIGN_ALLOCATE=${CODESIGN_ALLOCATE} codesign --force --sign
${LLDB_CODESIGN_IDENTITY} debugserver
+ WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/bin
+)
+ else()
+add_custom_command(TARGET debugserver
+ POST_BUILD
+ # Note: --entitlements option removed (see comment above).
+ COMMAND ${CMAKE_COMMAND} -E env CODESIGN_ALLOCATE=${CODESIGN_ALLOCATE}
codesign --force --sign ${LLDB_CODESIGN_IDENTITY} debugserver
+ WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/bin
+)
+ endif()
endif()
install(TARGETS debugserver
Index: tools/debugserver/source/MacOSX/CMakeLists.txt
===
--- tools/debugserver/source/MacOSX/CMakeLists.txt
+++ tools/debugserver/source/MacOSX/CMakeLists.txt
@@ -59,29 +59,31 @@
target_link_libraries(debugserver ${DEBUGSERVER_USED_LIBS})
-# Sign the debugserver binary
-set (CODESIGN_IDENTITY lldb_codesign)
-execute_process(
- COMMAND xcrun -f codesign_allocate
- OUTPUT_STRIP_TRAILING_WHITESPACE
- OUTPUT_VARIABLE CODESIGN_ALLOCATE
- )
-# Older cmake versions don't support "-E env".
-if (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} LESS 3.2)
- add_custom_command(TARGET debugserver
-POST_BUILD
-# Note: --entitlements option removed, as it causes errors when debugging.
-# was: COMMAND CODESIGN_ALLOCATE=${CODESIGN_ALLOCATE} codesign --entitlements ${CMAKE_CURRENT_SOURCE_DIR}/../debugserver-entitlements.plist --force --sign ${CODESIGN_IDENTITY} debugserver
-COMMAND CODESIGN_ALLOCATE=${CODESIGN_ALLOCATE} codesign --force --sign ${CODESIGN_IDENTITY} debugserver
-WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/bin
- )
-else()
- add_custom_command(TARGET debugserver
-POST_BUILD
-# Note: --entitlements option removed (see comment above).
-COMMAND ${CMAKE_COMMAND} -E env CODESIGN_ALLOCATE=${CODESIGN_ALLOCATE} codesign --force --sign ${CODESIGN_IDENTITY} debugserver
-WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/bin
- )
+set(LLDB_CODESIGN_IDENTITY "lldb_codesign"
+ CACHE STRING "Identity used for code signing. Set to empty string to skip the signing step.")
+if (NOT ("${LLDB_CODESIGN_IDENTITY}" STR
Re: [Lldb-commits] [PATCH] D20368: Remove Platform usages from NativeProcessLinux
labath abandoned this revision.
Comment at: source/Plugins/Process/Linux/NativeRegisterContextLinux.cpp:53
@@ -22,2 +52,3 @@
+
NativeRegisterContextLinux::NativeRegisterContextLinux(NativeThreadProtocol
&native_thread,
uint32_t
concrete_frame_idx,
nitesh.jain wrote:
> labath wrote:
> > jaydeep wrote:
> > > We have tried executing ptrace(NT_PRSTATUS) on MIPS with 3.18. It is able
> > > to detect the arch correctly (64->64 and 64->32). However with 3.10 it
> > > fails with EIO. Is there any fallback method when ptrace(NT_PRSTATUS)
> > > fails?
> > Thanks for checking that out.
> >
> > This makes things a bit tricky. We *could* fallback to the "parse the
> > executable ELF" method of getting the architecture, but that would make
> > this patch a bit pointless, as that is what I am trying to remove in the
> > first place. I suppose we could make the fallback mips-only, but that will
> > not be too ideal either.
> >
> > I don't know about any other fallbacks. It would be interesting to know how
> > strace does that. I've tried looking at strace source code, but I could not
> > make much out of it. Do you know if a single strace binary is capable of
> > correctly tracing both 32- and 64-bit processes? If so, could you try
> > running the following experiment for me:
> > - create a simple c file that does a sleep(1) and exits
> > - compile 32- and 64-bit versions of the executable
> > - execute the following commands:
> > ```
> > strace -o /tmp/32.txt -- strace -o /dev/null -- a.out.32
> > strace -o /tmp/64.txt -- strace -o /dev/null -- a.out.64
> > ```
> >
> > Could you send me the outputs (32.txt, 64.txt). Maybe I'll be able to
> > figure something out from that.
> >
> > If that does not work, I may have to abandon this.
> >
> > thanks.
> // 32 bit ELF
> gcc-4.9 -g -O0 -mabi=64 -mips64r2 simple.c -o a.out.64
>
> // 64 bit ELF
> gcc-4.9 -g -O0 -mabi=32 -mips32r2 simple.c -o a.out.32
>
> // Strace for 32 and 64 bit
> strace -o /tmp/64.txt -- strace -o /dev/null -- ./a.out.64
> strace -o /tmp/32.txt -- strace -o /dev/null -- ./a.out.32
>
>
> // File command output for both file
>
> a.out.64: ELF 64-bit LSB executable, MIPS, MIPS64 rel2 version 1 (SYSV),
> dynamically linked, interpreter /lib64/ld.so.1,
> BuildID[sha1]=6e0f92a8abee292b4b6462d79ec0420a3d8aaad0, for GNU/Linux 2.6.32,
> not stripped
>
> a.out.32: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, dynamically
> linked, interpreter /lib/ld.so.1, for GNU/Linux 2.6.32,
> BuildID[sha1]=c4e09148526975f777e3e70bec85868616d3ce94, not stripped
>
>
> {F1978053}
>
> {F1978054}
Thank you for helping me investigate this. I've been thinking about it a lot,
and I don't see any other way to get around this limitation at the moment. I
think we'll have to abandon this approach for now.
http://reviews.llvm.org/D20368
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala added a comment.
@aprantl, the lldbsuite/support/gmodules.py file didn't make it into your patch
set here. (It was the top file in the -v6 diff).
I'm going to adjust per comments above. @labath, see question on
add_test_categories.
I may end up filing this as a separate review since I'm WFH and we can probably
iterate faster without getting @aprantl to have to keep putting up patch sets
for me. (I didn't see a way for phabricator to allow multiple people to put up
a diff set on the same review - if that existed I'd use that).
@zturner, with the changes @labath suggested, that one decorator that was used
by that one test will go away, and then the is_supported-style check for
gmodules (as currently written) will not permit gmodules on Windows. It is set
to support macosx, ios, linux and freebsd.
Comment at: packages/Python/lldbsuite/support/gmodules.py:19
@@ -19,2 +19,2 @@
compiler = os.path.basename(compiler_path)
if "clang" not in compiler:
labath wrote:
> This diff looks broken. This appears to be a new file (I certainly don't have
> it in my tree), and it is being shown as a diff. Could you reupload a correct
> diff against the current top of tree?
Yes it is missing from the patch set. It is in the -v6.diff file I attached
earlier (top entry in the diff). We'll get this updated.
Comment at: packages/Python/lldbsuite/support/gmodules.py:22
@@ -21,3 +21,3 @@
return False
-clang_help = os.popen("%s --help" % compiler_path).read()
-return GMODULES_HELP_REGEX.search(clang_help, re.DOTALL) is not None
+elif os.name == "nt":
+# gmodules support is broken on Windows
labath wrote:
> This check should be folded into `test_categories.is_supported_on_platform`.
> (Also, it is incorrect as it should presumably be checking against the target
> platform and not the host.)
It actually is in is_supported_on_platform (by virtue of windows not being
included).
I had misunderstood your earlier comment on how add_categories worked. I did
not know that I could make a debuginfo-specific test work by adding the
category. That makes sense now, but I had kept the other decorator around only
because I didn't see this as an option.
I get it now. Good idea.
Comment at: packages/Python/lldbsuite/test/decorators.py:527
@@ -525,3 +526,3 @@
-def skipUnlessClangModules():
+def skipUnlessClangModules(func):
"""Decorate the item to skip test unless Clang -gmodules flag is
supported."""
labath wrote:
> This whole decorator can be removed. It's invocations can be replaced with
> `add_test_categories(["gmodules"])` (cf. `lldbtest.py:1453`, it will avoid
> duplicating the test if it is already annotated with categories).
Yes, I see now. I did not understand add_test_categories(["gmodules"]) was a
valid way to mark a test as gmodules-only.
It does look a little weird that we need to do:
@no_debug_info_test
@add_test_categories(["gmodules"])
I wonder if we want a combined decorator that is effectively:
@valid_debug_info([...])
that specifies that this test is only valid for those debug info entries
specified. Then the entry becomes a single decorator:
@valid_debug_info(["gmodules"])
What do you think?
Comment at:
packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py:13
@@ -12,1 +12,3 @@
+@skipUnlessClangModules
def test_specialized_typedef_from_pch(self):
+self.buildGModules()
labath wrote:
> replace these two decorators with `add_test_categories(["gmodules"])`
Yup.
Well we would need @no_debug_info_test still, wouldn't we? Otherwise we'll fan
out to all the debug info variants? (Or is add_test_categories() replace all
test categories? I assumed it was additive since it starts with "add_", in
which case I'd expect we'd still have all the normal debug info entries show
up).
Comment at: packages/Python/lldbsuite/test/lldbinline.py:148
@@ +147,3 @@
+self.BuildMakefile()
+self.buildDwarf()
+self.do_test()
labath wrote:
> `buildGModules()` ?
Yeah that's wrong. Good catch.
That also means the testing I did on OS X and Linux failed to do real gmodule
debugging for inline tests. I'll need to rerun.
http://reviews.llvm.org/D19998
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
aprantl abandoned this revision. aprantl added a comment. Todd, I'm abandoning the review. This should allow you to claim it as your own so you can iterate quicker. Thanks! http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala commandeered this revision. tfiala edited reviewers, added: aprantl; removed: tfiala. tfiala added a comment. Commandeering. Thanks, Adrian! http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala added a comment. > @aprantl, the lldbsuite/support/gmodules.py file didn't make it into your > patch set here. (It was the top file in the -v6 diff). Totally incorrect. The top file is the new file, but it is malformed and is showing a diff rather than the whole file. Not sure exactly how I produced that diff, but that is something I'm about to rectify. I'll put up a fresh patch set after I address the issues in the review. (It may take a while as I will also be testing with adjustments for the inline tests, that did not use the gmodules build steps --- regular tests did, just not inline ones, which we happen to have a lot of). http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala updated this revision to Diff 58449.
tfiala added a comment.
Just updating the patch set to what I had intended to give Adrian in r6. This
does not yet contain any of the suggestions from the latest round.
http://reviews.llvm.org/D19998
Files:
packages/Python/lldbsuite/support/gmodules.py
packages/Python/lldbsuite/test/decorators.py
packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
packages/Python/lldbsuite/test/functionalities/dead-strip/TestDeadStrip.py
packages/Python/lldbsuite/test/lang/c/global_variables/TestGlobalVariables.py
packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py
packages/Python/lldbsuite/test/lang/objc/foundation/TestRuntimeTypes.py
packages/Python/lldbsuite/test/lldbinline.py
packages/Python/lldbsuite/test/lldbtest.py
packages/Python/lldbsuite/test/make/Makefile.rules
packages/Python/lldbsuite/test/plugins/builder_base.py
packages/Python/lldbsuite/test/test_categories.py
Index: packages/Python/lldbsuite/test/test_categories.py
===
--- packages/Python/lldbsuite/test/test_categories.py
+++ packages/Python/lldbsuite/test/test_categories.py
@@ -11,16 +11,19 @@
# Third-party modules
# LLDB modules
+from lldbsuite.support import gmodules
+
debug_info_categories = [
-'dwarf', 'dwo', 'dsym'
+'dwarf', 'dwo', 'dsym', 'gmodules'
]
all_categories = {
'dataformatters': 'Tests related to the type command and the data formatters subsystem',
'dwarf' : 'Tests that can be run with DWARF debug information',
'dwo' : 'Tests that can be run with DWO debug information',
'dsym' : 'Tests that can be run with DSYM debug information',
+'gmodules' : 'Tests that can be run with -gmodules debug information',
'expression': 'Tests related to the expression parser',
'objc' : 'Tests related to the Objective-C programming language support',
'pyapi' : 'Tests related to the Python API',
@@ -42,12 +45,26 @@
candidate = item
return candidate
-def is_supported_on_platform(category, platform):
+
+def is_supported_on_platform(category, platform, compiler_paths):
if category == "dwo":
# -gsplit-dwarf is not implemented by clang on Windows.
return platform in ["linux", "freebsd"]
elif category == "dsym":
return platform in ["darwin", "macosx", "ios"]
+elif category == "gmodules":
+# First, check to see if the platform can even support gmodules.
+if platform not in ["linux", "freebsd", "darwin", "macosx", "ios"]:
+return False
+# If all compilers specified support gmodules, we'll enable it.
+for compiler_path in compiler_paths:
+if not gmodules.is_compiler_clang_with_gmodules(compiler_path):
+# Ideally in a multi-compiler scenario during a single test run, this would
+# allow gmodules on compilers that support it and not on ones that don't.
+# However, I didn't see an easy way for all the callers of this to know
+# the compiler being used for a test invocation.
+return False
+return True
return True
def validate(categories, exact_match):
Index: packages/Python/lldbsuite/test/plugins/builder_base.py
===
--- packages/Python/lldbsuite/test/plugins/builder_base.py
+++ packages/Python/lldbsuite/test/plugins/builder_base.py
@@ -143,6 +143,17 @@
# True signifies that we can handle building dwo.
return True
+def buildGModules(sender=None, architecture=None, compiler=None, dictionary=None, clean=True):
+"""Build the binaries with dwarf debug info."""
+commands = []
+if clean:
+commands.append([getMake(), "clean", getCmdLine(dictionary)])
+commands.append([getMake(), "MAKE_DSYM=NO", "MAKE_GMODULES=YES", getArchSpec(architecture), getCCSpec(compiler), getCmdLine(dictionary)])
+
+lldbtest.system(commands, sender=sender)
+# True signifies that we can handle building with gmodules.
+return True
+
def cleanup(sender=None, dictionary=None):
"""Perform a platform-specific cleanup after the test."""
#import traceback
Index: packages/Python/lldbsuite/test/make/Makefile.rules
===
--- packages/Python/lldbsuite/test/make/Makefile.rules
+++ packages/Python/lldbsuite/test/make/Makefile.rules
@@ -212,8 +212,13 @@
CFLAGS += -gsplit-dwarf
endif
+ifeq "$(MAKE_GMODULES)" "YES"
+ CFLAGS += -fmodules -gmodules
+endif
+
CXXFLAGS += -std=c++11
-CXXFLAGS += $(CFLAGS)
+# FIXME: C++ modules aren't supported on all platforms.
+CXXFLAGS += $(subst -fmodules,, $(CFLAGS))
LD = $(CC)
LDFLAGS ?= $(CFLAGS)
LDFLAGS += $(LD_EXTRAS)
@@ -519
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
labath added inline comments. Comment at: packages/Python/lldbsuite/test/decorators.py:527 @@ -525,3 +526,3 @@ -def skipUnlessClangModules(): +def skipUnlessClangModules(func): """Decorate the item to skip test unless Clang -gmodules flag is supported.""" tfiala wrote: > labath wrote: > > This whole decorator can be removed. It's invocations can be replaced with > > `add_test_categories(["gmodules"])` (cf. `lldbtest.py:1453`, it will avoid > > duplicating the test if it is already annotated with categories). > Yes, I see now. I did not understand add_test_categories(["gmodules"]) was a > valid way to mark a test as gmodules-only. > > It does look a little weird that we need to do: > @no_debug_info_test > @add_test_categories(["gmodules"]) > > I wonder if we want a combined decorator that is effectively: > @valid_debug_info([...]) > > that specifies that this test is only valid for those debug info entries > specified. Then the entry becomes a single decorator: > @valid_debug_info(["gmodules"]) > > What do you think? You shouldn't need both decorators. The test multiplicator will first check whether whether the test is already explicitly annotated with some debug info category (lldbtest.py:1446) and multiply only into the categories that were not annotated. Now that I look at it closer, I see that the code there is not entirely correct in case you annotate a test with two categories (it will create two tests, but both of them will be annotated with both categories). However, this is a topic for another change, and should not prevent you from using it now. So, yes, you should only need one decorator, and things should just work. As for the current syntax, I am open to making any changes to it, but I want to avoid having two ways of doing this in parallel. http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D20623: [cmake] Add ability to customize (and skip) debugserver codesign
tberghammer accepted this revision. tberghammer added a comment. This revision is now accepted and ready to land. lgtm http://reviews.llvm.org/D20623 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala added a comment. Yep, I see how it works now. I'll do a quick follow-up review after this to get that other issue with the debug info multiplicator (you may have just coined a word ;-)) fixed since I'm already in this code. Just finishing testing it on OS X. http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] LLVM buildmaster will be restarted tonight
Hello everyone, LLVM buildmaster will be updated and restarted after 6 PM Pacific time today. Thanks Galina ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala added a comment. I also stuck a print in to verify the gmodules build was being run everywhere I expected (i.e. for normal tests, inline tests, and the gmodules-explicit tests). http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala updated this revision to Diff 58458.
tfiala added a comment.
Adjustments per review, removal of decorator, fixup of
incorrect build method call in inline tests.
http://reviews.llvm.org/D19998
Files:
packages/Python/lldbsuite/support/gmodules.py
packages/Python/lldbsuite/test/decorators.py
packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
packages/Python/lldbsuite/test/functionalities/dead-strip/TestDeadStrip.py
packages/Python/lldbsuite/test/lang/c/global_variables/TestGlobalVariables.py
packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py
packages/Python/lldbsuite/test/lang/objc/foundation/TestRuntimeTypes.py
packages/Python/lldbsuite/test/lldbinline.py
packages/Python/lldbsuite/test/lldbtest.py
packages/Python/lldbsuite/test/make/Makefile.rules
packages/Python/lldbsuite/test/plugins/builder_base.py
packages/Python/lldbsuite/test/test_categories.py
Index: packages/Python/lldbsuite/test/test_categories.py
===
--- packages/Python/lldbsuite/test/test_categories.py
+++ packages/Python/lldbsuite/test/test_categories.py
@@ -11,16 +11,19 @@
# Third-party modules
# LLDB modules
+from lldbsuite.support import gmodules
+
debug_info_categories = [
-'dwarf', 'dwo', 'dsym'
+'dwarf', 'dwo', 'dsym', 'gmodules'
]
all_categories = {
'dataformatters': 'Tests related to the type command and the data formatters subsystem',
'dwarf' : 'Tests that can be run with DWARF debug information',
'dwo' : 'Tests that can be run with DWO debug information',
'dsym' : 'Tests that can be run with DSYM debug information',
+'gmodules' : 'Tests that can be run with -gmodules debug information',
'expression': 'Tests related to the expression parser',
'objc' : 'Tests related to the Objective-C programming language support',
'pyapi' : 'Tests related to the Python API',
@@ -42,12 +45,27 @@
candidate = item
return candidate
-def is_supported_on_platform(category, platform):
+
+def is_supported_on_platform(category, platform, compiler_paths):
if category == "dwo":
# -gsplit-dwarf is not implemented by clang on Windows.
return platform in ["linux", "freebsd"]
elif category == "dsym":
return platform in ["darwin", "macosx", "ios"]
+elif category == "gmodules":
+# First, check to see if the platform can even support gmodules.
+if platform not in ["linux", "freebsd", "darwin", "macosx", "ios"]:
+return False
+# If all compilers specified support gmodules, we'll enable it.
+for compiler_path in compiler_paths:
+if not gmodules.is_compiler_clang_with_gmodules(compiler_path):
+# Ideally in a multi-compiler scenario during a single test run, this would
+# allow gmodules on compilers that support it and not on ones that don't.
+# However, I didn't see an easy way for all the callers of this to know
+# the compiler being used for a test invocation. As we tend to run with
+# a single compiler per test run, this shouldn't be a major issue.
+return False
+return True
return True
def validate(categories, exact_match):
Index: packages/Python/lldbsuite/test/plugins/builder_base.py
===
--- packages/Python/lldbsuite/test/plugins/builder_base.py
+++ packages/Python/lldbsuite/test/plugins/builder_base.py
@@ -143,6 +143,17 @@
# True signifies that we can handle building dwo.
return True
+def buildGModules(sender=None, architecture=None, compiler=None, dictionary=None, clean=True):
+"""Build the binaries with dwarf debug info."""
+commands = []
+if clean:
+commands.append([getMake(), "clean", getCmdLine(dictionary)])
+commands.append([getMake(), "MAKE_DSYM=NO", "MAKE_GMODULES=YES", getArchSpec(architecture), getCCSpec(compiler), getCmdLine(dictionary)])
+
+lldbtest.system(commands, sender=sender)
+# True signifies that we can handle building with gmodules.
+return True
+
def cleanup(sender=None, dictionary=None):
"""Perform a platform-specific cleanup after the test."""
#import traceback
Index: packages/Python/lldbsuite/test/make/Makefile.rules
===
--- packages/Python/lldbsuite/test/make/Makefile.rules
+++ packages/Python/lldbsuite/test/make/Makefile.rules
@@ -212,8 +212,13 @@
CFLAGS += -gsplit-dwarf
endif
+ifeq "$(MAKE_GMODULES)" "YES"
+ CFLAGS += -fmodules -gmodules
+endif
+
CXXFLAGS += -std=c++11
-CXXFLAGS += $(CFLAGS)
+# FIXME: C++ modules aren't supported on all platforms.
+CXXFLAGS += $(subst -fmodules,, $(CFLAGS))
LD =
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala updated this revision to Diff 58459.
tfiala added a comment.
Remove the now-unneeded second check for Windows.
http://reviews.llvm.org/D19998
Files:
packages/Python/lldbsuite/support/gmodules.py
packages/Python/lldbsuite/test/decorators.py
packages/Python/lldbsuite/test/expression_command/top-level/TestTopLevelExprs.py
packages/Python/lldbsuite/test/functionalities/dead-strip/TestDeadStrip.py
packages/Python/lldbsuite/test/lang/c/global_variables/TestGlobalVariables.py
packages/Python/lldbsuite/test/lang/cpp/gmodules/TestWithModuleDebugging.py
packages/Python/lldbsuite/test/lang/objc/foundation/TestObjCMethods2.py
packages/Python/lldbsuite/test/lang/objc/foundation/TestRuntimeTypes.py
packages/Python/lldbsuite/test/lldbinline.py
packages/Python/lldbsuite/test/lldbtest.py
packages/Python/lldbsuite/test/make/Makefile.rules
packages/Python/lldbsuite/test/plugins/builder_base.py
packages/Python/lldbsuite/test/test_categories.py
Index: packages/Python/lldbsuite/test/test_categories.py
===
--- packages/Python/lldbsuite/test/test_categories.py
+++ packages/Python/lldbsuite/test/test_categories.py
@@ -11,16 +11,19 @@
# Third-party modules
# LLDB modules
+from lldbsuite.support import gmodules
+
debug_info_categories = [
-'dwarf', 'dwo', 'dsym'
+'dwarf', 'dwo', 'dsym', 'gmodules'
]
all_categories = {
'dataformatters': 'Tests related to the type command and the data formatters subsystem',
'dwarf' : 'Tests that can be run with DWARF debug information',
'dwo' : 'Tests that can be run with DWO debug information',
'dsym' : 'Tests that can be run with DSYM debug information',
+'gmodules' : 'Tests that can be run with -gmodules debug information',
'expression': 'Tests related to the expression parser',
'objc' : 'Tests related to the Objective-C programming language support',
'pyapi' : 'Tests related to the Python API',
@@ -42,12 +45,27 @@
candidate = item
return candidate
-def is_supported_on_platform(category, platform):
+
+def is_supported_on_platform(category, platform, compiler_paths):
if category == "dwo":
# -gsplit-dwarf is not implemented by clang on Windows.
return platform in ["linux", "freebsd"]
elif category == "dsym":
return platform in ["darwin", "macosx", "ios"]
+elif category == "gmodules":
+# First, check to see if the platform can even support gmodules.
+if platform not in ["linux", "freebsd", "darwin", "macosx", "ios"]:
+return False
+# If all compilers specified support gmodules, we'll enable it.
+for compiler_path in compiler_paths:
+if not gmodules.is_compiler_clang_with_gmodules(compiler_path):
+# Ideally in a multi-compiler scenario during a single test run, this would
+# allow gmodules on compilers that support it and not on ones that don't.
+# However, I didn't see an easy way for all the callers of this to know
+# the compiler being used for a test invocation. As we tend to run with
+# a single compiler per test run, this shouldn't be a major issue.
+return False
+return True
return True
def validate(categories, exact_match):
Index: packages/Python/lldbsuite/test/plugins/builder_base.py
===
--- packages/Python/lldbsuite/test/plugins/builder_base.py
+++ packages/Python/lldbsuite/test/plugins/builder_base.py
@@ -143,6 +143,17 @@
# True signifies that we can handle building dwo.
return True
+def buildGModules(sender=None, architecture=None, compiler=None, dictionary=None, clean=True):
+"""Build the binaries with dwarf debug info."""
+commands = []
+if clean:
+commands.append([getMake(), "clean", getCmdLine(dictionary)])
+commands.append([getMake(), "MAKE_DSYM=NO", "MAKE_GMODULES=YES", getArchSpec(architecture), getCCSpec(compiler), getCmdLine(dictionary)])
+
+lldbtest.system(commands, sender=sender)
+# True signifies that we can handle building with gmodules.
+return True
+
def cleanup(sender=None, dictionary=None):
"""Perform a platform-specific cleanup after the test."""
#import traceback
Index: packages/Python/lldbsuite/test/make/Makefile.rules
===
--- packages/Python/lldbsuite/test/make/Makefile.rules
+++ packages/Python/lldbsuite/test/make/Makefile.rules
@@ -212,8 +212,13 @@
CFLAGS += -gsplit-dwarf
endif
+ifeq "$(MAKE_GMODULES)" "YES"
+ CFLAGS += -fmodules -gmodules
+endif
+
CXXFLAGS += -std=c++11
-CXXFLAGS += $(CFLAGS)
+# FIXME: C++ modules aren't supported on all platforms.
+CXXFLAGS += $(subst -fmodules,, $(CFLAGS))
LD = $(CC)
LDFLAGS ?= $(CFLAGS)
LDFLAGS += $(LD_EXTR
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala added a comment. I believe this now accounts for everything we discussed changing. http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala marked 15 inline comments as done. tfiala added a comment. Marked all code comments as done. http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
zturner added a comment. Going to try this out on Windows and see how it goes. http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r270745 - Mark some arm-linux specific xfails marking bug entries
Author: omjavaid
Date: Wed May 25 13:48:39 2016
New Revision: 270745
URL: http://llvm.org/viewvc/llvm-project?rev=270745&view=rev
Log:
Mark some arm-linux specific xfails marking bug entries
TestCallUserAnonTypedef.py and TestIRInterpreter.py fail to limitation of JIT
expressions in handling hard float ABI targets.
TestBSDArchives.py fails due to python unicode error.
TestBuiltinTrap.py fails due to wrong line information generated by some gcc
versions.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
lldb/trunk/packages/Python/lldbsuite/test/expression_command/ir-interpreter/TestIRInterpreter.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/archives/TestBSDArchives.py
lldb/trunk/packages/Python/lldbsuite/test/linux/builtin_trap/TestBuiltinTrap.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py?rev=270745&r1=270744&r2=270745&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/anonymous-struct/TestCallUserAnonTypedef.py
Wed May 25 13:48:39 2016
@@ -24,6 +24,7 @@ class TestExprLookupAnonStructTypedef(Te
self.line = line_number('main.cpp', '// lldb testsuite break')
@expectedFailureAll(oslist=["windows"])
+@expectedFailureAll(oslist=['linux'], archs=['arm'],
bugnumber="llvm.org/pr27868")
def test(self):
"""Test typedeffed untagged struct arguments for function call
expressions"""
self.build()
Modified:
lldb/trunk/packages/Python/lldbsuite/test/expression_command/ir-interpreter/TestIRInterpreter.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/expression_command/ir-interpreter/TestIRInterpreter.py?rev=270745&r1=270744&r2=270745&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/expression_command/ir-interpreter/TestIRInterpreter.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/expression_command/ir-interpreter/TestIRInterpreter.py
Wed May 25 13:48:39 2016
@@ -38,7 +38,8 @@ class IRInterpreterTestCase(TestBase):
self.runCmd("run", RUN_SUCCEEDED)
@add_test_categories(['pyapi'])
-@expectedFailureAll(oslist=['windows'], bugnumber="21765") # getpid() is
POSIX, among other problems, see bug
+@expectedFailureAll(oslist=['windows'],
bugnumber="http://llvm.org/pr21765";) # getpid() is POSIX, among other
problems, see bug
+@expectedFailureAll(oslist=['linux'], archs=['arm'],
bugnumber="llvm.org/pr27868")
def test_ir_interpreter(self):
self.build_and_run()
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/archives/TestBSDArchives.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/archives/TestBSDArchives.py?rev=270745&r1=270744&r2=270745&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/archives/TestBSDArchives.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/archives/TestBSDArchives.py
Wed May 25 13:48:39 2016
@@ -21,6 +21,7 @@ class BSDArchivesTestCase(TestBase):
self.line = line_number('a.c', '// Set file and line breakpoint inside
a().')
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24527.
Makefile.rules doesn't know how to build static libs on Windows")
+@expectedFailureAll(oslist=["linux"], archs=["arm"],
bugnumber="llvm.org/pr27795")
def test(self):
"""Break inside a() and b() defined within libfoo.a."""
self.build()
Modified:
lldb/trunk/packages/Python/lldbsuite/test/linux/builtin_trap/TestBuiltinTrap.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/linux/builtin_trap/TestBuiltinTrap.py?rev=270745&r1=270744&r2=270745&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/linux/builtin_trap/TestBuiltinTrap.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/linux/builtin_trap/TestBuiltinTrap.py
Wed May 25 13:48:39 2016
@@ -25,6 +25,7 @@ class BuiltinTrapTestCase(TestBase):
@expectedFailureAll("llvm.org/pr15936", compiler="gcc",
compiler_version=["<=","4.6"])
@expectedFailureAll(archs="arm", compiler="gcc", triple=".*-android") #
gcc generates incorrect linetable
+@expectedFailureAll(oslist=['linux'], archs=['arm'])
@skipIfWindows
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala added a comment. Okay, thanks Zachary. http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] Builder llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast is back to normal
Hello, Builder http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast is back to normal. Sorry for the noise. Thanks Galina ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] Builder llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast is back to normal
A factory required a successful step of removing the llvm.obj directory, which could be missing in some cases. The fix is committed as r270773 Thanks Galina On Wed, May 25, 2016 at 12:22 PM, Sean Silva wrote: > What was the issue? > > On Wed, May 25, 2016 at 12:17 PM, Galina Kistanova via llvm-commits < > llvm-comm...@lists.llvm.org> wrote: > >> Hello, >> >> Builder >> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast >> is back to normal. >> Sorry for the noise. >> >> Thanks >> >> Galina >> >> ___ >> llvm-commits mailing list >> llvm-comm...@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits >> >> > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala added a comment. Timing info for Ubuntu 15.10: | Description | Time (seconds)(mm:ss) | | Ubuntu 15.10 6-core, 24 GB RAM, TOT clang, no gmodules | 377s (6:17) | | Ubuntu 15.10 6-core, 24 GB RAM, TOT clang, with gmodules | 517s (8:37) | Net increase: 37%. No new failures with Ubuntu 15.10 x86_64 with the inline test fix. http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
zturner accepted this revision. zturner added a reviewer: zturner. zturner added a comment. This revision is now accepted and ready to land. No problems here, I'd wait for Pavel for additional thoughts before going in. http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala added a comment. In http://reviews.llvm.org/D19998#439698, @zturner wrote: > No problems here, I'd wait for Pavel for additional thoughts before going in. Yep that's fine. I am in no hurry to get this in. http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19998: Add a "-gmodules" category to the test suite.
tfiala added a comment. Updated timings, now with OS X: | Configuration | Time (seconds)(mm:ss) | | Ubuntu 15.10 6-core, 24 GB RAM, TOT clang, no gmodules| 377 (6:17) | | Ubuntu 15.10 6-core, 24 GB RAM, TOT clang, with gmodules | 517 (8:37) | | OS X 10.5 8-core, 32 GB RAM, Xcode 7.3.1 clang, no gmodules | 361 (6:01) | | OS X 10.5 8-core, 32 GB RAM, Xcode 7.3.1 clang, with gmodules | 500 (8:20) | | Configuration | Net increase (%) | | Ubuntu 15.10 6-core, 24 GB RAM, TOT clang | 37 | | OS X 10.5 8-core, 32 GB RAM, Xcode 7.3.1 clang | 39 | http://reviews.llvm.org/D19998 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r270752 - Fix an issue where LLDB would crash if one tried to 'frame variable' an unordered_map more than once in a stop due to the synthetic provider not properly caching the Va
Author: enrico
Date: Wed May 25 15:38:33 2016
New Revision: 270752
URL: http://llvm.org/viewvc/llvm-project?rev=270752&view=rev
Log:
Fix an issue where LLDB would crash if one tried to 'frame variable' an
unordered_map more than once in a stop due to the synthetic provider not
properly caching the ValueObjects it was returning for the child elements
Fixes rdar://26470909
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/unordered/TestDataFormatterUnordered.py
lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/unordered/TestDataFormatterUnordered.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/unordered/TestDataFormatterUnordered.py?rev=270752&r1=270751&r2=270752&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/unordered/TestDataFormatterUnordered.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/unordered/TestDataFormatterUnordered.py
Wed May 25 15:38:33 2016
@@ -73,4 +73,5 @@ class LibcxxUnorderedDataFormatterTestCa
def look_for_content_and_continue(self, var_name, patterns):
self.expect( ("frame variable %s" % var_name), patterns=patterns)
+self.expect( ("frame variable %s" % var_name), patterns=patterns)
self.runCmd("continue")
Modified: lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp?rev=270752&r1=270751&r2=270752&view=diff
==
--- lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp
(original)
+++ lldb/trunk/source/Plugins/Language/CPlusPlus/LibCxxUnorderedMap.cpp Wed May
25 15:38:33 2016
@@ -125,10 +125,13 @@ lldb_private::formatters::LibcxxStdUnord
return lldb::ValueObjectSP();
const bool thread_and_frame_only_if_stopped = true;
ExecutionContext exe_ctx =
val_hash.first->GetExecutionContextRef().Lock(thread_and_frame_only_if_stopped);
-return val_hash.first->CreateValueObjectFromData(stream.GetData(),
- data,
- exe_ctx,
-
val_hash.first->GetCompilerType());
+ValueObjectSP
child_sp(val_hash.first->CreateValueObjectFromData(stream.GetData(),
+ data,
+ exe_ctx,
+
val_hash.first->GetCompilerType()));
+if (child_sp)
+m_children.emplace(idx, child_sp);
+return child_sp;
}
bool
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r270770 - Add logging to ValueObjectSyntheticFilter such that one can trace through the creation of synthetic children
Author: enrico
Date: Wed May 25 16:38:32 2016
New Revision: 270770
URL: http://llvm.org/viewvc/llvm-project?rev=270770&view=rev
Log:
Add logging to ValueObjectSyntheticFilter such that one can trace through the
creation of synthetic children
Modified:
lldb/trunk/source/Core/ValueObjectSyntheticFilter.cpp
Modified: lldb/trunk/source/Core/ValueObjectSyntheticFilter.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/ValueObjectSyntheticFilter.cpp?rev=270770&r1=270769&r2=270770&view=diff
==
--- lldb/trunk/source/Core/ValueObjectSyntheticFilter.cpp (original)
+++ lldb/trunk/source/Core/ValueObjectSyntheticFilter.cpp Wed May 25 16:38:32
2016
@@ -12,6 +12,8 @@
// Other libraries and framework includes
// Project includes
#include "lldb/Core/ValueObjectSyntheticFilter.h"
+
+#include "lldb/Core/Log.h"
#include "lldb/Core/ValueObject.h"
#include "lldb/DataFormatters/TypeSynthetic.h"
@@ -65,13 +67,7 @@ ValueObjectSynthetic::ValueObjectSynthet
m_might_have_children(eLazyBoolCalculate),
m_provides_value(eLazyBoolCalculate)
{
-#ifdef FOOBAR
-std::string new_name(parent.GetName().AsCString());
-new_name += "$$__synth__";
-SetName (ConstString(new_name.c_str()));
-#else
SetName(parent.GetName());
-#endif
CopyValueData(m_parent);
CreateSynthFilter();
}
@@ -108,14 +104,32 @@ ValueObjectSynthetic::GetDisplayTypeName
size_t
ValueObjectSynthetic::CalculateNumChildren(uint32_t max)
{
+Log* log = GetLogIfAllCategoriesSet(LIBLLDB_LOG_DATAFORMATTERS);
+
UpdateValueIfNeeded();
if (m_synthetic_children_count < UINT32_MAX)
return m_synthetic_children_count <= max ? m_synthetic_children_count
: max;
if (max < UINT32_MAX)
-return m_synth_filter_ap->CalculateNumChildren(max);
+{
+size_t num_children = m_synth_filter_ap->CalculateNumChildren(max);
+if (log)
+log->Printf("[ValueObjectSynthetic::CalculateNumChildren] for VO
of name %s and type %s, the filter returned %zu child values",
+GetName().AsCString(),
+GetTypeName().AsCString(),
+num_children);
+return num_children;
+}
else
-return (m_synthetic_children_count =
m_synth_filter_ap->CalculateNumChildren(max));
+{
+size_t num_children = (m_synthetic_children_count =
m_synth_filter_ap->CalculateNumChildren(max));
+if (log)
+log->Printf("[ValueObjectSynthetic::CalculateNumChildren] for VO
of name %s and type %s, the filter returned %zu child values",
+GetName().AsCString(),
+GetTypeName().AsCString(),
+num_children);
+return num_children;
+}
}
lldb::ValueObjectSP
@@ -159,6 +173,8 @@ ValueObjectSynthetic::CreateSynthFilter
bool
ValueObjectSynthetic::UpdateValue ()
{
+Log* log = GetLogIfAllCategoriesSet(LIBLLDB_LOG_DATAFORMATTERS);
+
SetValueIsValid (false);
m_error.Clear();
@@ -175,6 +191,11 @@ ValueObjectSynthetic::UpdateValue ()
ConstString new_parent_type_name = m_parent->GetTypeName();
if (new_parent_type_name != m_parent_type_name)
{
+if (log)
+log->Printf("[ValueObjectSynthetic::UpdateValue] name=%s, type
changed from %s to %s, recomputing synthetic filter",
+GetName().AsCString(),
+m_parent_type_name.AsCString(),
+new_parent_type_name.AsCString());
m_parent_type_name = new_parent_type_name;
CreateSynthFilter();
}
@@ -182,6 +203,8 @@ ValueObjectSynthetic::UpdateValue ()
// let our backend do its update
if (m_synth_filter_ap->Update() == false)
{
+if (log)
+log->Printf("[ValueObjectSynthetic::UpdateValue] name=%s,
synthetic filter said caches are stale - clearing", GetName().AsCString());
// filter said that cached values are stale
m_children_byindex.Clear();
m_name_toindex.Clear();
@@ -192,6 +215,11 @@ ValueObjectSynthetic::UpdateValue ()
m_synthetic_children_count = UINT32_MAX;
m_might_have_children = eLazyBoolCalculate;
}
+else
+{
+if (log)
+log->Printf("[ValueObjectSynthetic::UpdateValue] name=%s,
synthetic filter said caches are still valid", GetName().AsCString());
+}
m_provides_value = eLazyBoolCalculate;
@@ -199,11 +227,17 @@ ValueObjectSynthetic::UpdateValue ()
if (synth_val && synth_val->CanProvideValue())
{
+if (log)
+log->Printf("[ValueObjectSynthetic::UpdateValue] name=%s,
synthetic filter said it can provide a value", GetName().AsCString());
+
m_provides_value = eLazyBoolYes;
CopyValueData(synth_val.get());
}
else
{
+if (log)
+log->Printf("[ValueObjectSynthe
[Lldb-commits] [lldb] r270780 - Mark some aarch64-linux specific xfails marking bug entries
Author: omjavaid
Date: Wed May 25 17:30:05 2016
New Revision: 270780
URL: http://llvm.org/viewvc/llvm-project?rev=270780&view=rev
Log:
Mark some aarch64-linux specific xfails marking bug entries
TestBSDArchives.py and TestWatchLocation.py fail due to unicode error and bug
has already been reported for arm and macOSx.
TestConstVariables.py fails because lldb cant figure out frame variable type
when used in expr.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/archives/TestBSDArchives.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
lldb/trunk/packages/Python/lldbsuite/test/lang/c/const_variables/TestConstVariables.py
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/archives/TestBSDArchives.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/archives/TestBSDArchives.py?rev=270780&r1=270779&r2=270780&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/archives/TestBSDArchives.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/archives/TestBSDArchives.py
Wed May 25 17:30:05 2016
@@ -21,7 +21,7 @@ class BSDArchivesTestCase(TestBase):
self.line = line_number('a.c', '// Set file and line breakpoint inside
a().')
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24527.
Makefile.rules doesn't know how to build static libs on Windows")
-@expectedFailureAll(oslist=["linux"], archs=["arm"],
bugnumber="llvm.org/pr27795")
+@expectedFailureAll(oslist=["linux"], archs=["arm", "aarch64"],
bugnumber="llvm.org/pr27795")
def test(self):
"""Break inside a() and b() defined within libfoo.a."""
self.build()
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py?rev=270780&r1=270779&r2=270780&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/watchpoint/hello_watchlocation/TestWatchLocation.py
Wed May 25 17:30:05 2016
@@ -34,7 +34,7 @@ class HelloWatchLocationTestCase(TestBas
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24446:
WINDOWS XFAIL TRIAGE - Watchpoints not supported on Windows")
@expectedFailureAll(triple = re.compile('^mips')) # Most of the MIPS
boards provide only one H/W watchpoints, and S/W watchpoints are not supported
yet
@expectedFailureAll(archs=['s390x']) # SystemZ also currently supports
only one H/W watchpoint
-@expectedFailureAll(oslist=["linux"], archs=["arm"],
bugnumber="llvm.org/pr27795")
+@expectedFailureAll(oslist=["linux"], archs=["arm", "aarch64"],
bugnumber="llvm.org/pr27795")
@skipIfDarwin
def test_hello_watchlocation(self):
"""Test watching a location with '-s size' option."""
Modified:
lldb/trunk/packages/Python/lldbsuite/test/lang/c/const_variables/TestConstVariables.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/lang/c/const_variables/TestConstVariables.py?rev=270780&r1=270779&r2=270780&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/lang/c/const_variables/TestConstVariables.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/lang/c/const_variables/TestConstVariables.py
Wed May 25 17:30:05 2016
@@ -25,6 +25,7 @@ class ConstVariableTestCase(TestBase):
compiler="clang", compiler_version=[">=", "3.8"])
@expectedFailureAll(oslist=["freebsd", "linux"], compiler="icc")
@expectedFailureAll(archs=['mips', 'mipsel', 'mips64', 'mips64el'])
+@expectedFailureAll(oslist=["linux"], archs=['arm', 'aarch64'],
bugnumber="llvm.org/pr27883")
@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24489: Name
lookup not working correctly on Windows")
def test_and_run_command(self):
"""Test interpreted and JITted expressions on constant values."""
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r270793 - It has been brought to my attention that, given two variables
Author: enrico
Date: Wed May 25 18:19:01 2016
New Revision: 270793
URL: http://llvm.org/viewvc/llvm-project?rev=270793&view=rev
Log:
It has been brought to my attention that, given two variables
T x;
U y;
doing
x = *((T*)y)
is undefined behavior, even if sizeof(T) == sizeof(U), due to pointer aliasing
rules
Fix up a couple of places in LLDB that were doing this, and transform them into
a defined and safe memcpy() operation
Also, add a test case to ensure we didn't regress by doing this w.r.t. tagged
pointer NSDate instances
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/main.m
lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py?rev=270793&r1=270792&r2=270793&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/TestDataFormatterObjC.py
Wed May 25 18:19:01 2016
@@ -271,16 +271,18 @@ class ObjCDataFormatterTestCase(TestBase
# this test might fail if we hit the breakpoint late on December 31st
of some given year
# and midnight comes between hitting the breakpoint and running this
line of code
# hopefully the output will be revealing enough in that case :-)
-now_year = str(datetime.datetime.now().year)
+now_year = '%s-' % str(datetime.datetime.now().year)
-self.expect('frame variable date3 date4',
-substrs = [now_year,'1970'])
+self.expect('frame variable date3', substrs = [now_year])
+self.expect('frame variable date4', substrs = ['1970'])
+self.expect('frame variable date5', substrs = [now_year])
self.expect('frame variable date1_abs date2_abs',
substrs = ['1985-04','2011-01'])
-self.expect('frame variable date3_abs date4_abs',
-substrs = [now_year,'1970'])
+self.expect('frame variable date3_abs', substrs = [now_year])
+self.expect('frame variable date4_abs', substrs = ['1970'])
+self.expect('frame variable date5_abs', substrs = [now_year])
self.expect('frame variable cupertino home europe',
substrs = ['@"America/Los_Angeles"',
@@ -358,7 +360,6 @@ class ObjCDataFormatterTestCase(TestBase
self.runCmd('type format clear', check=False)
self.runCmd('type summary clear', check=False)
self.runCmd('type synth clear', check=False)
-self.runCmd('log timers disable', check=False)
# Execute the cleanup function during test case tear down.
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/main.m
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/main.m?rev=270793&r1=270792&r2=270793&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/main.m
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-objc/main.m
Wed May 25 18:19:01 2016
@@ -489,11 +489,13 @@ int main (int argc, const char * argv[])
NSDate *date2 = [NSDate dateWithNaturalLanguageString:@"12am
January 1, 2011"];
NSDate *date3 = [NSDate date];
NSDate *date4 = [NSDate dateWithTimeIntervalSince1970:24*60*60];
+NSDate *date5 = [NSDate dateWithTimeIntervalSinceReferenceDate:
floor([[NSDate date] timeIntervalSinceReferenceDate])];
CFAbsoluteTime date1_abs = CFDateGetAbsoluteTime(date1);
CFAbsoluteTime date2_abs = CFDateGetAbsoluteTime(date2);
CFAbsoluteTime date3_abs = CFDateGetAbsoluteTime(date3);
CFAbsoluteTime date4_abs = CFDateGetAbsoluteTime(date4);
+ CFAbsoluteTime date5_abs = CFDateGetAbsoluteTime(date5);
NSIndexSet *iset1 = [[NSIndexSet alloc]
initWithIndexesInRange:NSMakeRange(1, 4)];
NSIndexSet *iset2 = [[NSIndexSet alloc]
initWithIndexesInRange:NSMakeRange(1, 512)];
Modified: lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/Language/ObjC/Cocoa.cpp?rev=270793&r1=270792&r2=270793&view=diff
[Lldb-commits] [lldb] r270803 - Make sure to try and take the process stop lock when calling:
Author: gclayton
Date: Wed May 25 19:08:39 2016
New Revision: 270803
URL: http://llvm.org/viewvc/llvm-project?rev=270803&view=rev
Log:
Make sure to try and take the process stop lock when calling:
uint32_t SBProcess::GetNumQueues();
SBQueue SBProcess::GetQueueAtIndex (size_t index);
Otherwise this code will run when the process is running and cause problems.
Modified:
lldb/trunk/source/API/SBProcess.cpp
Modified: lldb/trunk/source/API/SBProcess.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/API/SBProcess.cpp?rev=270803&r1=270802&r2=270803&view=diff
==
--- lldb/trunk/source/API/SBProcess.cpp (original)
+++ lldb/trunk/source/API/SBProcess.cpp Wed May 25 19:08:39 2016
@@ -549,9 +549,11 @@ SBProcess::GetNumQueues ()
if (process_sp)
{
Process::StopLocker stop_locker;
-
-std::lock_guard
guard(process_sp->GetTarget().GetAPIMutex());
-num_queues = process_sp->GetQueueList().GetSize();
+if (stop_locker.TryLock(&process_sp->GetRunLock()))
+{
+std::lock_guard
guard(process_sp->GetTarget().GetAPIMutex());
+num_queues = process_sp->GetQueueList().GetSize();
+}
}
if (log)
@@ -572,9 +574,12 @@ SBProcess::GetQueueAtIndex (size_t index
if (process_sp)
{
Process::StopLocker stop_locker;
-std::lock_guard
guard(process_sp->GetTarget().GetAPIMutex());
-queue_sp = process_sp->GetQueueList().GetQueueAtIndex(index);
-sb_queue.SetQueue (queue_sp);
+if (stop_locker.TryLock(&process_sp->GetRunLock()))
+{
+std::lock_guard
guard(process_sp->GetTarget().GetAPIMutex());
+queue_sp = process_sp->GetQueueList().GetQueueAtIndex(index);
+sb_queue.SetQueue (queue_sp);
+}
}
if (log)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D20623: [cmake] Add ability to customize (and skip) debugserver codesign
sas accepted this revision. sas added a comment. This is really useful. http://reviews.llvm.org/D20623 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r270818 - Small further refinement to the check in ObjectFileMachO::ParseSymtab
Author: jmolenda
Date: Wed May 25 23:22:47 2016
New Revision: 270818
URL: http://llvm.org/viewvc/llvm-project?rev=270818&view=rev
Log:
Small further refinement to the check in ObjectFileMachO::ParseSymtab
which looks for binaries missing an LC_FUNCTION_STARTS section because
it was stripped/not emitted. If we see a normal user process binary
(executable, dylib, framework, bundle) without LC_FUNCTION_STARTS, that
is unusual and we should disallow instruction emulation because that
binary has likely been stripped a lot.
If this is a non-user process binary -- a kernel, a standalone bare-board
binary, a kernel extension (kext) -- and there is no LC_FUNCTION_STARTS,
we should not assume anything about the binary and allow instruction
emulation as we would normally do.
Modified:
lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
Modified: lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp?rev=270818&r1=270817&r2=270818&view=diff
==
--- lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp (original)
+++ lldb/trunk/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp Wed May 25
23:22:47 2016
@@ -2607,14 +2607,16 @@ ObjectFileMachO::ParseSymtab ()
const size_t function_starts_count = function_starts.GetSize();
-// kext bundles don't have LC_FUNCTION_STARTS / eh_frame sections, but
we can assume that we have
-// accurate symbol boundaries for them, they're a special case.
-
-if (function_starts_count == 0 && m_header.filetype !=
llvm::MachO::MH_KEXT_BUNDLE)
+// For user process binaries (executables, dylibs, frameworks,
bundles), if we don't have
+// LC_FUNCTION_STARTS/eh_frame section in this binary, we're going to
assume the binary
+// has been stripped. Don't allow assembly language instruction
emulation because we don't
+// know proper function start boundaries.
+//
+// For all other types of binaries (kernels, stand-alone bare board
binaries, kexts), they
+// may not have LC_FUNCTION_STARTS / eh_frame sections - we should not
make any assumptions
+// about them based on that.
+if (function_starts_count == 0 && CalculateStrata() == eStrataUser)
{
-// No LC_FUNCTION_STARTS/eh_frame section in this binary, we're
going to assume the binary
-// has been stripped. Don't allow assembly language instruction
emulation because we don't
-// know proper function start boundaries.
m_allow_assembly_emulation_unwind_plans = false;
Log *unwind_or_symbol_log (lldb_private::GetLogIfAnyCategoriesSet
(LIBLLDB_LOG_SYMBOLS | LIBLLDB_LOG_UNWIND));
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
