summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/python_api
Commit message (Collapse)AuthorAgeFilesLines
* Makefile.rules: compile all tests with -fno-limit-debug-infoPavel Labath2017-12-041-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This flag is on by default for darwin and freebsd, but off for linux. Without it, clang will sometimes not emit debug info for types like std::string. Whether it does this, and which tests will fail because of that depends on the linux distro and c++ library version. A bunch of tests were already setting these flags manually, but here instead I take a whole sale approach and enable this flag for all tests. Any test which does not want to have this flag (right now we have one such test) can turn it off explicitly via CFLAGS_EXTRAS+=$(LIMIT_DEBUG_INFO_FLAGS) This fixes a bunch of data formatter tests on red-hat. Reviewers: davide, jankratochvil Subscribers: emaste, aprantl, krytarowski, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D40717 llvm-svn: 319653
* Remove android watchpoint xfailsPavel Labath2017-11-026-14/+0
| | | | | | | | Now that the wathpoint tests have their own category, we can easily skip them on devices which don't have watchpoint support. Therefore, we don't need an android xfail on each of these tests. llvm-svn: 317276
* Revert r317182 for https://reviews.llvm.org/D39128Jason Molenda2017-11-021-228/+0
| | | | | | | we're still failing on android. I'll ask Larry to ask Pavel for any tips he might be able to give. llvm-svn: 317183
* Commit Lawrence D'Anna's patch to changeJason Molenda2017-11-021-0/+228
| | | | | | | | | | | | | | | SetOututFileHandle to work with IOBase. I did make one change after checking with Larry -- I renamed SBDebugger::Flush to FlushDebuggerOutputHandles and added a short docstring to the .i file to make it a little clearer under which context programs may need to use this API. Differential Revision: https://reviews.llvm.org/D39128 <rdar://problem/34870417> llvm-svn: 317182
* Add a "watchpoint" test category and annotate tests appropriatelyPavel Labath2017-10-311-0/+1
| | | | | | | | | | | Most of the watchpoint tests are organized into subtrees, so we can use the file-based .categories approach to annotate them. The exception are the concurrent_events tests, which needed to be annotated on a per-test basis. The motivation behind this is to provide an easy way to disable watchpoint tests on systems where the watchpoint functionality is not present/unreliable. llvm-svn: 317004
* Initial patchset to get the testsuite running against armv7 and arm64 iOS ↵Jason Molenda2017-09-258-18/+29
| | | | | | | | | | | | | | | | | | | | | | | devices. Normal customer devices won't be able to run these tests, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures. I have seen some instability with the armv7 test runs, I may submit additional patches to address this. arm64 looks good. I'll be watching the bots for the rest of today; if any problems are introduced by this patch I'll revert it - if anyone sees a problem with their bot that I don't see, please do the same. I know it's a rather large patch. One change I had to make specifically for iOS devices was that debugserver can't create files. There were several tests that launch the inferior process redirecting its output to a file, then they retrieve the file. They were not trying to test file redirection in these tests, so I rewrote those to write their output to a file directly. llvm-svn: 314132
* Revert "Initial patchset to get the testsuite running against armv7 and ↵Chris Bieneman2017-09-258-29/+18
| | | | | | | | | | | | | arm64 iOS devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures." This patch has been causing LLDB test failures on ObjC tests. A test log may still be available here: http://lab.llvm.org:8080/green/view/LLDB/job/lldb/1650/ This reverts commit r314038. llvm-svn: 314122
* Initial patchset to get the testsuite running against armv7 and arm64 iOS ↵Jason Molenda2017-09-228-18/+29
| | | | | | | | | | | | | | | | | | | | | | | devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures. I have seen some instability with the armv7 test runs, I may submit additional patches to address this. arm64 looks good. I'll be watching the bots for the rest of today; if any problems are introduced by this patch I'll revert it - if anyone sees a problem with their bot that I don't see, please do the same. I know it's a rather large patch. One change I had to make specifically for iOS devices was that debugserver can't create files. There were several tests that launch the inferior process redirecting its output to a file, then they retrieve the file. They were not trying to test file redirection in these tests, so I rewrote those to write their output to a file directly. llvm-svn: 314038
* Revert this patch; I was emailing with Eugene and they have some other ↵Jason Molenda2017-09-218-29/+18
| | | | | | | | | changes going in today and don't want the two changes to confuse the situation with the build bots. I'll commit tomorrow once they're known good. llvm-svn: 313934
* Initial patchset to get the testsuite running against armv7 and arm64 iOS ↵Jason Molenda2017-09-218-18/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. There will be some smaller follow-on patches. The changes to tools/lldb-server are verbose and I'm not thrilled with having to skip all of these tests manually. There are a few places where I'm making the assumption that "armv7", "armv7k", "arm64" means it's an ios device, and I need to review & clean these up with an OS check as well. (Android will show up as "arm" and "aarch64" so by pure luck they shouldn't cause problems, but it's not an assumption I want to rely on). I'll be watching the bots for the rest of today; if any problems are introduced by this patch I'll revert it - if anyone sees a problem with their bot that I don't see, please do the same. I know it's a rather large patch. One change I had to make specifically for iOS devices was that debugserver can't create files. There were several tests that launch the inferior process redirecting its output to a file, then they retrieve the file. They were not trying to test file redirection in these tests, so I rewrote those to write their output to a file directly. llvm-svn: 313932
* Make breakpoint names real entities.Jim Ingham2017-09-142-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Expose active and available platform lists via SBDebugger APIVadim Macagon2017-08-091-0/+4
| | | | | | | | | | | | Summary: The available platform list was previously only accessible via the `platform list` command, this patch makes it possible to access that list via the SBDebugger API. The active platform list has likewise been exposed via the SBDebugger API. Differential Revision: https://reviews.llvm.org/D35760 llvm-svn: 310452
* Fix ProcessAPITestCase.test_get_process_infoVadim Macagon2017-08-021-15/+27
| | | | llvm-svn: 309803
* xfail test_get_process_info pending bot fixesSean Callanan2017-08-011-0/+1
| | | | llvm-svn: 309714
* Expose process instance info via SB APIVadim Macagon2017-08-013-0/+96
| | | | | | | | | | | Summary: Implement SBProcessInfo to wrap lldb_private::ProcessInstanceInfo, and add SBProcess::GetProcessInfo() to retrieve info like parent ID, group ID, user ID etc. from a live process. Differential Revision: https://reviews.llvm.org/D35881 llvm-svn: 309664
* Added new API to SBStructuredData classAbhishek Aggarwal2017-05-291-0/+206
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Added API to access data types -- integer, double, array, string, boolean and dictionary data types -- Earlier user had to parse through the string output to get these values - Added Test cases for API testing - Added new StructuredDataType enum in public include file -- Replaced locally-defined enum in StructuredData.h with this new one -- Modified other internal files using this locally-defined enum Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com> Reviewers: clayborg, lldb-commits Reviewed By: clayborg Subscribers: labath Differential Revision: https://reviews.llvm.org/D33434 llvm-svn: 304138
* Switch SBBreakpointLocation to use a weak_ptrPavel Labath2017-03-011-0/+3
| | | | llvm-svn: 296594
* Switch SBWatchpoint to use a weak_ptr to the underlying objectPavel Labath2017-02-281-0/+3
| | | | llvm-svn: 296470
* Switch SBBreakpoint to storing a weak_ptr of the internal breakpoint objectPavel Labath2017-02-271-0/+23
| | | | | | | | | | | | | | | | | 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
* Fix TestNameLookup for GCCPavel Labath2017-02-151-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: GCC emits also symbols for the __PRETTY_FUNCTION__ virtual variable, which we accidentaly pick up when looking for functions for with "unique_function_name" in the name. This makes the target.FindFunctions call fail, as that symbol is not a function. I also strenghten the test a bit to make sure we actually find all the functions we are interested in. I've put a check that we find at least 6 functions, but maybe this should be *exactly* 6 ? Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D29932 llvm-svn: 295170
* XFAIL TestNameLookup for GCCPavel Labath2017-02-141-1/+2
| | | | | | | I think I have a fix for this, but it needs review. This should keep the bots happy until then. llvm-svn: 295047
* Fix buildbots.Greg Clayton2017-02-131-1/+1
| | | | llvm-svn: 294991
* FindFunctions now works again with mangled names.Greg Clayton2017-02-133-0/+124
| | | | | | <rdar://problem/28147057> llvm-svn: 294990
* Improve asserts in TestWatchpointIgnoreCountPavel Labath2017-02-101-9/+7
| | | | | | | | This test is flaky on the windows->android bot. Change assertTrue to assertEqual in the hope better error messages will direct us to the problem. llvm-svn: 294737
* Fix SBData::SetData() so that it always sets the address byte size correctly ↵Greg Clayton2017-01-251-0/+20
| | | | | | and added a test. llvm-svn: 293102
* Fix dereferencing of pointers to empty classesTamas Berghammer2017-01-073-0/+81
| | | | llvm-svn: 291350
* [LLDB][MIPS] All tests get errors in dotest after this test.Nitesh Jain2016-10-101-0/+1
| | | | | Subscribers: jaydeep, bhushan, slthakur, llvm-commits llvm-svn: 283739
* xfail TestSBTypeTypeClass.py on macOS i386Todd Fiala2016-10-061-1/+5
| | | | | | | Tracked by: rdar://28656677 llvm-svn: 283484
* Fixup the xfail situation on Windows.Zachary Turner2016-10-051-0/+1
| | | | | | Xfails added and/or removed to reflect the current state of Windows. llvm-svn: 283380
* Revert "XFAIL TestSBData for gcc-4.9 i386"Pavel Labath2016-10-021-1/+0
| | | | | | Test fixed. llvm-svn: 283069
* XFAIL TestSBData for gcc-4.9 i386Pavel Labath2016-09-301-0/+1
| | | | | | test broken in r282659. llvm-svn: 282849
* use assertEquals in TestSBTypeClassMembersTodd Fiala2016-09-281-26/+33
| | | | | | | | This change replaces the self.assertTrue() calls with self.assertEquals() so that test failures get more context on failure values. llvm-svn: 282628
* Fix TestSymbolContextTwoFiles on Android after rL281595Tamas Berghammer2016-09-151-1/+1
| | | | llvm-svn: 281601
* Add support for DW_AT_ranges_base attributeTamas Berghammer2016-09-154-19/+71
| | | | | | | | | | | | | It is a new attribute emitted by clang as a GNU extension and will be part of Dwarf5. The purpose of the attribute is to specify a compile unit level base value for all DW_AT_ranges to reduce the number of relocations have to be done by the linker. Fixes (at least partially): https://llvm.org/pr28826 Differential revision: https://reviews.llvm.org/D24514 llvm-svn: 281595
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-0676-1036/+2071
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Skip TestDisassembleRawData when remoteFrancis Ricci2016-07-011-0/+1
| | | | | | | | | | | | | | | Summary: As this test will create a new target, it will cause all following tests to fail when running in platform mode, if the new target does not match the existing architecture (for example, x86 vs x86_64). Reviewers: zturner, spyffe, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D21906 llvm-svn: 274364
* Revert "Make lldbinline.py regenerate the Makefile each time it builds."Pavel Labath2016-06-071-9/+0
| | | | | | This reverts commit r272024 as it is not windows-compatible. llvm-svn: 272062
* Make lldbinline.py regenerate the Makefile each time it builds.Sean Callanan2016-06-071-0/+9
| | | | | | | | | | | | | If a lldbinline test's source file changed language, then the Makefile wasn't updated. This was a problem if the Makefile was checked into the repository. Now lldbinline.py always regenerates the Makefile and asserts if the newly-generated version is not the same as the one already there. This ensures that the repository will never be out of date without a buildbot failing. http://reviews.llvm.org/D21032 llvm-svn: 272024
* Clean up test results on Windows.Zachary Turner2016-05-132-0/+2
| | | | | | | | | Remove XFAIL from some tests that now pass. Add XFAIL to some tests that now fail. Fix a crasher where a null pointer check isn't guarded. Properly handle all types of errors in SymbolFilePDB. llvm-svn: 269454
* Xfail failing watchpoint tests on aarch64-linuxOmair Javaid2016-05-111-0/+1
| | | | | | | | Some watchpoint tests fail on aarch64-linux as it lacks support for intalling watchpoints which are not alligned at 8bytes boundary. Marking them as xfail for now. llvm-svn: 269187
* Mark TestPrintStackTraces as flaky on linuxPavel Labath2016-05-091-0/+1
| | | | | | PR27687 llvm-svn: 268934
* Fix TestEvents.py on OS XTodd Fiala2016-05-051-3/+6
| | | | | | | | | | | | | | | | | | | | | This change addresses a hang/segfault in TestEvents.py. The threads that run the listener loops now do an SBListener.Clear() before they wrap up their work. This prevents the test from trying to clean up the SBListener too late. There is a separate issue here which is that we should prevent this clean-up time lock-up, but that is out of scope for this particular change. I'd like to get these tests back and running the normal flow rather than skipping them. This addresses: llvm.org/pr25924 (at least, the OS X side, although I suspect this will also address Linux) http://reviews.llvm.org/D19983 reviewed by: Jim Ingham llvm-svn: 268653
* Fix DW_AT_specification handling in DWO filesPavel Labath2016-05-055-0/+70
| | | | | | | | | | | | | | | Summary: We were trying to get a DWARFDIE from a CompileUnit belonging to a DWO file. However, this function does not understand the die encoding used by the DWO files. Instead use GetDIE on the SymbolFileDWARF, which is overriden in DWO to do the right thing. Reviewers: clayborg, tberghammer Subscribers: lldb-commits, ovyalov Differential Revision: http://reviews.llvm.org/D19927 llvm-svn: 268615
* Remote flaky decorator from TestSignalsAPI on linuxPavel Labath2016-04-281-1/+0
| | | | | | | The test seems to pass now, and the test does not seem to be doing anything unusual, so I don't expect it to cause problems. llvm-svn: 267867
* Fix TestGetVariables.py.Chaoren Lin2016-04-252-2/+3
| | | | | | | | | | Reviewers: sivachandra, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D19511 llvm-svn: 267492
* Fix StackFrame::GetVariables(...) function that was broken by 261858 when ↵Greg Clayton2016-04-253-0/+223
| | | | | | | | lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables(...) function should get all variables regardless if they are in scope. This wasn't caught by the test suite so I added a test for it. llvm-svn: 267478
* Fix test cases for big-endian systemsUlrich Weigand2016-04-142-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A number of test cases were failing on big-endian systems simply due to byte order assumptions in the tests themselves, and no underlying bug in LLDB. These two test cases: tools/lldb-server/lldbgdbserverutils.py python_api/process/TestProcessAPI.py actually check for big-endian target byte order, but contain Python errors in the corresponding code paths. These test cases: functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py functionalities/data-formatter/synthcapping/TestSyntheticCapping.py lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py python_api/sbdata/TestSBData.py (first change) could be fixed to check for big-endian target byte order and update the expected result strings accordingly. For the two synthetic tests, I've also updated the source to make sure the fake_a value is always nonzero on both big- and little-endian platforms. These test case: python_api/sbdata/TestSBData.py (second change) functionalities/memory/cache/TestMemoryCache.py simply accessed memory with the wrong size, which wasn't noticed on LE but fails on BE. Differential Revision: http://reviews.llvm.org/D18985 llvm-svn: 266315
* Support Linux on SystemZ as platformUlrich Weigand2016-04-144-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for Linux on SystemZ: - A new ArchSpec value of eCore_s390x_generic - A new directory Plugins/ABI/SysV-s390x providing an ABI implementation - Register context support - Native Linux support including watchpoint support - ELF core file support - Misc. support throughout the code base (e.g. breakpoint opcodes) - Test case updates to support the platform This should provide complete support for debugging the SystemZ platform. Not yet supported are optional features like transaction support (zEC12) or SIMD vector support (z13). There is no instruction emulation, since our ABI requires that all code provide correct DWARF CFI at all PC locations in .eh_frame to support unwinding (i.e. -fasynchronous-unwind-tables is on by default). The implementation follows existing platforms in a mostly straightforward manner. A couple of things that are different: - We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers, since some registers (access register) reside at offsets in the user area that are multiples of 4, but the PTRACE_PEEKUSER interface only allows accessing aligned 8-byte blocks in the user area. Instead, we use a s390 specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that allows accessing a whole block of the user area in one go, so in effect allowing to treat parts of the user area as register sets. - SystemZ hardware does not provide any means to implement read watchpoints, only write watchpoints. In fact, we can only support a *single* write watchpoint (but this can span a range of arbitrary size). In LLDB this means we support only a single watchpoint. I've set all test cases that require read watchpoints (or multiple watchpoints) to expected failure on the platform. [ Note that there were two test cases that install a read/write watchpoint even though they nowhere rely on the "read" property. I've changed those to simply use plain write watchpoints. ] Differential Revision: http://reviews.llvm.org/D18978 llvm-svn: 266308
* Mark TestPrintStackTraces as flaky on android armPavel Labath2016-04-111-0/+1
| | | | llvm-svn: 265959
* Extend XFlaky in TestProcessIO to linux as wellPavel Labath2016-03-141-5/+5
| | | | | | The test sometimes fails on local linux as well. The cause is the same. llvm-svn: 263421
OpenPOWER on IntegriCloud