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>
Add basic tests for `frame variable`'s ability to direct access fields of `this` and
ivars of `self`.
This splits the tests, preventing ObjC tests from running on Linux.
Differential Revision: https://reviews.llvm.org/D145348
Add basic tests for `frame variable`'s ability to direct access fields of `this` and
ivars of `self`.
Differential Revision: https://reviews.llvm.org/D145348
When using SBProcess::GetScriptedImplementation in python, if the
process has a valid implementation, we returned a reference of the
object without incrementing the reference counting. That causes the
interpreter to crash after accessing the reference several times.
This patch address this by incrementing the reference count when passing
the valid object reference.
Differential Revision: https://reviews.llvm.org/D145260
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
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>
The goal of the simple patch is to clean-up the scripted process
interface by removing methods that were introduced with the interface
originally, but that were never really implemented (get_thread_with_id &
get_registers_for_thread).
This patch also changes `get_memory_region_containing_address` to have a
base implementation (that retunrs `None`), instead of forcing the user
to override it in their derived class.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch adds process attach capabilities to the ScriptedProcess
plugin. This doesn't really expects a PID or process name, since the
process state is already script, however, this allows to create a
scripted process without requiring to have an executuble in the target.
In order to do so, this patch also turns the scripted process related
getters and setters from the `ProcessLaunchInfo` and
`ProcessAttachInfo` classes to a `ScriptedMetadata` instance and moves
it in the `ProcessInfo` class, so it can be accessed interchangeably.
This also adds the necessary SWIG wrappers to convert the internal
`Process{Attach,Launch}InfoSP` into a `SB{Attach,Launch}Info` to pass it
as argument the scripted process python implementation and convert it
back to the internal representation.
rdar://104577406
Differential Revision: https://reviews.llvm.org/D143104
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch tries to address an interoperability issue when writing
python string into the process memory.
Since the python string is not null-terminated, it would still be
written to memory however, when trying to read it again with
`SBProcess::ReadCStringFromMemory`, the memory read would fail, since
the read string doens't contain a null-terminator, and therefore is not
a valid C string.
To address that, this patch extends the `SBProcess` SWIG interface to
expose a new `WriteMemoryAsCString` method that is only exposed to the
SWIG target language. That method checks that the buffer to write is
null-terminated and otherwise, it appends a null byte at the end of it.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
With this patch member-function pointers are formatted using
`CXXFunctionPointerSummaryProvider`.
This turns,
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94
```
into
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94 (a.out`Foo::member_func() at main.cpp:3)
```
Differential Revision: https://reviews.llvm.org/D145242
Before this patch, LLDB used to format pointers to members, such as,
```
void (Foo::*pointer_to_member_func)() = &Foo::member_func;
```
as `eFormatBytes`. E.g.,
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) $1 = 94 3f 00 00 01 00 00 00 00 00 00 00 00 00 00 00
```
This patch makes sure we format pointers to member functions the same
way we do regular function pointers.
After this patch we format member pointers as:
```
(lldb) v pointer_to_member_func
(void (Foo::*)()) ::pointer_to_member_func = 0x00000000000000000000000100003f94
```
Differential Revision: https://reviews.llvm.org/D145241
Revert while I investigate two CI bot failures;
the more important is the lldb-arm-ubuntu where
the FixAddress is removing the 0th bit so we're
adding the `actual=` decorator on a string pointer,
```
Got output:
(char *) strptr = 0x00400817 (actual=0x400816) ptr = [{ },{H}]
```
in TestDataFormatterSmartArray.py line 229.
This reverts commit 4d635be2db.
On target where metadata is stored in bits that aren't used for
virtual addressing -- AArch64 Top Byte Ignore and pointer authentication
are two examples -- an SBValue object representing a pointer will
return the address with metadata for SBValue::GetValueAsUnsigned.
Users may want to get the virtual address without the metadata;
this new method gives them a way to do this.
Differential Revision: https://reviews.llvm.org/D142792
This patch adds the following methods:
* `GetType()`
* `GetWatchValueKind()`
* `GetWatchSpec()`
* `IsWatchingReads()`
* `IsWatchingWrites()`
These mostly expose methods that `lldb_private::Watchpoint` already
had. Tests are included that exercise these new methods.
The motivation for exposing these are as follows:
* `GetType()` - With this information and the address from a watchpoint
it is now possible to construct an SBValue from an SBWatchpoint.
Previously this wasn't possible. The included test case illustrates
doing this.
* `GetWatchValueKind()` - This allows the caller to determine whether the
watchpoint is a variable watchpoint or an expression watchpoint. A new
enum (`WatchpointValueKind`) has been introduced to represent the
return values. Unfortunately the name `WatchpointKind` was already
taken.
* `GetWatchSpec()` - This allows (at least for variable watchpoints)
to use a sensible name for SBValues created from an SBWatchpoint.
* `IsWatchingReads()` - This allow checking if a watchpoint is
monitoring read accesses.
* `IsWatchingWRites()` - This allow checking if a watchpoint is
monitoring write accesses.
rdar://105606978
Reviewers: jingham, mib, bulbazord, jasonmolenda, JDevlieghere
Differential Revision: https://reviews.llvm.org/D144937
initial stop. The code was using PrivateResume when it should have
used Resume.
This was allowing expression evaluation while the target was running,
and though that was caught a litle later on, we should never have gotten
that far. To make sure that this is caught immediately I made an error
SBValue when this happens, and test that we get this error.
Differential Revision: https://reviews.llvm.org/D144665
The latter only checks built-in commands. I also added some docs to
make the distinction clear and a test.
Differential Revision: https://reviews.llvm.org/D144929
In order to run a {break,watch}point command, lldb can resolve to the
script interpreter to run an arbitrary piece of code or call into a
user-provided function. To do so, we will generate a wrapping function,
where we first copy lldb's internal dictionary keys into the
interpreter's global dictionary, copied inline the user code before
resetting the global dictionary to its previous state.
However, {break,watch}point commands can optionally return a value that
would tell lldb whether we should stop or not. This feature was
only implemented for breakpoint commands and since we inlined the user
code directly into the wrapping function, introducing an early return,
that caused lldb to let the interpreter global dictionary tinted with the
internal dictionary keys.
This patch fixes that issue while also adding the stopping behaviour to
watchpoint commands.
To do so, this patch refactors the {break,watch}point command creation
method, to let the lldb wrapper function generator know if the user code is
a function call or a arbitrary expression.
Then the wrapper generator, if the user input was a function call, the
wrapper function will call the user function and save the return value into
a variable. If the user input was an arbitrary expression, the wrapper will
inline it into a nested function, call the nested function and save the
return value into the same variable. After resetting the interpreter global
dictionary to its previous state, the generated wrapper function will return
the varible containing the return value.
rdar://105461140
Differential Revision: https://reviews.llvm.org/D144688
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This has been flaky on the Windows on Arm LLDB bot.
https://lab.llvm.org/buildbot/#/builders/219/builds/826
Given that test_stop_reply_reports_multiple_threads is already expected
to fail on Windows, this is not suprising.
Context: The `expression` command uses artificial variables to store the expression
result. This result variable is unconditionally kept around after the expression command
has completed. These variables are known as persistent results. These are the variables
`$0`, `$1`, etc, that are displayed when running `p` or `expression`.
This change allows users to control whether result variables are persisted, by
introducing a `--persistent-result` flag.
This change keeps the current default behavior, persistent results are created by
default. This change gives users the ability to opt-out by re-aliasing `p`. For example:
```
command unalias p
command alias p expression --persistent-result false --
```
For consistency, this flag is also adopted by `dwim-print`. Of note, if asked,
`dwim-print` will create a persistent result even for frame variables.
Differential Revision: https://reviews.llvm.org/D144230
Adopt `expression`'s options in `dwim-print`.
This is primarily added to support the `--language`/`-l` flag.
Differential Revision: https://reviews.llvm.org/D144114
In json::Value, getAsInteger returns an optional<int64_t> and getAsNumber
returns an optional<double>. If a value is larger than what an int64_t
can hold but smaller than what a uint64_t can hold, the getAsInteger
function will fail but the getAsNumber will succeed. However, the value
shouldn't be interpreted as a double.
rdar://105556974
Differential Revision: https://reviews.llvm.org/D144238
Remove the persistent result variable after executing `po`.
Without this change, the following behavior happens:
```
(lldb) p thing
(NSObject *) $0 = 0x600000008000
(lldb) po thing
<NSObject: 0x600000008000>
(lldb) p thing
(NSObject *) $2 = 0x600000008000
(lldb) p $1
(NSObject *) $1 = 0x600000008000
```
Even though `po` hides the persistent result variable, it's still created - as $1 in
this example. It can be accessed even though its existence is not evident.
With this change, the persistent result is removed after the object description has
printed. Instead, this is the behavior:
```
(lldb) p thing
(NSObject *) $0 = 0x600000008000
(lldb) po thing
<NSObject: 0x600000008000>
(lldb) p thing
(NSObject *) $1 = 0x600000008000
```
The difference here is that the `po` doens't silently create a persistent result.
Differential Revision: https://reviews.llvm.org/D144044
GCC emits macro definitions into debug info when compiling with `-g3`. LLDB is
translating this information into `#define` directives which are injected into
the source code of user expressions. While this mechanism itself works fine,
it can lead to spurious "... macro redefined" warnings when the defined macro
is also a builtin Clang macro:
```
warning: <lldb wrapper prefix>:46:9: '__VERSION__' macro redefined
^
<built-in>:19:9: previous definition is here
[repeated about a 100 more times for every builtin macro]
```
This patch just disables the diagnostic when parsing LLDB's generated list of
macros definitions.
Reviewed By: Michael137
Differential Revision: https://reviews.llvm.org/D139740
This reverts commit 19128792e2.
As pointed out in https://reviews.llvm.org/D143652 this implementation
doesn't quite work for subobject constructors/destructors because DWARF
can map multiple definitions of a ctor/dtor to the same specification DIE.
With the current implementation we would pick the first definition we
find and use that linkage name which means we can sometimes pick the
wrong dtor/ctor and fail to execute a valid expression.
Differential Revision: https://reviews.llvm.org/D143652
This relands a patch previously reverted
in `181d6e24ca3c09bfd6ec7c3b20affde3e5ea9b40`.
This wasn't quite working on Linux because we
weren't populating the manual DWARF index with
`DW_TAG_imported_declaration`. The relanded patch
does this.
**Summary**
This patch makes the expression evaluator understand
namespace aliases.
This will become important once `std::ranges` become
more widespread since `std::views` is defined as:
```
namespace std {
namespace ranges::views {}
namespace views = ranges::views;
}
```
**Testing**
* Added API test
Differential Revision: https://reviews.llvm.org/D143398
YAML specification does not allow keys duplication an a mapping. However, YAML
parser in LLVM does not have any check on that and uses only the last key entry.
In this change duplicated keys are merged to satisfy the spec.
Differential Revision: https://reviews.llvm.org/D143727
This is a follow up to https://reviews.llvm.org/D141629
and applies the change it made to all paths through ToAddress
(now DoToAddress).
I have included the test from my previous attempt
https://reviews.llvm.org/D136938.
The initial change only applied fixing to addresses that
would parse as integers, so my test case failed. Since
ToAddress has multiple exit points, I've wrapped it into
a new method DoToAddress.
Now you can call ToAddress, it will call DoToAddress and
no matter what path you take, the address will be fixed.
For the memory tagging commands we actually want the full
address (to work out mismatches). So I added ToRawAddress
for that.
I have tested this on a QEMU AArch64 Linux system with
Memory Tagging, Pointer Authentication and Top Byte Ignore
enabled. By running the new test and all other tests in
API/linux/aarch64.
Some commands have had calls to the ABI plugin removed
as ToAddress now does this for them.
The "memory region" command still needs to use the ABI plugin
to detect the end of memory when there are non-address bits.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D142715
This relands the commit previously reverted in
`d2cc2c5610ffa78736aa99512bc85a85417efb0a` due to failures on Linux
when debugging split-debug-info enabled executables.
The problem was we called `SymbolFileDWARF::FindFunctions` directly
instead of `Module::FindFunctions` which resulted in a nullptr
dereference because the backing `SymbolFileDWARFDwo` didn't have
an index attached to it. The relanded version calls `Module::FindFunctions`
instead.
Differential Revision: https://reviews.llvm.org/D143652
In situations where only LLDB is ASANified, a false positive occurs
unless ASAN_OPTIONS=detect_container_overflow=0 is set in the
environment.
Differential Revision: https://reviews.llvm.org/D143772
This is a preparatory patch to add an SB API to get the progress data as
SBStructuredData. The advantage of using SBStructuredData is that the
dictionary can grow over time with more fields.
This approach is identical to the way this is implemented for diagnostic
events.
Differential revision: https://reviews.llvm.org/D143687
