It's possible for debugserver to attach to a process during the handoff
between /usr/lib/dyld and the dyld in the shared cache. When that
happens, we may end up in a state where there is no dyld in the process
and our debugging session is doomed. To make that scenario a lot less
likely, we can insert a sleep right before attaching after waiting to
find the right pid.
rdar://105513180
Differential Revision: https://reviews.llvm.org/D144311
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.
Leaving bits uncleared set causes callbacks to be triggered even
though there are no events to process. Starting with D131160
we have a callback that makes blocking read calls over pipe which
was causing the lldb-server main loop to become unresponsive / blocked
on Android.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D144240
I recently came across a binary that for some reason had overlapping
sections. When debugging it, LLDB was able to get information about one
of the sections but not the other because SectionLoadList assumes that
each address maps to exactly one section. We have the capability to warn
about this, but it was not turned on.
rdar://105751700
Differential Revision: https://reviews.llvm.org/D144528
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.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D138618
Note that those functions on the left hand side are soft-deprecated in
favor of those on the right hand side:
getMinSignedBits -> getSignificantBits
getNullValue -> getZero
isNullValue -> isZero
isOneValue -> isOne
This reverts commit 37eb9d13f891f7656f811516e765b929b169afe0.
Test failures have been fixed:
- ubsan failure fixed by 72eac42f21c0f45a27f3eaaff9364cbb5189b9e4
- warn-unsafe-buffer-usage-fixits-local-var-span.cpp fixed by
03cc52dfd1dbb4a59b479da55e87838fb93d2067 (wasn't related)
- test-output-format.ll failure was spurious, build failed at
https://lab.llvm.org/buildbot/#/builders/54/builds/3545 (b4431b2d945b6fc19b1a55ac6ce969a8e06e1e93)
but passed at
https://lab.llvm.org/buildbot/#/builders/54/builds/3546 (5ae99be0377248c74346096dc475af254a3fc799)
which is before my revert
b4431b2d94...5ae99be037
Original commit message:
Depends on https://reviews.llvm.org/D142861.
Alternative to https://reviews.llvm.org/D137601.
xxHash is much faster than djbHash. This makes a simple Rust test case with a large constant string 10% faster to compile.
Previous attempts at changing this hash function (e.g. https://reviews.llvm.org/D97396) had to be reverted due to breaking tests that depended on iteration order.
No additional tests fail with this patch compared to `main` when running `check-all` with `-DLLVM_ENABLE_PROJECTS="all"` (on a Linux host), so I hope I found everything that needs to be changed.
Differential Revision: https://reviews.llvm.org/D142862
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 (f71a8399997bfdc1ddeeb30c6a8897554a11c382)
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 be7d7ca1101840fc8e19e0e48f9dc395da569d23.
This commit was made to fix be7d7ca1101840fc8e19e0e48f9dc395da569d23
which got reverted in 620b3d9ba3343d7bc5bab2340174a20952fcd00f. 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 19128792e2aa320c1a149f7f93638cbd7f3c83c6.
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
