[Lldb-commits] [lldb] r324870 - Skip TestTargetXMLArch on non-darwin OSs
Author: labath Date: Mon Feb 12 01:46:06 2018 New Revision: 324870 URL: http://llvm.org/viewvc/llvm-project?rev=324870&view=rev Log: Skip TestTargetXMLArch on non-darwin OSs This test uses XML packets, but libxml is an optional dependency of lldb, and this test fails if it is not present. I'm leaving this enabled on mac, as thats the only platform that's likely to have libxml always available, but ideally we should have a way to skip this based on build configuration. I'll see if I can whip something like that up soon, but for the time being, this unblocks the buildbots. Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestTargetXMLArch.py Modified: lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestTargetXMLArch.py URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestTargetXMLArch.py?rev=324870&r1=324869&r2=324870&view=diff == --- lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestTargetXMLArch.py (original) +++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/gdb_remote_client/TestTargetXMLArch.py Mon Feb 12 01:46:06 2018 @@ -6,6 +6,7 @@ from gdbclientutils import * class TestTargetXMLArch(GDBRemoteTestBase): +@skipIf(hostoslist=no_match(lldbplatformutil.getDarwinOSTriples())) @expectedFailureAll(archs=["i386"]) def test(self): """ ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43099: Make LLDB's clang module cache path customizable
labath added a comment. There are several components in the "command line parsing" 1. argparse: parsing a single string into the individual words (processing quotes, backslashes, etc.) 2. resolving the "command" part of the command line (the "frame variable" part of "frame variable --raw-output FOO") 3. resolving the arguments of a command (the "--raw-output FOO" part) These parts compose quite nicely, and can be individually replaced. I'll briefly speak about each one : (1) is very specific to our interactive use case (for command line utilities, the shell/os does the parsing for us). There also isn't anything nearly similar in llvm (afaik). (2) is also quite specific to how lldb commands are structured, and there also isn't a suitable llvm replacement. This is the level at which the "command aliases" are resolved. (3) is a fairly generic piece of functionality -- we even implement it by delegating to getopt (in a scarily un-thread-safe way). For this there are *two* competing implementations in llvm: `llvm::cl` and `llvm::opt`. Of these the first one is not suitable for our use case right now as it relies on global variables. Making it work probably would be a bit or work. However, using the second one should be fairly easy, and it should be generic-enough (it's the thing that handles crazy gcc command lines). The reason I'm spelling it out this way is because I think you were mostly talking about (3), but some of the difficulties Jim pointed out (command aliases) just aren't relevant there. I don't think llvm::opt handles "shortest match" options yet, but that should be fairly easy to add. On the flip side, the library has recently gained argument suggestion capabilities (`error: unknown argument '-gllbb', did you mean '-glldb'`), so we would get that for free. Making sure tab completion works there would require a bit of thought, but I think this should not interfere with this library too much (after all, we use getopt now, and it does not support tab completion either). Repository: rL LLVM https://reviews.llvm.org/D43099 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r324743 - [Testsuite] Remove leak tests, it's not useful anymore.
I think you misunderstood the purpose the purpose of this test. The test was there to make sure that *lldb* does not leak file descriptors into the inferior (when I wrote it a couple of years ago, we were leaking about half a dozen of them). The python version check was added there just because we found there are some leaks coming from python itself that we could not control (so we skipped the test with those versions). With this in mind, I think the test is still very much useful. I think a better cleanup would be to rewrite this test to not depend on python so much, e.g. by driving the test from a command line lldb client a'la the tests in `lldb/lit/Expr` (unfortunately I can't think of a way to check that an FD is not leaked in a different way than with a full-scale integration test). On 9 February 2018 at 22:48, Vedant Kumar via lldb-commits wrote: > Nice! > > vedant > >> On Feb 9, 2018, at 8:06 AM, Davide Italiano via lldb-commits >> wrote: >> >> Author: davide >> Date: Fri Feb 9 08:06:39 2018 >> New Revision: 324743 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=324743&view=rev >> Log: >> [Testsuite] Remove leak tests, it's not useful anymore. >> >> This only worked on MacOS, which now ships a newer version of >> python without this bug. As such, we don't leak the fd, and >> this test is not needed anymore (as it also hardcoded the python >> version in the check). >> >> Removed: >> >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile >> >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py >> >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/main.c >> >> Removed: >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile >> URL: >> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile?rev=324742&view=auto >> == >> --- >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile >> (original) >> +++ >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile >> (removed) >> @@ -1,5 +0,0 @@ >> -LEVEL = ../../make >> - >> -C_SOURCES := main.c >> - >> -include $(LEVEL)/Makefile.rules >> >> Removed: >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py >> URL: >> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py?rev=324742&view=auto >> == >> --- >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py >> (original) >> +++ >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py >> (removed) >> @@ -1,108 +0,0 @@ >> -""" >> -Test whether a process started by lldb has no extra file descriptors open. >> -""" >> - >> -from __future__ import print_function >> - >> - >> -import os >> -import lldb >> -from lldbsuite.test import lldbutil >> -from lldbsuite.test.lldbtest import * >> -from lldbsuite.test.decorators import * >> - >> - >> -def python_leaky_fd_version(test): >> -import sys >> -# Python random module leaks file descriptors on some versions. >> -if sys.version_info >= (2, 7, 8) and sys.version_info < (2, 7, 10): >> -return "Python random module leaks file descriptors in this python >> version" >> -return None >> - >> - >> -class AvoidsFdLeakTestCase(TestBase): >> - >> -NO_DEBUG_INFO_TESTCASE = True >> - >> -mydir = TestBase.compute_mydir(__file__) >> - >> -@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376") >> -@expectedFailureAll( >> -oslist=['freebsd'], >> -bugnumber="llvm.org/pr25624 still failing with Python 2.7.10") >> -# The check for descriptor leakage needs to be implemented differently >> -# here. >> -@skipIfWindows >> -@skipIfTargetAndroid() # Android have some other file descriptors open >> by the shell >> -@skipIfDarwinEmbedded # # debugserver on ios >> has an extra fd open on launch >> -def test_fd_leak_basic(self): >> -self.do_test([]) >> - >> -@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376") >> -@expectedFailureAll( >> -oslist=['freebsd'], >> -bugnumber="llvm.org/pr25624 still failing with Python 2.7.10") >> -# The check for descriptor leakage needs to be implemented differently >> -# here. >> -@skipIfWindows >> -@skipIfTargetAndroid() # Android have some other file descriptors open >> by the shell >> -@skipIfDarwinEmbedded # # debugserver on ios >> has an extra fd open on launch >> -def test_fd_leak_log(self): >> -self.do_test(["log enable -f '/dev/null' lldb commands"]) >> - >> -def do_test(self, commands): >> -
[Lldb-commits] [PATCH] D43096: [lit] Update how clang and other binaries are found in per-configuration directories
labath added inline comments.
Comment at: CMakeLists.txt:73-80
+ if ("${LLDB_TEST_C_COMPILER}" STREQUAL "")
+set(LLDB_TESTING_DEFAULT_C_COMPILER ON)
+ endif()
+
+ if ("${LLDB_TEST_CXX_COMPILER}" STREQUAL "")
+set(LLDB_TESTING_DEFAULT_CXX_COMPILER ON)
+ endif()
I don't think this will work the second time you run cmake (i.e., re-run cmake
in an already-initialized build directory) as then this would pick up the
cached value from the previous cmake run.
I think a least magic solution would be to have a cmake option to specify
whether you are overriding the compiler, defaulting to off (and in that case
these cache values would be ignored).
https://reviews.llvm.org/D43096
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion
labath added a comment. (Btw, if you're looking for things to FileCheck-ify, I think the stuff under `lldb/unittests/UnwindAssembly` is a prime candidate and has a much higher bang/buck ratio.) https://reviews.llvm.org/D43048 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion
davide added a comment. In https://reviews.llvm.org/D43048#1004807, @labath wrote: > (Btw, if you're looking for things to FileCheck-ify, I think the stuff under > `lldb/unittests/UnwindAssembly` is a prime candidate and has a much higher > bang/buck ratio.) If you have ideas on how to FileCheck'ify unwind testing, I'm all for it. This recently came up in a discussion where the unwinder has been pointed out as hard to test. Feel free to ping me offline (or just send me a mail) and we can start thinking about something [and then propose upstream] https://reviews.llvm.org/D43048 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [lldb] r324743 - [Testsuite] Remove leak tests, it's not useful anymore.
Apologies, I clearly misunderstood. I'll add this again. On Mon, Feb 12, 2018 at 2:52 AM, Pavel Labath via lldb-commits < lldb-commits@lists.llvm.org> wrote: > I think you misunderstood the purpose the purpose of this test. The > test was there to make sure that *lldb* does not leak file descriptors > into the inferior (when I wrote it a couple of years ago, we were > leaking about half a dozen of them). The python version check was > added there just because we found there are some leaks coming from > python itself that we could not control (so we skipped the test with > those versions). > > With this in mind, I think the test is still very much useful. I think > a better cleanup would be to rewrite this test to not depend on python > so much, e.g. by driving the test from a command line lldb client a'la > the tests in `lldb/lit/Expr` (unfortunately I can't think of a way to > check that an FD is not leaked in a different way than with a > full-scale integration test). > > On 9 February 2018 at 22:48, Vedant Kumar via lldb-commits > wrote: > > Nice! > > > > vedant > > > >> On Feb 9, 2018, at 8:06 AM, Davide Italiano via lldb-commits < > lldb-commits@lists.llvm.org> wrote: > >> > >> Author: davide > >> Date: Fri Feb 9 08:06:39 2018 > >> New Revision: 324743 > >> > >> URL: http://llvm.org/viewvc/llvm-project?rev=324743&view=rev > >> Log: > >> [Testsuite] Remove leak tests, it's not useful anymore. > >> > >> This only worked on MacOS, which now ships a newer version of > >> python without this bug. As such, we don't leak the fd, and > >> this test is not needed anymore (as it also hardcoded the python > >> version in the check). > >> > >> Removed: > >>lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd- > leak/Makefile > >>lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd- > leak/TestFdLeak.py > >>lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd- > leak/main.c > >> > >> Removed: lldb/trunk/packages/Python/lldbsuite/test/ > functionalities/avoids-fd-leak/Makefile > >> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/ > Python/lldbsuite/test/functionalities/avoids-fd- > leak/Makefile?rev=324742&view=auto > >> > == > >> --- lldb/trunk/packages/Python/lldbsuite/test/ > functionalities/avoids-fd-leak/Makefile (original) > >> +++ lldb/trunk/packages/Python/lldbsuite/test/ > functionalities/avoids-fd-leak/Makefile (removed) > >> @@ -1,5 +0,0 @@ > >> -LEVEL = ../../make > >> - > >> -C_SOURCES := main.c > >> - > >> -include $(LEVEL)/Makefile.rules > >> > >> Removed: lldb/trunk/packages/Python/lldbsuite/test/ > functionalities/avoids-fd-leak/TestFdLeak.py > >> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/ > Python/lldbsuite/test/functionalities/avoids-fd- > leak/TestFdLeak.py?rev=324742&view=auto > >> > == > >> --- lldb/trunk/packages/Python/lldbsuite/test/ > functionalities/avoids-fd-leak/TestFdLeak.py (original) > >> +++ lldb/trunk/packages/Python/lldbsuite/test/ > functionalities/avoids-fd-leak/TestFdLeak.py (removed) > >> @@ -1,108 +0,0 @@ > >> -""" > >> -Test whether a process started by lldb has no extra file descriptors > open. > >> -""" > >> - > >> -from __future__ import print_function > >> - > >> - > >> -import os > >> -import lldb > >> -from lldbsuite.test import lldbutil > >> -from lldbsuite.test.lldbtest import * > >> -from lldbsuite.test.decorators import * > >> - > >> - > >> -def python_leaky_fd_version(test): > >> -import sys > >> -# Python random module leaks file descriptors on some versions. > >> -if sys.version_info >= (2, 7, 8) and sys.version_info < (2, 7, 10): > >> -return "Python random module leaks file descriptors in this > python version" > >> -return None > >> - > >> - > >> -class AvoidsFdLeakTestCase(TestBase): > >> - > >> -NO_DEBUG_INFO_TESTCASE = True > >> - > >> -mydir = TestBase.compute_mydir(__file__) > >> - > >> -@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376 > ") > >> -@expectedFailureAll( > >> -oslist=['freebsd'], > >> -bugnumber="llvm.org/pr25624 still failing with Python 2.7.10") > >> -# The check for descriptor leakage needs to be implemented > differently > >> -# here. > >> -@skipIfWindows > >> -@skipIfTargetAndroid() # Android have some other file descriptors > open by the shell > >> -@skipIfDarwinEmbedded # # debugserver > on ios has an extra fd open on launch > >> -def test_fd_leak_basic(self): > >> -self.do_test([]) > >> - > >> -@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376 > ") > >> -@expectedFailureAll( > >> -oslist=['freebsd'], > >> -bugnumber="llvm.org/pr25624 still failing with Python 2.7.10") > >> -# The check for descriptor leakage needs to be implemented > differ
[Lldb-commits] [PATCH] D42955: Make Module::GetSectionList output consistent
clayborg added inline comments. Herald added a subscriber: arichardson. Comment at: source/Core/Module.cpp:1286 +if (SymbolVendor *vendor = GetSymbolVendor()) + vendor->CreateSections(*GetUnifiedSectionList()); } should we pass "obj_file" down into the SymbolVendor::CreateSections(...) call for the case where the symbol vendor is using the same ObjectFile that it can just return? https://reviews.llvm.org/D42955 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r324919 - [testsuite] Reintroduce test to check leaking.
Author: davide
Date: Mon Feb 12 10:06:34 2018
New Revision: 324919
URL: http://llvm.org/viewvc/llvm-project?rev=324919&view=rev
Log:
[testsuite] Reintroduce test to check leaking.
It wasn't python leaking, it was lldb. Thanks to Pavel for the
explanation. Pointy-hat to me.
Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/main.c
Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile?rev=324919&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/Makefile
Mon Feb 12 10:06:34 2018
@@ -0,0 +1,5 @@
+LEVEL = ../../make
+
+C_SOURCES := main.c
+
+include $(LEVEL)/Makefile.rules
Added:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py?rev=324919&view=auto
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py
(added)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py
Mon Feb 12 10:06:34 2018
@@ -0,0 +1,108 @@
+"""
+Test whether a process started by lldb has no extra file descriptors open.
+"""
+
+from __future__ import print_function
+
+
+import os
+import lldb
+from lldbsuite.test import lldbutil
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test.decorators import *
+
+
+def python_leaky_fd_version(test):
+import sys
+# Python random module leaks file descriptors on some versions.
+if sys.version_info >= (2, 7, 8) and sys.version_info < (2, 7, 10):
+return "Python random module leaks file descriptors in this python
version"
+return None
+
+
+class AvoidsFdLeakTestCase(TestBase):
+
+NO_DEBUG_INFO_TESTCASE = True
+
+mydir = TestBase.compute_mydir(__file__)
+
+@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376")
+@expectedFailureAll(
+oslist=['freebsd'],
+bugnumber="llvm.org/pr25624 still failing with Python 2.7.10")
+# The check for descriptor leakage needs to be implemented differently
+# here.
+@skipIfWindows
+@skipIfTargetAndroid() # Android have some other file descriptors open by
the shell
+@skipIfDarwinEmbedded # # debugserver on ios
has an extra fd open on launch
+def test_fd_leak_basic(self):
+self.do_test([])
+
+@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376")
+@expectedFailureAll(
+oslist=['freebsd'],
+bugnumber="llvm.org/pr25624 still failing with Python 2.7.10")
+# The check for descriptor leakage needs to be implemented differently
+# here.
+@skipIfWindows
+@skipIfTargetAndroid() # Android have some other file descriptors open by
the shell
+@skipIfDarwinEmbedded # # debugserver on ios
has an extra fd open on launch
+def test_fd_leak_log(self):
+self.do_test(["log enable -f '/dev/null' lldb commands"])
+
+def do_test(self, commands):
+self.build()
+exe = self.getBuildArtifact("a.out")
+
+for c in commands:
+self.runCmd(c)
+
+target = self.dbg.CreateTarget(exe)
+
+process = target.LaunchSimple(
+None, None, self.get_process_working_directory())
+self.assertTrue(process, PROCESS_IS_VALID)
+
+self.assertTrue(
+process.GetState() == lldb.eStateExited,
+"Process should have exited.")
+self.assertTrue(
+process.GetExitStatus() == 0,
+"Process returned non-zero status. Were incorrect file descriptors
passed?")
+
+@expectedFailure(python_leaky_fd_version, "bugs.freebsd.org/197376")
+@expectedFailureAll(
+oslist=['freebsd'],
+bugnumber="llvm.org/pr25624 still failing with Python 2.7.10")
+# The check for descriptor leakage needs to be implemented differently
+# here.
+@skipIfWindows
+@skipIfTargetAndroid() # Android have some other file descriptors open by
the shell
+@skipIfDarwinEmbedded # # debugserver on ios
has an extra fd open on launch
+def test_fd_leak_multitarget(self):
+self.build()
+exe = self.getBuildArtifact("a.out")
+
+target = self.dbg.CreateTarget(exe)
+breakpoint = target.BreakpointCreateBySourceRegex(
+'Set breakpoint here', lldb.SBFileSpec("main.c", False))
+s
[Lldb-commits] [PATCH] D43096: [lit] Update how clang and other binaries are found in per-configuration directories
asmith updated this revision to Diff 133899.
Herald added a subscriber: llvm-commits.
Repository:
rL LLVM
https://reviews.llvm.org/D43096
Files:
CMakeLists.txt
lit/CMakeLists.txt
lit/lit.site.cfg.in
Index: lit/lit.site.cfg.in
===
--- lit/lit.site.cfg.in
+++ lit/lit.site.cfg.in
@@ -6,8 +6,8 @@
config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
config.lldb_obj_root = "@LLDB_BINARY_DIR@"
-config.lldb_libs_dir = "@LLVM_LIBRARY_OUTPUT_INTDIR@"
-config.lldb_tools_dir = "@LLVM_RUNTIME_OUTPUT_INTDIR@"
+config.lldb_libs_dir = "@LLDB_LIBS_DIR@"
+config.lldb_tools_dir = "@LLDB_TOOLS_DIR@"
config.target_triple = "@TARGET_TRIPLE@"
config.python_executable = "@PYTHON_EXECUTABLE@"
config.cc = "@LLDB_TEST_C_COMPILER@"
@@ -19,6 +19,10 @@
try:
config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
+config.lldb_libs_dir = config.lldb_libs_dir % lit_config.params
+config.lldb_tools_dir = config.lldb_tools_dir % lit_config.params
+config.cc = config.cc % lit_config.params
+config.cxx = config.cxx % lit_config.params
except KeyError as e:
key, = e.args
lit_config.fatal("unable to find %r parameter, use '--param=%s=VALUE'" %
(key,key))
Index: lit/CMakeLists.txt
===
--- lit/CMakeLists.txt
+++ lit/CMakeLists.txt
@@ -1,10 +1,23 @@
-set(LLVM_SOURCE_DIR "${LLVM_MAIN_SRC_DIR}")
-set(LLVM_BINARY_DIR "${LLVM_BINARY_DIR}")
-set(LLVM_BUILD_MODE "%(build_mode)s")
-set(LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}/%(build_config)s")
-set(LLVM_LIBS_DIR
"${LLVM_BINARY_DIR}/lib${LLVM_LIBDIR_SUFFIX}/%(build_config)s")
-set(CLANG_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/..")
-set(CLANG_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}/..")
+# Test runner infrastructure for LLDB. This configures the LLDB test trees
+# for use by Lit, and delegates to LLVM's lit test handlers.
+
+if (CMAKE_CFG_INTDIR STREQUAL ".")
+ set(LLVM_BUILD_MODE ".")
+else ()
+ set(LLVM_BUILD_MODE "%(build_mode)s")
+endif ()
+
+if (NOT LLDB_TEST_USE_CUSTOM_C_COMPILER)
+ string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_C_COMPILER
${LLDB_TEST_C_COMPILER})
+endif ()
+
+if (NOT LLDB_TEST_USE_CUSTOM_CXX_COMPILER)
+ string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TEST_CXX_COMPILER
${LLDB_TEST_CXX_COMPILER})
+endif ()
+
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_LIBS_DIR
${LLVM_LIBRARY_OUTPUT_INTDIR})
+string(REPLACE ${CMAKE_CFG_INTDIR} ${LLVM_BUILD_MODE} LLDB_TOOLS_DIR
${LLVM_RUNTIME_OUTPUT_INTDIR})
+
if(BUILD_SHARED_LIBS)
set(ENABLE_SHARED 1)
else()
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -61,12 +61,18 @@
option(LLDB_INCLUDE_TESTS "Generate build targets for the LLDB unit tests."
${LLVM_INCLUDE_TESTS})
+option(LLDB_TEST_USE_CUSTOM_C_COMPILER "Use the C compiler provided via
LLDB_TEST_C_COMPILER for building test inferiors (instead of the just-built
compiler). Defaults to OFF." OFF)
+option(LLDB_TEST_USE_CUSTOM_CXX_COMPILER "Use the C++ compiler provided via
LLDB_TEST_CXX_COMPILER for building test inferiors (instead of the just-built
compiler). Defaults to OFF." OFF)
if(LLDB_INCLUDE_TESTS)
- if (TARGET clang)
+ if (NOT LLDB_TEST_USE_CUSTOM_C_COMPILER AND TARGET clang)
set(LLDB_DEFAULT_TEST_C_COMPILER
"${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/clang${CMAKE_EXECUTABLE_SUFFIX}")
-set(LLDB_DEFAULT_TEST_CXX_COMPILER
"${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/clang++${CMAKE_EXECUTABLE_SUFFIX}")
else()
set(LLDB_DEFAULT_TEST_C_COMPILER "")
+ endif()
+
+ if (NOT LLDB_TEST_USE_CUSTOM_CXX_COMPILER AND TARGET clang)
+set(LLDB_DEFAULT_TEST_CXX_COMPILER
"${LLVM_BINARY_DIR}/${CMAKE_CFG_INTDIR}/bin/clang++${CMAKE_EXECUTABLE_SUFFIX}")
+ else()
set(LLDB_DEFAULT_TEST_CXX_COMPILER "")
endif()
Index: lit/lit.site.cfg.in
===
--- lit/lit.site.cfg.in
+++ lit/lit.site.cfg.in
@@ -6,8 +6,8 @@
config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
config.lldb_obj_root = "@LLDB_BINARY_DIR@"
-config.lldb_libs_dir = "@LLVM_LIBRARY_OUTPUT_INTDIR@"
-config.lldb_tools_dir = "@LLVM_RUNTIME_OUTPUT_INTDIR@"
+config.lldb_libs_dir = "@LLDB_LIBS_DIR@"
+config.lldb_tools_dir = "@LLDB_TOOLS_DIR@"
config.target_triple = "@TARGET_TRIPLE@"
config.python_executable = "@PYTHON_EXECUTABLE@"
config.cc = "@LLDB_TEST_C_COMPILER@"
@@ -19,6 +19,10 @@
try:
config.llvm_tools_dir = config.llvm_tools_dir % lit_config.params
config.llvm_libs_dir = config.llvm_libs_dir % lit_config.params
+config.lldb_libs_dir = config.lldb_libs_dir % lit_config.params
+config.lldb_tools_dir = config.lldb_tools_dir % lit_config.params
+config.cc = config.cc
[Lldb-commits] [PATCH] D43202: Remove dead code for handling DWARF pubnames
This revision was automatically updated to reflect the committed changes.
Closed by commit rL324925: Remove dead code for handling DWARF pubnames
(authored by amccarth, committed by ).
Herald added a subscriber: llvm-commits.
Changed prior to commit:
https://reviews.llvm.org/D43202?vs=133903&id=133906#toc
Repository:
rL LLVM
https://reviews.llvm.org/D43202
Files:
lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -65,7 +65,6 @@
#include "DWARFDebugInfo.h"
#include "DWARFDebugLine.h"
#include "DWARFDebugMacro.h"
-#include "DWARFDebugPubnames.h"
#include "DWARFDebugRanges.h"
#include "DWARFDeclContext.h"
#include "DWARFFormValue.h"
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
@@ -17,8 +17,6 @@
DWARFDebugMacro.cpp
DWARFDebugMacinfo.cpp
DWARFDebugMacinfoEntry.cpp
- DWARFDebugPubnames.cpp
- DWARFDebugPubnamesSet.cpp
DWARFDebugRanges.cpp
DWARFDeclContext.cpp
DWARFDefines.cpp
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
@@ -54,7 +54,6 @@
class DWARFDebugInfo;
class DWARFDebugInfoEntry;
class DWARFDebugLine;
-class DWARFDebugPubnames;
class DWARFDebugRanges;
class DWARFDeclContext;
class DWARFDIECollection;
Index: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.cpp
===
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.cpp
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.cpp
@@ -1,146 +0,0 @@
-//===-- DWARFDebugPubnamesSet.cpp ---*- C++ -*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-#include "DWARFDebugPubnamesSet.h"
-
-#include "lldb/Utility/Log.h"
-#include "lldb/Utility/RegularExpression.h"
-
-#include "SymbolFileDWARF.h"
-
-using namespace lldb_private;
-
-DWARFDebugPubnamesSet::DWARFDebugPubnamesSet()
-: m_offset(DW_INVALID_OFFSET), m_header(), m_descriptors(),
- m_name_to_descriptor_index() {}
-
-DWARFDebugPubnamesSet::DWARFDebugPubnamesSet(dw_offset_t debug_aranges_offset,
- dw_offset_t cu_die_offset,
- dw_offset_t cu_die_length)
-: m_offset(debug_aranges_offset), m_header(), m_descriptors(),
- m_name_to_descriptor_index() {
- m_header.length =
- 10; // set the length to only include the header right for now
- m_header.version = 2;// The DWARF version number
- m_header.die_offset = cu_die_offset; // compile unit .debug_info offset
- m_header.die_length = cu_die_length; // compile unit .debug_info length
-}
-
-void DWARFDebugPubnamesSet::AddDescriptor(dw_offset_t cu_rel_offset,
- const char *name) {
- if (name && name[0]) {
-// Adjust our header length
-m_header.length += strlen(name) + 1 + sizeof(dw_offset_t);
-Descriptor pubnameDesc(cu_rel_offset, name);
-m_descriptors.push_back(pubnameDesc);
- }
-}
-
-void DWARFDebugPubnamesSet::Clear() {
- m_offset = DW_INVALID_OFFSET;
- m_header.length = 10;
- m_header.version = 2;
- m_header.die_offset = DW_INVALID_OFFSET;
- m_header.die_length = 0;
- m_descriptors.clear();
-}
-
-//--
-// InitNameIndexes
-//--
-void DWARFDebugPubnamesSet::InitNameIndexes() const {
- // Create the name index vector to be able to quickly search by name
- const size_t count = m_descriptors.size();
- for (uint32_t idx = 0; idx < count; ++idx) {
-const char *name = m_descriptors[idx].name.c_str();
-if (name && name[0])
- m_name_to_descript
[Lldb-commits] [lldb] r324925 - Remove dead code for handling DWARF pubnames
Author: amccarth
Date: Mon Feb 12 11:19:04 2018
New Revision: 324925
URL: http://llvm.org/viewvc/llvm-project?rev=324925&view=rev
Log:
Remove dead code for handling DWARF pubnames
Summary:
LLDB doesn't use this code, the code has no tests, and the code does suspicious
things like hashing pointers to strings instead of the strings themselves.
Subscribers: sanjoy, mgorny, JDevlieghere
Differential Revision: https://reviews.llvm.org/D43202
Removed:
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.h
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnamesSet.h
Modified:
lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
lldb/trunk/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.h
Modified: lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt?rev=324925&r1=324924&r2=324925&view=diff
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/CMakeLists.txt Mon Feb 12
11:19:04 2018
@@ -17,8 +17,6 @@ add_lldb_library(lldbPluginSymbolFileDWA
DWARFDebugMacro.cpp
DWARFDebugMacinfo.cpp
DWARFDebugMacinfoEntry.cpp
- DWARFDebugPubnames.cpp
- DWARFDebugPubnamesSet.cpp
DWARFDebugRanges.cpp
DWARFDeclContext.cpp
DWARFDefines.cpp
Removed: lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp?rev=324924&view=auto
==
--- lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp (original)
+++ lldb/trunk/source/Plugins/SymbolFile/DWARF/DWARFDebugPubnames.cpp (removed)
@@ -1,255 +0,0 @@
-//===-- DWARFDebugPubnames.cpp --*- C++
-*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-#include "DWARFDebugPubnames.h"
-
-#include "lldb/Utility/Stream.h"
-#include "lldb/Utility/Timer.h"
-
-#include "DWARFCompileUnit.h"
-#include "DWARFDIECollection.h"
-#include "DWARFDebugInfo.h"
-#include "DWARFFormValue.h"
-#include "LogChannelDWARF.h"
-#include "SymbolFileDWARF.h"
-
-using namespace lldb;
-using namespace lldb_private;
-
-DWARFDebugPubnames::DWARFDebugPubnames() : m_sets() {}
-
-bool DWARFDebugPubnames::Extract(const DWARFDataExtractor &data) {
- static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
- Timer scoped_timer(func_cat,
- "DWARFDebugPubnames::Extract (byte_size = %" PRIu64 ")",
- (uint64_t)data.GetByteSize());
- Log *log(LogChannelDWARF::GetLogIfAll(DWARF_LOG_DEBUG_PUBNAMES));
- if (log)
-log->Printf("DWARFDebugPubnames::Extract (byte_size = %" PRIu64 ")",
-(uint64_t)data.GetByteSize());
-
- if (data.ValidOffset(0)) {
-lldb::offset_t offset = 0;
-
-DWARFDebugPubnamesSet set;
-while (data.ValidOffset(offset)) {
- if (set.Extract(data, &offset)) {
-m_sets.push_back(set);
-offset = set.GetOffsetOfNextEntry();
- } else
-break;
-}
-if (log)
- Dump(log);
-return true;
- }
- return false;
-}
-
-bool DWARFDebugPubnames::GeneratePubnames(SymbolFileDWARF *dwarf2Data) {
- static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
- Timer scoped_timer(func_cat,
- "DWARFDebugPubnames::GeneratePubnames (data = %p)",
- static_cast(dwarf2Data));
-
- Log *log(LogChannelDWARF::GetLogIfAll(DWARF_LOG_DEBUG_PUBNAMES));
- if (log)
-log->Printf("DWARFDebugPubnames::GeneratePubnames (data = %p)",
-static_cast(dwarf2Data));
-
- m_sets.clear();
- DWARFDebugInfo *debug_info = dwarf2Data->DebugInfo();
- if (debug_info) {
-uint32_t cu_idx = 0;
-const uint32_t num_compile_units = dwarf2Data->GetNumCompileUnits();
-for (cu_idx = 0; cu_idx < num_compile_units; ++cu_idx) {
-
- DWARFCompileUnit *cu = debug_info->GetCompileUnitAtIndex(cu_idx);
-
- DWARFFormValue::FixedFormSizes fixed_form_sizes =
- DWARFFormValue::GetFixedFormSizesForAddressSize(
- cu->GetAddressByteSize(), cu->IsDWARF64());
-
- bool clear_dies = cu->ExtractDIEsIfNeeded(false) > 1;
-
- DWARFDIECollection dies;
- const size_t die_count = cu->AppendDIEsWithTag(DW_TAG_subprogram, dies) +
- cu->AppendDIEsWithTag(DW_TAG_variable, dies);
-
- dw_offs
Re: [Lldb-commits] [PATCH] D43099: Make LLDB's clang module cache path customizable
Thanks for laying this out. I don't think any of us have a brief for getopt, it was the tool at hand. Getting some fuzzy match suggestions would be nice. Your comment about getopts reminds me, a more fundamental problem with lldb's command interpreter is that the CommandObject is stateful. So you can't actually call a command and then in the process of handling that command call back into the same command without destroying the options settings from the older invocation. We actually do this (e.g. anything that hits a breakpoint can call arbitrary lldb commands). We just luck out because most commands grab their arguments, decide what to do with them, then do the work. So the second invocation overwrites options that aren't going to get reused. But working by luck is never good... It would be much better to separate the Command definition part of the CommandObject from the Invocation part, so that one command definition could server multiple invocations. If somebody has ambition to dig into lldb's command interpreter, I'd propose this task over replacing something that works with something else that works more nicely. Jim > On Feb 12, 2018, at 2:31 AM, Pavel Labath via Phabricator > wrote: > > labath added a comment. > > There are several components in the "command line parsing" > > 1. argparse: parsing a single string into the individual words (processing > quotes, backslashes, etc.) > 2. resolving the "command" part of the command line (the "frame variable" > part of "frame variable --raw-output FOO") > 3. resolving the arguments of a command (the "--raw-output FOO" part) > > These parts compose quite nicely, and can be individually replaced. I'll > briefly speak about each one : > > (1) is very specific to our interactive use case (for command line utilities, > the shell/os does the parsing for us). There also isn't anything nearly > similar in llvm (afaik). > (2) is also quite specific to how lldb commands are structured, and there > also isn't a suitable llvm replacement. This is the level at which the > "command aliases" are resolved. > (3) is a fairly generic piece of functionality -- we even implement it by > delegating to getopt (in a scarily un-thread-safe way). For this there are > *two* competing implementations in llvm: `llvm::cl` and `llvm::opt`. Of these > the first one is not suitable for our use case right now as it relies on > global variables. Making it work probably would be a bit or work. However, > using the second one should be fairly easy, and it should be generic-enough > (it's the thing that handles crazy gcc command lines). > > The reason I'm spelling it out this way is because I think you were mostly > talking about (3), but some of the difficulties Jim pointed out (command > aliases) just aren't relevant there. I don't think llvm::opt handles > "shortest match" options yet, but that should be fairly easy to add. On the > flip side, the library has recently gained argument suggestion capabilities > (`error: unknown argument '-gllbb', did you mean '-glldb'`), so we would get > that for free. Making sure tab completion works there would require a bit of > thought, but I think this should not interfere with this library too much > (after all, we use getopt now, and it does not support tab completion either). > > > Repository: > rL LLVM > > https://reviews.llvm.org/D43099 > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r324930 - Remove the pubnames support from the Xcode project.
Author: jingham
Date: Mon Feb 12 12:25:37 2018
New Revision: 324930
URL: http://llvm.org/viewvc/llvm-project?rev=324930&view=rev
Log:
Remove the pubnames support from the Xcode project.
Modified:
lldb/trunk/lldb.xcodeproj/project.pbxproj
Modified: lldb/trunk/lldb.xcodeproj/project.pbxproj
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/lldb.xcodeproj/project.pbxproj?rev=324930&r1=324929&r2=324930&view=diff
==
--- lldb/trunk/lldb.xcodeproj/project.pbxproj (original)
+++ lldb/trunk/lldb.xcodeproj/project.pbxproj Mon Feb 12 12:25:37 2018
@@ -488,8 +488,6 @@
268900BE13353E5F00698AC0 /* DWARFDebugLine.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 260C89C310F57C5600BB2B04 /* DWARFDebugLine.cpp
*/; };
268900BF13353E5F00698AC0 /* DWARFDebugMacinfo.cpp in Sources */
= {isa = PBXBuildFile; fileRef = 260C89C510F57C5600BB2B04 /*
DWARFDebugMacinfo.cpp */; };
268900C013353E5F00698AC0 /* DWARFDebugMacinfoEntry.cpp in
Sources */ = {isa = PBXBuildFile; fileRef = 260C89C710F57C5600BB2B04 /*
DWARFDebugMacinfoEntry.cpp */; };
- 268900C113353E5F00698AC0 /* DWARFDebugPubnames.cpp in Sources
*/ = {isa = PBXBuildFile; fileRef = 260C89C910F57C5600BB2B04 /*
DWARFDebugPubnames.cpp */; };
- 268900C213353E5F00698AC0 /* DWARFDebugPubnamesSet.cpp in
Sources */ = {isa = PBXBuildFile; fileRef = 260C89CB10F57C5600BB2B04 /*
DWARFDebugPubnamesSet.cpp */; };
268900C313353E5F00698AC0 /* DWARFDebugRanges.cpp in Sources */
= {isa = PBXBuildFile; fileRef = 260C89CD10F57C5600BB2B04 /*
DWARFDebugRanges.cpp */; };
268900C413353E5F00698AC0 /* DWARFDefines.cpp in Sources */ =
{isa = PBXBuildFile; fileRef = 260C89CF10F57C5600BB2B04 /* DWARFDefines.cpp */;
};
268900C513353E5F00698AC0 /* DWARFDIECollection.cpp in Sources
*/ = {isa = PBXBuildFile; fileRef = 260C89D110F57C5600BB2B04 /*
DWARFDIECollection.cpp */; };
@@ -1491,10 +1489,6 @@
260C89C610F57C5600BB2B04 /* DWARFDebugMacinfo.h */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path =
DWARFDebugMacinfo.h; sourceTree = ""; };
260C89C710F57C5600BB2B04 /* DWARFDebugMacinfoEntry.cpp */ =
{isa = PBXFileReference; fileEncoding = 4; lastKnownFileType =
sourcecode.cpp.cpp; path = DWARFDebugMacinfoEntry.cpp; sourceTree = "";
};
260C89C810F57C5600BB2B04 /* DWARFDebugMacinfoEntry.h */ = {isa
= PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path
= DWARFDebugMacinfoEntry.h; sourceTree = ""; };
- 260C89C910F57C5600BB2B04 /* DWARFDebugPubnames.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
path = DWARFDebugPubnames.cpp; sourceTree = ""; };
- 260C89CA10F57C5600BB2B04 /* DWARFDebugPubnames.h */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path =
DWARFDebugPubnames.h; sourceTree = ""; };
- 260C89CB10F57C5600BB2B04 /* DWARFDebugPubnamesSet.cpp */ = {isa
= PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
path = DWARFDebugPubnamesSet.cpp; sourceTree = ""; };
- 260C89CC10F57C5600BB2B04 /* DWARFDebugPubnamesSet.h */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path =
DWARFDebugPubnamesSet.h; sourceTree = ""; };
260C89CD10F57C5600BB2B04 /* DWARFDebugRanges.cpp */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.cpp.cpp;
path = DWARFDebugRanges.cpp; sourceTree = ""; };
260C89CE10F57C5600BB2B04 /* DWARFDebugRanges.h */ = {isa =
PBXFileReference; fileEncoding = 4; lastKnownFileType = sourcecode.c.h; path =
DWARFDebugRanges.h; sourceTree = ""; };
260C89CF10F57C5600BB2B04 /* DWARFDefines.cpp */ = {isa =
PBXFileReference; explicitFileType = sourcecode.cpp.cpp; fileEncoding = 4; path
= DWARFDefines.cpp; sourceTree = ""; };
@@ -3907,10 +3901,6 @@
260C89C810F57C5600BB2B04 /*
DWARFDebugMacinfoEntry.h */,
23E77CD61C20F29F007192AD /* DWARFDebugMacro.cpp
*/,
23E77CD71C20F29F007192AD /* DWARFDebugMacro.h
*/,
- 260C89C910F57C5600BB2B04 /*
DWARFDebugPubnames.cpp */,
- 260C89CA10F57C5600BB2B04 /*
DWARFDebugPubnames.h */,
- 260C89CB10F57C5600BB2B04 /*
DWARFDebugPubnamesSet.cpp */,
- 260C89CC10F57C5600BB2B04 /*
DWARFDebugPubnamesSet.h */,
260C89CD10F57C5600BB2B04 /*
DWARFDebugRanges.cpp */,
260C89CE10F57C5600BB2B04 /* DWARFDebugRanges.h
*/,
26B1EFAC154638AF00E2DAC7 /*
DWARFDeclContext.cpp */,
@@ -7702,8
[Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion
jasonmolenda added a comment. No, the unwind unittests that exist today should stay written as unit tests. These are testing the conversion of native unwind formats -- for instance, eh_frame, compact unwind, or instruction analysis -- into the intermediate UnwindPlan representation in lldb. They are runtime invariant, unit tests are the best approach to these. If there were anything to say about these, it would be that we need more testing here - armv7 (AArch32) into UnwindPlan is not tested. eh_frame and compact_unwind into UnwindPlan is not tested. The part of unwind that is difficult to test is the runtime unwind behavior, and FileCheck style tests don't make that easier in any way. We need a live register context, stack memory, symbols and UnwindPlans to test this correctly -- we either need a full ProcessMock with SymbolVendorMock etc, or we need corefiles, or we need tests with hand-written assembly code. I'm leaning towards starting to write C test cases with hand written assembly routines that set up their stacks in unusual ways to test the unwinder, I've written unwind testsuites in the past in this way and it works well but it does mean that you need to be on the arch (and possibly even the OS) that the test is written in -- bots will show the failures for everyone after a commit goes in, at least. But these will be written as SB API tests. https://reviews.llvm.org/D43048 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43202: Remove dead code for handling DWARF pubnames
jingham added a comment. I also had to remove them from the Xcode project. With that done everything looks good. Repository: rL LLVM https://reviews.llvm.org/D43202 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion
zturner added a comment. In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote: > No, the unwind unittests that exist today should stay written as unit tests. > These are testing the conversion of native unwind formats -- for instance, > eh_frame, compact unwind, or instruction analysis -- into the intermediate > UnwindPlan representation in lldb. They are runtime invariant, unit tests > are the best approach to these. If there were anything to say about these, > it would be that we need more testing here - armv7 (AArch32) into UnwindPlan > is not tested. eh_frame and compact_unwind into UnwindPlan is not tested. That's exactly the type of thing that FileCheck tests work best for. I'm not sure why you're saying that unittests are better than FileCheck tests for this scenario. > The part of unwind that is difficult to test is the runtime unwind behavior, > and FileCheck style tests don't make that easier in any way. We need a live > register context, stack memory, symbols and UnwindPlans to test this > correctly -- we either need a full ProcessMock with SymbolVendorMock etc, or > we need corefiles, or we need tests with hand-written assembly code. I don't think we'd necessarily need a live register context or stack memory. A mock register context and stack memory should be sufficient, with an emulator that understands only a handful of instructions. https://reviews.llvm.org/D43048 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion
> On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator > wrote: > > zturner added a comment. > > In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote: > >> No, the unwind unittests that exist today should stay written as unit tests. >> These are testing the conversion of native unwind formats -- for instance, >> eh_frame, compact unwind, or instruction analysis -- into the intermediate >> UnwindPlan representation in lldb. They are runtime invariant, unit tests >> are the best approach to these. If there were anything to say about these, >> it would be that we need more testing here - armv7 (AArch32) into UnwindPlan >> is not tested. eh_frame and compact_unwind into UnwindPlan is not tested. > > > That's exactly the type of thing that FileCheck tests work best for. I'm not > sure why you're saying that unittests are better than FileCheck tests for > this scenario. I'm saying that the unittests here are entirely appropriate, and that rewriting existing tests in FileCheck style doesn't make any sense to me. If people want to write new tests using that style, that's fine I guess, but I wrote these tests for a part of lldb that I maintain and I'd prefer to keep them as-is. > >> The part of unwind that is difficult to test is the runtime unwind behavior, >> and FileCheck style tests don't make that easier in any way. We need a live >> register context, stack memory, symbols and UnwindPlans to test this >> correctly -- we either need a full ProcessMock with SymbolVendorMock etc, or >> we need corefiles, or we need tests with hand-written assembly code. > > I don't think we'd necessarily need a live register context or stack memory. > A mock register context and stack memory should be sufficient, with an > emulator that understands only a handful of instructions. That's ... exactly what I said? That we need to mock up memory and registers and symbols, or have a corefile and binary, or have hand written assembly routines that set up a particular stack and an SB API test that tries to backtrace out of it with a live process. After the inferior process state has been constructed/reconstituted, is the unwinder capable of walking the stack or finding spilled registers by following the correct UnwindPlans. This is right in the wheelhouse of SB API testing. J ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion
On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda wrote: > > > > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator < > revi...@reviews.llvm.org> wrote: > > > > zturner added a comment. > > > > In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote: > > > > I don't think we'd necessarily need a live register context or stack > memory. A mock register context and stack memory should be sufficient, > with an emulator that understands only a handful of instructions. > > > That's ... exactly what I said? That we need to mock up memory and > registers and symbols, or have a corefile and binary, or have hand written > assembly routines that set up a particular stack and an SB API test that > tries to backtrace out of it with a live process. After the inferior > process state has been constructed/reconstituted, is the unwinder capable > of walking the stack or finding spilled registers by following the correct > UnwindPlans. This is right in the wheelhouse of SB API testing. > I'm saying we shouldn't need a live process (and in fact we can test it better if we don't rely on a live process, since we can write tests that run anywhere). ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion
> On Feb 12, 2018, at 12:59 PM, Zachary Turner wrote: > > > > On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda wrote: >> >> >> > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator >> > wrote: >> > >> > zturner added a comment. >> > >> > In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote: >> > >> > I don't think we'd necessarily need a live register context or stack >> > memory. A mock register context and stack memory should be sufficient, >> > with an emulator that understands only a handful of instructions. >> >> >> That's ... exactly what I said? That we need to mock up memory and >> registers and symbols, or have a corefile and binary, or have hand written >> assembly routines that set up a particular stack and an SB API test that >> tries to backtrace out of it with a live process. After the inferior >> process state has been constructed/reconstituted, is the unwinder capable of >> walking the stack or finding spilled registers by following the correct >> UnwindPlans. This is right in the wheelhouse of SB API testing. > > I'm saying we shouldn't need a live process (and in fact we can test it > better if we don't rely on a live process, since we can write tests that run > anywhere). Yes, as we've all agreed many times for years, a ProcessMock style Process plugin which can fake up state from a yaml file would be a great addition -- and for the unwind tests, we need a way to provide symbolic information and possibly even eh_frame information from the "binaries", and maybe even a way to construct the yaml representation from an actual debug session. No one is disagreeing with this. But the fact that no one has had time to develop this plugin means that if I want to write an unwind test today, I either need to allocate time to write the above infrastructure first, or write the test given the tools we have available to us today. An unwind test that only runs on x86_64, or even only runs on x86_64 Darwin, is not ideal, but it is much better than no test at all especially in the world of buildbots that can flag a problem with a change right away. J ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion
Sure I don’t think anyone disputes that, but I thought we were discussing an ideal end state On Mon, Feb 12, 2018 at 1:31 PM Jason Molenda wrote: > > > > On Feb 12, 2018, at 12:59 PM, Zachary Turner wrote: > > > > > > > > On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda > wrote: > >> > >> > >> > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator < > revi...@reviews.llvm.org> wrote: > >> > > >> > zturner added a comment. > >> > > >> > In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote: > >> > > >> > I don't think we'd necessarily need a live register context or stack > memory. A mock register context and stack memory should be sufficient, > with an emulator that understands only a handful of instructions. > >> > >> > >> That's ... exactly what I said? That we need to mock up memory and > registers and symbols, or have a corefile and binary, or have hand written > assembly routines that set up a particular stack and an SB API test that > tries to backtrace out of it with a live process. After the inferior > process state has been constructed/reconstituted, is the unwinder capable > of walking the stack or finding spilled registers by following the correct > UnwindPlans. This is right in the wheelhouse of SB API testing. > > > > I'm saying we shouldn't need a live process (and in fact we can test it > better if we don't rely on a live process, since we can write tests that > run anywhere). > > > Yes, as we've all agreed many times for years, a ProcessMock style Process > plugin which can fake up state from a yaml file would be a great addition > -- and for the unwind tests, we need a way to provide symbolic information > and possibly even eh_frame information from the "binaries", and maybe even > a way to construct the yaml representation from an actual debug session. > No one is disagreeing with this. > > But the fact that no one has had time to develop this plugin means that if > I want to write an unwind test today, I either need to allocate time to > write the above infrastructure first, or write the test given the tools we > have available to us today. > > An unwind test that only runs on x86_64, or even only runs on x86_64 > Darwin, is not ideal, but it is much better than no test at all especially > in the world of buildbots that can flag a problem with a change right away. > > J ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D43048: [lldb-test/WIP] Allow a way to test autocompletion
Ah, no. Pavel suggested that the unwind plan unittests should be turned into FileCheck tests, and then Davide suggested that he'd heard unwind testing is difficult (he was conflating the unwind sources -> UnwindPlan IR conversions and the runtime use of UnwindPlans to walk the stack & find spilled registers), so he thought that this FileCheck could help there. I was clarifying that (1) I don't want the existing tests I wrote changed out of unittests, and (2) FileCheck does not help the actually difficult part of testing the unwinder at all. I provided an example of why this was difficult, outlining the possible approaches, and saying that if you were doing it today, you would need to do it with hand written assembly, and you suggested that a process mock style approach would be awesome, which was one of the approaches I described in my original email. > On Feb 12, 2018, at 2:18 PM, Zachary Turner wrote: > > Sure I don’t think anyone disputes that, but I thought we were discussing an > ideal end state > On Mon, Feb 12, 2018 at 1:31 PM Jason Molenda wrote: > > > > On Feb 12, 2018, at 12:59 PM, Zachary Turner wrote: > > > > > > > > On Mon, Feb 12, 2018 at 12:52 PM Jason Molenda wrote: > >> > >> > >> > On Feb 12, 2018, at 12:48 PM, Zachary Turner via Phabricator > >> > wrote: > >> > > >> > zturner added a comment. > >> > > >> > In https://reviews.llvm.org/D43048#1005513, @jasonmolenda wrote: > >> > > >> > I don't think we'd necessarily need a live register context or stack > >> > memory. A mock register context and stack memory should be sufficient, > >> > with an emulator that understands only a handful of instructions. > >> > >> > >> That's ... exactly what I said? That we need to mock up memory and > >> registers and symbols, or have a corefile and binary, or have hand written > >> assembly routines that set up a particular stack and an SB API test that > >> tries to backtrace out of it with a live process. After the inferior > >> process state has been constructed/reconstituted, is the unwinder capable > >> of walking the stack or finding spilled registers by following the correct > >> UnwindPlans. This is right in the wheelhouse of SB API testing. > > > > I'm saying we shouldn't need a live process (and in fact we can test it > > better if we don't rely on a live process, since we can write tests that > > run anywhere). > > > Yes, as we've all agreed many times for years, a ProcessMock style Process > plugin which can fake up state from a yaml file would be a great addition -- > and for the unwind tests, we need a way to provide symbolic information and > possibly even eh_frame information from the "binaries", and maybe even a way > to construct the yaml representation from an actual debug session. No one is > disagreeing with this. > > But the fact that no one has had time to develop this plugin means that if I > want to write an unwind test today, I either need to allocate time to write > the above infrastructure first, or write the test given the tools we have > available to us today. > > An unwind test that only runs on x86_64, or even only runs on x86_64 Darwin, > is not ideal, but it is much better than no test at all especially in the > world of buildbots that can flag a problem with a change right away. > > J ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
