|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3 |
|
| #
7822e5db |
| 11-Aug-2023 |
walter erquinigo <walter@modular.com> |
[LLDB] Allow expression evaluators to set arbitrary timeouts
https://github.com/llvm/llvm-project/commit/59237bb52c9483fce395428bfab5996eabe54ed0 changed the behavior of the `SetTimeout` and `GetTim
[LLDB] Allow expression evaluators to set arbitrary timeouts
https://github.com/llvm/llvm-project/commit/59237bb52c9483fce395428bfab5996eabe54ed0 changed the behavior of the `SetTimeout` and `GetTimeout` methods of `EvaluateExpressionOptions`, which broke the Mojo REPL and related services (https://docs.modular.com/mojo/) because it relies on having infinite timeouts. That's a necessity because developers often use the REPL for executing extremely long-running numeric jobs. Having said that, `EvaluateExpressionOptions` shouldn't be that opinionated on this matter anyway. Instead, it should be the responsibility of the evaluator to define which timeout to use for each specific case.
Differential Revision: https://reviews.llvm.org/D157764
show more ...
|
|
Revision tags: llvmorg-17.0.0-rc2 |
|
| #
91a0e832 |
| 07-Aug-2023 |
David Spickett <david.spickett@linaro.org> |
[lldb] Make IR interpreter timeout test more loose
This has failed once in a while on our Windows on Arm bot: https://lab.llvm.org/buildbot/#/builders/219/builds/4688
Traceback (most recent call la
[lldb] Make IR interpreter timeout test more loose
This has failed once in a while on our Windows on Arm bot: https://lab.llvm.org/buildbot/#/builders/219/builds/4688
Traceback (most recent call last): File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\... self.assertGreaterEqual(duration_sec, 1) AssertionError: 0.9907491207122803 not greater than or equal to 1
We're not here to check that Python/the C++ lib/the OS implemented timers correctly, so accept anything 0.95 or greater.
show more ...
|
| #
61af957a |
| 02-Aug-2023 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Make IR interpretation interruptible
Check the interrupt flag while interpreting IR expressions and allow the user to interrupt them.
Differential revision: https://reviews.llvm.org/D156822
|
| #
59237bb5 |
| 01-Aug-2023 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Use a time-based timeout in IRInterpreter
At the moment the IRInterpreter will stop interpreting an expression after a hardcoded 4096 instructions. After it reaches the limit it will stop int
[lldb] Use a time-based timeout in IRInterpreter
At the moment the IRInterpreter will stop interpreting an expression after a hardcoded 4096 instructions. After it reaches the limit it will stop interpreting and leave the process in whatever state it was when the timeout was reached.
This patch changes the instruction limit to a timeout and uses the user-specified expression timeout value for this. The main motivation is to allow users on targets where we can't use the JIT to run more complicated expressions if they really want to (which they can do now by just increasing the timeout).
The time-based approach also seems much more meaningful than the arbitrary (and very low) instruction limit. 4096 instructions can be interpreted in a few microseconds on some setups but might take much longer if we have a slow connection to the target. I don't think any user actually cares about the number of instructions that are executed but only about the time they are willing to wait for a result.
Based off an original patch by Raphael Isemann.
Differential revision: https://reviews.llvm.org/D102762
show more ...
|
|
Revision tags: llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5 |
|
| #
2238dcc3 |
| 25-May-2023 |
Jonas Devlieghere <jonas@devlieghere.com> |
[NFC][Py Reformat] Reformat python files in lldb
This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black` (23.1.0).
If you end up having problem
[NFC][Py Reformat] Reformat python files in lldb
This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black` (23.1.0).
If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run `git checkout --ours <yourfile>` and then reformat it with black.
RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Differential revision: https://reviews.llvm.org/D151460
show more ...
|
|
Revision tags: llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2 |
|
| #
95367da4 |
| 07-Aug-2022 |
Dave Lee <davelee.com@gmail.com> |
[lldb] Remove unused "import unittest2" statements
|
|
Revision tags: llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6 |
|
| #
4cc8f2a0 |
| 17-Jun-2022 |
Dave Lee <davelee.com@gmail.com> |
[lldb][tests] Automatically call compute_mydir (NFC)
Eliminate boilerplate of having each test manually assign to `mydir` by calling `compute_mydir` in lldbtest.py.
Differential Revision: https://r
[lldb][tests] Automatically call compute_mydir (NFC)
Eliminate boilerplate of having each test manually assign to `mydir` by calling `compute_mydir` in lldbtest.py.
Differential Revision: https://reviews.llvm.org/D128077
show more ...
|
|
Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1 |
|
| #
99562332 |
| 20-Dec-2020 |
Michał Górny <mgorny@moritz.systems> |
[lldb] [test] Update test status for NetBSD
|
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3 |
|
| #
b725142c |
| 29-Jun-2020 |
Pavel Labath <pavel@labath.sk> |
[lldb] Fix type conversion in the Scalar getters
Summary: The Scalar class claims to follow the C type conversion rules. This is true for the Promote function, but it is not true for the implicit co
[lldb] Fix type conversion in the Scalar getters
Summary: The Scalar class claims to follow the C type conversion rules. This is true for the Promote function, but it is not true for the implicit conversions done in the getter methods.
These functions had a subtle bug: when extending the type, they used the signedness of the *target* type in order to determine whether to do sign-extension or zero-extension. This is not how things work in C, which uses the signedness of the *source* type. I.e., C does (sign-)extension before it does signed->unsigned conversion, and not the other way around.
This means that: (unsigned long)(int)-1 is equal to (unsigned long)0xffffffffffffffff and not (unsigned long)0x00000000ffffffff
Unsurprisingly, we have accumulated code which depended on this inconsistent behavior. It mainly manifested itself as code calling "ULongLong/SLongLong" as a way to get the value of the Scalar object in a primitive type that is "large enough". Previously, the ULongLong conversion did not do sign-extension, but now it does.
This patch makes the Scalar getters consistent with the declared semantics, and fixes the couple of call sites that were using it incorrectly.
Reviewers: teemperor, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D82772
show more ...
|
|
Revision tags: llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1 |
|
| #
e179e723 |
| 10-May-2020 |
Muhammad Omair Javaid <omair.javaid@linaro.org> |
Remove XFAIL arm-linux decorator from passing tests
|
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2 |
|
| #
99451b44 |
| 11-Feb-2020 |
Jordan Rupprecht <rupprecht@google.com> |
[lldb][test] Remove symlink for API tests.
Summary: Moves lldbsuite tests to lldb/test/API.
This is a largely mechanical change, moved with the following steps:
``` rm lldb/test/API/testcases mkdi
[lldb][test] Remove symlink for API tests.
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
show more ...
|