summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* [lit, lldbsuite] Update the lldbsuite to correctly run tests on windows and ↵Aaron Smith2018-04-241-5/+5
| | | | | | | | | | | | | | | | | | | windows server Summary: The new script to run the lldbtests as part of lit invokes each test by calling dotest.py, however, we cannot rely on the system to always correctly interpret the script as python causing the tests to be unresolved on windows (at least). To fix this, we need to make sure that the first parameter in the command line is the python executable itself. In Makefile.rules, there are a number of windows specific definitions that rely on the HOST_OS being set as Windows_NT but the logic detecting the OS currently does not detect server versions of windows correctly. This change updates the logic to detect windows server as well. Reviewers: asmith, labath, JDevlieghere, zturner Reviewed By: JDevlieghere, zturner Subscribers: zturner, llvm-commits Differential Revision: https://reviews.llvm.org/D46020 llvm-svn: 330740
* [dotest] Make the set of tests independent of the test configurationPavel Labath2018-04-243-61/+33
| | | | | | | | | | | | | | | | | | | | | | | Summary: In the magic test duplicator, we were making the decision whether to create a test variant based on the compiler and the target platform. This meant that the set of known tests was different for each test configuration. This patch makes the set of generated test variants static and handles the skipping via runtime checks instead. This is more consistent with how we do other test-skipping decision (e.g. for libc++ tests), and makes it easier to expose the full set of tests to lit, which now does not need to know anything about what things can potentially cause tests to appear or disappear. Reviewers: JDevlieghere, aprantl Subscribers: eraman, lldb-commits Differential Revision: https://reviews.llvm.org/D45949 llvm-svn: 330708
* Temporarily skip Go TestExpressions on FreeBSD as it hangsEd Maste2018-04-211-0/+1
| | | | | | llvm.org/pr37194 llvm-svn: 330504
* Fix a crash when resolving overloads of C++ virtual methods.Adrian Prantl2018-04-203-0/+25
| | | | | | | | | The isOverload() method needs to account for situations where the two methods being compared don't have the same number of arguments. rdar://problem/39542960 llvm-svn: 330450
* Attempt to fix TestMiniDump on windowsPavel Labath2018-04-191-6/+6
| | | | | | | | | | | | | | | | | | | | | | | It was failing because the modules names were coming out as C:\Windows\System32/MSVCP120D.dll (last separator is a forward slash) on windows. There are two issues at play here: - the first problem is that the paths in minidump were being parsed as a host path. This meant that on posix systems the whole path was interpreted as a file name. - on windows the path was split into a directory-filename pair correctly, but then when it was reconsituted, the last separator ended up being a forward slash because SBFileSpec.fullpath was joining them with '/' unconditionally. I fix the first issue by parsing the minidump paths according to the path syntax of the host which produced the dump, which should make the test behavior on posix&windows identical. The last path will still be a forward slash because of the second issue. We should probably fix the "fullpath" property to do something smarter in the future. llvm-svn: 330314
* Improve LLDB's handling of non-local minidumpsLeonard Mosescu2018-04-182-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, LLDB is creating a high-fidelity representation of a live process, including a list of modules and sections, with the associated memory address ranges. In order to build the module and section map LLDB tries to locate the local module image (object file) and will parse it. This does not work for postmortem debugging scenarios where the crash dump (minidump in this case) was captured on a different machine. Fortunately the minidump format encodes enough information about each module's memory range to allow us to create placeholder modules. This enables most LLDB functionality involving address-to-module translations. Also, we may want to completly disable the search for matching local object files if we load minidumps unless we can prove that the local image matches the one from the crash origin. (not part of this change, see: llvm.org/pr35193) Example: Identify the module from a stack frame PC: Before: thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14 frame #0: 0x00164d14 frame #1: 0x00167c79 frame #2: 0x00167e6d frame #3: 0x7510336a frame #4: 0x77759882 frame #5: 0x77759855 After: thread #1, stop reason = Exception 0xc0000005 encountered at address 0x164d14 frame #0: 0x00164d14 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #1: 0x00167c79 C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #2: 0x00167e6d C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe frame #3: 0x7510336a C:\Windows\SysWOW64\kernel32.dll frame #4: 0x77759882 C:\Windows\SysWOW64\ntdll.dll frame #5: 0x77759855 C:\Windows\SysWOW64\ntdll.dll Example: target modules list Before: error: the target has no associated executable images After: [ 0] C:\Windows\System32\MSVCP120D.dll [ 1] C:\Windows\SysWOW64\kernel32.dll [ 2] C:\Users\amccarth\Documents\Visual Studio 2013\Projects\fizzbuzz\Debug\fizzbuzz.exe [ 3] C:\Windows\System32\MSVCR120D.dll [ 4] C:\Windows\SysWOW64\KERNELBASE.dll [ 5] C:\Windows\SysWOW64\ntdll.dll NOTE: the minidump format also includes the debug info GUID, so we can fill-in the module UUID from it, but this part was excluded from this change to keep the changes simple (the LLDB UUID is hardcoded to be either 16 or 20 bytes, while the CodeView GUIDs are normally 24 bytes) Differential Revision: https://reviews.llvm.org/D45700 llvm-svn: 330302
* Report more precise error message when attach failsPavel Labath2018-04-182-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: If the remote stub sends a specific error message instead of just a E?? code, we can use this to display a more informative error message instead of just the generic "unable to attach" message. I write a test for this using the SB API. On the console this will show up like: (lldb) process attach ... error: attach failed: <STUB-MESSAGE> if the stub supports error messages, or: error: attach failed: Error ?? if it doesn't. Reviewers: jingham, JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D45573 llvm-svn: 330247
* [Statistics] Relax the test output a little bit.Davide Italiano2018-04-161-4/+4
| | | | | | | | | | We don't really care about the order as this is a dictionary. It should be more resilient to changes (adding/shuffling stats around). Pointed out by Jason Molenda in a post-commit review (thanks Jason). llvm-svn: 330170
* [Commands] Expose statistics through the SBAPI.Davide Italiano2018-04-163-0/+34
| | | | | | | | | The API is `SBStructuredData GetStatistics()`. This allows the command to be used in scripts. <rdar://problem/36555975> llvm-svn: 330165
* Make sure deleting all breakpoints clears their sites firstEugene Zemtsov2018-04-162-0/+23
| | | | | | | | Bug: https://bugs.llvm.org/show_bug.cgi?id=36430 Differential Revision: https://reviews.llvm.org/D45554 llvm-svn: 330163
* [Command] Implement `statistics` command.Davide Italiano2018-04-133-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows us to collect useful metrics about lldb debugging sessions. I thought that an example would be better than a thousand words: Process 19705 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = step in frame #0: 0x0000000100000fb4 blah`main at blah.c:3 1 int main(void) { 2 int a = 6; -> 3 return 0; 4 } (lldb) statistics enable (lldb) frame var a (int) a = 6 (lldb) expr a (int) $1 = 6 (lldb) statistics disable (lldb) statistics dump Number of expr evaluation successes : 1 Number of expr evaluation failures : 0 Number of frame var successes : 1 Number of frame var failures : 0 Future improvements might include: 1. Passing a file, or implementing categories. The way this patch has been implemented is generic enough to allow this to be extended easily without breaking the grammar. 2. Adding an SBAPI and Python API for use in scripts. Thanks to Jim Ingham for discussing the design with me. <rdar://problem/36555975> Differential Revision: https://reviews.llvm.org/D45547 llvm-svn: 330043
* Allow relative file paths when settings source breakpointsGreg Clayton2018-04-132-2/+26
| | | | | | | | | | | | | | | | | Many IDEs set breakpoints using absolute paths and this causes problems when the full path of the source file path doesn't match what is in the debug info. This can be due to different build systems and do or do not resolve symlinks. This patch allows relative breakpoint to be set correctly without needing to do any target.source-map tricks. If IDEs want to, they can send down relative paths like: ./main.c ./src/main.c src/main.c foo/bar/src/main.c I used the breakpoint resolver to match on the file basename and then we weed out anything whose relative paths don't match. This will be a huge improvement for IDEs as they can specify as much of a relative path as desired to uniquely identify a source file in the current project. Differential Revision: https://reviews.llvm.org/D45592 llvm-svn: 330028
* Re-land "Don't assume backing thread shares protocol ID."Jonas Devlieghere2018-04-132-0/+95
| | | | | | | | | | | | | | | | | | When we're dealing with virtual (memory) threads created by the OS plugins, there's no guarantee that the real thread and the backing thread share a protocol ID. Instead, we should iterate over the memory threads to find the virtual thread that is backed by the current real thread. Differential revision: https://reviews.llvm.org/D45497 rdar://36485830 The original revision (r329891) was reverted because the associated tests ran into a deadlock on the Linux bots. That problem was resolved by r330002. llvm-svn: 330005
* Revert "Don't assume backing thread shares protocol ID."Jonas Devlieghere2018-04-122-95/+0
| | | | | | | This reverts r329891 because the test case is timing out on linux: http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/21834 llvm-svn: 329897
* Don't assume backing thread shares protocol ID.Jonas Devlieghere2018-04-122-0/+95
| | | | | | | | | | | | | | When we're dealing with virtual (memory) threads created by the OS plugins, there's no guarantee that the real thread and the backing thread share a protocol ID. Instead, we should iterate over the memory threads to find the virtual thread that is backed by the current real thread. Differential revision: https://reviews.llvm.org/D45497 rdar://36485830 llvm-svn: 329891
* [dotest] Fix syntax error and typo.Jonas Devlieghere2018-04-122-2/+2
| | | | | | Python uses `elif` rather than `else if`. Fixes r329889. llvm-svn: 329890
* [dotest] Use in-tree dsymutil on DarwinJonas Devlieghere2018-04-123-2/+10
| | | | | | | | | | | | | | | | | | | Summary: With the upstream implementation of dsymutil containing almost all functionality from the one shipped with Xcode, we want to use the in-tree version for running the test suite. This will also allow us to re-enable TestUnicodeSymbols which was failing because of the discrepancy in how Unicode symbols were hashed in lldb and older versions of dsymutil. Reviewers: aprantl, davide, jingham, labath Subscribers: mgorny, llvm-commits, lldb-commits Differential Revision: https://reviews.llvm.org/D45518 llvm-svn: 329889
* [lldb-server] Set a more generous timeout when testing gdbremote.Davide Italiano2018-04-061-1/+1
| | | | | | | One of our downstream bot is struggling under load, but this value should be enough for everyone. llvm-svn: 329426
* [debugserver] Fix LC_BUILD_VERSION load command handling.Frederic Riss2018-04-063-0/+142
| | | | | | | | | | | | | | | | | | | | | | Summary: In one of the 2 places the LC_BUILD_VERSION load command is handled, there is a bug preventing us from actually handling them (the address where to read the load command was not updated). This patch factors reading the deployment target load commands into a helper and adds testing for the 2 code paths calling the helper. The testing is a little bit complicated because the only times those load commands matter is when debugging a simulator process. I added a new decorator to check that a specific SDK is available. The actual testing was fairly easy once I knew how to run a simulated process. Reviewers: jasonmolenda, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D45298 llvm-svn: 329374
* [dotest] --skip-category should append and not override.Davide Italiano2018-04-051-1/+1
| | | | | | <rdar://problem/38566150> llvm-svn: 329358
* Support template template parametersFrederic Riss2018-04-022-0/+35
| | | | | | | | | | | | | | | | | | Summary: We would fail to resolve (and thus display the value of) any templated type which contained a template template argument even though we don't really use template arguments. This patch adds minimal support for template template arguments, but I doubt we need any more than that. Reviewers: clayborg, jingham Subscribers: JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D44613 llvm-svn: 328984
* Revert r328715. Wasn't wrong, just not the issue.Jim Ingham2018-03-281-1/+0
| | | | llvm-svn: 328721
* Explicitly import subprocessJim Ingham2018-03-281-0/+1
| | | | | | | For some reason on one of our bots subprocess wasn't already imported. Do so explicitly. llvm-svn: 328715
* Use the DWARF linkage name when importing C++ methods.Davide Italiano2018-03-273-0/+63
| | | | | | | | | | | | | | | | | | | | When importing C++ methods into clang AST nodes from the DWARF symbol table, preserve the DW_AT_linkage_name and use it as the linker ("asm") name for the symbol. Concretely, this enables `expression` to call into names that use the GNU `abi_tag` extension, and enables lldb to call into code using std::string or std::list from recent versions of libstdc++. See https://bugs.llvm.org/show_bug.cgi?id=35310 . It also seems broadly more robust than relying on the DWARF->clang->codegen pipeline to roundtrip properly, but I'm not immediately aware of any other cases in which it makes a difference. Patch by Nelson Elhage! Differential Revision: https://reviews.llvm.org/D40283 llvm-svn: 328658
* Fix TestDisassembleBreakpoint broken by r328488Pavel Labath2018-03-262-33/+22
| | | | | | | | | | | | | | | | | The first issue was that the test was capturing the "before" disassembly before launching, and the "after" after. This is a problem because some of the disassembly will change after we know the load address (e.g. PCs in call instructions). I fix this by capturing both disassemblies with the process running. The second issue was that the refactor in r328488 accidentaly changed the meaning of the test, as it was no longer disassembling the function which contained the breakpoint. While inside, I also modernize the test to use lldbutil.run_to_source_breakpoint and prevent debug-info replication. llvm-svn: 328504
* Make @skipUnlessSupportedTypeAttribute windows-compatiblePavel Labath2018-03-261-5/+4
| | | | | | | | | - close_fds is not compatible with stdin/out redirection on windows. I just remove it, as this is not required for correct operation. - the command string was assuming a posix shell. I rewrite the Popen invocation to avoid the need for passing the arguments through a shell. llvm-svn: 328489
* Add and fix some tests for PPC64Pavel Labath2018-03-266-35/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: TestExprsChar.py Char is unsigned char by default in PowerPC. TestDisassembleBreakpoint.py Modify disassemble testcase to consider multiple architectures. TestThreadJump.py Jumping directly to the return line on PowerPC architecture dos not means returning the value that is seen on the code. The last test fails, because it needs the execution of some assembly in the beginning of the function. Avoiding this test for this architecture. TestEhFrameUnwind.py Implement func for ppc64le test case. TestWatchLocation.py TestStepOverWatchpoint.py PowerPC currently supports only one H/W watchpoint. TestDisassembleRawData.py Add PowerPC opcode and instruction for disassemble testcase. Reviewers: labath Reviewed By: labath Subscribers: davide, labath, alexandreyy, lldb-commits, luporl, lbianc Differential Revision: https://reviews.llvm.org/D44472 Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br>. llvm-svn: 328488
* [LLDB][PPC64] Fix TestGdbRemoteAuxvSupportPavel Labath2018-03-261-0/+15
| | | | | | | | | | | | | | | Summary: PPC64's auxvec has a special key that must be ignored. Reviewers: clayborg, labath Reviewed By: clayborg, labath Subscribers: alexandreyy, lbianc Differential Revision: https://reviews.llvm.org/D43771 Patch by Leandro Lupori <leandro.lupori@gmail.com>. llvm-svn: 328486
* Add a test for setting the load address of a module with differing ↵Pavel Labath2018-03-261-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | physical/virtual addresses Summary: First attempt at landing D42145 was reverted because it caused test failures on some android devices. It turned out this was because these devices had vdso modules with differing physical and virtual addresses. This was not caught earlier because all of the modules in our tests either lack physical addresses or have them identical to virtual ones. In the discussion on the patch, we came to the conclusion that in the scenario where we are merely setting a load address of a module (for example from a dynamic loader plugin), we should always use virtual addresses (i.e., preserve status quo). This patch adds a test to make sure we don't regress in that direction. Reviewers: owenpshaw Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44738 llvm-svn: 328485
* Add support for __attribute__(trivial_abi).Jim Ingham2018-03-234-0/+128
| | | | | | <rdar://problem/36035075>, <rdar://problem/36035039> llvm-svn: 328389
* Last batch of test-tree cleaning changesPavel Labath2018-03-215-118/+80
| | | | | | | | | | | | | | | - postmortem tests: make sure the core files are created in the build folder - TestSourceManager: copy the .c file into the build dir before modifying it - TestLogging: create log files in the build folder After these changes I get a clean test run (on linux) even if I set the source tree to be read only. It's possible some of the skipped/xfailed tests are still creating files in the source tree, but at the moment, I don't have plans to go hunting for those. llvm-svn: 328106
* Fix TestOperatorOverload for 32-bit buildsPavel Labath2018-03-212-14/+4
| | | | | | | | | | | | - use more goodies from Makefile.rules to correctly build a 32-bit binary. - avoid hardcoding typeof(nil) in the test. This should partially fix the linux bot. There is still one assertion failure remaining, which I'll have to investigate separately, as I am not experiencing it locally. llvm-svn: 328083
* [Testsuite] Modernize this test to be run out-of-tree.Davide Italiano2018-03-201-5/+3
| | | | | | | | New tests should run the make syntax voodoo $@ and $< instead of hardcoding the names. We should also document how to write one, it's on my list. llvm-svn: 328062
* [ExpressionParser] Re-implement r327356 in a less disruptive way.Davide Italiano2018-03-204-0/+61
| | | | | | | | | | | | Instead of applying the sledgehammer of refusing to insert any C++ symbol in the ASTContext, try to validate the decl if what we have is an operator. There was other code in lldb which was responsible for this, just not really exposed (or used) in this codepath. Also, add a better/more comprehensive test. <rdar://problem/35645893> llvm-svn: 328025
* [TestExpr] Fix a typo in a test, unbreaking the lldb Mac OS X bot.Davide Italiano2018-03-201-1/+1
| | | | llvm-svn: 328013
* [LLDB] Fix TestTargetXMLArch's expected archPavel Labath2018-03-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: When running on an architecture other than x86_64, the target.ConnectRemote() part of the test may add platform information to the target triple. It was observed that this happens at Process::CompleteAttach() method, after the platform_sp->IsCompatibleArchitecture() check fails. This method then calls platform_sp->GetPlatformForArchitecture(), that on a Linux machine ends up returning a generic Linux platform, that then ends up getting added to the original target architecture. Reviewers: clayborg, labath, jasonmolenda Reviewed By: labath Subscribers: alexandreyy, lbianc Differential Revision: https://reviews.llvm.org/D44022 Patch by Leandro Lupori <leandro.lupori@gmail.com>. llvm-svn: 327981
* Fix some tests for PPC64le architecturePavel Labath2018-03-204-15/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Fix test jump for powerpc64le Jumping directly to the return line on power architecture dos not means returning the value that is seen on the code. The last test fails, because it needs the execution of some assembly in the beginning of the function. Avoiding this test for this architecture. - Avoid evaluate environ variable name on Linux On Linux the Symbol environ conflicts with another variable, then in order to avoid it, this test was moved into a specific test, which is not supported if the OS is Linux. - Added PPC64le as MIPS behavior Checking the disassembler output, on PPC64le machines behaves as MPIS. Added method to identify PPC64le architecture and checking it when disassembling instructions in the test case. Reviewers: labath Reviewed By: labath Subscribers: clayborg, labath, luporl, alexandreyy, sdardis, ki.stfu, arichardson Differential Revision: https://reviews.llvm.org/D44101 Patch by Leonardo Bianconi <leonardo.bianconi@eldorado.org.br>. llvm-svn: 327977
* Re-land: [lldb] Use vFlash commands when writing to target's flash memory ↵Pavel Labath2018-03-202-2/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | regions The difference between this and the previous patch is that now we use ELF physical addresses only for loading objects into the target (and the rest of the module load address logic still uses virtual addresses). Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup. - Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address. - Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications - Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html Reviewers: clayborg, labath Reviewed By: labath Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net>. llvm-svn: 327970
* Modernize a test.Jim Ingham2018-03-191-29/+2
| | | | llvm-svn: 327924
* [test] Skip flaky tests in TestMiSyntax on DarwinVedant Kumar2018-03-191-0/+3
| | | | | | These tests tend to time out locally and on our bots. llvm-svn: 327906
* [test] Skip flaky TestThreadStates tests on DarwinVedant Kumar2018-03-191-3/+3
| | | | | | | | These tests do not pass/fail consistently, so just skip them. This is llvm.org/pr15824 & rdar://problem/28557237. llvm-svn: 327905
* [DWARFASTParserClang] Complete external record types before using them as a ↵Frederic Riss2018-03-163-0/+31
| | | | | | | | | | | | | | | | | | decl context. Summary: When in a gmodules-like debugging scenario, you can have a parent decl context that gets imported from an external AST. When this happens, we must be careful to complete this type before adding children to it, otherwise it sometimes results in a crash. Reviewers: clayborg, jingham Subscribers: aprantl, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D43592 llvm-svn: 327750
* Skip TestThreadSpecificBpPlusCondition on Darwin due to timeoutsVedant Kumar2018-03-161-0/+1
| | | | | | Bot failure: https://ci.swift.org/job/oss-lldb-incremental-osx/1104/ llvm-svn: 327731
* Remove -gmodules restriction from testAdrian Prantl2018-03-161-1/+0
| | | | llvm-svn: 327729
* [dotest] Clean up test folder clean-upPavel Labath2018-03-1616-71/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Skip more lldb-mi tests which time out on DarwinVedant Kumar2018-03-161-0/+3
| | | | | | Bot failure: https://ci.swift.org/job/oss-lldb-incremental-osx/1097/testReport/junit/TestMiTarget/MiTargetTestCase/test_lldbmi_target_attach_wait_for/ llvm-svn: 327692
OpenPOWER on IntegriCloud