…e use of it (llvm#109498)

This patch re-lands llvm#105449 and fixes the various test failures.

---------

Signed-off-by: Med Ismail Bennani <[email protected]>
(cherry picked from commit f732157)

I am using VSCode with the official vscode-lldb extension. When I try to
list the breakpoints in the debug console get the message:

```
br list
can't evaluate expressions when the process is running.
```

I know that this is wrong and you need to use
```
`br list
(lldb) br list
No breakpoints currently set.
```
but the error message is misleading. I cleaned up the code and now the
error message is

```
br list
sbframe object is not valid.
```
which is still not perfect, but at least it's not misleading.

(cherry picked from commit ccbb888)

This patch makes interactive mode as the default when using the crashlog
command. It replaces the existing `-i|--interactive` flag with a new
`-m|--mode` option, that can either be `interactive` or `batch`.

By default, when the option is not explicitely set by the user, the
interactive mode is selected, however, lldb will fallback to batch mode
if the command interpreter is not interactive or if stdout is not a tty.

This also adds some railguards to prevent users from using interactive
only options with the batch mode and updates the tests accordingly.

rdar://97801509

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

Signed-off-by: Med Ismail Bennani <[email protected]>
(cherry picked from commit 7b989ad)

…llvm#145104)

This patch addresses 2 issues:
1. It makes registers available on non-crashed threads all the time
2. It fixes arm64 registers parsing for registers that don't use the `x`
prefix (`fp` -> `x29` / `lr` -> `x30`)

---------

Signed-off-by: Med Ismail Bennani <[email protected]>
(cherry picked from commit 1db9afb)

…orm (llvm#150720)

This is NFC, I'm modernizing the interface before I add to it in a
subsequent commit.

(cherry picked from commit 4c8e79f)

In architectures where pointers may contain metadata, such as arm64e, it
is important to ignore those bits when comparing two different StackIDs,
as the metadata may not be the same even if the pointers are.

This patch is a step towards allowing consumers of pointers to decide
whether they want to keep or remove metadata, as opposed to discarding
metadata at the moment pointers are created. See
llvm#150537.

This was tested running the LLDB test suite on arm64e.

(cherry picked from commit 9c8e716)

Commit 9c8e716 updated some APIs that are used by this
downstream-only test.

(cherry picked from commit 5d30e9c)

…153117)

This patch changes the way frames created from scripted affordances like
Scripted Threads are displayed. Currently, they're marked artificial
which is used usually for compiler generated frames.

This patch changes that behaviour by introducing a new synthetic
StackFrame kind and moves 'artificial' to be a distinct StackFrame
attribut.

On top of making these frames less confusing, this allows us to know
when a frame was created from a scripted affordance.

rdar://155949703

Signed-off-by: Med Ismail Bennani <[email protected]>
(cherry picked from commit 6c10ab8)

The ctor that takes a reference to ExecutionContextRef can be
implemented in terms of the ctor that takes a pointer to that object,
removing code duplication.

(cherry picked from commit 80bd72b)

This *private* method is only defined as a member class of SBThread so
that it may be declared a `friend` of SBError and access a private
constructor of SBError that takes a `Status`, which is an `lldb_private`
object. In other words, the method does not use anything about the class
is belongs to, so it has no business being a member method.

A subsequent patch will need to add a new argument to this class, a
`Process::StopLocker`, which is also another `lldb_private` object. This
is another strong suggestion that this method does not belong on the
header file of a public API, even if at the private visibility level. We
can't forward declare nested types like `Process:StopLocker`, so this
problem is not easily solvable.

This commit moves the method out of the header and into an anon
namespace of the cpp file. It is also made to return a Status instead,
and the private `SBError` constructor is accessed by the SBThread
methods that call it.

(cherry picked from commit 849daa4)

…#152020)

Prior to this patch, SBFrame/SBThread methods exhibit racy behavior if
called while the process is running, because they do not lock the
`Process::RetRunLock` mutex. If they did, they would fail, correctly
identifying that the process is not running.

Some methods _attempt_ to protect against this with the pattern:

```
ExecutionContext exe_ctx(m_opaque_sp.get(), lock); // this is a different lock
Process *process = exe_ctx.GetProcessPtr();
if (process) {
  Process::StopLocker stop_locker;
  if (stop_locker.TryLock(&process->GetRunLock()))
        .... do work ...
```

However, this is also racy: the constructor of `ExecutionContext` will
access the frame list, which is something that can only be done once the
process is stopped.

With this patch:

1. The constructor of `ExecutionContext` now expects a `ProcessRunLock`
as an argument. It attempts to lock the run lock, and only fills in
information about frames and threads if the lock can be acquired.
Callers of the constructor are expected to check the lock.
2. All uses of ExecutionContext are adjusted to conform to the above.
3. The SBThread.cpp-defined helper function ResumeNewPlan now expects a
locked ProcessRunLock as _proof_ that the execution is stopped. It will
unlock the mutex prior to resuming the process.

This commit exposes many opportunities for early-returns, but these
would increase the diff of this patch and distract from the important
changes, so we opt not to do it here.

(cherry picked from commit f12e038)
(cherry picked from commit 057b4b0)
Signed-off-by: Med Ismail Bennani <[email protected]>

This case is passing since llvm#152020.

(cherry picked from commit 52f7cfb)

This patch introduces a new scripting affordance in lldb:
`ScriptedFrame`.

This allows user to produce mock stackframes in scripted threads and
scripted processes from a python script.

With this change, StackFrame can be synthetized from different sources:
- Either from a dictionary containing a load address, and a frame index,
  which is the legacy way.
- Or by creating a ScriptedFrame python object.

One particularity of synthezising stackframes from the ScriptedFrame
python object, is that these frame have an optional PC, meaning that
they don't have a report a valid PC and they can act as shells that just
contain static information, like the frame function name, the list of
variables or registers, etc. It can also provide a symbol context.

rdar://157260006

(cherry picked from commit 84b5620)
Signed-off-by: Med Ismail Bennani <[email protected]>

Signed-off-by: Med Ismail Bennani <[email protected]>