summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite
Commit message (Collapse)AuthorAgeFilesLines
...
* [lldb] [Process] Add proper support for NetBSD core files with threadsMichal Gorny2019-03-0811-0/+316
| | | | | | | | | | | | | | Improve the support for processing NetBSD cores. Fix reading process identifier, thread information and associating the terminating signal with the correct thread. Includes test cases for single-threaded program receiving SIGSEGV, and two dual-threaded programs: one where thread receives the signal, and the other one when the whole process is signalled. Differential Revision: https://reviews.llvm.org/D32149 llvm-svn: 355736
* Add more logging to TestQueues.pyFrederic Riss2019-03-081-2/+4
| | | | | | | | | The last round of logging taught us that when the test fails, lldb is indeed aware of the thread it's failing to associate to a given queue. Add more logging to try to figure out why the thread and the queue do not appear related to the Queue APIs. llvm-svn: 355706
* Add ASAN llvm build directory variants toJason Molenda2019-03-081-0/+3
| | | | | | get_llvm_bin_dirs(). llvm-svn: 355661
* Fix TestPaths.py on windowsAlex Langford2019-03-071-10/+2
| | | | | | | | | | | | I committed an implementation of GetClangResourceDir on windows but forgot to update this test. I merged the tests like I intended to, but I realized that the test was actually failing. After looking into it, it appears that FileSystem::Resolve was taking the path and setting the FileSpec's Directory to "/path/to/lldb/lib/clang/" and the File to "9.0.0" which isn't what we want. So I removed the resolve line from DefaultComputeClangResourceDir. llvm-svn: 355648
* Add logging to TestQueues.pyFrederic Riss2019-03-071-0/+20
| | | | | | | In an attempt to understand why the test is still failing after r355555, add some logging. llvm-svn: 355647
* Fix TestAppleSimulatorOSType.py with Xcode 10.2Frederic Riss2019-03-071-1/+3
| | | | | | | It looks like the simctl tool shipped in Xcode10.2 changed the format of its json output. llvm-svn: 355644
* [testsuite] Recommit the TestTerminal directory.Davide Italiano2019-03-071-0/+111
| | | | | | | Turns out this is actually testing that editline doesn't screw up the terminal. llvm-svn: 355640
* [testsuite] Spring cleaning: this tests `stty`, not `lldb`.Davide Italiano2019-03-071-111/+0
| | | | llvm-svn: 355615
* [testsuite] Drop characters that can't be decoded, restoring parity with Py2.Davide Italiano2019-03-071-0/+3
| | | | | | | Tests that check the output of `memory find` may trip over unreadable characters, and in Python 3 this is an error. llvm-svn: 355612
* Relax testcase.Adrian Prantl2019-03-071-1/+1
| | | | | | | Recent versions of llvm monorepo builds build libc++abi.dylib as libc++abi.1.dylib. This accespts both variants. llvm-svn: 355571
* Remove redundant second os.path.join call [NFC]Raphael Isemann2019-03-061-2/+1
| | | | llvm-svn: 355548
* Fix core files for 32 bit architectures that are supported in ProcessELFCore.cppGreg Clayton2019-03-062-0/+29
| | | | | | | | | | Core files need to know the size of the PRSTATUS header so that we can grab the register values that follow it. The code that figure out this size was using a hard coded list of architecture cores instead of relying on 32 or 64 bit for most cores. The fix here fixes core files for 32 bit ARM. Prior to this the PRSTATUS header size was being returned as zero and the register values were being taken from the first bytes of the PRSTATUS struct (signo, etc). Differential Revision: https://reviews.llvm.org/D58985 llvm-svn: 355526
* Adding test to cover the correct import of SourceLocation pertaining to a ↵Shafik Yaghmour2019-03-063-0/+39
| | | | | | | | | | | | built-in during expression parsing Summary: This tests a fix in the ASTImpoter.cpp to ensure that we import built-in correctly, see differential: https://reviews.llvm.org/D58743 Once this change is merged this test should pass and should catch regressions in this feature. Differential Revision: https://reviews.llvm.org/D58790 llvm-svn: 355525
* [lldb] [test] Pass appropriate -L&-Wl,-rpath for libc++ on NetBSDMichal Gorny2019-03-061-0/+5
| | | | | | | | | | | | Pass appropriate -L and -Wl,-rpath flags pointing out to the LLVM library directory on NetBSD. This is necessary since clang on NetBSD requires libc++ but it is not installed as part of the system by default. For the purpose of running buildbot, we want LLDB to use just-built libc++. Differential Revision: https://reviews.llvm.org/D58630 llvm-svn: 355502
* [ExpressionParser] Test GetClangResourceDirAlex Langford2019-03-061-0/+9
| | | | | | | | | | | | | Summary: I'm doing this because I plan on implementing `ComputeClangResourceDirectory` on windows so that `GetClangResourceDir` will work. Additionally, I made test_paths make sure that the directory member of the returned FileSpec is not none. This will fail on windows since `ComputeClangResourceDirectory` isn't implemented yet. Differential Revision: https://reviews.llvm.org/D58748 llvm-svn: 355463
* [lldbsuite, windows] Skip the TestEvents tests on WindowsStella Stamenova2019-03-051-0/+3
| | | | | | These tests are flakey on Windows and recently they have started failing AND also hanging the whole suite when they fail. llvm-svn: 355443
* Revert "[lldbtest] Check against the correct name for libcxxabi (macOS)."Davide Italiano2019-03-051-1/+1
| | | | | | | This passes locally but breaks on the bots. Maybe an SDK difference. Reverting while I investigate. llvm-svn: 355415
* [lldb] Disable some of TestJITLoaderGDB.py tests on WindowsYury Delendik2019-03-051-0/+2
| | | | | | | | | | | | The test expect sample executable code be built, but fails on Windows. Review comment https://reviews.llvm.org/D57689#1418597 Tags: #lldb Differential Revision: https://reviews.llvm.org/D57689 llvm-svn: 355413
* Adds property to force enabling of GDB JIT loader for MacOSYury Delendik2019-03-054-0/+112
| | | | | | | | | | | | | | | | | Summary: Based on https://gist.github.com/thlorenz/30bf0a3f67b1d97b2945#patching-and-rebuilding The functionality was disabled at https://github.com/llvm/llvm-project/commit/521c2278abb16f0148cef1bd061cadb01ef43192 Reviewers: jingham Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D57689 llvm-svn: 355402
* [lldbtest] Check against the correct name for libcxxabi (macOS).Davide Italiano2019-03-051-1/+1
| | | | llvm-svn: 355356
* [lldb] [test] Mark failing tests XFAIL on NetBSDMichal Gorny2019-03-04130-9/+194
| | | | | | | | | | | | | | | | Add a convenience 'expectedFailureNetBSD' decorator and mark all tests currently failing on NetBSD with it. Also skip a few tests that hang the test suite. This should establish a baseline for the test suite and get us closer to enabling tests on buildbot. This will help us catch regressions while we still have a lot of work to do to get tests working. It seems that there are also some flaky tests. I am going to address them later on. Differential Revision: https://reviews.llvm.org/D58527 llvm-svn: 355320
* [lldb] [lldbtest] Fix getBuildFlags() not to use libstdc++ on NetBSDMichal Gorny2019-03-021-1/+2
| | | | | | | | | | Remove the code forcing -stdlib=libstdc++ on NetBSD in getBuildFlags() method. NetBSD uses libc++ everywhere else, and using libstdc++ here causes lang/cpp/dynamic-value to fail to build. Differential Revision: https://reviews.llvm.org/D58871 llvm-svn: 355273
* Pass arguments correctly to the objc object checker on arm64Jim Ingham2019-02-272-0/+30
| | | | | | | | | | | | | | | | | Traditionally objc had two entry points, objc_msgSend for scalar return methods, and objc_msgSend_stret for struct return convention methods. But on arm64 the second was not needed (since arm64 doesn't use an argument register for the struct return pointer) so it was removed. The code that dispatches to the objc object checker when it sees some flavor of objc_msgSend was not aware of this change so was sending the wrong arguments to the checker. <rdar://problem/48315890> Differential Revision: https://reviews.llvm.org/D58699 llvm-svn: 355026
* Remove XFAIL-Linux from two asan testsPavel Labath2019-02-272-6/+0
| | | | | | | | It turns out these tests actually succeed, if one has a clang with address sanitizer support enabled (i.e., has enabled the compiler-rt project). I guess none of the linux lldb devs have done that until now. llvm-svn: 354976
* When deserializing breakpoints some options may not be present.Jim Ingham2019-02-221-0/+6
| | | | | | | | | | | The deserializer was not handling this case. For now we just accept the absent option, and set it to the breakpoint default. This will be more important if/when I figure out how to serialize the options set on breakpont locations. <rdar://problem/48322664> llvm-svn: 354702
* [lldb] [test] Do not link -ldl on NetBSDMichal Gorny2019-02-213-2/+12
| | | | | | | | | | | | | | | | Fix the load_* using test Makefiles not to link -ldl on NetBSD. There is no such a library on NetBSD, and dlopen() is available without a library. Quoting the manpage: (These functions are not in a library. They are included in every dynamically linked program automatically.) To resolve this portably, introduce a new USE_LIBDL option. If it set to 1, Makefile.rules automatically appends -ldl on platforms needing it. Differential Revision: https://reviews.llvm.org/D58517 llvm-svn: 354617
* testsuite: Fix TestCompDirSymLink and TestSourceManager on Linux with ↵Jan Kratochvil2019-02-212-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | symlinked build dir Getting failure when building in a directory which is symlinked elsewhere: Failing Tests (1): lldb-Suite :: functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.py lldb-Suite :: source-manager/TestSourceManager.py For TestCompDirSymLink: ------------------------------------------------------------------------------ runCmd: file .../lldb-test-build.noindex/functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.test_symlink_paths_set_procselfcwd_dwarf/CompDirSymLink output: Current executable set to '.../lldb-test-build.noindex/functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.test_symlink_paths_set_procselfcwd_dwarf/CompDirSymLink' (x86_64). runCmd: settings set plugin.symbol-file.dwarf.comp-dir-symlink-paths /proc/self/cwd output: None runCmd: breakpoint set -f ".../lldb-test-build.noindex/functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.test_symlink_paths_set_procselfcwd_dwarf/relative.cpp" -l 11 output: Breakpoint 1: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. It is because /proc/self/cwd (used above for plugin.symbol-file.dwarf.comp-dir-symlink-paths) points to an already resolved directory: (cd /tmp;mkdir real;ln -s real symlink;cd symlink;ls -l /proc/self/cwd) lrwxrwxrwx 1 jkratoch jkratoch 0 Feb 20 19:55 /proc/self/cwd -> /tmp/real/ ------------------------------------------------------------------------------ For TestSourceManager the resolving is done by 'make -C' as found by Pavel Labath. Differential Revision: https://reviews.llvm.org/D58465 llvm-svn: 354556
* Revert "[lldb-mi] Move TestMIPrompt away from pexpect()."Davide Italiano2019-02-211-0/+58
| | | | | | | I see a test failing on the macOS bots. I can't reproduce locally, so try to get the bots green before I can investigate. llvm-svn: 354540
* [lldb-mi] Move TestMIPrompt away from pexpect().Davide Italiano2019-02-201-58/+0
| | | | llvm-svn: 354506
* [lldb-mi] Remove a test that uses pexpect().Davide Italiano2019-02-201-82/+0
| | | | | | | | | | | | | | | | Summary: Its functionality is entirely covered by exec-run.test (which doesn't use pexpect) Reviewers: serge-sans-paille Subscribers: ki.stfu, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58459 llvm-svn: 354494
* [lldb] [test] Fix expected netbsd output for TestImageListMultiArchitectureMichal Gorny2019-02-201-1/+1
| | | | llvm-svn: 354483
* Move -fcxx-modules to MANDATORY_MODULE_BUILD_CFLAGS (NFC)Adrian Prantl2019-02-201-3/+4
| | | | llvm-svn: 354418
* [lldbtest] Remove some accidentally commented out code.Davide Italiano2019-02-201-2/+0
| | | | llvm-svn: 354415
* [testsuite] Fix TestUnicodeString to work with Py2 and Py3.Davide Italiano2019-02-201-2/+2
| | | | llvm-svn: 354414
* Fix vscode tests for python3Pavel Labath2019-02-191-2/+2
| | | | | | | | encode/decode the data before sending it over the socket. Since (AFAICT) the vscode protocol (unlike the gdb-remote one) is fully textual, using the utf8 codec here is appropriate. llvm-svn: 354308
* [lldbtest] Fix some code to be compatible between py2 and py3.Davide Italiano2019-02-181-18/+4
| | | | llvm-svn: 354297
* [Python3] Fix TestObjCMethods.py to work with py2 and 3.Davide Italiano2019-02-181-1/+1
| | | | llvm-svn: 354286
* Un-XFAIL TestLinuxCore for windowsPavel Labath2019-02-181-11/+0
| | | | | | | It turns out all that was needed to get this test passing was to fix the python3 incompatibility. llvm-svn: 354278
* Fix TestLinuxCore for python3Pavel Labath2019-02-181-4/+4
| | | | | | | - dictionaries don't have iteritems() - division returns floats llvm-svn: 354273
* [testsuite] Skip this test correctly also on macOS.Davide Italiano2019-02-161-3/+2
| | | | llvm-svn: 354204
* Fix TestDataFormatterLibcxxListLoop.py testRaphael Isemann2019-02-161-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The compilation of the TestDataFormatterLibcxxListLoop.py currently fails with this error: ``` functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/main.cpp:19:24: error: no member named '__value_' in 'std::__1::__list_node_base<int, void *>' assert(third_elem->__value_ == 3); ~~~~~~~~~~ ^ ``` It seems the internal structure of list has changed with the 3.8 release. This patch makes the test compile with the current libc++ and with the previous libc++. Reviewers: shafik, zturner, labath Reviewed By: labath Subscribers: christof, jdoerfert, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D58273 llvm-svn: 354202
* Temporarily disable test:Richard Smith2019-02-161-1/+4
| | | | | | | | | test/lang/cpp/class-template-parameter-pack/TestClassTemplateParameterPack.py It fails on Mac OS; apparently a VarDecl 'void *&C' is implicitly declared there, making the class template name C ambiguous. llvm-svn: 354185
* Fix the gdb-client test suite for python3Pavel Labath2019-02-151-12/+5
| | | | | | | | | | This applies the same fix that was done in r354106 to the lldb-server test: bitcasting the string to a bytes object before sending it over a socket. Since the gdb-remote protocol occasionally contains binary data, and it does not assign any particular encoding to them, this is the right thing to do here. llvm-svn: 354114
* Fix lldb-server test suite for python3Pavel Labath2019-02-156-16/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch finishes the python3-ification of the lldb-server test suite. It reverts the partial attempt in r352709 to encode/decode the string via utf8 before writing to the socket. This wasn't enough because the gdb-remote protocol can sometimes (but not very often) carry binary data, and the utf8 codec chokes on that. Instead I add utility functions to the "seven" module for performing "identity" transformations on the byte data. This basically drills back the hole in the python type system that the string/bytes distinction was supposed to plug. That is not ideal, but was the best solution of the alternatives I could come up with. The options I considered were: - make use of the type system to add type safety to the test suite: This required making a lot of changes to the test suite, since most of the strings would now become byte objects instead, and it was not even fully clear to me where to draw the line. One extreme solution would be to just use byte objects everywhere, as the protocol doesn't support non-ascii characters anyway. However, this appeared to be: a) weird, because most of the protocol actually deals with strings, but we would have to prefix everything with 'b' b) clunky, because the handling of the bytes objects is sufficiently different in PY2 and PY3 (e.g. b'a'[0] is a string in PY2, but an int in PY3). - using the latin1 codec (which gives an identity transformation for the first 256 code points of unicode) instead of the custom bytes_to_string functions. This almost could work, but it was still slightly different between python 2 and 3, because in PY2 in would return a unicode object, which would then cause problems when combined with regular strings if it contained 8-bit chars. With this in mind, I think the best solution for the time being is to just coerce everything into the string type as early as possible, and have things proceed indentically on both python versions. Once we stop supporting python3, we can revisit the idea of using bytes objects more prevasively. Reviewers: davide, zturner, serge-sans-paille Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D58177 llvm-svn: 354106
* Embed swig version into lldb.py in a different wayPavel Labath2019-02-151-0/+28
| | | | | | | | | | | | | | | | | | | | | | | Summary: Instead of doing string chopping on the resulting python file, get swig to output the version for us. The two things which make slightly non-trivial are: - in order to get swig to expand SWIG_VERSION for us, we cannot use %pythoncode directly, but we have to go through an intermediate macro. - SWIG_VERSION is a hex number, but it's components are supposed to be interpreted decimally, so there is a bit of integer magic needed to get the right number to come out. I've tested that this approach works both with the latest (3.0.12) and oldest (1.3.40) supported swig. Reviewers: zturner, jingham, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58172 llvm-svn: 354104
* Add explicit language specifier to test.Adrian Prantl2019-02-141-1/+1
| | | | llvm-svn: 354048
* [dotest] Fix compiler version number comparisonFrederic Riss2019-02-141-4/+5
| | | | | | | | | | | | | | | dotest's version comparision function is just a lexicographical compare of the version strings. This is obviously wrong. This patch implements the comparison using distutils.version.LooseVersion as suggested by Zachary. Reviewers: zturner, labath, serge-sans-paille Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58219 llvm-svn: 354047
* Deserialize Clang module search path from DWARFAdrian Prantl2019-02-136-0/+53
| | | | | | | | | | | | This patch properly extracts the full submodule path as well as its search paths from DWARF import decls and passes it on to the ClangModulesDeclVendor. rdar://problem/47970144 Differential Revision: https://reviews.llvm.org/D58090 llvm-svn: 353961
* Revert "Fix one more string/bytes issue in lldb-server tests"Pavel Labath2019-02-131-1/+1
| | | | | | | | | | | | | It looks like I was too hasty to submit the previous patch. It does fix some tests on python3, but it also breaks one tests with python2. This happens because the gdb-remote protocol can sometimes (but not very often) contain binary data, and attempting to parse this as utf8 characters fails. This reverts commit r353944. llvm-svn: 353945
* Fix one more string/bytes issue in lldb-server testsPavel Labath2019-02-131-1/+1
| | | | | | This fixes about a dozen tests with python3. llvm-svn: 353944
OpenPOWER on IntegriCloud