| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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
|
|
The test is failing on x86_64 but passing on arm64. Skip until Ismail
can investigate this further.
|
|
module"
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 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
|
|
module"
This reverts commit 273a2d337f675f3ee050f281b1fecc3e806b9a3c, since it
might be the cause for `TestStackCoreScriptedProcess` and
`TestInteractiveScriptedProcess` failures on GreenDragon:
https://green.lab.llvm.org/green/job/lldb-cmake/55460/`
|
|
This patch moves the `PassthroughScriptedProcess` & `PassthroughScriptedThread`
classes from the `interactive_scripted_process.py` test implementation
to the `lldb.scripted_process` python module.
This class is very versatile so it makes more sense to ship it with the
python module to make it easier for our adopters to derive their class
from it instead of copying it.
During the "migration", I've also noticed some bugs in the
`PassthroughScriptedThread` creation and update, so I also fixed that as
part of this patch.
Differential Revision: https://reviews.llvm.org/D151044
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
|
|
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>
|
|
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
|
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>
|
|
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 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 reverts commit 70b9822ef3b0774609c72d380504c9abfa717f81.
|
|
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. Then, we
create a intermediary scripted process who's job will be to wrap the
real process while intercepting 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.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
|
