These don't need to be ConstStrings. They don't really benefit much from
deduplication and comparing them isn't on a hot path, so they don't
really benefit much from quick comparisons.
Differential Revision: https://reviews.llvm.org/D152331
Most users of this stick it into a StringRef. The one user that doesn't
just tries to get the length out of it, which we can precompute by
putting it in a constexpr StringLiteral.
Differential Revision: https://reviews.llvm.org/D151951
Currently the expression parser prints a mostly useless generic error before printing the compiler error:
(lldb) p 1+x)
error: expression failed to parse:
error: <user expression 18>:1:3: use of undeclared identifier 'x'
1+x)
^
This is distracting and as far as I can tell only exists to work
around the fact that the first "error: " is unconditionally injected
by CommandReturnObject. The solution is not very elegant, but the
result looks much better.
(Partially addresses rdar://110492710)
Differential Revision: https://reviews.llvm.org/D152590
In the interest of keeping the ConstString StringPool small, this patch
aims to remove the use of ConstString from OptionValueProperties.
We can maintain quick lookups by using an llvm::StringMap to find the
correct index by name.
Differential Revision: https://reviews.llvm.org/D152210
This patch should allow the user to set specific auto-completion type
for their custom commands.
To do so, we had to hoist the `CompletionType` enum so the user can
access it and add a new completion type flag to the CommandScriptAdd
Command Object.
So now, the user can specify which completion type will be used with
their custom command, when they register it.
This also makes the `crashlog` custom commands use disk-file completion
type, to browse through the user file system and load the report.
Differential Revision: https://reviews.llvm.org/D152011
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
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>
Fix a mutation of `CommandAlias::m_option_args_sp`, which resulted in cases where
aliases would fail to run on second, and subsequent times.
For example, an alias such as:
```
command alias p1 p 1
```
When run the second time, the following error would be reported to the user:
```
error: expression failed to parse:
error: <user expression 1>:1:1: expression is not assignable
-- 1
^ ~
```
To fix this, `CommandAlias::Desugar` now constructs options to a freshly constructed
vector, rather than by appending to the results of `GetOptionArguments`.
rdar://107770836
Differential Revision: https://reviews.llvm.org/D150078
Use templates to simplify {Get,Set}PropertyAtIndex. It has always
bothered me how cumbersome those calls are when adding new properties.
After this patch, SetPropertyAtIndex infers the type from its arguments
and GetPropertyAtIndex required a single template argument for the
return value. As an added benefit, this enables us to remove a bunch of
wrappers from UserSettingsController and OptionValueProperties.
Differential revision: https://reviews.llvm.org/D149774
The majority of call sites are nullptr as the execution context.
Refactor OptionValueProperties to make the argument optional and
simplify all the callers.
Various OptionValue related classes are passing around will_modify but
the value is never used. This patch simplifies the interfaces by
removing the redundant argument.
Similar to fdbe7c7faa54, refactor OptionValueProperties to return a
std::optional instead of taking a fail value. This allows the caller to
handle situations where there's no value, instead of being unable to
distinguish between the absence of a value and the value happening the
match the fail value. When a fail value is required,
std::optional::value_or() provides the same functionality.
Refactor OptionValue to return a std::optional instead of taking a fail
value. This allows the caller to handle situations where there's no
value, instead of being unable to distinguish between the absence of a
value and the value happening the match the fail value. When a fail
value is required, std::optional::value_or() provides the same
functionality.
llvm has a structure for maps where the key's type is a string. Using
that also means that the keys for OptionValueDictionary don't stick
around forever in ConstString's StringPool (even after they are gone).
The only thing we lose here is ordering: iterating over the map where the keys
are ConstStrings guarantees that we iterate in alphabetical order.
StringMap makes no guarantees about the ordering when you iterate over
the entire map.
Differential Revision: https://reviews.llvm.org/D149482
Add a new setting (debugger.external-editor) to specify an external
editor. The setting takes precedence over the existing
LLDB_EXTERNAL_EDITOR environment variable.
Differential revision: https://reviews.llvm.org/D149565
This patch refactors the macOS implementation of
OpenFileInExternalEditor. It fixes an AppleEvent memory leak, the
caching of LLDB_EXTERNAL_EDITOR and speculatively fixes a crash when
CFURL is NULL (rdar://108633464). The new code also improves error
handling, readability and documents calls to the CoreFoundation Launch
Services APIs.
A bunch of the Launch Services APIs have been deprecated
(LSFindApplicationForInfo, LSOpenURLsWithRole). The preferred API is
LSOpenCFURLRef but it doesn't specifying the "location" Apple Event
which is used to highlight the current line and switching over would
regress the existing behavior.
rdar://108633464
Differential revision: https://reviews.llvm.org/D149482
Some LLDB set ups need to hide certain commands for security reasons, so I'm adding a flag that allows removing non-user commands.
Differential Revision: https://reviews.llvm.org/D149312
This is useful in contexts where you have multiple languages in play:
You may be stopped in a frame for language A, but want to set a watchpoint
with an expression using language B. The current way to do this is to
use the setting `target.language` while setting the watchpoint and
unset it after the watchpoint is set, but that's kind of clunky and
somewhat error-prone. This should add a better way to do this.
rdar://108202559
Differential Revision: https://reviews.llvm.org/D149111
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>
These probably do not need to be in the ConstString StringPool as they
don't really need any of the advantages that ConstStrings offer.
Lifetime for these things is always static and we never need to perform
comparisons for setting descriptions.
Differential Revision: https://reviews.llvm.org/D148679
Non-plugin lldb libraries should generally not be linking against lldb
plugin libraries. Enforce this in CMake.
Differential Revision: https://reviews.llvm.org/D146553
Fix logic for repeat commands, so that regex commands (specificially `bt`) are
given the opportunity to provide a repeat command.
rdar://104562616
Differential Revision: https://reviews.llvm.org/D143695
Redefine the `p` alias to the `dwim-print` command instead of `expression`.
See https://reviews.llvm.org/D138315 for the introduction of `dwim-print`.
To summarize, `dwim-print` is, as the name suggests, a command for printing. How a value
gets printed, is decided by `dwim-print`. In some cases, `dwim-print` will print values
using the same means as `frame variable` (because it's generally more reliable and
faster that `expression` evaluation), and in other cases `dwim-print` uses the same code
path as `expression`.
This change has been tested in two different ways:
1. Re-aliasing `p` to `dwim-print`, as in this patch
2. Redefinining the `expression` command to `CommandObjectDWIMPrint`
Previously, many of the lldb's tests used `p`, and which meant a test run with `p`
aliases to `dwim-print` was a good way to test `dwim-print`. However most of those tests
were updated to use `expression` explicitly (in anticipation of this change). Now, the
best way to test `dwim-print` is the second approach:
```
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp b/lldb/source/Interpreter/CommandInterpreter.cpp
index 373c894f34f5..9c943cd30c7c 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -539,7 +539,7 @@ void CommandInterpreter::LoadCommandDictionary() {
REGISTER_COMMAND_OBJECT("diagnostics", CommandObjectDiagnostics);
REGISTER_COMMAND_OBJECT("disassemble", CommandObjectDisassemble);
REGISTER_COMMAND_OBJECT("dwim-print", CommandObjectDWIMPrint);
- REGISTER_COMMAND_OBJECT("expression", CommandObjectExpression);
+ REGISTER_COMMAND_OBJECT("expression", CommandObjectDWIMPrint);
REGISTER_COMMAND_OBJECT("frame", CommandObjectMultiwordFrame);
REGISTER_COMMAND_OBJECT("gui", CommandObjectGUI);
REGISTER_COMMAND_OBJECT("help", CommandObjectHelp);
```
When the test suite is run with this change, there are two main categories of test
failures for specific to features that `dwim-print` intentionally doesn't support:
1. Top level expressions (`--top-level`/`-p`)
2. Multiline expressions
In cases where the behavior of `expression` is needed, users can use `expression` at
those times.
Differential Revision: https://reviews.llvm.org/D145189
Currently empty arguments are not respected. They are silently dropped
in two places: (1) when extracting them from the target.run-args
setting and (2) when constructing the lldb-argdumper invocation.
(1) is actually a regression from a few years ago. We did not always
drop empty arguments. See 31d97a5c8ab78c619deada0cdb1fcf64021d25dd.
rdar://106279228
Differential Revision: https://reviews.llvm.org/D145450
Redefine the `p` alias to the `dwim-print` command instead of `expression`.
See https://reviews.llvm.org/D138315 for the introduction of `dwim-print`.
To summarize, `dwim-print` is, as the name suggests, a command for printing. How a value
gets printed, is decided by `dwim-print`. In some cases, `dwim-print` will print values
using the same means as `frame variable` (because it's generally more reliable and
faster that `expression` evaluation), and in other cases `dwim-print` uses the same code
path as `expression`.
This change has been tested in two different ways:
1. Re-aliasing `p` to `dwim-print`, as in this patch
2. Redefinining the `expression` command to `CommandObjectDWIMPrint`
Previously, many of the lldb's tests used `p`, and which meant a test run with `p`
aliases to `dwim-print` was a good way to test `dwim-print`. However most of those tests
were updated to use `expression` explicitly (in anticipation of this change). Now, the
best way to test `dwim-print` is the second approach:
```
diff --git a/lldb/source/Interpreter/CommandInterpreter.cpp b/lldb/source/Interpreter/CommandInterpreter.cpp
index 373c894f34f5..9c943cd30c7c 100644
--- a/lldb/source/Interpreter/CommandInterpreter.cpp
+++ b/lldb/source/Interpreter/CommandInterpreter.cpp
@@ -539,7 +539,7 @@ void CommandInterpreter::LoadCommandDictionary() {
REGISTER_COMMAND_OBJECT("diagnostics", CommandObjectDiagnostics);
REGISTER_COMMAND_OBJECT("disassemble", CommandObjectDisassemble);
REGISTER_COMMAND_OBJECT("dwim-print", CommandObjectDWIMPrint);
- REGISTER_COMMAND_OBJECT("expression", CommandObjectExpression);
+ REGISTER_COMMAND_OBJECT("expression", CommandObjectDWIMPrint);
REGISTER_COMMAND_OBJECT("frame", CommandObjectMultiwordFrame);
REGISTER_COMMAND_OBJECT("gui", CommandObjectGUI);
REGISTER_COMMAND_OBJECT("help", CommandObjectHelp);
```
When the test suite is run with this change, there are two main categories of test
failures for specific to features that `dwim-print` intentionally doesn't support:
1. Top level expressions (`--top-level`/`-p`)
2. Multiline expressions
In cases where the behavior of `expression` is needed, users can use `expression` at
those times.
Differential Revision: https://reviews.llvm.org/D145189
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>
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>
Adopt `expression`'s options in `dwim-print`.
This is primarily added to support the `--language`/`-l` flag.
Differential Revision: https://reviews.llvm.org/D144114
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 patch should address a bug when a user have multiple scripted
processes in the same debugging session.
In order for the scripted process plugin to be able to call into the
scripted object instance methods to fetch the necessary data to
reconstruct its state, the scripted process plugin calls into a
scripted process interface, that has a reference to the created script
object instance.
However, prior to this patch, we only had a single instance of the
scripted process interface, living the script interpreter. So every time
a new scripted process plugin was created, it would overwrite the script
object instance that was held by the single scripted process interface
in the script interpreter.
That would cause all the method calls made to the scripted process
interface to be dispatched by the last instanciated script object
instance, which is wrong.
In order to prevent that, this patch moves the scripted process
interface reference to be help by the scripted process plugin itself.
rdar://104882562
Differential Revision: https://reviews.llvm.org/D143308
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
On systems like ARM, where the non-addressable bits of a pointer
value may be used for metadata (ARMv8.3 pointer authentication, or
Type Byte Ignore), those bits need to be cleared before the address
points to a valid memory location. Add a call to the target's ABI
to clear those from address expression arguments to the lldb
commands (e.g. `disassemble -a`).
Differential Revision: https://reviews.llvm.org/D141629
This patch introduces both the ScriptedPlatformInterface and the
ScriptedPlatformPythonInterface. As the name suggests, these calls will
be used to call into the Scripted Platform python implementation from
the C++ Scripted Platform plugin instance.
Differential Revision: https://reviews.llvm.org/D139251
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch is preparatory work for Scripted Platform support and does
multiple things:
First, it introduces new options for the `platform select` command and
`SBPlatform::Create` API, to hold a reference to the debugger object,
the name of the python script managing the Scripted Platform and a
structured data dictionary that the user can use to pass arbitrary data.
Then, it updates the various `Create` and `GetOrCreate` methods for
the `Platform` and `PlatformList` classes to pass down the new parameter
to the `Platform::CreateInstance` callbacks.
Finally, it updates every callback to reflect these changes.
Differential Revision: https://reviews.llvm.org/D139249
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
