llvm-project.git/lldb/test/API/functionalities/interactive_scripted_process/TestInteractiveScriptedProcess.py, branch main Unnamed repository; edit this file 'description' to name the repository. [lldb][Tests] Reformat API tests with black 2023-09-11T16:44:12+00:00 David Spickett david.spickett@linaro.org 2023-09-11T16:42:27+00:00 6bf923d5c3daf5d66e0acf53d037a12ceff4a275 These are all recent additions I think, including a few of mine for AArch64. Going forward the CI checks should help us fix these earlier. 
These are all recent additions I think, including a few of mine
for AArch64.

Going forward the CI checks should help us fix these earlier.
Replace the singleton "ShadowListener" with a primary and N secondary Listeners 2023-08-16T17:35:32+00:00 Jim Ingham jingham@apple.com 2023-08-15T18:32:55+00:00 2e7aa2ee34eb53347396731dc8a3b2dbc6a3df45 Before the addition of the process "Shadow Listener" you could only have one Listener observing the Process Broadcaster. That was necessary because fetching the Process event is what switches the public process state, and for the execution control logic to be manageable you needed to keep other listeners from causing this to happen before the main process control engine was ready. Ismail added the notion of a "ShadowListener" - which allowed you ONE extra process listener. This patch inverts that setup by designating the first listener as primary - and giving it priority in fetching events. Differential Revision: https://reviews.llvm.org/D157556 
Before the addition of the process "Shadow Listener" you could only have one
Listener observing the Process Broadcaster.  That was necessary because fetching the
Process event is what switches the public process state, and for the execution
control logic to be manageable you needed to keep other listeners from causing
this to happen before the main process control engine was ready.

Ismail added the notion of a "ShadowListener" - which allowed you ONE
extra process listener.  This patch inverts that setup by designating the
first listener as primary - and giving it priority in fetching events.

Differential Revision: https://reviews.llvm.org/D157556
[lldb] Skip instead of XFAIL TestInteractiveScriptedProcess 2023-05-26T20:13:18+00:00 Jonas Devlieghere jonas@devlieghere.com 2023-05-26T20:10:51+00:00 c0d1128f4243276e9c771b88c2012c87c1a71495 The test is failing on x86_64 but passing on arm64. Skip until Ismail can investigate this further. 
The test is failing on x86_64 but passing on arm64. Skip until Ismail
can investigate this further.
Re-revert "[lldb] Move PassthroughScriptedProcess to `lldb.scripted_process` module" 2023-05-25T21:00:11+00:00 Med Ismail Bennani ismail@bennani.ma 2023-05-25T20:59:26+00:00 0e90ac9c94d716fa78e0c86a6c7f6ff24decf7fe This reverts commit 429e74839506ea8ba962d24647264ed81f680bbf since it didn't address the test failures on GreenDragon. This patch will mark the tests as expected to fail until I can reproduce the issue and find a solution. Signed-off-by: Med Ismail Bennani <ismail@bennani.ma> 
This reverts commit 429e74839506ea8ba962d24647264ed81f680bbf since it
didn't address the test failures on GreenDragon.

This patch will mark the tests as expected to fail until I can reproduce
the issue and find a solution.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
[NFC][Py Reformat] Reformat python files in lldb 2023-05-25T19:54:09+00:00 Jonas Devlieghere jonas@devlieghere.com 2023-05-25T15:48:57+00:00 2238dcc39358353cac21df75c3c3286ab20b8f53 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 
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
[lldb/test] Fix test failure from missing decorator 2023-04-25T23:08:55+00:00 Med Ismail Bennani medismail.bennani@gmail.com 2023-04-25T23:08:55+00:00 f8d6542e873be7821636fd5ae313e8249c235438 This should fix a test failure in TestInteractiveScriptedProcess.py caused by a missing decorator added in d0d902d. Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com> 
This should fix a test failure in TestInteractiveScriptedProcess.py
caused by a missing decorator added in d0d902d.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
[lldb/test] Disable Interactive Scripted Process test unless Darwin 2023-04-25T23:00:58+00:00 Med Ismail Bennani medismail.bennani@gmail.com 2023-04-25T23:00:13+00:00 d0d902df0698f94957e13df159e9cd159a99344c Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com> 
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
[lldb/test] Consolidate interactive scripted process debugging test 2023-04-25T22:03:45+00:00 Med Ismail Bennani medismail.bennani@gmail.com 2023-04-25T22:01:50+00:00 d3a6b93135cd344737b2877b78afe9c862e40041 This patch improve the interactive scripted process debugging test by adding test coverage for child process breakpoint setting and execution state change. This patch introduces a new test case for a multiplexed launch, which does the same thing as the simple passthrough launch. After the multiplexer process stops, this new test launches 2 other scripted processes that should contain respectively the even and odd threads from the multiplexer scripted process. Then, we create a breakpoint on one the child scripted process, make sure it was set probably on the child process, the multiplexer process and the real process. This also test the breakpoint name tagging at the multiplexer level. Finally, we resume the child process that had a breakpoint and make sure that all the processes has stopped at the right location. Differential Revision: https://reviews.llvm.org/D149179 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com> 
This patch improve the interactive scripted process debugging test by
adding test coverage for child process breakpoint setting and execution
state change.

This patch introduces a new test case for a multiplexed launch, which
does the same thing as the simple passthrough launch. After the
multiplexer process stops, this new test launches 2 other scripted processes
that should contain respectively the even and odd threads from the
multiplexer scripted process.

Then, we create a breakpoint on one the child scripted process, make
sure it was set probably on the child process, the multiplexer process
and the real process. This also test the breakpoint name tagging at the
multiplexer level.

Finally, we resume the child process that had a breakpoint and make sure
that all the processes has stopped at the right location.

Differential Revision: https://reviews.llvm.org/D149179

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
[lldb] Improve breakpoint management for interactive scripted process 2023-04-25T22:03:15+00:00 Med Ismail Bennani medismail.bennani@gmail.com 2023-04-25T22:03:15+00:00 e31d0c20e411f22a943f1ed5f8b618c529436c59 This patch improves breakpoint management when doing interactive scripted process debugging. In other to know which process set a breakpoint, we need to do some book keeping on the multiplexer scripted process. When initializing the multiplexer, we will first copy breakpoints that are already set on the driving target. Everytime we launch or resume, we should copy breakpoints from the multiplexer to the driving process. When creating a breakpoint from a child process, it needs to be set both on the multiplexer and on the driving process. We also tag the created breakpoint with the name and pid of the originator process. This patch also implements all the requirement to achieve proper breakpoint management. That involves: - Adding python interator for breakpoints and watchpoints in SBTarget - Add a new `ScriptedProcess.create_breakpoint` python method Differential Revision: https://reviews.llvm.org/D148548 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com> 
This patch improves breakpoint management when doing interactive
scripted process debugging.

In other to know which process set a breakpoint, we need to do some book
keeping on the multiplexer scripted process. When initializing the
multiplexer, we will first copy breakpoints that are already set on the
driving target.

Everytime we launch or resume, we should copy breakpoints from the
multiplexer to the driving process.

When creating a breakpoint from a child process, it needs to be set both
on the multiplexer and on the driving process. We also tag the created
breakpoint with the name and pid of the originator process.

This patch also implements all the requirement to achieve proper
breakpoint management. That involves:

- Adding python interator for breakpoints and watchpoints in SBTarget
- Add a new `ScriptedProcess.create_breakpoint` python method

Differential Revision: https://reviews.llvm.org/D148548

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
[lldb] Add an example of interactive scripted process debugging 2023-04-25T22:02:34+00:00 Med Ismail Bennani medismail.bennani@gmail.com 2023-04-21T20:34:56+00:00 6cf668016efde05db8c9f179843ec457ad017ff7 This patch is a proof of concept that shows how a scripted process could be used with real process to perform interactive debugging. In this example, we run a process that spawns 10 threads. That process gets launched by an intermediary scripted process who's job is to intercept all of it's process events and dispatching them back either to the real process or to other child scripted processes. In this example, we have 2 child scripted processes, with even and odd thread indices. The goal is to be able to do thread filtering and explore the various interactive debugging approaches, by letting a child process running when stopping the other process and inspecting it. Another approach would be to have the child processes execution in-sync to force running every child process when one of them starts running. Differential Revision: https://reviews.llvm.org/D145297 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com> 
This patch is a proof of concept that shows how a scripted process could
be used with real process to perform interactive debugging.

In this example, we run a process that spawns 10 threads.
That process gets launched by an intermediary scripted process who's job
is to intercept all of it's process events and dispatching them
back either to the real process or to other child scripted processes.

In this example, we have 2 child scripted processes, with even and odd
thread indices. The goal is to be able to do thread filtering and
explore the various interactive debugging approaches, by letting a child
process running when stopping the other process and inspecting it.
Another approach would be to have the child processes execution in-sync
to force running every child process when one of them starts running.

Differential Revision: https://reviews.llvm.org/D145297

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>