Recently we've observed lldb crashes caused by missing object file linked to a thin archive (.a) files. The crash is due to a missing NULL check in the code when looking for child object file referred by the thin archive. Malformed archive file should not crash LLDB. Instead, it should report the error and continue.
New error message will look like the following
```
error: libfoo.a(__objects__/foo/barAppDelegate.mm.o) failed to load objfile for path/to/libfoo.a.
Debugging will be degraded for this module.
```
Test Plan:
llvm-lit test
```
./bin/llvm-lit -sv ../llvm-project/lldb/test/API/functionalities/archives/TestBSDArchives.py
```
Test without code change will error out with LLDB crash
```
--
Command Output (stderr):
--
PASS: LLDB (~/llvm-upstream/Debug/bin/clang-arm64) :: test (TestBSDArchives.BSDArchivesTestCase)
PASS: LLDB (~/llvm-upstream/Debug/bin/clang-arm64) :: test_frame_var_errors_when_archive_missing (TestBSDArchives.BSDArchivesTestCase)
FAIL: LLDB (~/llvm-upstream/Debug/bin/clang-arm64) :: test_frame_var_errors_when_mtime_mistmatch_for_object_in_archive (TestBSDArchives.BSDArchivesTestCase)
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. HandleCommand(command = "b a")
1. HandleCommand(command = "breakpoint set --name 'a'")
Fatal Python error: Segmentation fault
Current thread 0x00000001f7b99e00 (most recent call first):
File "~/llvm-upstream/Debug/bin/LLDB.framework/Resources/Python/lldb/__init__.py", line 3270 in HandleCommand
File "~/llvm-upstream/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2070 in runCmd
File "~/llvm-upstream/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2421 in expect
File "~/llvm-upstream/llvm-project/lldb/test/API/functionalities/archives/TestBSDArchives.py", line 156 in test_frame_var_errors_when_thin_archive_malformed
...
```
Differential Revision: https://reviews.llvm.org/D156367
This patch fixes a 32bit integer overflow in lldb-vscode.
The current implementation of frame_id does `(thread_index << 19 | frame_index)`. Since thread_index is a 32 bit integer this leaves only 32 - 19 == 13 bits available for the thread_index. As a result, lldb-vscode can only handle 2^13 == 8192 threads. Normally, this would be sufficient, but we have seen crazy process having +12000 threads, causing the frame_id algorithm above to integer overflow during casting.
The patch fixes the overflow by up casting to 64 bit integer first before bit shifiting.
Differential Revision: https://reviews.llvm.org/D156375
When we build the Clang module compilation command (e.g., when
a user requests import of a module via `expression @import Foundation`),
LLDB will try to determine which SDK directory to use as the `sysroot`.
However, it currently does so by simply enumerating the `SDKs` directory
and picking the last one that's appropriate for module compilation
(see `PlatformDarwin::GetSDKDirectoryForModules`). That means if we have
multiple platform SDKs installed (e.g., a public and internal one), we
may pick the wrong one by chance.
On Darwin platforms we emit the SDK path that a object
file was compiled against into DWARF (using `DW_AT_LLVM_sysroot`
and `DW_AT_APPLE_sdk`). For Swift debugging, we already parse the SDK
path from debug-info if we can.
This patch mimicks the Swift behaviour for non-Swift languages. I.e.,
if we can get the SDK path from debug-info, do so. Otherwise, fall back
to the old heuristic.
rdar://110407148
Differential Revision: https://reviews.llvm.org/D156020
With D149091, ARM64X binaries are no longer reported as ARM64. This broke
lldb tests as Windows 11 system DLLs are mostly ARM64X binaries and lldb
doesn't know how to handle them. Ideally lldb would understand a bit more
about ARM64X and handle them as AMD64 in x64 processes, but this is
enough to preserve previous behavior and fix tests.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D156268
This changes the TLS regset to not only be dynamic in that it could
exist or not (though it always does) but also of a dynamic size.
If SME is present then the regset is 16 bytes and contains both tpidr
and tpidr2.
Testing is the same as tpidr. Write from assembly, read from lldb and
vice versa since we have no way to predict what its value should be
by just running a program.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154930
The Scalable Matrix Extension (SME) adds a new Scalable Vector mode
called "streaming SVE mode".
In this mode a lot of things change, but my understanding overall
is that this mode assumes you are not going to move data out of
the vector unit very often or read flags.
Based on "E1.3" of "Arm® Architecture Reference Manual Supplement,
The Scalable Matrix Extension (SME), for Armv9-A".
https://developer.arm.com/documentation/ddi0616/latest/
The important details for debug are that this adds another set
of SVE registers. This set is only active when we are in streaming
mode and is read from a new ptrace regset NT_ARM_SSVE.
We are able to read the header of either mode at all times but
only one will be active and contain register data.
For this reason, I have reused the existing SVE state. Streaming
mode is just another mode value attached to that state.
The streaming mode registers do not have different names in the
architecture, so I do not plan to allow users to read or write the
inactive mode's registers. "z0" will always mean "z0" of the active
mode.
Ptrace does allow reading inactive modes, but the data is of little
use. Writing to inactive modes will switch to that mode which would
not be what a debugger user would expect. So lldb will do neither.
Existing SVE tests have been updated to check streaming mode and
mode switches. However, we are limited in what we can check given
that state for the other mode is invalidated on mode switch.
The only way to know what mode you are in for testing purposes would
be to execute a streaming only, or non-streaming only instruction in
the opposite mode. However, the CPU feature smefa64 actually allows
all non-streaming mode instructions in streaming mode.
This is enabled by default in QEMU emulation and rather than mess
about trying to disable it I'm just going to use the pseduo streaming
control register added in a later patch to make these tests more
robust.
A new test has been added to check SIMD read/write from all the modes
as there is a subtlety there that needs noting, though lldb
doesn't have to make extra effort to do so.
If you are in streaming mode and write to v0, when you later exit
streaming mode that value may not be in the non-streaming state.
This can depend on how the core works but is a valid behaviour.
For example, say I am stopped here:
mov x0, v0.d[0]
And I want to update v0 in lldb. "register write v0 ..." should update
the v0 that this instruction is about to see. Not the potential other
copy of v0 in the non-streaming state (which is what I attempted in
earlier versions of this patch).
Not to mention, switching out of streaming mode here would be unexpected
and difficult to signal to the user.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154926
Increase the default timeouts when running under ASan. We had something
similar before we adopted tablegen, but the larger timeouts got lost in
the transition, possibly because tablegen's preprocessor support is very
limited. This patch passes a new define (LLDB_SANITIZED) to
lldb-tablegen on which we can base the default value.
Differential revision: https://reviews.llvm.org/D156279
As of 0beffb854209a41f31beb18f9631258349a99299 there is a CMake
function to actually calculate the relative path to the clang resource
directory. Currently we have some bespoke logic that looks in a few
places, but with this new function we should be able to eliminate some
complexity here.
Also, I moved the functionality from LLDBConfig to LLDBStandalone since
it is only used in standalone builds.
Differential Revision: https://reviews.llvm.org/D156270
When the process is contiuned using an lldb command expression the thread state in VS Code is never informed and will be out of sync with the current state of the process. The new event will fire whenever the process is continued and keeps the debugger in sync with the dap client.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D154989
This is an enhancement for the locate module callback.
https://discourse.llvm.org/t/rfc-python-callback-for-target-get-module/71580/6
On Android remote platform, module UUID is resolved by
Platform::GetRemoteSharedModule. Which means the current
Target::CallLocateModuleCallbackIfSet() call undesirably is not able to pass the
module UUID to the locate module callback.
This diff moves the CallLocateModuleCallbackIfSet() implementation from Target
to Platform to allows both Target and Platform can call it. One is from the
current Target call site, and second is from Platform after resolving the module
UUID.
As the result of this change, the locate module callback may be called twice
for a same module on remote platforms. And it should be ok.
- First, without UUID.
- The locate module callback is allowed to return an error
if the callback requires UUID.
- Second, with UUID, if the first callback call did not return a module.
Differential Revision: https://reviews.llvm.org/D156066
Since 5d66f9fd8e97c05a5dba317d3ad2566e61ead1ff this test has
been upassing on Linaro's Windows on Arm lldb bot:
https://lab.llvm.org/buildbot/#/builders/219/builds/4320
I can't explain exactly how that happened, but I do see a bunch
of QEnvironment packets going by in that test. It is very likely
that the order would have been different on Windows.
Indeed, when it was xfailed back in df9051e7cfda5519f4584cda22e9ef2006517e94
the reason was not known either.
Similar to ae316ac66ffff430997e342772fc4629c1acece0 for
QEMU_(UN)SET_ENV.
The iteration order of StringMap is not guaranteed to be deterministic.
Sort the entries to give deterministic packets for the tests added by
D108018.
This patch adds the ability to pass native types from the script
interpreter to methods that use a {SB,}StructuredData argument.
To do so, this patch changes the `ScriptedObject` struture that holds
the pointer to the script object as well as the originating script
interpreter language. It also exposes that to the SB API via a new class
called `SBScriptObject`.
This structure allows the debugger to parse the script object and
convert it to a StructuredData object. If the type is not compatible
with the StructuredData types, we will store its pointer in a
`StructuredData::Generic` object.
This patch also adds some SWIG typemaps that checks the input argument to
ensure it's either an SBStructuredData object, in which case it just
passes it throught, or a python object that is NOT another SB type, to
provide some guardrails for the user.
rdar://111467140
Differential Revision: https://reviews.llvm.org/D155161
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This rewrites DW_OP_addrx inside DWARFExpression as an DW_OP_addr so
that we can update addresses that are originally located in the
debug_addr section.
The full discussion behind this can be found in
https://discourse.llvm.org/t/dwarfexpression-and-dw-op-addrx/71627/12, but a
summary follows.
When SymbolFileDWARF::ParseVariableDIE creates DWARFExpressions for
variables whose location is an OP_addr, it knows how to remap
addresses appropriately in the DebugMap case. It then calls
DWARFExpression::Update_DW_OP_addr, which updates the value associated
with OP_addr.
However, when we have an OP_addrx, the update function does
nothing. This makes sense, as the DWARFExpression does not have a
mutable view of the debug_addr section. In non-DebugMap flows this is
not an issue, as the debug_addr contains the correct addresses of
variables. In DebugMap flows, this is problematic because the work
done by RelinkOSOAddress is lost. By updating the OP to OP_addr, we
can also update the address as required,
We also explored the alternative of relinking the debug_addr section
when we are initializing OSOs (InitOSO). However, this creates an
inconsistent story for users of
DWARFExpression::GetLocation_DW_OP_addr. This function returns an
address without telling callers whether that address came from an
OP_addr or an OP_addrx. If we preemptively relink OP_addrx results
without doing the same for OP_addr results, then callers can’t know
whether the address they got was an executable address or an object
file address. In other words, they can’t know whether they need to
call LinkOSOFileAddress on those results or not.
This patch addresses the majority of test failures when enabling DWARF
5 for MachO (over 200 test failures).
Differential Revision: https://reviews.llvm.org/D155198
/data/llvm-project/lldb/source/Plugins/Process/Utility/RegisterInfos_x86_64_with_base_shared.cpp:319:1: error: non-void function does
not return a value in all control paths [-Werror,-Wreturn-type]
}
^
1 error generated.
Classes implemented in Swift can be exposed to ObjC. For those classes, the ObjC
metadata is incomplete. Specifically, the encoded types of the ivars are incomplete. As
one might expect, the Swift metadata _is_ complete. In such cases, the Swift runtime
should be consulted when determining the dynamic type of a value.
Differential Revision: https://reviews.llvm.org/D152837
Summary:
[lldb][x86_64] This patch adds fs_base/gs_base support for Linux x86_64.
Originally, I plan to split the diff into two parts, one to refactoring lldb_xxx_x86_64 => x86_64::lldb_xxx across code base and the other one for adding fs_base/gs_base, but it turns out to be a non-trivial effort to split and very error prone so I decided to keep a single diff to get feedback.
GDB supports fs_base/gs_base registers while LLDB does not. Since both linux coredump note section and ptrace
supports them it is a missing feature.
For context, this is a required feature to support getting pthread pointer on linux from both live and dump debugging.
See thread below for details:
https://discourse.llvm.org/t/how-to-get-pthread-pointer-from-lldb/70542/2?u=jeffreytan81
Implementation wise, we have initially tried `#ifdef` approach to reuse the code but it is introducing very tricky bugs and proves
hard to maintain. Instead the diff completely separates the registers between x86_64 and x86_64_with_base so that non-linux related
implementations can use x86_64 registers while linux uses x86_64_with_base.
Here are the list of changes done in the patch:
* Registers in lldb-x86-register-enums.h are separated into two: x86_64 and x86_64_with_base
* fs_base/gs_base are added into x86_64_with_base
* All linux files are change to use x86_64::lldb_xxx => x86_64_with_base::lldb_xxx
* Support linux elf-core:
* A new RegisterContextLinuxCore_x86_64 class is added for ThreadElfCore
* RegisterContextLinuxCore_x86_64 overrides and uses its own register set supports fs_base/gs_base
* RegisterInfos_x86_64_with_base/RegisterInfos_x86_64_with_base_shared ared added to provide g_contained_XXX/g_invalidate_XXX and RegInfo related code sharing.
* `RegisterContextPOSIX_x86 ::m_gpr_x86_64` seems to be unused so I removed it.
* `NativeRegisterContextDBReg_x86::GetDR()` is overridden in `NativeRegisterContextLinux_x86_64` to make watchpoint work.
Reviewers:clayborg,labath,jingham,jdoerfert,JDevlieghere,kusmour,GeorgeHuyubo
Subscribers:
Tasks:
Tags:
Differential Revision: https://reviews.llvm.org/D155256
Reading through the Watchpoint class, I found this method
that wasn't being used properly, and a couple of ivars that
weren't used at all. Cleanup.
Differential Revision: https://reviews.llvm.org/D155768
Currently frame var --regex sometimes searches globals, sometimes it doesn't.
This happens because `StackFrame::GetVariableList` always returns the biggest
list it has, regardless of whether only globals were requested or not. In other
words, if a previous call to `GetVariableList` requested globals, all subsequent
calls will see them.
The implication here is that users of `StackFrame::GetVariableList` are expected
to filter the results of this function. This is what we do for a vanilla
`frame var` command. But it is not what we do when `--regex` is used. This
commit solves the issue by:
1. Making `--regex` imply `--globals`. This matches the behavior of `frame var
<some_name>`, which will also search the global scope.
2. Making the `--regex` search respect the command object options.
See the added test for an example of the oddities this patch addresses. Without
the patch, the test fails. However it could be made to pass by calling a plain
`frame var` before calling `frame var --regex A::`.
Differential Revision: https://reviews.llvm.org/D155334
This adds a new flag and lldb runtime command to allow users to manage the behavior of the lldb-vscode evaluate repl request.
When evaluating a repl context this now has runtime managed flag for control how the repl behaviors with the follow values:
* `variable` - the existing behavior, with this mode requests are evaluted in the current frame context as variable expressions. To trigger a lldb command prefix an expression with ` and it will be evaluted as an lldb command.
* `command` - all expressions are evaluated as lldb commands.
* `auto` - An alternative mode that will attempt to determine if the expression is an lldb command or a variable expression. Based off the intepreted results the expression will be evaluted either as a command or an expression.
Additionally, I enabled completions and ensured they work with the new repl expression behavior to provide auto-completes.
This commit includes updates to the tests to verify the new behavior after the previous failures from submitting https://reviews.llvm.org/D154030.
Differential Revision: https://reviews.llvm.org/D155248
On a subsequent commit, I intend to update the expression and call the evaluate
function more times. This refactors enables reusing some of the existing code
for that.
Differential Revision: https://reviews.llvm.org/D155197
It was implicitly assumning that "/" would have no files in it, only
directories. That's not true, for instance on macOS if you've navigated
to the root directory in the Finder...
Since we're assuming everything we check against is a directory, then we
need to filter the completion for that coming in.
"sme" is just one of many cpuinfo features for SME but it's the
only one we need for testing.
The rest are related to the use of certain instructions and
don't change the register state available.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154823
This test runs to a breakpoint on thread 0. Thread 0 then starts
thread 2 and 3, which both have breakpoints in them.
In https://lab.llvm.org/buildbot/#/builders/96/builds/41674
I think that we managed to do the first check on thread 2 before
thread 3 had started. Therefore "thread continue 3" failed.
So wait for all three to startup before we check their status.
I considered putting a timeout on the while like the wait_for... methods,
but the test itself already has a global timeout. Plus, I'd rather
not be tuning a timeout per piece of hardware this runs on.
99% of the time we will already have 3 threads when the check is done.
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D154705
This reverts commit 668a3efd42e7fea19a0d331f73345f2ac13cdf4f.
Reverting because of build errors:
In file included from /Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/source/API/SBPlatform.cpp:19:
/Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/include/lldb/Target/Target.h:1035:18: warning: parameter 'merged' not found in the function declaration [-Wdocumentation]
This reverts commit df054499c35cdda02b196b2ca5c0a326abdc0a29.
Reverting because of build errors
In file included from /Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/source/API/SBPlatform.cpp:19:
/Users/buildslave/jenkins/workspace/as-lldb-cmake/llvm-project/lldb/include/lldb/Target/Target.h:1035:18: warning: parameter 'merged' not found in the function declaration [-Wdocumentation]
This reverts commit 7f1028e9df52b4e7246f189a24684b1ca8c9bfbe.
This is because test failures
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModule
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModuleAndBreakpadSymbol
This reverts commit fb087c17c82309404fe0ebf3505c186642a719f7.
This is because of test failures:
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModule
lldb-unit.Target/_/TargetTests/LocateModuleCallbackTest.GetOrCreateModuleWithCachedModuleAndBreakpadSymbol
Add support for compressed CTF data. The flags in the header can
indicate whether the CTF body is compressed with zlib deflate. This
patch supports inflating the data before parsing.
Differential revision: https://reviews.llvm.org/D155221
In preparation for removing the #include "llvm/ADT/StringExtras.h"
from the header to source file of llvm/Support/Error.h, first add in
all the missing includes that were previously included transitively
through this header.
This is fixing all files missed in b0abd4893fa1, 39d8e6e22cd1,
a11efd49266f, 5551657b310b, and 90bfe2df25e7.
Differential Revision: https://reviews.llvm.org/D155178
Add support for the Compact C Type Format (CTF) in LLDB. The format
describes the layout and sizes of C types. It is most commonly consumed
by dtrace.
We generate CTF for the XNU kernel and want to be able to use this in
LLDB to debug kernels for which we don't have dSYMs (anymore). CTF is a
much more limited debug format than DWARF which allows is to be an order
of magnitude smaller: a 1GB dSYM can be converted to a handful of
megabytes of CTF. For XNU, the goal is not to replace DWARF, but rather
to have CTF serve as a "better than nothing" debug info format when
DWARF is not available.
It's worth noting that the LLVM toolchain does not support emitting CTF.
XNU uses ctfconvert to generate CTF from DWARF which is used for
testing.
Differential revision: https://reviews.llvm.org/D154862
