summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/functionalities/breakpoint
Commit message (Collapse)AuthorAgeFilesLines
* Canonicalize variable usage in testsuite MakefilesAdrian Prantl2019-09-2513-14/+19
| | | | | | | | | | | | This test streamlines our use of variables that are expected by Makefile.rules throughout the test suite. Mostly it replaced potentially dangerous overrides and updates of variables like CFLAGS with safe assignments to variables reserved for this purpose like CFLAGS_EXTRAS. Differential Revision: https://reviews.llvm.org/D67984 llvm-svn: 372795
* [lldb][NFC] Simplify makefiles also for breakpoint testsRaphael Isemann2019-09-1230-90/+30
| | | | | | | | These tests were temporarily missing when the big Makefile simplification patch landed, so this just applies the same change to these tests. llvm-svn: 371738
* [lldb] Readd missing functionalities/breakpoint testsRaphael Isemann2019-09-10108-0/+5369
| | | | | | | It seems when I restructured the test folders the functionalities/breakpoint was deleted. This just reverts this change and re-adds the tests. llvm-svn: 371512
* [lldb] Restructure test folders to match LLDB command hierarchyRaphael Isemann2019-09-01108-5369/+0
| | | | | | | | | | | | | | | | | | | Summary: As discussed on lldb-dev, this patch moves some LLDB tests into a hierarchy that more closely resembles the commands we use in the LLDB interpreter. This patch should only move tests that use the command interpreter and shouldn't touch any tests that primarily test the SB API. Reviewers: #lldb, jfb, JDevlieghere Reviewed By: #lldb, JDevlieghere Subscribers: dexonsmith, arphaman, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67033 llvm-svn: 370605
* [LLDB][Test] Remove `skipIfWindows` for conditional breakpoint test (NFC)Med Ismail Bennani2019-08-201-8/+0
| | | | | | | | | | | | | | | | | | | | | Summary: The test for conditional breakpoints on Windows was skipped because there was no expression evaluation support at the time it was written. After removing the annotation and testing it again, the test is passing. http://lists.llvm.org/pipermail/lldb-dev/2019-August/015405.html Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com> Reviewers: stella.stamenova, jingham Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66499 llvm-svn: 369453
* [lldb][NFC] Remove unused imports in python testsRaphael Isemann2019-08-0229-63/+0
| | | | llvm-svn: 367663
* [lldb][test_suite] Update tests with unexpected pass on Android aarch64Alex Langford2019-07-231-2/+0
| | | | | | | | | | Summary: update some test decorates that can actually pass on andriod aarch64 Patch by Wanyi Ye <kusmour@gmail.com> Differential Revision: https://reviews.llvm.org/D64767 llvm-svn: 366858
* [lldb] [test] Mark frequently failing flaky tests skipped on NetBSDMichal Gorny2019-05-151-1/+1
| | | | llvm-svn: 360767
* Improve step over performance by not stopping at branches that are function ↵Greg Clayton2019-05-091-4/+3
| | | | | | | | | | calls and stepping into and them out of each one Currently when we single step over a source line, we run and stop at every branch in the source line range. We can reduce the number of times we stop when stepping over by figuring out if any of these branches are function calls, and if so, ignore these branches. Since we are stepping over we can safely ignore these calls since they will return to the next instruction. Currently the step logic would stop at those branches (1st stop), single step into the branch (2nd stop), and then set a breakpoint at the return address (3rd stop), and then continue. Differential Revision: https://reviews.llvm.org/D58678 llvm-svn: 360375
* [lldb] [test] Mark a few tests flakey on NetBSDMichal Gorny2019-03-111-0/+1
| | | | llvm-svn: 355830
* [lldb] [test] Mark failing tests XFAIL on NetBSDMichal Gorny2019-03-043-0/+3
| | | | | | | | | | | | | | | | 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
* When deserializing breakpoints some options may not be present.Jim Ingham2019-02-221-0/+6
| | | | | | | | | | | The deserializer was not handling this case. For now we just accept the absent option, and set it to the breakpoint default. This will be more important if/when I figure out how to serialize the options set on breakpont locations. <rdar://problem/48322664> llvm-svn: 354702
* testsuite: Fix TestCompDirSymLink and TestSourceManager on Linux with ↵Jan Kratochvil2019-02-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | symlinked build dir Getting failure when building in a directory which is symlinked elsewhere: Failing Tests (1): lldb-Suite :: functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.py lldb-Suite :: source-manager/TestSourceManager.py For TestCompDirSymLink: ------------------------------------------------------------------------------ runCmd: file .../lldb-test-build.noindex/functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.test_symlink_paths_set_procselfcwd_dwarf/CompDirSymLink output: Current executable set to '.../lldb-test-build.noindex/functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.test_symlink_paths_set_procselfcwd_dwarf/CompDirSymLink' (x86_64). runCmd: settings set plugin.symbol-file.dwarf.comp-dir-symlink-paths /proc/self/cwd output: None runCmd: breakpoint set -f ".../lldb-test-build.noindex/functionalities/breakpoint/comp_dir_symlink/TestCompDirSymLink.test_symlink_paths_set_procselfcwd_dwarf/relative.cpp" -l 11 output: Breakpoint 1: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. It is because /proc/self/cwd (used above for plugin.symbol-file.dwarf.comp-dir-symlink-paths) points to an already resolved directory: (cd /tmp;mkdir real;ln -s real symlink;cd symlink;ls -l /proc/self/cwd) lrwxrwxrwx 1 jkratoch jkratoch 0 Feb 20 19:55 /proc/self/cwd -> /tmp/real/ ------------------------------------------------------------------------------ For TestSourceManager the resolving is done by 'make -C' as found by Pavel Labath. Differential Revision: https://reviews.llvm.org/D58465 llvm-svn: 354556
* [Python2 to Python 3] Fix print -> print().Davide Italiano2019-02-051-6/+6
| | | | llvm-svn: 353130
* [Test] Fix up tests affected by the new LLVM header.Jonas Devlieghere2019-01-221-4/+4
| | | | | | | | | The new LLVM header is one line shorter than the old one, which lead to some test failures. Ideally tests should rely on line numbers for breakpoints or output, but that's a different discussion. Hopefully this turns the bots green again. llvm-svn: 351779
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1913-52/+39
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [lit] Use the new build.py script in the lldb-mi testsStella Stamenova2018-12-181-2/+0
| | | | | | This allows the tests to pass on Windows as well llvm-svn: 349562
* Skip TestRequireHWBreakpoints on WindowsJonas Devlieghere2018-11-301-0/+4
| | | | | | | | | The test assumes that HW breakpoints are not implemented by the debug server. Windows doesn't use these and might actually support HW breakpoints so these tests are expected fail because they don't raise the expected error. llvm-svn: 348010
* Add setting to require hardware breakpoints.Jonas Devlieghere2018-11-153-0/+120
| | | | | | | | | | | | | | | | When debugging read-only memory we cannot use software breakpoint. We already have support for hardware breakpoints and users can specify them with `-H`. However, there's no option to force LLDB to use hardware breakpoints internally, for example while stepping. This patch adds a setting target.require-hardware-breakpoint that forces LLDB to always use hardware breakpoints. Because hardware breakpoints are a limited resource and can fail to resolve, this patch also extends error handling in thread plans, where breakpoints are used for stepping. Differential revision: https://reviews.llvm.org/D54221 llvm-svn: 346920
* [lldbsuite] Mark the TestScriptedResolver tests as XFAIL on WindowsStella Stamenova2018-10-181-0/+4
| | | | | | | | | | | | Summary: They fail similarly to some of the other breakpoint tests on Windows, so I suspect the cause is the same. I've linked to the same bug. Reviewers: asmith, zturner, jingham Subscribers: abidh, lldb-commits Differential Revision: https://reviews.llvm.org/D53331 llvm-svn: 344744
* Skip test if gcc version is less than 7.1 since it doesn't support ↵Tatyana Krasnukha2018-09-211-0/+4
| | | | | | -gcolumn-info option llvm-svn: 342732
* Make the eSearchDepthFunction searches work, add tests Jim Ingham2018-09-142-8/+31
| | | | | | | | using the scripted breakpoint resolver. Differential Revision: https://reviews.llvm.org/D52111 llvm-svn: 342259
* svn add the new files...Jim Ingham2018-09-134-0/+253
| | | | | | | | | I started from a clean slate to do the checkin, but forgot to svn add the new files. Do that now. Also add the one new source file to CMakeLists.txt llvm-svn: 342190
* Rollback "Fix raw address breakpoints not resolving".Davide Italiano2018-09-101-37/+0
| | | | | | | It broke a bunch of bots. Ted confirmed, but can't revert for now so I'm reverting on his behalf. llvm-svn: 341878
* Fix raw address breakpoints not resolvingTed Woodward2018-09-101-0/+37
| | | | | | | | | | | | | | Summary: An address breakpoint of the form "b 0x1000" won't resolve if it's created while the process isn't running. This patch deletes Address::SectionWasDeleted, renames Address::SectionWasDeletedPrivate to SectionWasDeleted (and makes it public), and changes the section check in Breakpoint::ModulesChanged back to its original form Reviewers: jingham, #lldb Reviewed By: jingham Subscribers: davide, lldb-commits Differential Revision: https://reviews.llvm.org/D51816 llvm-svn: 341849
* Support setting a breakpoint by FileSpec+Line+Column in the SBAPI.Adrian Prantl2018-08-305-5/+81
| | | | | | | | | | | | This patch extends the SBAPI to allow for setting a breakpoint not only at a specific line, but also at a specific (minimum) column. When a column is specified, it will try to find an exact match or the closest match on the same line that comes after the specified location. Differential Revision: https://reviews.llvm.org/D51461 llvm-svn: 341078
* If a function starts with line number 0, don't try to check if a breakpoint ↵Jim Ingham2018-08-072-1/+7
| | | | | | | | | | crossed function boundaries. clang doesn't use line number 0 (to mean artifically generated code) very often, but swift does it quite often. We were rejecting all by line breakpoints in functions that started at line 0. But that's a special marker so we can just not do this test in that case. llvm-svn: 339182
* [lldbsuite, windows] Mark tests as XFAIL on Windows or skip themStella Stamenova2018-08-021-0/+2
| | | | | | | | | | | | | | Summary: 1) Several tests that are flakey on windows fail the run even if they are marked as expected to be flakey. This is because they fail frequently enough that even a retry won't help 2) Skip several tests on Windows that will occasionally hang rather than failing or exiting. This is causing the entire test suite to hang Reviewers: asmith, labath, zturner Reviewed By: zturner Differential Revision: https://reviews.llvm.org/D50198 llvm-svn: 338769
* Fix whitespace in the python test suite.Raphael Isemann2018-07-277-44/+40
| | | | | | | | | | | | | 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
* [lldbsuite] Fix TestBreakpointHitCount on WindowsStella Stamenova2018-06-281-1/+1
| | | | | | | | | | | | Summary: On Windows, the newer DIA SDKs end up producing function names that contain the return type as well. This means that the function name returned in the test will contain the return type (int) in addition to the name of the function and the type of the input (a(int)). To account for the possibility of both, the test should pass if the function name matches either pattern. Reviewers: zturner, asmith Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48654 llvm-svn: 335906
* Make test sources compatible with android+libcxx+modulesPavel Labath2018-06-201-45/+45
| | | | | | | | | | | | | | In a modules build, android is very picky about which symbols are visible after including libc++ headers (e.g. <cstdio> defines only std::printf and not ::printf). This consolidates the tests where this was an issue to always include the <c???> version of the headers and prefixes the symbols with std:: as necessary. Apart from that, there is no functional change in the tests. llvm-svn: 335149
* Fix the 'tb' alias commandFrederic Riss2018-06-181-0/+25
| | | | | | | No idea when this broke or if it ever worked. Added a small test for one-shot breakpoints while I was there. llvm-svn: 334921
* Fix/unify the spelling of Objective-C.Adrian Prantl2018-06-131-1/+1
| | | | llvm-svn: 334614
* 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
* Allow relative file paths when settings source breakpointsGreg Clayton2018-04-131-1/+25
| | | | | | | | | | | | | | | | | 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
* [dotest] Clean up test folder clean-upPavel Labath2018-03-161-2/+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
* Add "lldb-test breakpoint" command and convert the case-sensitivity test to ↵Pavel Labath2018-02-263-143/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | use it Summary: The command takes two input arguments: a module to use as a debug target and a file containing a list of commands. The command will execute each of the breakpoint commands in the file and dump the breakpoint state after each one. The commands are expected to be breakpoint set/remove/etc. commands, but I explicitly allow any lldb command here, so you can do things like change setting which impact breakpoint resolution, etc. There is also a "-persistent" flag, which causes lldb-test to *not* automatically clear the breakpoint list after each command. Right now I don't use it, but the idea behind it was that it could be used to test more complex combinations of breakpoint commands (set+modify, set+disable, etc.). Right now the command prints out only the basic breakpoint state, but more information can be easily added there. To enable easy matching of the "at least one breakpoint location found" state, the command explicitly prints out the string "At least one breakpoint location.". To enable testing of breakpoints set with an absolute paths, I add the ability to perform rudimentary substitutions on the commands: right now the string %p is replaced by the directory which contains the command file (so, under normal circumstances, this will perform the same substitution as lit would do for %p). I use this command to rewrite the TestBreakpointCaseSensitivity test -- the test was checking about a dozen breakpoint commands, but it was launching a new process for each one, so it took about 90 seconds to run. The new test takes about 0.3 seconds for me, which is approximately a 300x speedup. Reviewers: davide, zturner, jingham Subscribers: luporl, lldb-commits Differential Revision: https://reviews.llvm.org/D43686 llvm-svn: 326112
* Fix TestMoveNearest on WindowsAdrian McCarthy2018-02-221-3/+2
| | | | | | | | | | The header file for the DLL tried to declare inline functions and a local function as dllexport which broke the compile and link. Removing the bad declarations solves the problem, and the test passes on Windows now. Differential Revision: https://reviews.llvm.org/D43600 llvm-svn: 325836
* Fix TestBreakpointInGlobalConstructor for WindowsAdrian McCarthy2018-02-211-1/+2
| | | | | | | | | | | | | | | | | | Summary: This test was failing on Windows because it expected the breakpoint in the dynamic library to be resolved before the process is launched. Since the DLL isn't loaded until the process is launched this didn't work. The fix creates a special value (-2) for num_expected_locations that ignores the actual number of breakpoint locations found. Reviewers: jasonmolenda Subscribers: sanjoy, lldb-commits Differential Revision: https://reviews.llvm.org/D43419 llvm-svn: 325704
* 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
OpenPOWER on IntegriCloud