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, llvmorg-17.0.0-rc2, 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 |
|
#
193259cb |
| 12-Aug-2022 |
David Spickett <david.spickett@linaro.org> |
[LLDB] Remove __future__ imports from tests
Not needed now that we require python 3.
Reviewed By: kastiglione, JDevlieghere
Differential Revision: https://reviews.llvm.org/D131761
|
Revision tags: llvmorg-15.0.0-rc2, 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 |
|
#
33c0f93f |
| 11-Nov-2021 |
Pavel Labath <pavel@labath.sk> |
[lldb/test] Move gdb client utils into the packages tree
This infrastructure has proven proven its worth, so give it a more prominent place.
My immediate motivation for this is the desire to reuse
[lldb/test] Move gdb client utils into the packages tree
This infrastructure has proven proven its worth, so give it a more prominent place.
My immediate motivation for this is the desire to reuse this infrastructure for qemu platform testing, but I believe this move makes sense independently of that. Moving this code to the packages tree will allow as to add more structure to the gdb client tests -- currently they are all crammed into the same test folder as that was the only way they could access this code.
I'm splitting the code into two parts while moving it. The first once contains just the generic gdb protocol wrappers, while the other one contains the unit test glue. The reason for that is that for qemu testing, I need to run the gdb code in a separate process, so I will only be using the first part there.
Differential Revision: https://reviews.llvm.org/D113893
show more ...
|
Revision tags: 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 |
|
#
121cff78 |
| 13-Apr-2021 |
Pavel Labath <pavel@labath.sk> |
Revert "[lldb] [Process] Watch for fork/vfork notifications" and associated followups
This commit has caused the following tests to be flaky: TestThreadSpecificBpPlusCondition.py TestExitDuringExpre
Revert "[lldb] [Process] Watch for fork/vfork notifications" and associated followups
This commit has caused the following tests to be flaky: TestThreadSpecificBpPlusCondition.py TestExitDuringExpression.py
The exact cause is not known yet, but since both tests deal with threads, my guess is it has something to do with the tracking of creation of new threads (which the commit touches upon).
This reverts the following commits: d01bff8cbdc98fb8751f7bf10af19b47ae5c445d, ba62ebc48e8c424ce3a78ba01acda679d536dd47, e761b6b4c58d4f7ae1073d925d7cb321d68ee93a, a345419ee03095c8cdfbe1c2728467c4da8fa0a4.
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
#
a345419e |
| 12-Mar-2021 |
Michał Górny <mgorny@moritz.systems> |
[lldb] [Process] Watch for fork/vfork notifications
Watch for fork(2)/vfork(2) (also fork/vfork-style clone(2) on Linux) notifications and explicitly detach the forked child process, and add initial
[lldb] [Process] Watch for fork/vfork notifications
Watch for fork(2)/vfork(2) (also fork/vfork-style clone(2) on Linux) notifications and explicitly detach the forked child process, and add initial tests for these cases. The code covers FreeBSD, Linux and NetBSD process plugins. There is no new user-visible functionality provided -- this change lays foundations over subsequent work on fork support.
Differential Revision: https://reviews.llvm.org/D98822
show more ...
|
#
b601c671 |
| 12-Mar-2021 |
Michał Górny <mgorny@moritz.systems> |
[lldb] [client] Support for multiprocess extension
Add a minimal support for the multiprocess extension in gdb-remote client. It accepts PIDs as part of thread-ids, and rejects PIDs that do not mat
[lldb] [client] Support for multiprocess extension
Add a minimal support for the multiprocess extension in gdb-remote client. It accepts PIDs as part of thread-ids, and rejects PIDs that do not match the current inferior.
Differential Revision: https://reviews.llvm.org/D99603
show more ...
|