Revert "[lldb] Implement basic support for reverse-continue" (#123906)

Reverts llvm/llvm-project#112079 due to failures on the arm bot.

[lldb] Implement basic support for reverse-continue (#112079)

This commit adds support for a
`SBProcess::ContinueInDirection()` API. A user-accessible command for
this will follow in a later commit.

[lldb] Implement basic support for reverse-continue (#112079)

This commit adds support for a
`SBProcess::ContinueInDirection()` API. A user-accessible command for
this will follow in a later commit.

This feature depends on a gdbserver implementation (e.g. `rr`) providing
support for the `bc` and `bs` packets. `lldb-server` does not support
those packets, and there is no plan to change that. For testing
purposes, this commit adds a Python implementation of *very limited*
record-and-reverse-execute functionality, implemented as a proxy between
lldb and lldb-server in `lldbreverse.py`. This should not (and in
practice cannot) be used for anything except testing.

The tests here are quite minimal but we test that simple breakpoints and
watchpoints work as expected during reverse execution, and that
conditional breakpoints and watchpoints work when the condition calls a
function that must be executed in the forward direction.

show more ...

Revert "[lldb] Implement basic support for reverse-continue (#99736)"

Reverting this again; I added a commit which added @skipIfDarwin
markers to the TestReverseContinueBreakpoints.py and
TestRevers

Revert "[lldb] Implement basic support for reverse-continue (#99736)"

Reverting this again; I added a commit which added @skipIfDarwin
markers to the TestReverseContinueBreakpoints.py and
TestReverseContinueNotSupported.py API tests, which use lldb-server
in gdbserver mode which does not work on Darwin. But the aarch64 ubuntu
bot reported a failure on TestReverseContinueBreakpoints.py,
https://lab.llvm.org/buildbot/#/builders/59/builds/6397

File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/reverse-execution/TestReverseContinueBreakpoints.py", line 63, in test_reverse_continue_skip_breakpoint
self.reverse_continue_skip_breakpoint_internal(async_mode=False)
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/functionalities/reverse-execution/TestReverseContinueBreakpoints.py", line 81, in reverse_continue_skip_breakpoint_internal
self.expect(
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2372, in expect
self.runCmd(
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1002, in runCmd
self.assertTrue(self.res.Succeeded(), msg + output)
AssertionError: False is not true : Process should be stopped due to history boundary
Error output:
error: Process must be launched.

This reverts commit 4f297566b3150097de26c6a23a987d2bd5fc19c5.

show more ...

[lldb] Implement basic support for reverse-continue (#99736)

This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later com

[lldb] Implement basic support for reverse-continue (#99736)

This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later commit.

This feature depends on a gdbserver implementation (e.g. `rr`) providing
support for the `bc` and `bs` packets. `lldb-server` does not support
those packets, and there is no plan to change that. So, for testing
purposes, `lldbreverse.py` wraps `lldb-server` with a Python
implementation of *very limited* record-and-replay functionality for use
by *tests only*.

The majority of this PR is test infrastructure (about 700 of the 950
lines added).

show more ...

Revert "[lldb] Implement basic support for reverse-continue (#99736)"

This reverts commit d5e1de6da96c1ab3b8cae68447e8ed3696a7006e.

[lldb] Implement basic support for reverse-continue (#99736)

This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later com

[lldb] Implement basic support for reverse-continue (#99736)

This commit only adds support for the
`SBProcess::ReverseContinue()` API. A user-accessible command for this
will follow in a later commit.

This feature depends on a gdbserver implementation (e.g. `rr`) providing
support for the `bc` and `bs` packets. `lldb-server` does not support
those packets, and there is no plan to change that. So, for testing
purposes, `lldbreverse.py` wraps `lldb-server` with a Python
implementation of *very limited* record-and-replay functionality for use
by *tests only*.

The majority of this PR is test infrastructure (about 700 of the 950
lines added).

show more ...

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
ant

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

` ResultTy DoFoo(Status& error)
`
to

` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

show more ...

Fix a stall in running `quit` while a live process is running (#74687)

We need to generate events when finalizing, or we won't know that we
succeeded in stopping the process to detach/kill. Instea

Fix a stall in running `quit` while a live process is running (#74687)

We need to generate events when finalizing, or we won't know that we
succeeded in stopping the process to detach/kill. Instead, we stall and
then after our 20 interrupt timeout, we kill the process (even if we
were supposed to detach) and exit.

OTOH, we have to not generate events when the Process is being
destructed because shared_from_this has already been torn down, and
using it will cause crashes.

show more ...

[lldb] Fix assert in ScriptedProcess destructor (#71744)

This patch should fix a test failure in
`Expr/TestIRMemoryMapWindows.test`:

https://lab.llvm.org/buildbot/#/builders/219/builds/6786

T

[lldb] Fix assert in ScriptedProcess destructor (#71744)

This patch should fix a test failure in
`Expr/TestIRMemoryMapWindows.test`:

https://lab.llvm.org/buildbot/#/builders/219/builds/6786

The problem here is that since 7991412 landed, all the
`ScriptInterpreter::CreateScripted*Interface` now return a `nullptr`
when using the base `ScriptInterpreter` instance, instead of
`ScriptInterpreterPython` for instance.

This nullptr is actually well handled in the various places where we
create a Scripted Interface, however, because of the way to instanciate
a process, the process plugin manager have to iterate over every process
plugin and call the `CreateInstance` static function that should
instanciate the right object.

So in the ScriptedProcess case, because we are getting a `nullptr` when
trying to create a `ScriptedProcessInterface`, we try to discard the
process object, which calls the Process destructor, which in turns calls
the `ScriptedProcess` plugin `IsAlive` method. That method will fire an
assertion if the scripted interface pointer is not allocated.

This patch address that issue by setting a flag when destroying the
ScriptedProcess object, and checks that flag when calling `IsAlive`.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

[lldb] Fix assertions caused by un-checked errors in ScriptedProcess

This patch should fix some assertion that started getting hit after f22d82c.

That commit changed the scripted object plugin crea

[lldb] Fix assertions caused by un-checked errors in ScriptedProcess

This patch should fix some assertion that started getting hit after f22d82c.

That commit changed the scripted object plugin creation to use
`llvm::Expected<T>` as a return type to enforce error handling, however
I forgot to handle the error which caused the assert.

The interesting part about this, is that since that assert was triggered
in the ScriptedProcess constructor (where the `llvm::Error` wasn't
handled), that impacted every test that launched any kind of process,
since the process plugin manager would eventually also iterate over the
`ScriptedProcess::Create` factory method.

This patch should fix the assertions by handling the errors.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

[lldb/Interpreter] Make ScriptedInterface Object creation more generic (#68052)

This patch changes the way plugin objects used with Scripted Interfaces
are created.

Instead of implementing a dif

[lldb/Interpreter] Make ScriptedInterface Object creation more generic (#68052)

This patch changes the way plugin objects used with Scripted Interfaces
are created.

Instead of implementing a different SWIG method to create the object for
every scripted interface, this patch makes the creation more generic by
re-using some of the ScriptedPythonInterface templated Dispatch code.

This patch also improves error handling of the object creation by
returning an `llvm::Expected`.

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

[lldb] Fix dead lock issue when loading modules in Scripted Process

This patch attempts to fix a dead lock when loading modules in a Scripted
Process.

This issue was triggered by loading the module

[lldb] Fix dead lock issue when loading modules in Scripted Process

This patch attempts to fix a dead lock when loading modules in a Scripted
Process.

This issue was triggered by loading the modules after the process did resume,
but before the process actually stop, causing the language runtime mutex to
be locked by a separate thread, responsible to unwind the stack (using
the runtime unwind plan), while the module loading thread was trying to
notify the runtimes of the newly loaded module.

To address that, this patch moves the module loading logic to be done before
sending the stop event, to prevent the dead lock situation described above.

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

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

[lldb] Add support for negative integer to {SB,}StructuredData

This patch refactors the `StructuredData::Integer` class to make it
templated, makes it private and adds 2 public specialization for bo

[lldb] Add support for negative integer to {SB,}StructuredData

This patch refactors the `StructuredData::Integer` class to make it
templated, makes it private and adds 2 public specialization for both
`int64_t` & `uint64_t` with a public type aliases, respectively
`SignedInteger` & `UnsignedInteger`.

It adds new getter for signed and unsigned interger values to the
`StructuredData::Object` base class and changes the implementation of
`StructuredData::Array::GetItemAtIndexAsInteger` and
`StructuredData::Dictionary::GetValueForKeyAsInteger` to support signed
and unsigned integers.

This patch also adds 2 new `Get{Signed,Unsigned}IntegerValue` to the
`SBStructuredData` class and marks `GetIntegerValue` as deprecated.

Finally, this patch audits all the caller of `StructuredData::Integer`
or `StructuredData::GetIntegerValue` to use the proper type as well the
various tests that uses `SBStructuredData.GetIntegerValue`.

rdar://105575764

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

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

[lldb] Improve breakpoint management for interactive scripted process

This patch improves breakpoint management when doing interactive
scripted process debugging.

In other to know which process set

[lldb] Improve breakpoint management for interactive scripted process

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>

show more ...

[lldb/Plugin] Add breakpoint setting support to ScriptedProcess

This patch adds support for breakpoint setting to Scripted Processes.

For now, Scripted Processes only support setting software break

[lldb/Plugin] Add breakpoint setting support to ScriptedProcess

This patch adds support for breakpoint setting to Scripted Processes.

For now, Scripted Processes only support setting software breakpoints.

When doing interactive scripted process debugging, it makes use of the
memory writing capability to write the trap opcodes in the memory of the
driving process. However the real process' target doesn't keep track of
the breakpoints that got added by the scripted process. This is a design
that we might need to change in the future, since we'll probably need to
do some book keeping to handle breakpoints that were set by different
scripted processes.

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

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

show more ...

[lldb] Move ScriptedProcess private state update to implementation

While debugging a Scripted Process, in order to update its state and
work nicely with lldb's execution model, it needs to toggle it

[lldb] Move ScriptedProcess private state update to implementation

While debugging a Scripted Process, in order to update its state and
work nicely with lldb's execution model, it needs to toggle its private
state from running to stopped, which will result in broadcasting a
process state changed event to the debugger listener.

Originally, this state update was done systematically in the Scripted
Process C++ plugin, however in order to make scripted process
interactive, we need to be able to update their state dynamically.

This patch makes use of the recent addition of the
SBProcess::ForceScriptedState to programatically, and moves the
process private state update to the python implementation of the resume
method instead of doing it in ScriptedProcess::DoResume.

This patch also removes the unused ShouldStop & Stop scripted
process APIs, and adds new ScriptedInterface transform methods for
boolean arguments. This allow the user to programmatically decide if
after running the process, we should stop it (which is the default setting).

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

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

show more ...

[lldb] Fix assertion when ScriptedProcess have no pid after launch

This patch should fix an assertion that causes some test failures:
https://ci.swift.org/view/LLDB/job/llvm-org-lldb-release-debugin

[lldb] Fix assertion when ScriptedProcess have no pid after launch

This patch should fix an assertion that causes some test failures:
https://ci.swift.org/view/LLDB/job/llvm-org-lldb-release-debuginfo/3587/console

This was caused by the changes introduces in `88f409194d5a` where we
replaced `DidLaunch` by `DidResume` in the `ScriptedProcess` class.

However, by the time we resume the process, the pid should be already
set. To address this, this patch brings back `DidLaunch` which will
initialize the ScriptedProcess pid with a placeholder value. That value
will be updated in `DidResume` to the final pid.

Note, this 2 stage PID initialization is necessary sometimes, when the
scripted process gets stopped at entry (launch) and gets assigned an
object that contains the PID value. In this case, we need to update the
PID when we resume the process after we've stopped at entry.

This also replaces the default scripted process id to an arbitrary
number (42) since the current value (0) is considered invalid.

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

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

show more ...

[lldb] Parse the crashlog only once

Now that we can pass Python objects to the scripted process instance, we
don't need to parse the crashlog twice anymore.

Differential revision: https://reviews.l

[lldb] Parse the crashlog only once

Now that we can pass Python objects to the scripted process instance, we
don't need to parse the crashlog twice anymore.

Differential revision: https://reviews.llvm.org/D148063

show more ...

[lldb] Fix a 32 bit warning in ScriptedProcessInterface

../llvm-project/lldb/include/lldb/Interpreter/ScriptedProcessInterface.h:61:12:
warning: implicit conversion from 'unsigned long long' to 'siz

[lldb] Fix a 32 bit warning in ScriptedProcessInterface

../llvm-project/lldb/include/lldb/Interpreter/ScriptedProcessInterface.h:61:12:
warning: implicit conversion from 'unsigned long long' to 'size_t' (aka 'unsigned int')
changes value from 18446744073709551615 to 4294967295 [-Wconstant-conversion]
../llvm-project/lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp:275:39:
warning: result of comparison of constant 18446744073709551615 with expression
of type 'size_t' (aka 'unsigned int') is always false [-Wtautological-constant-out-of-range-compare]

This happens because size_t on 32 bit is 32 bit, but LLDB_INVALID_OFFSET is
UINT64_MAX. Return lldb::offset_t instead, which is 64 bit everywhere.

DoWriteMemory still returns size_t but this is because every other
Process derived thing does that. As long as the failure check works I think
it should be fine.

Reviewed By: mib

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

show more ...

Revert "[lldb/Plugin] Add breakpoint setting support to ScriptedProcesses."

This reverts commit cfe06f495beb520ab366957d1108bb80c7c92832.

Revert "[lldb] Move ScriptedProcess private state update to implementation"

This reverts commit 3c33d72e7fa83beb8a9b39fb3b8ecf4ee00c697d.

[lldb/Utility] Fix layering violation caused by ScriptedMetadata

This patch moves `ScriptedMetadata.h` from the `Interpreter` directory to
the `Utility` sub-directory since `ProcessInfo.h` depends o

[lldb/Utility] Fix layering violation caused by ScriptedMetadata

This patch moves `ScriptedMetadata.h` from the `Interpreter` directory to
the `Utility` sub-directory since `ProcessInfo.h` depends on it.

It also gets rid of the unused `OptionGroupPythonClassWithDict`
constructor for `ScriptedMetadata` which would address the layering
violation.

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

show more ...

[lldb/Plugin] Add breakpoint setting support to ScriptedProcesses.

This patch adds support for breakpoint setting to Scripted Processes.

For now, Scripted Processes only support setting software br

[lldb/Plugin] Add breakpoint setting support to ScriptedProcesses.

This patch adds support for breakpoint setting to Scripted Processes.

For now, Scripted Processes only support setting software breakpoints.

When doing interactive scripted process debugging, it makes use of the
memory writing capability to write the trap opcodes in the memory of the
driving process. However the real process' target doesn't keep track of
the breakpoints that got added by the scripted process. This is a design
that we might need to change in the future, since we'll probably need to
do some book keeping to handle breakpoints that were set by different
scripted processes.

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

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

show more ...

[lldb] Move ScriptedProcess private state update to implementation

While debugging a Scripted Process, in order to update its state and
work nicely with lldb's execution model, it needs to toggle it

[lldb] Move ScriptedProcess private state update to implementation

While debugging a Scripted Process, in order to update its state and
work nicely with lldb's execution model, it needs to toggle its private
state from running to stopped, which will result in broadcasting a
process state changed event to the debugger listener.

Originally, this state update was done systematically in the Scripted
Process C++ plugin, however in order to make scripted process
interactive, we need to be able to update their state dynamically.

This patch makes use of the recent addition of the
`SBProcess::ForceScriptedState` to programatically, and moves the
process private state update to the python implementation of the `resume`
method instead of doing it in `ScriptedProcess::DoResume`.

This patch also removes the unused `ShouldStop` & `Stop` scripted
process APIs, and adds new ScriptedInterface transform methods for
boolean arguments. This allow the user to programmatically decide if
after running the process, we should stop it (which is the default setting).

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

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

show more ...

[lldb/Plugins] Add memory writing capabilities to Scripted Process

This patch adds memory writing capabilities to the Scripted Process plugin.

This allows to user to get a target address and a memo

[lldb/Plugins] Add memory writing capabilities to Scripted Process

This patch adds memory writing capabilities to the Scripted Process plugin.

This allows to user to get a target address and a memory buffer on the
python scripted process implementation that the user can make processing
on before performing the actual write.

This will also be used to write trap instruction to a real process
memory to set a breakpoint.

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

show more ...