summaryrefslogtreecommitdiff
path: root/lldb/test/API/python_api
AgeCommit message (Collapse)Author
2025-02-04[lldb] WatchAddress ignores modify option (#124847)Ben Jackson
The WatchAddress API includes a flag to indicate if watchpoint should be for read, modify or both. This API uses 2 booleans, but the 'modify' flag was ignored and WatchAddress unconditionally watched write (actually modify). We now only watch for modify when the modify flag is true. --- The included test fails prior to this patch and succeeds after. That is previously specifying `False` for `modify` would still stop on _write_, but after the patch correctly only stops on _read_
2025-02-04[lldb] Check the command string in TestCommandInterepterPrintCallbackJonas Devlieghere
Now that we store the command in the CommandReturnObject (#125132) we can check the command in the print callback.
2025-02-04[lldb] Support CommandInterpreter print callbacks (#125006)Jonas Devlieghere
Xcode uses a pseudoterminal for the debugger console. - The upside of this apporach is that it means that it can rely on LLDB's IOHandlers for multiline and script input. - The downside of this approach is that the command output is printed to the PTY and you don't get a SBCommandReturnObject. Adrian added support for inline diagnostics (#110901) and we'd like to access those from the IDE. This patch adds support for registering a callback in the command interpreter that gives access to the `(SB)CommandReturnObject` right before it will be printed. The callback implementation can choose whether it likes to handle printing the result or defer to lldb. If the callback indicated it handled the result, the command interpreter will skip printing the result. We considered a few other alternatives to solve this problem: - The most obvious one is using `HandleCommand`, which returns a `SBCommandReturnObject`. The problem with this approach is the multiline input mentioned above. We would need a way to tell the IDE that it should expect multiline input, which isn't known until LLDB starts handling the command. - To address the multiline issue,we considered exposing (some of the) IOHandler machinery through the SB API. To solve this particular issue, that would require reimplementing a ton of logic that already exists today in the CommandInterpeter. Furthermore that seems like overkill compared to the proposed solution. rdar://141254310
2025-02-04[lldb] Store the command in the CommandReturnObject (#125132)Jonas Devlieghere
As suggested in #125006. Depending on which PR lands first, I'll update `TestCommandInterepterPrintCallback.py` to check that the `CommandReturnObject` passed to the callback has the correct command.
2025-01-17[LLDB] Add SBProgress so Python scripts can also report progress (#119052)Jacob Lalonde
Recently I've been working on a lot of internal Python tooling, and in certain cases I want to report async to the script over DAP. Progress.h already handles this, so I've exposed Progress via the SB API so Python scripts can also update progress objects. I actually have no idea how to test this, so I just wrote a [toy command to test it](https://gist.github.com/Jlalond/48d85e75a91f7a137e3142e6a13d0947) ![image](https://github.com/user-attachments/assets/7317cbb8-9145-4fdb-bacf-9864bf50c467) I also copied the first section of the extensive Progress.h class documentation to the docstrings.
2025-01-16[LLDB] Make the thread list for SBSaveCoreOptions iterable (#122541)Jacob Lalonde
This patch adds the ability to get a thread at a give index, based on insertion order, for SBSaveCore Options. This is primarily to benefit scripts using SBSaveCore, and remove the need to have both options and a second collection if your script is tracking what threads need to be saved. Such as if you want to collect the source of all the threads to be saved after the Core is generated.
2024-12-09[lldb] Add lookup by name to SBValue through new member property (#118814)Dave Lee
Introduces a `member` property to `SBValue`. This property provides pythonic access to a value's members, by name. The expression `value.member["name"]` will be an alternate form form of writing `value.GetChildMemberWithName("name")`.
2024-12-03Make SBMemoryRegionInfoList iterable with Python SWIG (#117358)Luke Riddle
This PR fixes a simple SWIG issue with SBMemoryRegionInfoList not being iterable out-of-the-box. This is mostly because of limitations to the `lldb_iter` function, which doesn't allow for specifying arguments to the size / iter functions passed. Before: ``` (lldb) script Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. >>> for region in lldb.process.GetMemoryRegions(): ... print(region) ... Traceback (most recent call last): File "<console>", line 1, in <module> File "/opt/llvm/stable/Toolchains/llvm-sand.xctoolchain/usr/lib/python3.10/site-packages/lldb/__init__.py", line 114, in lldb_iter yield elem(i) TypeError: SBMemoryRegionInfoList.GetMemoryRegionAtIndex() missing 1 required positional argument: 'region_info' ``` After: ``` (lldb) script Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. >>> for region in lldb.process.GetMemoryRegions(): ... print(region) ... [0x0000000000200000-0x00000000002cf000 R--] [0x00000000002cf000-0x0000000000597000 R-X] [0x0000000000597000-0x00000000005ad000 R--] [0x00000000005ad000-0x00000000005b1000 RW-] [0x00000000005b1000-0x0000000000b68000 RW-] [0x000000007fff7000-0x000000008fff7000 RW-] [0x000002008fff7000-0x000010007fff8000 RW-] [0x0000503000000000-0x0000503000010000 RW-] [0x0000503e00000000-0x0000503e00010000 RW-] [0x0000504000000000-0x0000504000010000 RW-] [0x0000504e00000000-0x0000504e00010000 RW-] [0x000050d000000000-0x000050d000010000 RW-] [0x000050de00000000-0x000050de00010000 RW-] [0x000050e000000000-0x000050e000010000 RW-] [0x000050ee00000000-0x000050ee00010000 RW-] [0x0000511000000000-0x0000511000010000 RW-] [0x0000511e00000000-0x0000511e00010000 RW-] [0x0000513000000000-0x0000513000010000 RW-] ... ```
2024-11-12[lldb] Support true/false in ValueObject::SetValueFromCString (#115780)Jonas Devlieghere
Support "true" and "false" (and "YES" and "NO" in Objective-C) in ValueObject::SetValueFromCString. Fixes #112597
2024-11-11[lldb] Disable TestCancelAttach for Windows host (#115619)Dmitry Vasilyev
See #115618 for details.
2024-10-30[lldb] Fix API test for file redirection to existing files (#114119)Wanyi
API test failed for remote platform in [#112657](https://github.com/llvm/llvm-project/pull/112657) Previously when putting files onto remote platform, I used `platform file write -d <data>` which actually required a `platform file open <path>` first in order to obtain a file descriptor. eg. in file [TestGDBRemotePlatformFile.py](https://github.com/llvm/llvm-project/blob/94e7d9c0bfe517507ea08b00fb00c32fb2837a82/lldb/test/API/functionalities/gdb_remote_client/TestGDBRemotePlatformFile.py#L24-L32) To fix this, use the `platform put-file` method, which is used in the `redirect_stdin` from this test already.
2024-10-30Fix a couple of tests that were incorrectly using ↵jimingham
configuration.dwarf_version (#114161) The tests were using the variable directly to get the dwarf version used for the test. That's only the overridden value, and won't be set if we're using the compiler default. I also put a comment by the variable to make sure people don't make the same mistake in the future.
2024-10-29[lldb] Fix write only file action to truncate the file (#112657)Wanyi
When `FileAction` opens file with write access, it doesn't clear the file nor append to the end of the file if it already exists. Instead, it writes from cursor index 0. For example, by using the settings `target.output-path` and `target.error-path`, lldb will redirect process stdout/stderr to files. It then calls this function to write to the files which the above symptoms appear. ## Test - Added unit test checking the file flags - Added 2 api tests checking - File content overwritten if the file path already exists - Stdout and stderr redirection to the same file doesn't change its behavior
2024-10-18[lldb] Speed up FindInMemory tests (#111951)Igor Kudrin
A memory region can be relatively large. Searching for a value in the entire region is time-consuming, especially when running tests against a remote target, because the memory data is transferred in small chunks over a relatively slow GDB Remote Protocol. The patch limits the address range to be searched to 2K, which seems sufficient for these tests. In my setup, for local runs, these tests now take half the time they did before the patch. For a remote target, the improvement is even more significant.
2024-10-18Revert "Renormalize line endings whitespace only after dccebddb3b80"Luke Drummond
This reverts commit 9d98acb196a40fee5229afeb08f95fd36d41c10a.
2024-10-17Renormalize line endings whitespace only after dccebddb3b80Luke Drummond
Line ending policies were changed in the parent, dccebddb3b80. To make it easier to resolve downstream merge conflicts after line-ending policies are adjusted this is a separate whitespace-only commit. If you have merge conflicts as a result, you can simply `git add --renormalize -u && git merge --continue` or `git add --renormalize -u && git rebase --continue` - depending on your workflow.
2024-10-09[lldb] Fix TestGlobalModuleCache.py for remote debugging (#111483)Igor Kudrin
`SBDebugger().Create()` returns a debugger with only the host platform in its platform list. If the test suite is running for a remote platform, it should be explicitly added and selected in the new debugger created within the test, otherwise, the test will fail because the host platform may not be able to launch the built binary.
2024-09-25[lldb] Fix error reporting in SBTarget::ReadMemory (#109764)Pavel Labath
The function should use the by-ref SBError argument instead of creating a new one. This code has been here since ~forever, and was probably copied from methods which return an SBError result (where one needs to create a local variable).
2024-09-11[lldb][test] Toolchain detection rewrite in Python (#102185)Vladislav Dzhidzhoev
This fix is based on a problem with cxx_compiler and cxx_linker macros on Windows. There was an issue with compiler detection in paths containing "icc". In such case, Makefile.rules thought it was provided with icc compiler. To solve that, utilities detection has been rewritten in Python. The last element of compiler's path is separated, taking into account the platform path delimiter, and compiler type is extracted, with regard of possible cross-toolchain prefix. --------- Co-authored-by: Pavel Labath <pavel@labath.sk>
2024-08-15[LLDB] Reapply #100443 SBSaveCore Thread list (#104497)Jacob Lalonde
Reapply #100443 and #101770. These were originally reverted due to a test failure and an MSAN failure. I changed the test attribute to restrict to x86 (following the other existing tests). I could not reproduce the test or the MSAN failure and no repo steps were provided.
2024-08-07[lldb/API] Fix SBStructuredData support any JSON type (#101929)Med Ismail Bennani
This patch loosen the parsing requirement to allow parsing not only JSON dictionaries but also valid JSON type (integer, float, string, bool, array, null). Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
2024-08-05Revert "[LLDB][SBSaveCore] Implement a selectable threadlist for Core… ↵Jacob Lalonde
(#102018) … Options. (#100443)" This reverts commit 3e4af616334eae532f308605b89ff158dd195180. @adrian-prantl FYI Reverts #100443
2024-08-02[LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. ↵Jacob Lalonde
(#100443) In #98403 I enabled the SBSaveCoreOptions object, which allows users via the scripting API to define what they want saved into their core file. As the first option I've added a threadlist, so users can scan and identify which threads and corresponding stacks they want to save. In order to support this, I had to add a new method to `Process.h` on how we identify which threads are to be saved, and I had to change the book keeping in minidump to ensure we don't double save the stacks. Important to @jasonmolenda I also changed the MachO coredump to accept these new APIs.
2024-07-18[LLDB][SaveCore] Add SBSaveCoreOptions Object, and SBProcess::SaveCore() ↵Jacob Lalonde
overload (#98403) This PR adds `SBSaveCoreOptions`, which is a container class for options when LLDB is taking coredumps. For this first iteration this container just keeps parity with the extant API of `file, style, plugin`. In the future this options object can be extended to allow users to take a subset of their core dumps.
2024-07-15git add a test file from a previous commit.Jim Ingham
A new file was added to the python_api/events test, but I forgot to git add it before making the PR. The commit was: 44d9692e6a657ec46e98e4912ac56417da67cfee
2024-07-15Private process events were being delivered to the secondary listener (#98571)jimingham
This fixes a bug where Process events were being delivered to secondary listeners when the Private state thread listener was processing the event. That meant the secondary listener could get an event before the Primary listener did. That in turn meant the state when the secondary listener got the event wasn't right yet. Plus it meant that the secondary listener saw more events than the primary (not all events get forwarded from the private to the public Process listener.) This bug became much more evident when we had a stop hook that did some work, since that delays the Primary listener event delivery. So I also added a stop-hook to the test, and put a little delay in as well.
2024-07-15[API] add GetSyntheticValue (#95959)Vincent Belliard
Adds GetSyntheticValue to the API on top of GetNonSyntheticValue. --------- Co-authored-by: Vincent Belliard <v-bulle@github.com>
2024-07-10[lldb][test] Fix instruction test step on WindowsDavid Spickett
On Windows the function name is the full prototype including the calling convention, all we care about is that the last part is correct. This also reverts the xfail added by 07b3e2c0c68b93a3d4d89426dc7fd14cc31ca6be.
2024-07-09[lldb] Put the new debugger in synchronous mode in TestGlobalModuleCache ↵Pavel Labath
(#98041) In async mode, the test terminates sooner than it should (`run_to_source_breakpoint` does not work in this mode), and then the test crashes due to #76057. Most of the time, the test does not fail because its already XFAILed, but the crash still registers as a failure.
2024-07-04[LLDB] XFail on Windows TestThreadAPI.py test_StepInstructionMuhammad Omair Javaid
TestThreadAPI.py test_StepInstruction started failing after #97493 Following assertion fails but I am not sure if test will pass after changing the test. AssertionError: 'void __cdecl call_me(bool)' != 'call_me(bool)' I have marked it as xfail I ll run it on a Windows machine to find an appropriate fix. https://lab.llvm.org/buildbot/#/builders/141/builds/476
2024-07-03SBThread::StepInstruction shouldn't discard other plans (#97493)jimingham
This was just a typo, none of the external execution control functions should discard other plans. In particular, it means if you stop in a hand-called function and step an instruction, the function call thread plan gets unshipped, popping all the function call frames. I also added a test that asserts the correct behavior. I tested all the stepping operations even though only StepInstruction was wrong.
2024-06-26[lldb] fix(lldb/**.py): fix comparison to None (#94017)Eisuke Kawashima
from PEP8 (https://peps.python.org/pep-0008/#programming-recommendations): > Comparisons to singletons like None should always be done with is or is not, never the equality operators. Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
2024-06-24[lldb][API] Add Find(Ranges)InMemory() to Process SB API (#96569)Miro Bucko
This is a second attempt to land #95007 Test Plan: llvm-lit llvm-project/lldb/test/API/python_api/find_in_memory/TestFindInMemory.py llvm-project/lldb/test/API/python_api/find_in_memory/TestFindRangesInMemory.py Reviewers: clayborg Tasks: lldb
2024-06-24Revert commits that add `TestFind(Ranges)InMemory.py` (#96560)Chelsea Cassanova
Reverting to unblock macOS buildbots which are currently failing on these tests. https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake/6377/
2024-06-24[lldb] Fix failing TestFind(Ranges)InMemory.py tests. (#96511)Miro Bucko
This is to unblock #95007. Will investigate why the assertion is failing on some arch.
2024-06-24[lldb][API] Add Find(Ranges)InMemory() to Process SB API (#95007)Miro Bucko
Test Plan: llvm-lit llvm-project/lldb/test/API/python_api/find_in_memory/TestFindInMemory.py llvm-project/lldb/test/API/python_api/find_in_memory/TestFindRangesInMemory.py Reviewers: clayborg Tasks: lldb
2024-06-21[lldb] Fix SBAddressRange validation checks. (#95997)Miro Bucko
2024-06-11Reland "[lldb][api-test] Add API test for SBCommandInterpreter::Comm… ↵Chelsea Cassanova
(#95181) …andOverrideCallback (#94518)" This reverts commit 7cff05ada05e87408966d56b4c1675033187ff5c. The API test that was added erroneously imports a module that isn't needed and wouldn't be found which causes a test failures. This reversion removes that import.
2024-06-11Revert "[lldb][api-test] Add API test for ↵Chelsea Cassanova
SBCommandInterpreter::CommandOverrideCallback (#94518)" This reverts commit 6fb6eba9304b63e86ebf039edcb9a0b32e4b39e7. This test breaks due to an incorrect import in the test.
2024-06-11[lldb][api-test] Add API test for ↵Chelsea Cassanova
SBCommandInterpreter::CommandOverrideCallback (#94518) `SBCommandInterpreter::CommandOverrideCallback` was not being exposed to the Python API and has no coverage in the API test suite, so this commits exposes and adds a test for it. Doing this involves also adding a typemap for the callback used for this function so that it matches the functionality of other callback functions that are exposed to Python.
2024-06-07Add AllowRepeats to SBCommandInterpreterRunOptions. (#94786)jimingham
This is useful if you have a transcript of a user session and want to rerun those commands with RunCommandInterpreter. The same functionality is also useful in testing. I'm adding it primarily for the second reason. In a subsequent patch, I'm adding the ability to Python based commands to provide their "auto-repeat" command. Among other things, that will allow potentially state destroying user commands to prevent auto-repeat. Testing this with Shell or pexpect tests is not nearly as accurate or convenient as using RunCommandInterpreter, but to use that I need to allow auto-repeat. I think for consistency's sake, having interactive sessions always do auto-repeats is the right choice, though that's a lightly held opinion...
2024-06-03Re-merge `A few updates around "transcript"` (#92843) (#94067)royitaqi
Problematic PR: https://github.com/llvm/llvm-project/pull/92843 Reverted by: https://github.com/llvm/llvm-project/pull/94088 The first PR added a test which fails in Linux builds (see the last few comments there). This PR contains all the changes in the first PR, plus the fix to the said test. --------- Co-authored-by: Roy Shi <royshi@meta.com>
2024-05-31Revert "A few updates around "transcript"" (#94088)gulfemsavrun
Reverts llvm/llvm-project#92843 because it broke some lldb tests: https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8746385730949743489/overview
2024-05-31A few updates around "transcript" (#92843)royitaqi
# Changes 1. Changes to the structured transcript. 1. Add fields `commandName` and `commandArguments`. They will hold the name and the arguments string of the expanded/executed command (e.g. `breakpoint set` and `-f main.cpp -l 4`). This is not to be confused with the `command` field, which holds the user input (e.g. `br s -f main.cpp -l 4`). 2. Add field `timestampInEpochSeconds`. It will hold the timestamp when the command is executed. 3. Rename field `seconds` to `durationInSeconds`, to improve readability, especially since `timestampInEpochSeconds` is added. 2. When transcript is available and the newly added option `--transcript` is present, add the transcript to the output of `statistics dump`, as a JSON array under a new field `transcript`. 3. A few test name and comment changes.
2024-05-31[lldb] FormatManager::GetPossibleMatches assumes all ValueObjects have ↵jimingham
targets. (#93880) But one made in a situation where that's impossible might only have an error, and no symbol context, so that's not necessarily true. Check for the target's validity before using it. Fixes issue #93313
2024-05-30[lldb][test] Fix failing test TestAddressRange.py (#93871)Miro Bucko
Test llvm-project/lldb/test/API/python_api/address_range/TestAddressRange.py is failing on Windows due adding a carriage return character at the end of line. Original PR is #93836.
2024-05-30[lldb] Add SBAddressRange and SBAddressRangeList to SB API (#93836)Miro Bucko
This adds new SB API calls and classes to allow a user of the SB API to obtain an address range from SBFunction and SBBlock. This is a second attempt to land the reverted PR #92014.
2024-05-30[lldb] Fixed the TestDebuggerAPI test running on a remote target (#93829)Dmitry Vasilyev
Recently we have disabled this test for Windows host and Linux target. Now we faced the same issue #92419 in case of Linux x86_64 host and Linux Aarch64 target.
2024-05-30Revert "Add SBAddressRange and SBAddressRangeList to SB API (#92014)"Michael Buch
This reverts commit 42944e4600827738fae868f0df831fb2678be8b4.
2024-05-29[lldb][Test][Windows] Fix flaky address range API testsDavid Spickett
The new tests added in #92014 have been flaky on Linaro's Windows on Arm bot. They appear to be hitting a deadlock trying to clean up the test process. This only happens in async mode and I don't see why this test case needs async mode, so the simple workaround is to stick to sync mode.