summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/macosx
Commit message (Collapse)AuthorAgeFilesLines
* Add a test to verify that lldb can load a kext binary.Jason Molenda2018-11-302-0/+260
| | | | | | <rdar://problem/46356062> llvm-svn: 348040
* Port the Darwin universal binary testcase to x86_64.Adrian Prantl2018-11-152-61/+57
| | | | | | | | | Xcode 10 doesn't ship with an i386 SDK any more. This patch ports the testcase from an i386/x86_64 -> x86_64/x86_64h universal binary. rdar://problem/46099343 llvm-svn: 346981
* Tiny testsuite tweaks. Don't run the apple simulatorJason Molenda2018-10-161-0/+1
| | | | | | | | | | 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
* lldbtest.py: Unconditionally set the clang module cache path.Adrian Prantl2018-08-211-1/+2
| | | | | | This should fix the errors observable on the new lldb-cmake bot. llvm-svn: 340293
* Fix a little thinko in generating ___lldb_unnamed_symbol symbols Jim Ingham2018-08-153-0/+112
| | | | | | | | | | | when we have only an in-memory copy of the binary. Also added a test for the generation of these symbols in the in-memory and regular cases. <rdar://problem/43160401> llvm-svn: 339833
* Fix whitespace in the python test suite.Raphael Isemann2018-07-274-9/+9
| | | | | | | | | | | | | 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
* Fix silly error introduced after testing in r333813.James Y Knight2018-06-021-7/+0
| | | | | | Oops. llvm-svn: 333816
* Fix support for distinguishing archive members by timestamp on Darwin.James Y Knight2018-06-025-0/+129
| | | | | | | | | | | | | | | | | | | On Darwin, the binary's symbol table points to debug info in object files -- potentially object files within a static library. Such a library may have multiple entries with the same name, distinguished only by timestamp. The code was already _attempting_ to handle this case (see the code in ObjectContainerBSDArchive::Archive::FindObject which disambiguates via timestamp). But, unfortunately, while the timestamp was taken into account on the _first_ lookup, the result was then cached in a map keyed only off of the path. Added the timestamp to the cache, and added a test case. Differential Revision: https://reviews.llvm.org/D47660 llvm-svn: 333813
* [dotest] Clean up test folder clean-upPavel Labath2018-03-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements a unified way of cleaning the build folder of each test. This is done by completely removing the build folder before each test, in the respective setUp() method. Previously, we were using a combination of several methods, each with it's own drawbacks: - nuking the entire build tree before running dotest: the issue here is that this did not take place if you ran dotest manually - running "make clean" before the main "make" target: this relied on the clean command being correctly implemented. This was usually true, but not always. - for files which were not produced by make, each python file was responsible for ensuring their deleting, using a variety of methods. With this approach, the previous methods become redundant. I remove the first two, since they are centralized. For the other various bits of clean-up code in python files, I indend to delete it when I come across it. Reviewers: aprantl Subscribers: emaste, ki.stfu, mgorny, eraman, lldb-commits Differential Revision: https://reviews.llvm.org/D44526 llvm-svn: 327703
* [testsuite] Throw away test/debug_info/apple_types.Davide Italiano2018-02-233-104/+0
| | | | | | | | | | | | This test was only testing that clang produced the correct informations for __apple accelerated tables. So, it's a clang test. Also, it doesn't require any debugger intervention, the object file can be analyzed statically with a dumper. Also, the input program was highly verbose (unnecessarily). r325850 commits a clang test instead, so it's time to retire this. llvm-svn: 325851
* Fix TestAppleTypesIsProduced after r324226Frederic Riss2018-02-211-1/+1
| | | | | | | | This test was accessing self.debug_info, which doesn't exist anymore. For some reason the macOS bots are skipping this test because they think the compiler is not clang. We'll look into this separately. llvm-svn: 325666
* Make LLDB's clang module cache path customizableAdrian Prantl2018-02-091-6/+5
| | | | | | | | | | | This patch makes LLDB's clang module cache path customizable via settings set target.clang-modules-cache-path <path> and uses it in the LLDB testsuite to reuse the same location inside the build directory for LLDB and clang. Differential Revision: https://reviews.llvm.org/D43099 llvm-svn: 324775
* Enforce that NO_DEBUG_INFO_TESTCASEs build using buildDefault().Adrian Prantl2018-01-301-1/+1
| | | | | | This is a prerequisite for building each test variant in its own subdirectory. llvm-svn: 323830
* Compile the LLDB tests out-of-tree.Adrian Prantl2018-01-3017-126/+66
| | | | | | | | | | | | | | | | | | | | | | | | This patch is the result of a discussion on lldb-dev, see http://lists.llvm.org/pipermail/lldb-dev/2018-January/013111.html for background. For each test (should be eventually: each test configuration) a separate build directory is created and we execute make VPATH=$srcdir/path/to/test -C $builddir/path/to/test -f $srcdir/path/to/test/Makefile -I $srcdir/path/to/test In order to make this work all LLDB tests need to be updated to find the executable in the test build directory, since CWD still points at the test's source directory, which is a requirement for unittest2. Although we have done extensive testing, I'm expecting that this first attempt will break a few bots. Please DO NOT HESITATE TO REVERT this patch in order to get the bots green again. We will likely have to iterate on this some more. Differential Revision: https://reviews.llvm.org/D42281 llvm-svn: 323803
* Wrap all references to build artifacts in the LLDB testsuite (NFC)Adrian Prantl2018-01-198-12/+13
| | | | | | | | | in TestBase::getBuildArtifact(). This NFC commit is in preparation for https://reviews.llvm.org/D42281 (compile the LLDB tests out-of-tree). Differential Revision: https://reviews.llvm.org/D42280 llvm-svn: 323007
* Fix the Makefile - this version should work on the botJim Ingham2018-01-121-4/+3
| | | | llvm-svn: 322341
* Print the SBDebugger.CreateTarget error message.Jim Ingham2018-01-121-1/+3
| | | | | | | This is failing on the bot but not locally. Maybe the error message will tell us why. llvm-svn: 322338
* Fix the same thinko in another place...Jim Ingham2018-01-111-1/+1
| | | | | | Thanks Jason. llvm-svn: 322329
* Fix a tiny thinko in this test and re-add.Jim Ingham2018-01-114-0/+120
| | | | | | target.IsValid() not target... llvm-svn: 322328
* [testsuite] Remove a broken test which tried to find App in bundles.Davide Italiano2018-01-115-119/+0
| | | | | | | That never really worked, and the change associated isn't yet committed, so, let's try to make the bots green for now. llvm-svn: 322322
* Make the bundle folders in the find-app-in-bundle test non-emptyPavel Labath2018-01-112-0/+0
| | | | | | | git will not create empty folders, which makes this test fail if the repo is checked out with git. llvm-svn: 322271
* Running this on other systems won't work because I don'tJim Ingham2018-01-101-0/+1
| | | | | | know how to specifically build a MachO binary on other systems. llvm-svn: 322239
* Runs the part of the test that just finds the binary on all systems.Jim Ingham2018-01-101-13/+14
| | | | | | That should work everywhere. Then only try actually running on macosx. llvm-svn: 322235
* Add a test for finding a binary in an app package.Jim Ingham2018-01-105-0/+117
| | | | llvm-svn: 322232
* [MacOSX/Queues] Relax an overly aggressive assertion in a test.Davide Italiano2017-12-151-1/+2
| | | | | | | | | | "Default" is a valid QoS for a thread on older versions of macOS, like the one installed in the bot. Thanks to Jason Molenda for helping me figuring out the problem. <rdar://problem/28346273> llvm-svn: 320883
* [test-suite] Un'XFAIL a test that's not failing anymore.Davide Italiano2017-12-111-1/+0
| | | | | | | | | | This is the first of a series of commits aiming to improve overall LLDB's hygiene. Feel free to shout at me in case I break something. <rdar://problem/30915340> llvm-svn: 320425
* Initial patchset to get the testsuite running against armv7 and arm64 iOS ↵Jason Molenda2017-09-255-4/+34
| | | | | | | | | | | | | | | | | | | | | | | devices. Normal customer devices won't be able to run these tests, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures. I have seen some instability with the armv7 test runs, I may submit additional patches to address this. arm64 looks good. I'll be watching the bots for the rest of today; if any problems are introduced by this patch I'll revert it - if anyone sees a problem with their bot that I don't see, please do the same. I know it's a rather large patch. One change I had to make specifically for iOS devices was that debugserver can't create files. There were several tests that launch the inferior process redirecting its output to a file, then they retrieve the file. They were not trying to test file redirection in these tests, so I rewrote those to write their output to a file directly. llvm-svn: 314132
* Revert "Initial patchset to get the testsuite running against armv7 and ↵Chris Bieneman2017-09-255-34/+4
| | | | | | | | | | | | | arm64 iOS devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures." This patch has been causing LLDB test failures on ObjC tests. A test log may still be available here: http://lab.llvm.org:8080/green/view/LLDB/job/lldb/1650/ This reverts commit r314038. llvm-svn: 314122
* Initial patchset to get the testsuite running against armv7 and arm64 iOS ↵Jason Molenda2017-09-225-4/+34
| | | | | | | | | | | | | | | | | | | | | | | devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures. I have seen some instability with the armv7 test runs, I may submit additional patches to address this. arm64 looks good. I'll be watching the bots for the rest of today; if any problems are introduced by this patch I'll revert it - if anyone sees a problem with their bot that I don't see, please do the same. I know it's a rather large patch. One change I had to make specifically for iOS devices was that debugserver can't create files. There were several tests that launch the inferior process redirecting its output to a file, then they retrieve the file. They were not trying to test file redirection in these tests, so I rewrote those to write their output to a file directly. llvm-svn: 314038
* Revert this patch; I was emailing with Eugene and they have some other ↵Jason Molenda2017-09-215-34/+4
| | | | | | | | | changes going in today and don't want the two changes to confuse the situation with the build bots. I'll commit tomorrow once they're known good. llvm-svn: 313934
* Initial patchset to get the testsuite running against armv7 and arm64 iOS ↵Jason Molenda2017-09-215-4/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. There will be some smaller follow-on patches. The changes to tools/lldb-server are verbose and I'm not thrilled with having to skip all of these tests manually. There are a few places where I'm making the assumption that "armv7", "armv7k", "arm64" means it's an ios device, and I need to review & clean these up with an OS check as well. (Android will show up as "arm" and "aarch64" so by pure luck they shouldn't cause problems, but it's not an assumption I want to rely on). I'll be watching the bots for the rest of today; if any problems are introduced by this patch I'll revert it - if anyone sees a problem with their bot that I don't see, please do the same. I know it's a rather large patch. One change I had to make specifically for iOS devices was that debugserver can't create files. There were several tests that launch the inferior process redirecting its output to a file, then they retrieve the file. They were not trying to test file redirection in these tests, so I rewrote those to write their output to a file directly. llvm-svn: 313932
* Change how LocateDSYMInVincinityOfExecutable strips off pathJason Molenda2017-06-1510-0/+298
| | | | | | | | | | | | | | | | | | components to not depend on "." characters in the fileanme (e.g. "Foundation.framework") but instead to just use path separators. The names of the files themselves may have dots in them ("com.apple.sbd") which would break the old scheme. Also add a test case for this (macosx/find-dsym/bundle-with-dot-in-filename) as well as a test case for r304520 (macosx/find-dsym/deep-bundle) which needed a similar setup to test correctly on a single machine. (both of these are really testing remote debug session situations where the binary can't be found on the system where lldb is running, complicating the test case a bit.) <rdar://problem/31825940> llvm-svn: 305441
* Back to xfailing this. For some reason on our buildbotsJason Molenda2017-03-081-0/+1
| | | | | | | | it fails, but it works on the local workstations. I'll need to figure out what the difference is between these. <rdar://problem/30915340> llvm-svn: 297259
* TestQueues should be passing again, remove the expected fail.Jason Molenda2017-03-081-1/+0
| | | | llvm-svn: 297258
* Clean up the new TestInterruptThreadNames test a bit.Jason Molenda2016-12-081-23/+39
| | | | llvm-svn: 289155
* When we interrupt a process, it was possible or the thread namesJason Molenda2016-12-083-0/+180
| | | | | | | | | | | | | | | | | | to not be set by Process::WillPublicStop() so the driver won't get access to them. The fix is straightforward, moving the call to WillPublicStop above the early return for the interrupt case. (the interrupt case does an early return because the rest of the function is concerned with running stop hooks etc and those are not applicable when we've interrupted the process). Also added a test case for it. The test case is a little complicated because I needed to drive lldb asynchronously to give the program a chance to get up and running before I interrupt it. Running to a breakpoint was not sufficient to catch this bug. <rdar://problem/22693778> llvm-svn: 289026
* xfail TestQueues on macOSTodd Fiala2016-10-061-0/+1
| | | | | | | | | | This test is failing on CI. I cannot get it to fail on my local setup. Tracked by: rdar://28658529 llvm-svn: 283492
* TestQueues could error out because the one second sleep main.c wasJason Molenda2016-09-132-3/+6
| | | | | | | | using to enqueue all the jobs wasn't enough time on a slow/overloaded system. Instead use a global to indicate when all the work has been enqueued, let's see if this makes the CIs work more reliably. llvm-svn: 281418
* xfail TestQueues.py and TestDarwinLogFilterMatchMessage.pyTodd Fiala2016-09-121-0/+1
| | | | | | | | | | | | | | It looks like the message-content-retrieval aspect of DarwinLog support is flaky, not just the regex match against it. Slightly less frequently than the regex matching, I am seeing the direct string-match variant of log-message-content matching also fail. Tracked by: llvm.org/pr30299 rdar://28237450 llvm-svn: 281251
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-068-226/+391
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* This test now succeeds.Jim Ingham2016-08-271-1/+0
| | | | llvm-svn: 279897
* Fix TestDarwinNSLogOutput for windowsPavel Labath2016-07-151-1/+1
| | | | | | pexpect python package does not exist on windows llvm-svn: 275555
* adjust one of the NSLog output tests to only run on macOS 10.12+Todd Fiala2016-07-151-0/+7
| | | | | | | | The LLDB NSLog handling when Xcode intends to suppress NSLog output only works on Fall 2016 OS releases. Skip it on earlier OSes. llvm-svn: 275506
* removed darwin_log.py file from previous check-inTodd Fiala2016-07-141-139/+0
| | | | | | This file was not intended to be part of the last check-in. llvm-svn: 275478
* fix command-line LLDB so NSLog messages show upTodd Fiala2016-07-144-0/+304
| | | | | | | | | | | Changes to the underlying logging infrastructure in Fall 2016 Darwin OSes were no longer showing up NSLog messages in command-line LLDB. This change restores that functionality, and adds test cases to verify the new behavior. rdar://26732492 llvm-svn: 275472
* Make sure code that is in the middle of figuring out the correct architectureJim Ingham2016-02-182-1/+63
| | | | | | | | | on attach uses the architecture it has figured out, rather than the Target's architecture, which may not have been updated to the correct value yet. <rdar://problem/24632895> llvm-svn: 261279
* Move the rest of the tests over to using the new decorator module.Zachary Turner2016-02-047-4/+14
| | | | llvm-svn: 259838
* Remove `use_lldb_suite` from the package, and don't import it anymore.Zachary Turner2015-11-037-7/+7
| | | | | | | | | | | | | | | | This module was originally intended to be imported by top-level scripts to be able to find the LLDB packages and third party libraries. Packages themselves shouldn't need to import it, because by the time it gets into the package, the top-level script should have already done this. Indeed, it was just adding the same values to sys.path multiple times, so this patch is essentially no functional change. To make sure it doesn't get re-introduced, we also delete the `use_lldb_suite` module from `lldbsuite/test`, although the original copy still remains in `lldb/test` llvm-svn: 251963
* Tighten up sys.path, and use absolute imports everywhere.Zachary Turner2015-11-037-13/+13
| | | | | | | | | | | | | | | | | | | | For convenience, we had added the folder that dotest.py was in to sys.path, so that we could easily write things like `import lldbutil` from anywhere and any test. This introduces a subtle problem when using Python's package system, because when unittest2 imports a particular test suite, the test suite is detached from the package. Thus, writing "import lldbutil" from dotest imports it as part of the package, and writing the same line from a test does a fresh import since the importing module was not part of the same package. The real way to fix this is to use absolute imports everywhere. Instead of writing "import lldbutil", we need to write "import lldbsuite.test.util". This patch fixes up that and all other similar cases, and additionally removes the script directory from sys.path to ensure that this can't happen again. llvm-svn: 251886
* Move lldb/test to lldb/packages/Python/lldbsuite/test.Zachary Turner2015-10-2826-0/+1097
This is the conclusion of an effort to get LLDB's Python code structured into a bona-fide Python package. This has a number of benefits, but most notably the ability to more easily share Python code between different but related pieces of LLDB's Python infrastructure (for example, `scripts` can now share code with `test`). llvm-svn: 251532
OpenPOWER on IntegriCloud