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
Rename `SetResultIsInternal` and `GetResultIsInternal` to `SetSuppressPersistentResult`
and `GetSuppressPersistentResult` respectively. Also rename `m_result_is_internal`.
This matches the naming in the SB API.
A separate change calls `SetSuppressPersistentResult`, where the name
`SetResultIsInternal` doesn't quite fit.
Differential Revision: https://reviews.llvm.org/D144042
Given the line
```
launch_info = lldb.SBLaunchInfo(None)
```
We see different behaviors across different versionf of swig. On some
older versions of swig (e.g. 3.0.2) this line fails because it attempts
to use the copy constructor and blows up with an invalid null reference.
On newer versions of swig, this is correctly routed to the constructor
taking a pointer.
Prior to generating the swig bindings with the API headers,
SBLaunchInfo's copy constructor was not exposed so we're effectively
going back to the old behavior anyway.
Differential Revision: https://reviews.llvm.org/D144228
/data/llvm-project/lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp:398:34: error: variable 'lang_rt' set but not used [-Werror,-Wunused-but-set-variable]
lldb_private::LanguageRuntime *lang_rt = nullptr;
^
1 error generated.
This came out of from https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902
With big binaries we can have .dwp files where .debug_info.dwo section can grow
beyond 4GB. We would like to support this in LLVM and in LLDB.
The plan is to enable manual parsing of cu/tu index in DWARF library
(https://reviews.llvm.org/D137882), and then
switch internal index data structure to 64 bit.
For the second part is to enable 64bit offset support in LLDB with
this patch.
Depends on D139955
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D138618
Instead of maintaining separate swig interface files, we can use the API
headers directly. They implement the exact same C++ APIs and we can
conditionally include the python extensions as needed. To remove the
swig extensions from the API headers when building the LLDB
framework, we can use the unifdef tool when it is available. Otherwise
we just copy them as-is.
Differential Revision: https://reviews.llvm.org/D142926
Prior to setting up logging, we have uses of RNBLogSTDERR and
RNBLogSTDOUT. These macros will dump to STDERR and STDOUT respectively
if debugserver has a tty. Otherwise, it uses _DNBLog, which will do
nothing if a logging function hasn't been set up. For example, if you
specify a log file that cannot be opened for any reason and you don't
have a tty, you have 0 insight into what happened.
rdar://105473133
Differential Revision: https://reviews.llvm.org/D144142
The Python script interpreter imports `pydoc` during initialization, but this can be
slow in some cases, and doesn't seem to be necessary any more.
This can be slow because pydoc may execute shell commands (for example `xcrun` on
macOS). The shell commands may have variable performance, depending on their caches and
search space.
The 2012 bug report for the original commit (f71a839999)
says the following:
> "script help" in lldb pipes the help documentation through less(1) but there's some
> problem with the key handling and often the keys you'd use to move in less (space to
> move down a page, 'q' to quit) are not received by less (they're going to lldb
> instead)
This was resolved at the time by overriding `pydoc`'s pager to be the `plainpager`
function.
I have manually tested `script help(lldb.SBDebugger)` and found no issues with the
pager, including using "space" for paging, "/" for searching, and "q" for quitting.
The presumption is that lldb and/or Python have improved I/O handling that eliminates
the original problem.
The original bug report gave an ~/.lldbinit workaround:
```
script import pydoc; pydoc.pager = pydoc.plainpager
```
Note that calling Python's `help()` will import `pydoc`, but this will only happen for
users who use `help()` from the `script` command.
Differential Revision: https://reviews.llvm.org/D144138
This patch adds several missing GlobalList modifier functions, like
removeGlobalVariable(), eraseGlobalVariable() and insertGlobalVariable().
There is no longer need to access the list directly so it also makes
getGlobalList() private.
Differential Revision: https://reviews.llvm.org/D144027
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
lldb was originally designed to get the watchpoint exception behavior
from the gdb remote serial protocol stub -- exceptions are either
received before the instruction executes, or after the instruction
has executed. This behavior was reported via two lldb extensions
to gdb RSP, so generic remote stubs like gdbserver or a JTAG stub,
would not tell lldb which behavior was correct, and it would default
to "exceptions are received after the instruction has executed".
Two architectures hard coded their correct "exceptions before
instruction" behavior, to work around this issue.
Most architectures have a fixed behavior of watchpoint exceptions,
and we can center that information in lldb. We can allow a remote
stub to override the default behavior via our packet extensions
if it's needed on a specific target.
This patch also separates the fetching of the number of watchpoints
from whether exceptions are before/after the insn. Currently if
lldb couldn't fetch the number of watchpoints (not really needed), it
also wouldn't get when exceptions are received, and watchpoint
handling would fail. lldb doesn't actually use the number of
watchpoints for anything beyond printing it to the user.
Differential Revision: https://reviews.llvm.org/D143215
rdar://101426626
This patch adds several missing AliasList modifier functions, like
removeAlias(), eraseAlias() and insertAlias().
There is no longer need to access the list directly so it also makes
getAliaList() private.
Differential Revision: https://reviews.llvm.org/D143958
This reverts commit be7d7ca110.
This commit was made to fix be7d7ca110
which got reverted in 620b3d9ba3. We need
to revert this commit as well because types in log statements are 32 bit again.
In https://reviews.llvm.org/D122373 I delayed the search for
the SDK filepath until the simulator platform is Created.
In the qProcessInfo binary-addresses key, I have to force-Create
every platform to find one that can handle a kernel fileset;
this forced all of the simulator platforms to create, taking the
SDK filepath discovery perf hit.
This patch delays that path search further until the Apple
Simulator platform calls a method that actually needs the full
filepath; it saves the SDK name ("WatchSimulator.sdk" etc) until
it needs to expand it.
Differential Revision: https://reviews.llvm.org/D143932
rdar://103380717
This came out of from https://discourse.llvm.org/t/dwarf-dwp-4gb-limit/63902
With big binaries we can have .dwp files where .debug_info.dwo section can grow
beyond 4GB. We would like to support this in LLVM and in LLDB.
The plan is to enable manual parsing of cu/tu index in DWARF library
(https://reviews.llvm.org/D137882), and then
switch internal index data structure to 64 bit.
For the second part is to enable 64bit offset support in LLDB with
this patch.
Depends on D139955
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D138618
lldb may crash when performing `image lookup --verbose --address $ADDR`.
The ExecutionContext that gets passed into DWARFExpression::Evaluate may
be valid but unpopulated. However, in one specific case, we were
assuming that it has a valid Target and using it without checking first.
We reach this codepath when we attempt to get information about an
address that doesn't map to a CompileUnit in the module containing the
requested address. lldb then checks to see if it maps to a global
variable, so lldb has to evaluate the location of each global variable
in the module. If a location expression contains DW_OP_deref_size that
uses a FileAddress, we hit this code path. The simplest test case is to
take a module that has a global variable with DW_OP_deref_size in its
location expression, attempt to read an address that doesn't map to a
CompileUnit (e.g. 0x0) and ensure we don't crash.
Differential Revision: https://reviews.llvm.org/D143792
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
Consider the following example as motivation. Say you have to load
symbols for 3 dynamic libraries: `libFoo`, `libBar` and `libBaz`.
Currently, there are two ways to report process for this operation:
1. As 3 separate progress instances. In this case you create a progress
instance with the message "Loading symbols: libFoo", "Loading
symbols: libBar", and "Loading symbols: libBaz" respectively. Each
progress event gets a unique ID and therefore cannot be correlated
by the consumer.
2. As 1 progress instance with 3 units of work. The title would be
"Loading symbols" and you call Progress::Increment for each of the
libraries. The 3 progress events share the same ID and can easily be
correlated, however, in the current design, there's no way to
include the name of the libraries.
The second approach is preferred when the amount of work is known in
advance, because determinate progress can be reported (i.e. x out of y
operations completed). An additional benefit is that the progress
consumer can decide to ignore certain progress updates by their ID if
they are deemed to noisy, which isn't trivial for the first approach due
to the use of different progress IDs.
This patch adds the ability to add a message (detail) to a progress
event update. For the example described above, progress can now be
displayed as shown:
[1/3] Loading symbols: libFoo
[2/3] Loading symbols: libBar
[3/3] Loading symbols: libBaz
Differential revision: https://reviews.llvm.org/D143690
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
**Summary**
This patch addresses the case where we have a `DW_AT_external`
subprogram for a constructor (and/or destructor) that doesn't carry
a `DW_AT_linkage_name` attribute. The corresponding DIE(s) that
represent the definition will have a linkage name, but if the name
contains constructs that LLDBs fallback mechanism for guessing mangled
names to resolve external symbols doesn't support (e.g., abi-tags)
then we end up failing to resolve the function call.
We address this by trying to find the linkage name before we create
the constructor/destructor decl, which will get attached using
an `AsmLabelAttr` to make symbol resolution easier.
**Testing**
* Added API test
Differential Revision: https://reviews.llvm.org/D143652
