summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/tools
Commit message (Collapse)AuthorAgeFilesLines
...
* @skipIfLinux another batch of flaky lldb-mi testsPavel Labath2019-04-292-1/+3
| | | | llvm-svn: 359452
* @skipIfLinux flaky lldb-mi testsPavel Labath2019-04-213-0/+3
| | | | llvm-svn: 358848
* Make TestVSCode_step pass reliablyPavel Labath2019-04-211-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The test was failing occasionally (1% of runs or so), because of unpredictable timings between the two threads spawned by the test. If the second thread hit the breakpoint right as we were stepping out of the function on the first thread, we would still be stuck at the inner frame when the process stopped. This would cause errors like: File "/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm/tools/lldb/packages/Python/lldbsuite/test/tools/lldb-vscode/step/TestVSCode_step.py", line 67, in test_step self.assertEqual(x1, x3, 'verify step out variable') AssertionError: 2 != 1 : verify step out variable AFAICT, lldb-vscode is doing the right thing here, and the problem is that the test is not taking this sequence of events into account. Since the test is about testing stepping, it does not seem necessary to have threads in the inferior at all, so I just rewrite the test to execute the code we're supposed to step through directly on the main thread. Reviewers: clayborg, jgorbe Subscribers: jfb, lldb-commits Differential Revision: https://reviews.llvm.org/D60608 llvm-svn: 358847
* [lldb] [test] Mark three more tests flakey/xfail on NetBSDMichal Gorny2019-04-182-0/+3
| | | | llvm-svn: 358660
* [lldb-server] Update tests to use std::thread/mutex for all platformsAaron Smith2019-04-121-86/+81
| | | | | | | | | | | | | | | | | | Summary: Some cleanup suggested when bringing up lldb-server on Windows. Thanks to Hui Huang for the patch. Reviewers: zturner, labath, jfb, Hui Reviewed By: labath Subscribers: clayborg, dexonsmith, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60496 llvm-svn: 358265
* TestVCCode_step: replace assertTrue with more specific assertionsPavel Labath2019-04-051-10/+10
| | | | | | | | | When this test fails (flakes) all we get is an error message like "False is not True". This replaces patterns like assertTrue(a == b) with assertEqual(a, b), so we get a better error message (and hopefully a hint as to why the test is flaky). llvm-svn: 357747
* Re-enable most lldb-vscode tests on Linux.Jorge Gorbe Moya2019-04-034-20/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: After https://reviews.llvm.org/D59828 and https://reviews.llvm.org/D59849, I believe the problems with these tests hanging have been solved. I tried enabling all of them on my machine, and got two failures: - One of them was spawning a child process that lives for 5 seconds, waited for 5 seconds to attach to the child, and failed because the child wasn't there. - The other one was a legit failure because shell expansion of arguments doesn't work on Linux. This tests enables all lldb-vscode tests on Linux except for "launch process with shell expansion of args" (which doesn't work), and fixes the other broken test by reducing the time it waits before attaching to its child process. Reviewers: zturner, clayborg Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60153 llvm-svn: 357633
* Simplify TestGdbRemoteRegisterStatePavel Labath2019-04-021-9/+0
| | | | | | | | While reviewing D56233 it became clear to me that this test can be simplified. There's no need for a start-stop cycle in the inferior -- we can start fiddling with its registers as soon as it is launched. llvm-svn: 357451
* [lldb-vscode] Add logic to handle EOF when reading from lldb-vscode stdout.Jorge Gorbe Moya2019-04-011-31/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change prevents the lldb-vscode test harness from hanging up waiting for new messages when the lldb-vscode subprocess crashes. Now, when an EOF from the subprocess pipe is detected we enqueue a `None` packet in the received packets list. Then, during the message processing loop, we can use this `None` packet to tell apart the case where lldb-vscode has terminated unexpectedly from the normal situation where no pending messages means blocking and waiting for more data. I believe this should be enough to fix the issues with these tests hanging on multiple platforms. Once this lands, I'll prepare and test a separate change removing the @skipIfLinux annotations. Reviewers: clayborg, zturner Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D59849 llvm-svn: 357426
* Skip TestVSCode_setFunctionBreakpoints on linuxPavel Labath2019-03-181-0/+1
| | | | | | Test hangs under heavy load. llvm-svn: 356379
* [Python] Fix another batch of python 2/python 3 portability issues.Davide Italiano2019-03-131-2/+7
| | | | llvm-svn: 355998
* [lldb-mi] Make this test more reliable. NFC.Davide Italiano2019-03-121-0/+6
| | | | | | Except that it will probably stop failing on and off on my machine. llvm-svn: 355968
* [lldb] [test] Mark a few tests flakey on NetBSDMichal Gorny2019-03-111-0/+1
| | | | llvm-svn: 355830
* 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
* [lldb] [test] Mark failing tests XFAIL on NetBSDMichal Gorny2019-03-048-0/+17
| | | | | | | | | | | | | | | | 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
* 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
* 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
* Fix lldb-server test suite for python3Pavel Labath2019-02-155-16/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* [Py3/TestAppleOSSimulator] Another byte<->str interoperability issue.Davide Italiano2019-02-051-1/+1
| | | | llvm-svn: 353226
* [testsuite] Fix TestAppleSimulator so that it works with Python 3.Davide Italiano2019-01-311-2/+2
| | | | llvm-svn: 352710
* [Python] Fix gdb-remote and lldb-server utilities to work with Py3.Davide Italiano2019-01-312-5/+5
| | | | llvm-svn: 352709
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1914-56/+42
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* symbols.enable-external-lookup=false on all hosts (not just OSX)Jan Kratochvil2019-01-033-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is already in use: lit/lit-lldb-init: settings set symbols.enable-external-lookup false packages/Python/lldbsuite/test/lldbtest.py: self.runCmd('settings set symbols.enable-external-lookup false') But those are not in effect during MI part of the testsuite. Another problem is that symbols.enable-external-lookup (read by GetEnableExternalLookup) has been currently read only by LocateMacOSXFilesUsingDebugSymbols and therefore it had no effect on Linux. On Red Hat platforms (Fedoras, RHEL-7) there is DWZ in use and so MiSyntaxTestCase-test_lldbmi_output_grammar FAILs due to: AssertionError: error: inconsistent pattern ''^.+?\n'' for state 0x5f (matched string: warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21 It is the only testcase with this error. It happens due to: (lldb) target create "/lib64/libstdc++.so.6" Current executable set to '/lib64/libstdc++.so.6' (x86_64). (lldb) b main warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21 Breakpoint 1: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. which happens only with gcc-base-debuginfo rpm installed (similarly for other packages). It should also speed up the testsuite as it no longer needs to read /usr/lib/debug symbols which have no effect (and should not have any effect) on the testsuite results. Differential Revision: https://reviews.llvm.org/D55859 llvm-svn: 350368
* refactor testsuite spawnLldbMi args->exe+argsJan Kratochvil2018-12-193-11/+14
| | | | | | | | | | | | | | | | | Currently spawnLldbMi accepts both lldb-mi options and executable to debug as a single parameter. Split them. As in D55859 we will need to execute one lldb-mi command before loading the exe. Therefore we can no longer use the exe as lldb-mi command-line parameter as then there is no way to execute a command before loading exe specified as lldb-mi command-line parameter. LocateExecutableSymbolFileDsym should be static, that is also a little refactorization. Differential Revision: https://reviews.llvm.org/D55858 llvm-svn: 349607
* A few small updates to the testsuite for running against an iOS device.Jason Molenda2018-12-171-0/+1
| | | | | | | Remove the expected-fails for 34538611; using an alternate platform implementation handles these correctly. llvm-svn: 349417
* Make TestAppleSimulatorOSType.py more flexibleFrederic Riss2018-11-171-1/+7
| | | | | | Different versions of Xcode have different outputs for the simctl command llvm-svn: 347117
* Tiny testsuite tweaks. Don't run the apple simulatorJason Molenda2018-10-161-0/+3
| | | | | | | | | | tests when targetting a device. Add an include to safe-to-call-func to work around a modules issue with a certain combination of header files. Add rules for Darwin systems to ad-hoc codesign binaries that the testsuite builds. llvm-svn: 344635
* Fix typos.Bruce Mitchener2018-10-041-1/+1
| | | | | | | | | | Reviewers: lldb-commits Subscribers: srhines, ki.stfu Differential Revision: https://reviews.llvm.org/D52884 llvm-svn: 343825
* XFail one more VSCode test which fails under heavy loadPavel Labath2018-08-311-0/+1
| | | | llvm-svn: 341186
* [vscode] Skip some of the vscode tests on Linux and fix oneStella Stamenova2018-08-243-0/+17
| | | | | | | | | | | | Summary: These are already skipped on Darwin because they cause build bot failures. Both on the build bots as well as in our testing we have seen a number of these tests fail and hang. This change skips the failing/hanging tests on Linux and also fixes one of the test - the test needs the thread library to build. Reviewers: asmith, clayborg, aprantl Subscribers: teemperor, lldb-commits Differential Revision: https://reviews.llvm.org/D51227 llvm-svn: 340658
* Skip tests on Darwin for now. The build bots are not passing due to heavy ↵Greg Clayton2018-08-188-3/+24
| | | | | | load and poor machines. llvm-svn: 340112
* Skip the lldb-vscode attach with waitFor test for now, some build bots are ↵Greg Clayton2018-08-171-0/+1
| | | | | | having trouble. llvm-svn: 340077
* Change the attach test case to use self.assertEqual so we can get more info ↵Greg Clayton2018-08-171-2/+10
| | | | | | | | on what is going wrong on test bots. Also add a cleanup function to remove the copied binary. llvm-svn: 340050
* Disable two flaky pexpect-backed tests on DarwinVedant Kumar2018-08-161-0/+8
| | | | | | | | These tests are sporadically timing out on our bots, e.g here: https://ci.swift.org/job/swift-PR-Linux/6841 llvm-svn: 339914
* Add a new tool named "lldb-vscode" that implements the Visual Studio Code ↵Greg Clayton2018-08-1623-0/+2891
| | | | | | | | | | | | Debug Adaptor Protocol This patch adds a new lldb-vscode tool that speaks the Microsoft Visual Studio Code debug adaptor protocol. It has full unit tests that test all packets. This tool can be easily packaged up into a native extension and used with Visual Studio Code, and it can also be used by Nuclide Differential Revision: https://reviews.llvm.org/D50365 llvm-svn: 339911
* Fix whitespace in the python test suite.Raphael Isemann2018-07-273-3/+3
| | | | | | | | | | | | | Summary: The test suite has often unnecessary trailing whitespace, and sometimes unnecessary trailing lines or a missing final new line. This patch just strips trailing whitespace/lines and adds missing newlines at the end. Subscribers: ki.stfu, JDevlieghere, christof, lldb-commits Differential Revision: https://reviews.llvm.org/D49943 llvm-svn: 338171
* [lldb-mi] Re-implement data-info-line command.Alexander Polyakov2018-07-231-56/+0
| | | | | | | | | | | | | | Summary: Now data-info-line command uses SB API instead of HandleCommand. Reviewers: aprantl, clayborg, jingham Reviewed By: aprantl Subscribers: ki.stfu, lldb-commits Differential Revision: https://reviews.llvm.org/D49062 llvm-svn: 337689
* [lldb-mi] Re-implement symbol-list-lines command.Alexander Polyakov2018-07-035-124/+0
| | | | | | | | | | | | | | Summary: Now this command uses SB API instead of HandleCommand. Reviewers: aprantl, clayborg Reviewed By: aprantl, clayborg Subscribers: ki.stfu, eraman, lldb-commits Differential Revision: https://reviews.llvm.org/D48802 llvm-svn: 336206
* [lldb-mi] Re-implement a few MI commands.Alexander Polyakov2018-07-021-348/+0
| | | | | | | | | | | | | | | Summary: This patch updates exec-next-instruction, exec-step-instruction, exec-finish, exec-interrupt commands to use SB API instead of HandleCommand. Reviewers: aprantl, clayborg Reviewed By: aprantl Subscribers: ki.stfu, lldb-commits Differential Revision: https://reviews.llvm.org/D48520 llvm-svn: 336155
* [lldb-mi] Re-implement MI -exec-step command.Alexander Polyakov2018-06-101-2/+2
| | | | | | | | | | | | | | Summary: Now -exec-step uses SB API instead of HandleCommand hack. Reviewers: aprantl, clayborg, labath, stella.stamenova Reviewed By: aprantl Subscribers: ki.stfu, lldb-commits Differential Revision: https://reviews.llvm.org/D47838 llvm-svn: 334364
* Fix TestMiExec.pyPavel Labath2018-06-081-2/+2
| | | | | | | r334215 changed the error message the tool prints for invalid thread arguments to -exec-next command. This adjust the test to match that. llvm-svn: 334279
* Fixup r331049 (FileSpec auto-normalization)Pavel Labath2018-04-301-1/+1
| | | | | | | | | | | | | | | | | | A typo in the patch (using syntax instead of m_syntax) resulted in the normalization not working properly for windows filespecs when the syntax was passed as host-native. This did not affect the unit tests, as all of those pass an explicity syntax, but failed gloriously when running the full test suite. I also fix an expectation in an lldb-mi test, which was now failing because it was expecting a path to be echoed verbatim, but we were now normalizing it. As a drive-by, this also fixes the default-in-fully-covered-switch warning and removes an unused argument from the NeedsNormalization function. llvm-svn: 331172
* [debugserver] Fix the G packet handling.Frederic Riss2018-04-271-0/+9
| | | | | | Of course r331004 needed a counterpart on the write side. llvm-svn: 331073
* Mark test as @skipIfOutOfTreeDebugserverFrederic Riss2018-04-271-0/+1
| | | | | | This test will currently fail for people using the system debugserver. llvm-svn: 331043
* [debugserver] Fix handling of the 'g' packetFrederic Riss2018-04-271-0/+30
| | | | | | | | | | | | | | LLDB doesn't use this packet so we never hit this, but it looks like some other projects talk to debugserver and are hitting an assert (https://github.com/derekparker/delve/issues/1015). We had an off by 1 in the accounting of the FPU structure sizes. I added a test that basically just check that 'g' doesn't return an error (currently it assert in debug builds). I didn't make it an lldb-server test because it looks like lldb-server doesn't implement the g packet. llvm-svn: 331004
* [debugserver] Return 'ios' instead of 'iphoneos' for the ostype.Frederic Riss2018-04-251-8/+8
| | | | | | | | | | | | | When I merged the 2 codepaths that return an OS type, I hade checked that the places accepting 'iphoneos' would also accept 'ios', but then I got it backwards and return 'iphoneos'. We use this value to build triples, and there 'iphoneos' is invalid. This also makes the test slightly simpler. llvm-svn: 330877
OpenPOWER on IntegriCloud