summaryrefslogtreecommitdiffstats
path: root/lldb/lit
Commit message (Collapse)AuthorAgeFilesLines
...
* [CMake] Add missing test depDavid Zarzycki2019-03-301-0/+1
| | | | | | lit/SymbolFile/NativePDB/globals-bss.cpp needs llvm-readobj llvm-svn: 357336
* minidump: Add ability to attach (breakpad) symbol files to placeholder modulesPavel Labath2019-03-273-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-commits r354263, which was because it uncovered with handling of modules with empty (zero) UUIDs. This would cause us to treat two modules as intentical even though they were not. This caused an assert in PlaceholderObjectFile::SetLoadAddress to fire, because we were trying to load the module twice even though it was designed to be only loaded at a specific address. (The same problem also existed with the previous implementation, but it had no asserts to warn us about this.) These issues have now been fixed in r356896. windows bot. The issue there was that ObjectFilePECOFF vended its base address through the incorrect interface. SymbolFilePDB depended on that, which lead to assertion failures when SymbolFilePDB was attempting to use the placeholder object files as a base. This has been fixed in r354258 The original commit message was: The reason this wasn't working was that ProcessMinidump was creating odd object-file-less modules, and SymbolFileBreakpad required the module to have an associated object file because it needed to get its base address. This fixes that by introducing a PlaceholderObjectFile to serve as a dummy object file. The general idea for this is taken from D55142, but I've reworked it a bit to avoid the need for the PlaceholderModule class. Now that we have an object file, our modules are sufficiently similar to regular modules that we can use the regular Module class almost out of the box -- the only thing I needed to tweak was the Module::CreateModuleFromObjectFile functon to set the module's FileSpec in addition to it's architecture. This wasn't needed for ObjectFileJIT (the other user of CreateModuleFromObjectFile), but it shouldn't hurt it either, and the change seems like a straightforward extension of this function. Reviewers: clayborg, lemo, amccarth Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D57751 llvm-svn: 357060
* Update the lldb driver to support the -O and -S options when passing --replAdrian Prantl2019-03-251-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment when --repl is passed to lldb it silently ignores any commands passed via the options below: --one-line-before-file <command> Tells the debugger to execute this one-line lldb command before any file provided on the command line has been loaded. --one-line <command> Tells the debugger to execute this one-line lldb command after any file provided on the command line has been loaded. --source-before-file <file> Tells the debugger to read in and execute the lldb commands in the given file, before any file has been loaded. --source <file> Tells the debugger to read in and execute the lldb commands in the given file, after any file has been loaded. -O <value> Alias for --one-line-before-file -o <value> Alias for --one-line -S <value> Alias for --source-before-file -s <value> Alias for --source The -O and -S options are quite useful when writing tests for the REPL though, e.g. to change settings prior to entering REPL mode. This patch updates the driver to still respect the commands supplied via -O and -S when passing --repl instead of silently ignoring them. As -s and -o don't really make sense in REPL mode, commands supplied via those options are still ignored, but the driver now emits a warning to make that clear to the user. Patch by Nathan Hawes! Differential Revision: https://reviews.llvm.org/D59681 llvm-svn: 356911
* Minidump: Use minidump constants defined in llvmPavel Labath2019-03-252-2/+2
| | | | | | | | | | | | | | | This patch begins the process of migrating the "minidump" plugin to the minidump parser in llvm. The llvm parser is not fully finished yet, but even now, a lot of things can be switched over. The gradual migration process will allow us to easier detect if things break than doing a big one-step migration. Doing it early will allow us to make sure that the llvm parser fits the use case that we need in lldb. In this patch I start with the various minidump constants, which have their llvm equivalent. It doesn't contain any functional changes. The diff just reflects the different naming of things in llvm. llvm-svn: 356898
* [Reproducers] Properly handle QEnvironment packetsJonas Devlieghere2019-03-211-1/+1
| | | | | | | | On Linux, a QEnvironment packet is sent for every environment variable. This breaks replay when the number of environment variables is different then during capture. The solution is to always reply with OK. llvm-svn: 356643
* Reinitialize UnwindTable when the SymbolFile changesPavel Labath2019-03-182-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a preparatory step to enable adding of unwind plans by symbol file plugins. Although at the surface it seems that currently symbol files have nothing to do with unwinding, this isn't entirely correct even now. The mere act of adding a symbol file can have the effect of making more sections (typically .debug_frame) available to the unwinding machinery, so that it can have more unwind strategies to choose from. Up until now, we've had a bug, which went largely unnoticed, where unwind info in the manually added symbols files (target symbols add) was being ignored during unwinding. Reinitializing the UnwindTable fixes that bug too. Reviewers: clayborg, jasonmolenda, alexshap Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D58347 llvm-svn: 356361
* This test is failing on and off on the bots. Jim Ingham2019-03-121-1/+1
| | | | | | Disable it for now till I can figure out what's going wrong. llvm-svn: 355992
* [Reproducers] Add a test to ensure we can reuse the reproducer dir.Jonas Devlieghere2019-03-121-0/+10
| | | | | | | | Yesterday I noticed a reproducer test failing after making a local change. Removing the reproducer directory solved the issue. Add a test case that detects this. llvm-svn: 355941
* [Reproducers] Support capturing a reproducer without an explicit path.Jonas Devlieghere2019-03-127-11/+25
| | | | | | | | | | | | | | Tablegen doesn't support options that are both flags and take values as an argument. I noticed this when doing the tablegen rewrite, but forgot that that affected the reproducer --capture flag. This patch makes --capture a flag and adds --capture-path to specify a path for the reproducer. In reality I expect this to be mostly used for testing, but it could be useful nonetheless. Differential revision: https://reviews.llvm.org/D59238 llvm-svn: 355936
* Quiet command regex instructions during batch executionDave Lee2019-03-102-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Within .lldbinit, regex commands can be structured as a list of substitutions over multiple lines. It's possible that this is uninentional, but it works and has benefits. For example: command regex <command-name> s/pat1/repl1/ s/pat2/repl2/ ... I use this form of `command regex` in my `~/.lldbinit`, because it makes it clearer to write and read compared to a single line definition, because multiline substitutions don't need to be quoted, and are broken up one per line. However, multiline definitions result in usage instructions being printed for each use. The result is that every time I run `lldb`, I get a dozen or more lines of noise. With this change, the instructions are only printed when `command regex` is invoked interactively, or from a terminal, neither of which are true when lldb is sourcing `~/.lldbinit`. Reviewers: clayborg, jingham Reviewed By: clayborg Subscribers: jdoerfert, kastiglione, xiaobai, keith, lldb-commits Differential Revision: https://reviews.llvm.org/D48752 llvm-svn: 355793
* [lldb] [test] Adjust XFAIL list to match buildbot resultsMichal Gorny2019-03-096-6/+0
| | | | | | | | Adjust the XFAIL-ing tests to match consistent results from buildbot. I'm going to work on differences between them and my local results following this. llvm-svn: 355774
* [lldb-instr] Support LLDB_RECORD_DUMMYJonas Devlieghere2019-03-084-0/+5
| | | | | | | Extend lldb-instr to insert LLDB_RECORD_DUMMY macros for currently unsupported signatures (void and function pointers). llvm-svn: 355710
* [Reproducers] TestImagineList.test -> TestImageList.testJonas Devlieghere2019-03-081-0/+1
| | | | | | And run the actual binary so we load the shared libraries. llvm-svn: 355658
* [lldb] Fix DW_OP_addrx uses.Ali Tamur2019-03-071-0/+66
| | | | | | | | | | | | | | | | Summary: DW_OP_GNU_addr_index has been renamed as DW_OP_addrx in the standard. clang produces DW_OP_addrx tags and with this change lldb starts to process them. Reviewers: aprantl, jingham, davide, clayborg, serge-sans-paille Reviewed By: aprantl Subscribers: jdoerfert, dblaikie, labath, shafik, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D59004 llvm-svn: 355629
* Fix TestDataFormatter.test uninitialized variableJan Kratochvil2019-03-073-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After D55626 I see a failure in my Fedora buildbot. There is uninitialized variable as the Foo constructor has not been run and foo is an autovariable. (lldb) breakpoint set -f foo.cpp -l 11 Breakpoint 1: where = TestDataFormatter.test.tmp.out`main + 30 at foo.cpp:11:7, address = 0x000000000040112e (lldb) run Process 801065 stopped * thread #1, name = 'TestDataFormatt', stop reason = breakpoint 1.1 frame #0: 0x000000000040112e TestDataFormatter.test.tmp.out`main(argc=1, argv=0x00007fffffffcc48) at foo.cpp:11:7 8 }; 9 10 int main(int argc, char **argv) { -> 11 Foo foo(1, 2.22); 12 return 0; 13 } Process 801065 launched: '.../tools/lldb/lit/Reproducer/Functionalities/Output/TestDataFormatter.test.tmp.out' (x86_64) (lldb) frame var (int) argc = 1 (char **) argv = 0x00007fffffffcc48 (Foo) foo = (m_i = 4198432, m_d = 0) While the testcase expects m_i will be 0. Differential Revision: https://reviews.llvm.org/D59088 llvm-svn: 355611
* Skip TestGdbserverPort.test on WindowsJan Kratochvil2019-03-071-1/+3
| | | | | | | | | | | lldb/cmake/modules/LLDBConfig.cmake does not build lldb-server on Windows: if (CMAKE_SYSTEM_NAME MATCHES "Android|Darwin|FreeBSD|Linux|NetBSD") set(LLDB_CAN_USE_LLDB_SERVER 1) Also do not append 'platform' parameter twice - although that was quietly ignored. llvm-svn: 355579
* Avoid using -S in combination with "script"; it's unreliable.Adrian Prantl2019-03-071-1/+1
| | | | llvm-svn: 355573
* [Reproducers] Add tests for different types of functionalityJonas Devlieghere2019-03-076-0/+201
| | | | | | | | | | | | | This patch adds test that check that functionality in lldb continues to work when replaying a reproducer. - Entries in image list are identical. - That stepping behaves the same. - That the data formatters behave the same. Differential revision: https://reviews.llvm.org/D55626 llvm-svn: 355570
* Sanity check --max-gdbserver-portJan Kratochvil2019-03-062-0/+6
| | | | | | | | | | | | | | | | | | | | In mail [lldb-dev] Remote debugging a docker process https://lists.llvm.org/pipermail/lldb-dev/2019-March/014795.html user was confused by --min-gdbserver-port and --max-gdbserver-port options being ignored. I think there is even a bug that --max-gdbserver-port is upper exclusive limit (and not upper inclusive limit appropriate for max). At least this patch should catch such mistake by an error message. The question is whether --max-gdbserver-port should not be changed to really be max and not max+1 but that would break backward compatibility. Now the mail example does produce: error: --min-gdbserver-port (5001) is not lower than --max-gdbserver-port (5001) Differential Revision: https://reviews.llvm.org/D58962 llvm-svn: 355554
* [lldb] [lit] Attempt to fix regex in toolchain-clang.testMichal Gorny2019-03-061-2/+2
| | | | llvm-svn: 355510
* [lldb] [test] Pass appropriate -L&-Wl,-rpath for libc++ on NetBSDMichal Gorny2019-03-064-2/+23
| | | | | | | | | | | | 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
* [Reproducers] Enable replay from SBRepro.Jonas Devlieghere2019-03-064-11/+4
| | | | | | | | | Now that the LLDB instrumentation macros are in place, we should use that to test reproducer replay. Differential revision: https://reviews.llvm.org/D58565 llvm-svn: 355470
* [lit, windows] Disable stop-hook-threads on WindowsStella Stamenova2019-03-051-1/+2
| | | | | | This test is also no longer reliably failing or passing on Windows and it is hanging every few runs. llvm-svn: 355448
* [build.py] Allow clang-cl to build files starting with '/U'Alex Langford2019-03-041-0/+2
| | | | | | | | | | | | | | | | | | Summary: clang-cl tries to match cl's interface, and treats /U as "Removes a predefined macro" as cl does. When you feed clang-cl a file that begins with '/U' (e.g. /Users/xiaobai/foo.c), clang-cl will emit a warning and in some cases an error, like so: clang-9: warning: '/Users/xiaobai/foo.c' treated as the '/U' option [-Wslash-u-filename] clang-9: note: Use '--' to treat subsequent arguments as filenames clang-9: error: no input files If you're using clang-cl, make sure '--' is passed before the source file. Differential Revision: https://reviews.llvm.org/D58860 llvm-svn: 355341
* [lldb] [test] Mark failing tests XFAIL on NetBSDMichal Gorny2019-03-0416-0/+24
| | | | | | | | | | | | | | | | 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
* Reinstate UNSUPPORTED: linux on stop-hook-threads.testPavel Labath2019-03-021-0/+1
| | | | | | | | This stanza was removed in r355213, but it seems that patch did not fully fix the problem, as the test still fails sporadically (particularly under heavy load) on linux. llvm-svn: 355276
* [lldb] [lit] Pass -pthread on NetBSD as wellMichal Gorny2019-03-021-1/+1
| | | | llvm-svn: 355274
* Resubmit r354706 with a fix for process launch.Jim Ingham2019-03-016-18/+21
| | | | | | | | | | | | | | | When the debugger is run in sync mode, you need to be able to tell whether a hijacked resume is for some special purpose (like waiting for the SIGSTOP on attach) or just to perform a synchronous resume. Target::Launch was doing that wrong, and that caused stop-hooks on process launch in source files to behave incorrectly. <rdar://problem/48115661> Differential Revision: https://reviews.llvm.org/D58727 llvm-svn: 355213
* [lldb] [lit] Set LD_LIBRARY_PATH or alike for Suite testsMichal Gorny2019-02-262-0/+24
| | | | | | | | | | | | | | | | Set LD_LIBRARY_PATH or local platform's equivalent of it when running the 'Suite' tests. This is necessary when running tests inside build tree with BUILD_SHARED_LIBS enabled, in order to make the LLDB modules load freshly built LLVM libraries. The code is copied from clang (test/Unit/lit.cfg). SHLIBDIR substitution is added to site-config (already present in top-level LLDB site-config) to future-proof this into supporting stand-alone builds with shared LLDB libraries. Differential Revision: https://reviews.llvm.org/D58610 llvm-svn: 354920
* Fix short options syntax in Minidump testTatyana Krasnukha2019-02-261-20/+20
| | | | llvm-svn: 354890
* Finish revert of r354706Pavel Labath2019-02-251-2/+0
| | | | | | The revert in r354711 wasn't complete. Finish the job. llvm-svn: 354766
* Revert r354706 - lit touched my thighJim Ingham2019-02-237-22/+20
| | | | llvm-svn: 354711
* Make sure that stop-hooks run asynchronously.Jim Ingham2019-02-237-18/+22
| | | | | | | | | | | | | | They aren't designed to nest recursively, so this will prevent that. Also add a --auto-continue flag, putting "continue" in the stop hook makes the stop hooks fight one another in multi-threaded programs. Also allow more than one -o options so you can make more complex stop hooks w/o having to go into the editor. <rdar://problem/48115661> Differential Revision: https://reviews.llvm.org/D58394 llvm-svn: 354706
* Revert "[lldb-mi] Move TestMIPrompt away from pexpect()."Davide Italiano2019-02-211-17/+0
| | | | | | | 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-0/+17
| | | | llvm-svn: 354506
* [TestModuleCXX] Make this test Darwin-only.Jonas Devlieghere2019-02-201-1/+1
| | | | | | | Apparently this functionality is not expected to work on non-Darwin systems. I should've checked the decorator on the original test. llvm-svn: 354487
* [lldb] [ObjectFile/ELF] Fix recognizing NetBSD imagesMichal Gorny2019-02-204-1/+35
| | | | | | | | | | | | | | | | | | | | | Split the recognition into NetBSD executables & shared libraries and core(5) files. Introduce new owner type: "NetBSD-CORE", as core(5) files are not tagged in the same way as regular NetBSD executables. Stop using incorrectly ABI_TAG and ABI_SIZE. Introduce IDENT_TAG, IDENT_DECSZ, IDENT_NAMESZ and PROCINFO. The new values detect correctly the NetBSD images. The patch has been originally written by Kamil Rytarowski. I've added tests and applied minor code changes per review. The work has been sponsored by the NetBSD Foundation. Differential Revision: https://reviews.llvm.org/D42870 llvm-svn: 354466
* [TestModuleCXX] Use UNSUPPORTED instead of REQUIRESJonas Devlieghere2019-02-201-1/+1
| | | | | | | The requires value turns out to be bogus and the test gets skipped on macOS. llvm-svn: 354425
* [lldb-instr] Group RECORD macrosJonas Devlieghere2019-02-201-0/+2
| | | | | | Group LLDB_RECORD macros per input file. llvm-svn: 354423
* [lldb-instr] Don't print REGISTER macro when RECORD is already presentJonas Devlieghere2019-02-191-0/+1
| | | | | | | | | | | Currently we'd always print the LLDB_REGISTER macro, even if the LLDB_RECORD macro was already present. This patches changes that to make it easier to incrementally update the macros. Note that it's still possible for the RECORD and REGISTER macros to get out of sync. llvm-svn: 354400
* Add Facebook Minidump directory streams and options to dump them.Greg Clayton2019-02-192-0/+105
| | | | | | | | Facebook creates minidump files that contain specific information about why things crash. Adding ways to dump these allows tools to be made that can auto download symbols based on the information that is contained in the minidump files. Differential Revision: https://reviews.llvm.org/D58398 llvm-svn: 354385
* Revert "minidump: Add ability to attach (breakpad) symbol files to ↵Pavel Labath2019-02-193-30/+0
| | | | | | | | | | | | | | | | | | placeholder modules" This reverts r354263, because it uncovered a problem in handling of the minidumps with conflicting UUIDs. If a minidump contains two files with the same UUID, we will not create to placeholder modules for them, but instead reuse the first one for the second instance. This creates a problem because these modules have their load address hardcoded in them (and I've added an assert to verify that). Technically this is not a problem with this patch, as the same issue existed in the previous implementation, but it did not have the assert which would diagnose that. Nonetheless, I am reverting this until I figure out what's the best course of action in this situation. llvm-svn: 354324
* [lldb-instr] Test that we ignore existing macros.Jonas Devlieghere2019-02-193-1/+13
| | | | | | Although the functionality was already present, it wasn't tested. llvm-svn: 354303
* [lldb-instr] Wrap returns of struct/classes in LLDB_RECORD_RESULTJonas Devlieghere2019-02-194-1/+8
| | | | | | | The instrumentation framework requires return values of custom classes and structs to be wrapped in the LLDB_RECORD_RESULT macro. llvm-svn: 354301
* Disable TestModuleCXX.test on WindowsJonas Devlieghere2019-02-191-0/+2
| | | | | | | | | | Importing cxx modules doesn't seem to work on Windows: error: a.out :: Class 'tagARRAYDESC' has a member 'tdescElem' of type 'tagTYPEDESC' which does not have a complete definition. error: a.out :: Class 'tagPARAMDESCEX' has a member 'varDefaultValue' of type 'tagVARIANT' which does not have a complete definition. llvm-svn: 354300
* [lldb-instr] Add constructor and move test into lit/toolsJonas Devlieghere2019-02-184-16/+26
| | | | | | | | The test had an implicit constructor for the Foo struct. Also, as the instrumentation doesn't have to be reproducer specific, I moved the tests into the lit/tools directory. llvm-svn: 354294
* [Reproducers] Make clang use lldb's VFS.Jonas Devlieghere2019-02-188-10/+60
| | | | | | | | | | In r353906 we hooked up clang and lldb's reproducer infrastructure to capture files used by clang. This patch adds the necessary logic to have clang reuse the files from lldb's reproducer during replay. Differential revision: https://reviews.llvm.org/D58309 llvm-svn: 354283
* minidump: Add ability to attach (breakpad) symbol files to placeholder modulesPavel Labath2019-02-183-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-commits r353677, which was reverted due to test failures on the windows bot. The issue there was that ObjectFilePECOFF vended its base address through the incorrect interface. SymbolFilePDB depended on that, which lead to assertion failures when SymbolFilePDB was attempting to use the placeholder object files as a base. This has been fixed in r354258 It also fixes one small problem in the original patch. The issue was that the Module class would attempt to overwrite the object file we created in CreateModuleFromObjectFile if the file corresponding to the placeholder object file happened to exist (but we have already disqualified it due to UUID mismatch. The fix is simple -- we set the m_did_load_objfile flag to properly record the fact that we have already created an object file for the module. The original commit message was: The reason this wasn't working was that ProcessMinidump was creating odd object-file-less modules, and SymbolFileBreakpad required the module to have an associated object file because it needed to get its base address. This fixes that by introducing a PlaceholderObjectFile to serve as a dummy object file. The general idea for this is taken from D55142, but I've reworked it a bit to avoid the need for the PlaceholderModule class. Now that we have an object file, our modules are sufficiently similar to regular modules that we can use the regular Module class almost out of the box -- the only thing I needed to tweak was the Module::CreateModuleFromObjectFile functon to set the module's FileSpec in addition to it's architecture. This wasn't needed for ObjectFileJIT (the other user of CreateModuleFromObjectFile), but it shouldn't hurt it either, and the change seems like a straightforward extension of this function. Reviewers: clayborg, lemo, amccarth Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D57751 llvm-svn: 354263
* PECOFF: Implement GetBaseAddressPavel Labath2019-02-181-0/+86
| | | | | | | | | | | | | | | | | | COFF files are modelled in lldb as having one big container section spanning the entire module image, with the actual sections being subsections of that. In this model, the base address is simply the address of the first byte of that section. This also removes the hack where ObjectFilePECOFF was using the m_file_offset field to communicate this information. Using file offset for this purpose is completely wrong, as that is supposed to indicate where is this ObjectFile located in the file on disk. This field is only meaningful for fat binaries, and should normally be 0. Both PDB plugins have been updated to use GetBaseAddress instead of GetFileOffset. llvm-svn: 354258
* Disable stop-hook-threads.test on LinuxJorge Gorbe Moya2019-02-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ExecControl/StopHook/stop-hook-threads.test is flaky on Linux (it's consistently failing on my machine, but doesn't fail on a co-worker's). I'm seeing the following assertion failure: ``` CommandObject.cpp:145: bool lldb_private::CommandObject::CheckRequirements(lldb_private::CommandReturnObject&): Assertion `m_exe_ctx.GetTargetPtr() == NULL' failed. ``` Interestingly, this doesn't happen when typing the same commands in interactive mode. The cause seems to be that, in synchronous execution mode continue waits until the process stops again, and that includes running any stop-hooks for that later stop, so we end with a stack trace like this (lots of frames omitted for clarity): ``` abort() CommandObject::CheckRequirements() <-- this is again the same instance of CommandObjectProcessContinue, fails assertion because the previous continue command hasn't finished. Target::RunStopHooks() CommandObjectProcessContinue::DoExecute() Target::RunStopHooks() ``` In general, it seems like using process control commands inside stop-hooks does not have very well defined semantics. You don't even need multiple threads to make that assertion fail, you can build ``` int main() { printf("1\n"); // break1 printf("2\n"); // break2 } ``` and then on lldb ``` target stop-hook add -o continue break set -f stop-hook-simple.cpp -p "break1" break set -f stop-hook-simple.cpp -p "break2" run ``` In this case it's even worse because the presence of multiple threads makes it prone to race conditions. In some tests I ran with a simpler version of this test case, I was hitting either the previous assertion failure or the following issue: 1. Two threads reach a breakpoint 2. First stop-hook does a process continue 3. Threads end 4. Second stop-hook runs, complains about process not existing. This change disables the test on Linux. It's already marked as XFAIL on Windows, so maybe we should just delete it until it's clear what should be the expected behavior in these cases. Or maybe try to come up with a way to write a similar multithreaded test without calling continue from a stop hook, I don't know. Differential Revision: https://reviews.llvm.org/D58257 llvm-svn: 354149
OpenPOWER on IntegriCloud