summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/functionalities/breakpoint
Commit message (Collapse)AuthorAgeFilesLines
* Avoid dirtying the source tree in breakpoint command testsPavel Labath2018-02-204-92/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The paralelization patch exposed a bunch of cases where we were still touching the source tree (as these tests were now stepping on each others toes and being flaky). This patch removes such issues from breakpoint command tests. Since the only reason they were creating files was to indirectly test whether the breakpoint commands got executed (and plumbing the full build tree path to all places that needed it would be messy) I decided to modify the tests to check for a different side effect instead: modification of a global variable. This also makes the code simpler as checking the value of the global variable is easier, and there is nothing to clean up. As the tests aren't really doing anything debug-info related, I took the opportunity to also mark them as NO_DEBUG_INFO_TESTCASEs. Reviewers: jingham, aprantl Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D43464 llvm-svn: 325570
* Only throw -fPIC when building a shared libraryAaron Smith2018-02-082-2/+0
| | | | | | | | | | | | | | | | | | Summary: Update makefiles to specify -fPIC in Makefile.rules and only throw -fPIC when building a shared library. This change is necessary to allow building the lldb tests on Windows where -fPIC is not a valid option. Update a few places to Python 3.x syntax Reviewers: zturner, lldb-commits Reviewed By: zturner Subscribers: stella.stamenova, labath, llvm-commits Differential Revision: https://reviews.llvm.org/D42994 llvm-svn: 324671
* Build each testcase variant in its own subdirectory and remove the srcdir ↵Adrian Prantl2018-02-061-5/+7
| | | | | | | | | | | | | | lock file This patch creates a <test>.dwarf, <test>.dwo, etc., build directory for each testcase variant. Most importantly, this eliminates the need for the per-test lock file in the source directory. Tests that are marked as NO_DEBUG_INFO_TESTCASE and build with buildDefault() are built in a <test>.default build directory. Differential Revision: https://reviews.llvm.org/D42763 llvm-svn: 324368
* Add more diagnostics to help diagnose flaky testAdrian Prantl2018-01-301-4/+6
| | | | llvm-svn: 323808
* Compile the LLDB tests out-of-tree.Adrian Prantl2018-01-308-25/+32
| | | | | | | | | | | | | | | | | | | | | | | | 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-1928-42/+38
| | | | | | | | | 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
* Advanced guessing of rendezvous breakpoint (resubmit)Eugene Zemtsov2018-01-111-8/+8
| | | | | | | | | | | | | When rendezvous structure is not initialized we need to set up rendezvous breakpoint anyway. In this case the code will locate dynamic loader (interpreter) and look for known function names. This is r322209, but with fixed VDSO loading fixed. Bug: https://bugs.llvm.org/show_bug.cgi?id=25806 Differential Revision: https://reviews.llvm.org/D41533 llvm-svn: 322251
* Revert "Advanced guessing of rendezvous breakpoint"Eugene Zemtsov2018-01-101-8/+8
| | | | | | | This reverts commit r322209, because it broke TestNoreturnUnwind,TestInferiorAssert and TestNumThreads on i386. llvm-svn: 322229
* Advanced guessing of rendezvous breakpointEugene Zemtsov2018-01-101-8/+8
| | | | | | | | | | | When rendezvous structure is not initialized we need to set up rendezvous breakpoint anyway. In this case the code will locate dynamic loader (interpreter) and look for known function names. Bug: https://bugs.llvm.org/show_bug.cgi?id=25806 Differential Revision: https://reviews.llvm.org/D41533 llvm-svn: 322209
* Fix this test so that the breakpoints you set areJim Ingham2017-11-302-2/+6
| | | | | | | | unambiguously on one bit of code. On macOS these lines mapped to two distinct locations, and that was artificially throwing off the test. llvm-svn: 319472
* Add a test case for open bug 35480Pavel Labath2017-11-305-0/+82
| | | | | | | The test is about failing to hit breakpoints in global constructors in shared libraries. llvm-svn: 319443
* Wire up the breakpoint name help string.Jim Ingham2017-09-151-5/+22
| | | | llvm-svn: 313327
* Make breakpoint names real entities.Jim Ingham2017-09-143-21/+230
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When introduced, breakpoint names were just tags that you could apply to breakpoints that would allow you to refer to a breakpoint when you couldn't capture the ID, or to refer to a collection of breakpoints. This change makes the names independent holders of breakpoint options that you can then apply to breakpoints when you add the name to the breakpoint. It adds the "breakpoint name configure" command to set up or reconfigure breakpoint names. There is also full support for then in the SB API, including a new SBBreakpointName class. The connection between the name and the breakpoints sharing the name remains live, so if you reconfigure the name, all the breakpoint options all change as well. This allows a quick way to share complex breakpoint behavior among a bunch of breakpoints, and a convenient way to iterate on the set. You can also create a name from a breakpoint, allowing a quick way to copy options from one breakpoint to another. I also added the ability to make hidden and delete/disable protected names. When applied to a breakpoint, you will only be able to list, delete or disable that breakpoint if you refer to it explicitly by ID. This feature will allow GUI's that need to use breakpoints for their own purposes to keep their breakpoints from getting accidentally disabled or deleted. <rdar://problem/22094452> llvm-svn: 313292
* Commands are -d to break modify, not -C.Jim Ingham2017-09-141-1/+1
| | | | | | | | The auto-continue test was using the new (better) name for providing commands (-C) but I haven't checked in that change yet. Put the test back to the old way for now. llvm-svn: 313221
* Forgot to svn add the test cases for breakpoint auto-continue flag.Jim Ingham2017-09-133-0/+129
| | | | | | Adding that now. llvm-svn: 313216
* Add an auto-continue flag to breakpoints & locations.Jim Ingham2017-08-031-1/+30
| | | | | | | | | | | | | | You can get a breakpoint to auto-continue by adding "continue" as a command, but that has the disadvantage that if you hit two breakpoints simultaneously, the continue will force the process to continue, and maybe even forstalling the commands on the other. The auto-continue flag means the breakpoints can negotiate about whether to stop. Writing tests, I wanted to supply some commands when I made the breakpoints, so I also added that ability. llvm-svn: 309969
* Fix a mis-feature with propagation of breakpoint options -> location options.Jim Ingham2017-08-021-7/+101
| | | | | | | | | | | | | | When an option was set at on a location, I was just copying the whole option set to the location, and letting it shadow the breakpoint options. That was wrong since it meant changes to unrelated options on the breakpoint would no longer take on this location. I added a mask of set options and use that for option propagation. I also added a "location" property to breakpoints, and added SBBreakpointLocation.{G,S}etCommandLineCommands since I wanted to use them to write some more test cases. <rdar://problem/24397798> llvm-svn: 309772
* Expose hit count via SBBreakpointLocation.Bruce Mitchener2017-07-193-0/+141
| | | | | | | | | | | | | | | Summary: SBBreakpointLocation exposed the ignore count, but didn't expose the hit count. Both values were exposed by SBBreakpoint and SBWatchpoint, so this makes things a bit more consistent. Reviewers: lldb-commits Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D31283 llvm-svn: 308480
* Convert a few more tests to use run_to_source_breakpoint.Jim Ingham2017-07-132-58/+5
| | | | llvm-svn: 307943
* [LLDB][MIPS] Fix TestStepOverBreakpoint.py failure.Nitesh Jain2017-05-041-5/+4
| | | | | | | | | | Reviewers: jingham, labath Subscribers: jaydeep, bhushan, lldb-commits, slthakur Differential Revision: https://reviews.llvm.org/D32168 llvm-svn: 302139
* Fix TestMoveNearest for remote targetsPavel Labath2017-03-151-1/+2
| | | | | | | Launching a process with shared libraries on remote targets requires a special dance, which I forgot to do in r297830. llvm-svn: 297834
* Fix TestMoveNearest breakage on darwinPavel Labath2017-03-151-0/+4
| | | | | | | | | It seems that on darwin we are not able to resolve breakpoints in the test shared library until the process has started. That seems unfortunate, but it is not the purpose of this test, so work around that by starting the process before doing the rest of our checks. llvm-svn: 297830
* BreakpointResolverFileLine: Restrict move-to-nearest-code from moving across ↵Pavel Labath2017-03-157-15/+85
| | | | | | | | | | | | | | | | | | | | | | | | | function boundaries Summary: This fixes the case where a user tries to set a breakpoint on a source line outside of any function (e.g. because that code is #ifdefed out, or the compiler did not emit code for the function, etc.) and we would silently move the breakpoint to the next function. Now we check whether the line range of the resolved symbol context function matches the original line number. We reject any breakpoint locations that appear to move the breakpoint into a new function. This filtering only happens if we have full debug info available (e.g. in case of -gline-tables-only compilation, we still set the breakpoint on the nearest source line). Reviewers: jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D30817 llvm-svn: 297817
* Switch SBBreakpoint to storing a weak_ptr of the internal breakpoint objectPavel Labath2017-02-271-1/+0
| | | | | | | | | | | | | | | | | Summary: There is nothing we can do with the breakpoint once the associated target becomes deleted. This will make sure we don't hold on to more resources than we need in this case. In particular, this fixes the case TestStepOverBreakpoint on windows, where a lingering SBBreakpoint object causes us to nor unmap the executable file from memory. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D30249 llvm-svn: 296328
* Hardware breakpoints for Linux on Arm/AArch64 targetsOmair Javaid2017-02-243-0/+171
| | | | | | | | Please look at below differential link for upstream discussion. Differential revision: https://reviews.llvm.org/D29669 llvm-svn: 296119
* Skip TestStepOverBreakpoint on windowsPavel Labath2017-02-151-0/+2
| | | | llvm-svn: 295211
* Bug 30863 - Step doesn't stop with conditional breakpoint on the next lineBoris Ulasevich2017-02-153-0/+140
| | | | | | | | | Differential Revisions: https://reviews.llvm.org/D26497 (committed r290168, temporary reverted r290197) https://reviews.llvm.org/D28945 (fix for Ubuntu tests fail) https://reviews.llvm.org/D29909 (fix for TestCallThatThrows test fail) llvm-svn: 295168
* Unroll r292930 due to TestCallThatThrows test fail is not fixed in ↵Boris Ulasevich2017-01-273-140/+0
| | | | | | reasonable time. llvm-svn: 293269
* Bug 30863 - Step doesn't stop with conditional breakpoint on the next lineBoris Ulasevich2017-01-243-0/+140
| | | | | | | | Differential Revisions: https://reviews.llvm.org/D26497 (committed r290168, temporary reverted r290197) https://reviews.llvm.org/D28945 (fix for Ubuntu tests fail) llvm-svn: 292930
* Rollback my commit r290168 to fix linux tests failure. I'll be back!Boris Ulasevich2016-12-203-140/+0
| | | | llvm-svn: 290197
* Bug 30863 - Step doesn't stop with coditional breakpoint on the next lineBoris Ulasevich2016-12-203-0/+140
| | | | | | | | | Fixed by additional completed plans detection, and applying them on breakpoint condition fail. Thread::GetStopInfo reworked. New test added. Review https://reviews.llvm.org/D26497 Many thanks to Jim llvm-svn: 290168
* Test num locations >= 1 not == 1.Jim Ingham2016-12-141-1/+1
| | | | llvm-svn: 289695
* These test cases don't test different debug info formats.Jim Ingham2016-10-062-0/+4
| | | | llvm-svn: 283468
* Fix the decorator of TestBreakpointCaseSensitivityTamas Berghammer2016-10-041-4/+2
| | | | llvm-svn: 283262
* Fix test when using remote debugging.Pavel Labath2016-10-041-1/+1
| | | | | | | | | | | | | | Summary: Use os.getcwd() instead of get_process_working_directory() as prefix for souce file. Reviewers: labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D25217 llvm-svn: 283171
* IsValid is the way to ask a breakpoint location whether it is valid.Jim Ingham2016-09-301-2/+3
| | | | llvm-svn: 282966
* Fix serialization of Python breakpoint commands.Jim Ingham2016-09-262-3/+3
| | | | | | | | | | | CommandData breakpoint commands didn't know whether they were Python or Command line commands, so they couldn't serialize & deserialize themselves properly. Fix that. I also changed the "breakpoint list" command to note in the output when the commands are Python commands. Fortunately only one test was relying on this explicit bit of text output. llvm-svn: 282432
* Add the ability to append breakpoints to the save file.Jim Ingham2016-09-221-3/+57
| | | | llvm-svn: 282212
* Add the ability to deserialize only breakpoints matching a given name.Jim Ingham2016-09-221-1/+34
| | | | | | Also tests for this and the ThreadSpec serialization. llvm-svn: 282207
* Probably should add the breakpoint names test directory as well...Jim Ingham2016-09-213-0/+200
| | | | llvm-svn: 282103
* Add some more tests for breakpoint serialization.Jim Ingham2016-09-201-45/+99
| | | | | | | | | | Serialize breakpoint names & the hardware_requested attributes. Also added a few missing affordances to SBBreakpoint whose absence writing the tests pointed out. <rdar://problem/12611863> llvm-svn: 282036
* First tests for serializing breakpoints.Jim Ingham2016-09-163-0/+206
| | | | | | Plus a few bug fixes I found along the way. llvm-svn: 281690
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-0624-514/+921
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Remove a test that depends on knowing all compiler's register allocation ↵Jim Ingham2016-08-191-23/+0
| | | | | | | | | | | schemes. This test was using a condition that would compare a variable against the register that would hold it. It was failing with clang on arm64 because clang put the variable on the stack. This is not a supportable way to write tests. llvm-svn: 279345
* Undid LLVM macro usage in test suite test subject files.Todd Fiala2016-08-101-7/+7
| | | | llvm-svn: 278197
* Delete Host/windows/win32.hZachary Turner2016-08-091-7/+7
| | | | | | | | | | | | | | | | | | | It's always hard to remember when to include this file, and when you do include it it's hard to remember what preprocessor check it needs to be behind, and then you further have to remember whether it's windows.h or win32.h which you need to include. This patch changes the name to PosixApi.h, which is more appropriately named, and makes it independent of any preprocessor setting. There's still the issue of people not knowing when to include this, because there's not a well-defined set of things it exposes other than "whatever is missing on Windows", but at least this should make it less painful to fix when problems arise. This patch depends on LLVM revision r278170. llvm-svn: 278177
* Errors compiling breakpoint conditions will cause the breakpoint not to be hitJim Ingham2016-08-031-0/+44
| | | | | | | | | This was a shadowed variable error from the big Expression Parser plugin-ification. I also added a test case for this. <rdar://problem/27682376> llvm-svn: 277662
* LLDB help content has accumulated over time without a recent attempt toKate Stone2016-07-141-1/+1
| | | | | | | | | review it for consistency, accuracy, and clarity. These changes attempt to address all of the above while keeping the text relatively terse. <rdar://problem/24868841> llvm-svn: 275485
* Enable some tests on linuxPavel Labath2016-06-091-1/+0
| | | | | | | | | This enables a couple of tests which have been shown to run reliably on the linux x86 buildbot. If you see a failure after this commit, feel free to add the xfail back, but please make it as specific as possible (i.e., try to make it not cover i386/x86_64 with clang-3.5, clang-3.9 or gcc-4.9). llvm-svn: 272326
* Fix error propagation from the Z0 packet in gdb-remote breakpoint setting.Jim Ingham2016-05-191-0/+77
| | | | | | | | | | | | | The error was not getting propagated to the caller, so the higher layers thought the breakpoint was successfully set & resolved. I added a testcase, but it assumes 0x0 is not a valid place to set a breakpoint. On most systems that is true, but if it isn't true of your system, either find another good place and add it to the test, or x-fail the test. <rdar://problem/26345962> llvm-svn: 270014
OpenPOWER on IntegriCloud