summaryrefslogtreecommitdiff
path: root/lldb/packages/Python/lldbsuite/test/functionalities
AgeCommit message (Collapse)Author
2020-02-11[lldb][test] Remove symlink for API tests.Jordan Rupprecht
Summary: Moves lldbsuite tests to lldb/test/API. This is a largely mechanical change, moved with the following steps: ``` rm lldb/test/API/testcases mkdir -p lldb/test/API/{test_runner/test,tools/lldb-{server,vscode}} mv lldb/packages/Python/lldbsuite/test/test_runner/test lldb/test/API/test_runner for d in $(find lldb/packages/Python/lldbsuite/test/* -maxdepth 0 -type d | egrep -v "make|plugins|test_runner|tools"); do mv $d lldb/test/API; done for d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-vscode -maxdepth 1 -mindepth 1 | grep -v ".py"); do mv $d lldb/test/API/tools/lldb-vscode; done for d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-server -maxdepth 1 -mindepth 1 | egrep -v "gdbremote_testcase.py|lldbgdbserverutils.py|socket_packet_pump.py"); do mv $d lldb/test/API/tools/lldb-server; done ``` lldb/packages/Python/lldbsuite/__init__.py and lldb/test/API/lit.cfg.py were also updated with the new directory structure. Reviewers: labath, JDevlieghere Tags: #lldb Differential Revision: https://reviews.llvm.org/D71151
2020-02-07[lldb] Remove all 'clean' targets from test MakefilesRaphael Isemann
Summary: To my knowledge we don't actually use or need these rules. And if we need them then there is probably a better way to implement this than having all these random regexes. Reviewers: labath, JDevlieghere Reviewed By: labath, JDevlieghere Subscribers: jingham, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D74126
2020-02-06[lldb/Target] Add Assert StackFrame RecognizerMed Ismail Bennani
When a thread stops, this checks depending on the platform if the top frame is an abort stack frame. If so, it looks for an assert stack frame in the upper frames and set it as the most relavant frame when found. To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a "cooked" stop reason description. When the thread is about to stop, it checks if the current frame is recognized, and if so, it fetches the recognized frame's attributes and applies them. rdar://58528686 Differential Revision: https://reviews.llvm.org/D73303 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-02-05Revert "[LLDB] Add DynamicLoaderWasmDYLD plugin for WebAssembly debugging"Pavel Labath
This patch has a couple of outstanding issues. The test is not python3 compatible, and it also seems to fail with python2 (at least under some circumstances) due to an overambitious assertion. This reverts the patch as well as subsequent fixup attempts: 014ea9337624fe20aca8892e73b6b3f741d8da9e, f5f70d1c8fbf12249b4b9598f10a10f12d4db029. 4697e701b8cb40429818609814c7422e49b2ee07. 5c15e8e682e365b3a7fcf35200df79f3fb93b924. 3ec28da6d6430a00b46780555a87acd43fcab790.
2020-02-05[lldb] Remove "print xml" from TestWasm.pyPavel Labath
It's not py3 compatible, and the test should not be printing this to stdout (unless in --trace mode) anyway.
2020-02-05Revert "[lldb/Target] Add Assert StackFrame Recognizer"Pavel Labath
This reverts commit 2b7f32892b76cdfbe075300a5bf4a52e1b674bc7 because of test failures due to dangling pointers.
2020-02-05Add missing directory from 3ec28da6Derek Schuff
Also revert 4697e701b8, restoring the original patch from https://reviews.llvm.org/D72751
2020-02-05Partially revert "[LLDB] Add DynamicLoaderWasmDYLD plugin for WebAssembly ↵Jonas Devlieghere
debugging" This temporarily and partially reverts 3ec28da6d643 because it's missing a directory.
2020-02-05[LLDB] Add DynamicLoaderWasmDYLD plugin for WebAssembly debuggingPaolo Severini
Add a dynamic loader plug-in class for WebAssembly modules. Differential Revision: https://reviews.llvm.org/D72751
2020-02-05[lldb/Target] Add Assert StackFrame RecognizerMed Ismail Bennani
When a thread stops, this checks depending on the platform if the top frame is an abort stack frame. If so, it looks for an assert stack frame in the upper frames and set it as the most relavant frame when found. To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a "cooked" stop reason description. When the thread is about to stop, it checks if the current frame is recognized, and if so, it fetches the recognized frame's attributes and applies them. rdar://58528686 Differential Revision: https://reviews.llvm.org/D73303 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-02-05[lldb] Revert some change in data-formatter-objc/main.m that broke ↵Raphael Isemann
TestDataFormatterObjCNSDate.py Changing the date2 to an timezone independent value broke the test as the data formatters uses the current time zone for the summary (so changing it to a time zone independent value would again break the test in some time zones). We anyway just care about this for date2 which will be printed in a timezone-independent summary.
2020-02-05[lldb] Make TestDataFormatterObjCCF.py pass outside CaliforniaRaphael Isemann
Summary: This test creates its dates with `NSDate dateWithNaturalLanguageString` which is deprecated and uses the current time zone of the machine to interpret the input string. This causes that the created NSDate has a different value depending on the locale of the machine and we hardcoded the value for California's time zone (PST) but the data formatter gives out the GMT value as a string. This just replaces the use with the timezone-independent dateWithTimeIntervalSince1970 (which we also use in the rest of the test) to make this pass independently of the time zone of the machine running the test. Reviewers: mib Reviewed By: mib Subscribers: lldb-commits, JDevlieghere Tags: #lldb Differential Revision: https://reviews.llvm.org/D74038
2020-02-04[lldb/test] Skip TestBasicEntryValuesX86_64 due to llvm.org/PR44774Vedant Kumar
2020-02-03[lldb/Test] Sort substr for TestDataFormatterStdMap.py (2/2)Jonas Devlieghere
2020-02-03[lldb/Test] Fix substr order in asan & ubsan testsJonas Devlieghere
2020-02-03[lldb/Test] Fix typo in TestDataFormatterStdMap.pyJonas Devlieghere
2020-02-03[lldb/Test] Sort substr for TestDataFormatterStdMap.pyJonas Devlieghere
2020-01-31[lldb/Value] Avoid reading more data than the host has availableVedant Kumar
Value::GetValueByteSize() reports the size of a Value as the size of its underlying CompilerType. However, a host buffer that backs a Value may be smaller than GetValueByteSize(). This situation arises when the host is only able to partially evaluate a Value, e.g. because the expression contains DW_OP_piece. The cleanest fix I've found to this problem is Greg's suggestion, which is to resize the Value if (after evaluating an expression) it's found to be too small. I've tried several alternatives which all (in one way or the other) tried to teach the Value/ValueObjectChild system not to read past the end of a host buffer, but this was flaky and impractical as it isn't easy to figure out the host buffer's size (Value::GetScalar() can point to somewhere /inside/ a host buffer, but you need to walk up the ValueObject hierarchy to try and find its size). This fixes an ASan error in lldb seen when debugging a clang binary. I've added a regression test in test/functionalities/optimized_code. The point of that test is not specifically to check that DW_OP_piece is handled a particular way, but rather to check that lldb doesn't crash on an input that it used to crash on. Testing: check-lldb, and running the added tests using a sanitized lldb -- Thanks to Jim for pointing out that an earlier version of this patch, which simply changed the definition of Value::GetValueByteSize(), would interact poorly with the ValueObject machinery. Thanks also to Pavel who suggested a neat way to test this change (which, incidentally, caught another ASan issue still present in the original version of this patch). rdar://58665925 Differential Revision: https://reviews.llvm.org/D73148
2020-01-31[lldb/Test] Fix more substr ordering issues that only repro on the botJonas Devlieghere
2020-01-31[lldb/Test] Fix substrs order in self.expect for the remaining tests (NFC)Jonas Devlieghere
Currently the substrs parameter takes a list of strings that need to be found but the ordering isn't checked. D73766 might change that so this changes a several tests so that the order of the strings in the substrs list is in the order in which they appear in the output.
2020-01-31[lldb/Test] Fix substrs order in self.expect for more tests (NFC)Jonas Devlieghere
Currently the substrs parameter takes a list of strings that need to be found but the ordering isn't checked. D73766 might change that so this changes a several tests so that the order of the strings in the substrs list is in the order in which they appear in the output.
2020-01-31[lldb/Test] Fix substrs order in self.expect for more tests (NFC)Jonas Devlieghere
Currently the substrs parameter takes a list of strings that need to be found but the ordering isn't checked. D73766 might change that so this changes a several tests so that the order of the strings in the substrs list is in the order in which they appear in the output.
2020-01-31[lldb][NFC] Fix expect calls with wrong order of 'substrs' items for D73766Raphael Isemann
Currently the substrs parameter takes a list of strings that need to be found but the ordering isn't checked. D73766 might change that so this changes a several tests so that the order of the strings in the substrs list is in the order in which they appear in the output.
2020-01-28Revert "[lldb/Target] Add Assert StackFrame Recognizer"Med Ismail Bennani
This reverts commit 03a6b858fde5c644ec16b1fddd8e10aa9ef3f0ad. The test doesn't pass on Debian.
2020-01-28[lldb/Target] Add Assert StackFrame RecognizerMed Ismail Bennani
When a thread stops, this checks depending on the platform if the top frame is an abort stack frame. If so, it looks for an assert stack frame in the upper frames and set it as the most relavant frame when found. To do so, the StackFrameRecognizer class holds a "Most Relevant Frame" and a "cooked" stop reason description. When the thread is about to stop, it checks if the current frame is recognized, and if so, it fetches the recognized frame's attributes and applies them. rdar://58528686 Differential Revision: https://reviews.llvm.org/D73303 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-01-24[lldb/Test] Disable hardware check on arm/aarch64Jonas Devlieghere
BreakpointSites know they're backed by hardware based on whether the "hardware index" is set. This does not appear the to be done for arm/aarch64. https://llvm.org/PR44659
2020-01-24[lldb/Breakpoint] Include whether or not a breakpoint is a HW BPJonas Devlieghere
Include whether or not a breakpoint is a hardware breakpoint in the breakpoint location. This will show up in things like the breakpoint list. Differential revision: https://reviews.llvm.org/D73389
2020-01-24[lldb/Breakpoint] Recogize hardware breakpoints as suchJonas Devlieghere
Recognize hardware breakpoints as breakpoints instead of just mach exceptions. The mach exception is the same for watch and breakpoints, so we have to try each to figure out which is which. Differential revision: https://reviews.llvm.org/D73401
2020-01-24[lldb/debugserver] Implement hardware breakpoints for x86_64 and i386Jonas Devlieghere
This implements hardware breakpoints for x86_64 and i386 in debugserver. It's based on Pedro's patch sent to lldb-commits [1] although most of it is the same as the existing hardware watchpoint implementation. [1] http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20200113/060327.html Differential revision: https://reviews.llvm.org/D72985
2020-01-22[lldb] Fix an asan error from 27df2d9f556cPavel Labath
This error is caused by a combination of a couple of factors: - the test accidentally creating a list with a single (empty) FileSpec instead of an empty list - lldb overzeleously converting empty strings into nullptrs - asan overzeleously validating symlink(2) arguments (the real symlink call would just fail with EFAULT) I fix this by using FileSpec::GetPath instead of GetCString. This avoids the nullptr and also avoids inserting the path into the global string pool. I also enhance the test case to test both empty paths and empty lists.
2020-01-21[lldb/DataFormatters] Fix the `$$deference$$` synthetic childFred Riss
Summary: The ValueObject code checks for a special `$$dereference$$` synthetic child to allow formatter providers to implement a natural dereferencing behavior in `frame variable` for objects like smart pointers. This support was broken when used directly throught the Python API and not trhough `frame variable`. The reason is that SBFrame.FindVariable() will return by default the synthetic variable if it exists, while `frame variable` will not do this eagerly. The code in `ValueObject::Dereference()` accounted for the latter but not for the former. The fix is trivial. The test change includes additional covergage for the already-working bahevior as it wasn't covered by the testsuite before. This commit also adds a short piece of documentatione explaining that it is possible (even advisable) to provide this synthetic child outstide of the range of the normal children. Reviewers: jingham Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73053
2020-01-20[lldb/IOHandler] Improve synchronization between IO handlers.Jonas Devlieghere
The way the IO handlers are currently managed by the debugger is wrong. The implementation lacks proper synchronization between RunIOHandlerSync and RunIOHandlers. The latter is meant to be run by the "main thread", while the former is meant to be run synchronously, potentially from a different thread. Imagine a scenario where RunIOHandlerSync is called from a different thread than RunIOHandlers. Both functions manipulate the debugger's IOHandlerStack. Although the push and pop operations are synchronized, the logic to activate, deactivate and run IO handlers is not. While investigating PR44352, I noticed some weird behavior in the Editline implementation. One of its members (m_editor_status) was modified from another thread. This happened because the main thread, while running RunIOHandlers ended up execution the IOHandlerEditline created by the breakpoint callback thread. Even worse, due to the lack of synchronization within the IO handler implementation, both threads ended up executing the same IO handler. Most of the time, the IO handlers don't need to run synchronously. The exception is sourcing commands from external files, like the .lldbinit file. I've added a (recursive) mutex to prevent another thread from messing with the IO handlers wile another thread is running one synchronously. It has to be recursive, because we might have to source another file when encountering a command source in the original file. Differential revision: https://reviews.llvm.org/D72748
2020-01-20[lldb] Don't process symlinks deep inside DWARFUnitPavel Labath
Summary: This code is handling debug info paths starting with /proc/self/cwd, which is one of the mechanisms people use to obtain "relocatable" debug info (the idea being that one starts the debugger with an appropriate cwd and things "just work"). Instead of resolving the symlinks inside DWARFUnit, we can do the same thing more elegantly by hooking into the existing Module path remapping code. Since llvm::DWARFUnit does not support any similar functionality, doing things this way is also a step towards unifying llvm and lldb dwarf parsers. Reviewers: JDevlieghere, aprantl, clayborg, jdoerfert Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71770
2020-01-18[lldb/Test] XFAIL TestRequireHWBreakpoints when HW BPs are avialableJonas Devlieghere
Resolves PR44055
2020-01-17[lldb] Re-add NSDate formatterRaphael Isemann
This test had been overwritten by accident in ff75262f701da396a0d34d4f6b67cf8e4c9dc7c2. This just readds the test with the correct content.
2020-01-16lldb: xfail TestCrossDSOTailCalls.py and TestCrossObjectTailCalls.py on ↵Vedant Kumar
arm/aarch64 This effectively reverts commit 8d2f252bb8e4d199be8498c4ee2245117ef08fd2, which went a bit too far and disabled these on all non-Darwin systems.
2020-01-16[lldb/test] Exted test for CMTime data formatterJonas Devlieghere
Cover more cases handled by the formatter.
2020-01-16[lldb][NFC] Delete TestDataFormatterObjCNSDate.pyRaphael Isemann
This test is just TestDataFormatterObjCNSData.py copied but without any changes (and it therefore doesn't even test NSDate). It's also failing as NSData has been changed by me in 4f244bba4f66b14382c446b62e122fa684b8db78.
2020-01-16[lldb] Fix asan failures in data-formatter-objc testsRaphael Isemann
The test is currently failing on some systems with ASAN enabled due to: ``` ==22898==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000003da4 at pc 0x00010951c33d bp 0x7ffee6709e00 sp 0x7ffee67095c0 READ of size 5 at 0x603000003da4 thread T0 #0 0x10951c33c in wrap_memmove+0x16c (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x1833c) #1 0x7fff4a327f57 in CFDataReplaceBytes+0x1ba (CoreFoundation:x86_64+0x13f57) #2 0x7fff4a415a44 in __CFDataInit+0x2db (CoreFoundation:x86_64+0x101a44) #3 0x1094f8490 in main main.m:424 #4 0x7fff77482084 in start+0x0 (libdyld.dylib:x86_64+0x17084) 0x603000003da4 is located 0 bytes to the right of 20-byte region [0x603000003d90,0x603000003da4) allocated by thread T0 here: #0 0x109547c02 in wrap_calloc+0xa2 (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x43c02) #1 0x7fff763ad3ef in class_createInstance+0x52 (libobjc.A.dylib:x86_64+0x73ef) #2 0x7fff4c6b2d73 in NSAllocateObject+0x12 (Foundation:x86_64+0x1d73) #3 0x7fff4c6b5e5f in -[_NSPlaceholderData initWithBytes:length:copy:deallocator:]+0x40 (Foundation:x86_64+0x4e5f) #4 0x7fff4c6d4cf1 in -[NSData(NSData) initWithBytes:length:]+0x24 (Foundation:x86_64+0x23cf1) #5 0x1094f8245 in main main.m:404 #6 0x7fff77482084 in start+0x0 (libdyld.dylib:x86_64+0x17084) ``` The reason is that we create a string "HELLO" but get the size wrong (it's 5 bytes instead of 4). Later on we read the buffer and pretend it is 5 bytes long, causing an OOB read which ASAN detects. In general this test probably needs some cleanup as it produces on macOS 10.15 around 100 compiler warnings which isn't great, but let's first get the bot green.
2020-01-15lldb: Run TestCrossDSOTailCalls.py and TestCrossObjectTailCalls.py on Darwin ↵Vedant Kumar
only See https://bugs.llvm.org/show_bug.cgi?id=44561, these tests are failing on an aarch64/Linux bot: http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/655 For some reason the backtrace the tests are expecting to find is incomplete.
2020-01-15[DWARF] Emit DW_AT_call_return_pc as an addressVedant Kumar
This reverts D53469, which changed llvm's DWARF emission to emit DW_AT_call_return_pc as a function-local offset. Such an encoding is not compatible with post-link block re-ordering tools and isn't standards- compliant. In addition to reverting back to the original DW_AT_call_return_pc encoding, teach lldb how to fix up DW_AT_call_return_pc when the address comes from an object file pointed-to by a debug map. While doing this I noticed that lldb's support for tail calls that cross a DSO/object file boundary wasn't covered, so I added tests for that. This latter case exercises the newly added return PC fixup. The dsymutil changes in this patch were originally included in D49887: the associated test should be sufficient to test DW_AT_call_return_pc encoding purely on the llvm side. Differential Revision: https://reviews.llvm.org/D72489
2020-01-15[lldb] Add expect_expr function for testing expression evaluation in dotests.Raphael Isemann
Summary: This patch adds a new function to lldbtest: `expect_expr`. This function is supposed to replace the current approach of calling `expect`/`runCmd` with `expr`, `p` etc. `expect_expr` allows evaluating expressions and matching their value/summary/type/error message without having to do any string matching that might allow unintended passes (e.g., `self.expect("expr 3+4", substrs=["7"])` can unexpectedly pass for results like `(Class7) $0 = 7`, `(int) $7 = 22`, `(int) $0 = 77` and so on). This only uses the function in a few places to test and demonstrate it. I'll migrate the tests in follow up commits. Reviewers: JDevlieghere, shafik, labath Reviewed By: labath Subscribers: christof, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70314
2020-01-14[lldb/test] Add test for CMTime data formatterJonas Devlieghere
Add a test for the CMTime data formatter. The coverage report showed that this code path was untested.
2020-01-10[lldb][tests] Cleanup '.categories'Tatyana Krasnukha
2020-01-10Data formatters: Look through array element typedefsJaroslav Sevcik
Summary: Motivation: When formatting an array of typedefed chars, we would like to display the array as a string. The string formatter currently does not trigger because the formatter lookup does not resolve typedefs for array elements (this behavior is inconsistent with pointers, for those we do look through pointee typedefs). This patch tries to make the array formatter lookup somewhat consistent with the pointer formatter lookup. Reviewers: teemperor, clayborg Reviewed By: teemperor, clayborg Subscribers: clayborg, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72133
2020-01-09When reading Aux file in chunks, read consecutive byte rangesJason Molenda
qemu has a very small maximum packet size (4096) and it actually only uses half of that buffer for some implementation reason, so when lldb asks for the register target definitions, the x86_64 definition is larger than 4096/2 and we need to fetch it in two parts. This patch and test is fixing a bug in GDBRemoteCommunicationClient::ReadExtFeature when reading a target file in multiple parts. lldb was assuming that it would always get back the maximum packet size response (4096) instead of using the actual size received and asking for the next group of bytes. We now have two tests in gdb_remote_client for unique features of qemu - TestNestedRegDefinitions.py would test the ability of lldb to follow multiple levels of xml includes; I opted to create a separate TestRegDefinitionInParts.py test to test this wrinkle in qemu's gdb remote serial protocol stub implementation. Instead of combining both tests into a single test file. <rdar://problem/49537922>
2020-01-01tests: XFAIL/UNSUPPORTED tests on WindowsSaleem Abdulrasool
Now that we are building the python bindings on Windows once more, the extended testsuite is running. Mark a few failing tests and skip a few tests which hang. This should at least bring the bot back to green without reverting the Python changes which are an improvement for the build system and enable another ~35% of the test suite which was previously disabled.
2019-12-26[lldb][tests] Posix function strdup requires macro _POSIX_C_SOURCETatyana Krasnukha
2019-12-24test: ensure that we dead-strip in the linkerSaleem Abdulrasool
`/OPT:REF` is needed for link to dead strip functions, `/Gy` by itself is not sufficient.
2019-12-23test: correct flags for WindowsSaleem Abdulrasool
Adjust the flags for the LLDB test on Windows. This test was previously not running, but after the fix to the python detection, we now run this.
generated by cgit v1.2.3 (git 2.25.1) at 2026-10-23 10:22:18 +0000