`isRISCV()` check always returns false because we only get here if
`min_op_byte_size` and `max_op_byte_size` are equal, which is not true
for RISC-V.
Also, replase `if (!got_op)` check with an `else`. The check is
equivalent to
`if (min_op_byte_size != max_op_byte_size)`, and the `if` above checks
for the opposite condition.
Since #189401, LLVM and Clang generate `S_DEFRANGE_REGISTER_REL_INDIR`
for indirect locations. This adds support in LLDB.
The offset added after dereferencing is signed here - unlike in
`S_REGREL32_INDIR` (at least that's the assumption). So I updated
`MakeRegisterBasedIndirectLocationExpressionInternal` to handle the
signedness. This is the reason the MSVC test was changed here.
I didn't find a test case where LLVM emits the record with the `VFRAME`
register. Other than that, the clang test is similar to the MSVC one
except that the locations are slightly different.
In the non-ARM case, the offset was left unset, so the symbol
synthesized for the entry point pointed to the start of the containing
section.
As a drive-by change, simplify offset adjustment in ARM case.
The LLVM Coding Standards [1] specify that:
> [T]o match error message styles commonly produced by other tools,
> start the first sentence with a lowercase letter, and finish the last
> sentence without a period, if it would end in one otherwise.
Historically, that hasn't been something we've enforced in LLDB, but in
the past year or so I've started to pay more attention to this in code
reviews. This PR brings more error messages in compliance, further
increasing consistency.
I also adopted `createStringErrorV` where it improved the code as a
drive-by for lines I was already touching.
[1] https://llvm.org/docs/CodingStandards.html#error-and-warning-messages
Assisted-by: Claude Code
Value::ResolveValue() only does something if the value has an associated
compiler type, which is never set on values used in DWARF expressions.
Simplify code by inlining the method.
Some WebAssembly runtimes might use environment variables such as `HOME`
or `XDG_CONFIG_HOME` to store configuration files, additionally some VMs
might allow wasm modules to read environment variables from the host.
Currently, if a runtime is launched using the WebAssembly platform it
doesn't inherit the environment. As a result wasm runtimes and modules
are unable to read from environment variables and might even fail to
launch (if the config file is required). This PR aims to resolve this
issue, I have tested this with the WARDuino runtime and my WIP gdbstub.
Fixes a crash with the following alias, which I use for printing the
contents of pointer variables:
```
command alias vp v -P1
```
At some point in the recent-ish past, parsing this alias has started
crashing lldb. The problem is code that assumes the option and its value
are separate. This assumption causes an index past the end of a vector.
This fix changes `FindArgumentIndexForOption`. The function now returns
a pair of indexes, the first index is the option, the second index is
the index of the value. In the case of joined options like `-P1`, the
two indexes are the same.
This patch does two thing:
- It reverts to the previous behavior of warning for untrusted dSYMs.
- It includes whether a dSYM is trusted or untrusted in the warning
output.
My reasoning is that there's no tooling for automatically signing dSYMs
and therefore we shouldn't change the behavior until this is more
common. The inclusion of whether the dSYM is signed or not is the first
step towards advertising the existence of the feature.
This now also means the release note I added in #189444 is correct
(again).
I had auto-merge enabled in #189444 and since the formatter is
non-blocking it got merged despite the issue. Given I'm already here, I
just formatted the whole file.
LLDB automatically discovers, but doesn't automatically load, scripts in
the dSYM bundle. This is to prevent running untrusted code. Users can
choose to import the script manually or toggle a global setting to
override this policy. This isn't a great user experience: the former
quickly becomes tedious and the latter leads to decreased security.
This PR offers a middle ground that allows LLDB to automatically load
scripts from trusted dSYM bundles. Trusted here means that the bundle
was signed with a certificate trusted by the system. This can be a
locally created certificate (but not an ad-hoc certificate) or a
certificate from a trusted vendor.
* Correctly return the result when used from the console, so that
`DiagnosticsRendering` could use it to output the error.
* Add location pointer to `DILDiagnosticError` internal formatting to
show diagnostics when called from the API.
This patch is motivated by
https://github.com/llvm/llvm-project/pull/189943, where we would like to
print the "these module scripts weren't loaded" warning for *all*
modules batched together. I.e., we want to print the warning *after* all
the script loading attempts, not from within each attempt.
To do so we want to hoist the `ReportWarning` calls in
`Module::LoadScriptingResourceInTarget` out into the callsites. But if
we do that, the callers have to remember to print the warnings. To avoid
this, we redirect all callsites to use
`ModuleList::LoadScriptingResourceInTarget`, which will be responsible
for printing the warnings.
To avoid future accidental uses of
`Module::LoadScriptingResourceInTarget` I moved the API into
`ModuleList` and made it `private`.
A kernel developer noticed that I missed a call to index the local
filesystem in one of our codepaths, and had a use case that depended on
that working.
rdar://173814556
In some environments like swiftlang, the `''` causes the command used to
drain the init sequence of the ConPTY to fail. Replacing with a `cls`
invocation removes the need for quotation marks and works just as well.
Fixes#165413. Where a build failure was reported:
```
/b/s/w/ir/x/w/llvm-llvm-project/lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux_arm64.cpp:1182:9: error: unknown type name 'user_sve_header'; did you mean 'sve::user_sve_header'?
1182 | user_sve_header *header =
| ^~~~~~~~~~~~~~~
| sve::user_sve_header
```
To fix this, add sve:: as we do for all other uses of this.
This is LLDB's copy of a structure that Linux also defines. I think the
build worked on some machines because that version ended up being
included, but with a more isolated build, it may not.
We have our own definition of it so we can be sure what we're using in
case Linux extends it later.
This is the implementation part of #138717, tests and documentation will
be in a separate PR.
SME only systems have SME but not SVE. Previously we assumed that you
would either have SVE, SVE+SME, or neither. On an SME only system, the
SVE register state exists only in streaming mode. SVE instructions may
be used, but only in streaming mode. The Linux kernel will report that
such a processor has SME features but no SVE features.
This means that the non-streaming SVE ptrace register set is
inaccessible (with one exception mentioned below). So the main change
here is around the management of FP registers.
* In non-streaming mode, FP registers must be accessed via the FP
register set. Not the non-streaming SVE register set.
* In streaming mode, FP registers are a subset of the streaming SVE
registers, accessed via the streaming SVE register set.
The one exception the kernel allows is:
> On systems that do not support SVE it is permitted to use SETREGSET to
write SVE_PT_REGS_FPSIMD formatted data via NT_ARM_SVE, in this case the
vector length should be specified as 0. This allows streaming mode to be
disabled on systems with SME but not SVE.
https://docs.kernel.org/arch/arm64/sve.html
This is how we are able to restore to a non-streaming state when an
expression leaves us in streaming mode.
The major changes to LLDB are:
* If we receive only SVG in the expedited registers, we now assume it's
an SME only system and therefore VG == SVG.
* A new state SVEState::StreamingFPSIMD is added to mark the mode where
we are in FPSIMD mode on an SME only system (as opposed to the FPSIMD
state of an SVE or SVE+SME system).
* CalculateFprOffset now returns different results depending on whether
we have only SIMD or we have streaming SVE. In the latter case, the
stored register offsets are relative to the SVE registers, but actual
accesses need to be relative to the ptrace FP register set.
* In WriteAllRegisters, if we have an FP set to restore on an SME only
system we assume we must have been in non-streaming mode at the time of
the save. So we restore it using the previously mentioned non-streaming
SVE write.
* GetSVERegSet and ConfigureRegisterContext were updated to handle the
new StreamingFPSIMDOnly state.
The only difference between them is that OptionalBool's third state
is "unknown" and LazyBool's is "calculate". We don't need to tell
the difference in a single context, so I've made a new eLazyBoolDontKnow
which is an alias of eLazyBoolCalculate.
This patch changes the `Platform::LocateXXX` to return a map from
`FileSpec` to `LoadScriptFromSymFile` enum.
This is needed for https://github.com/llvm/llvm-project/pull/188722,
where I intend to set `LoadScriptFromSymFile` per-module.
By default the `Platform::LocateXXX` set the value to whatever the
target's current `target.load-script-from-symbol-file` is set to. In
https://github.com/llvm/llvm-project/pull/188722 we'll allow overriding
this per-target setting on a per-module basis.
Drive-by:
* Added logging when we fail to load a script.
In preparation for updating DIL to handle assignments, this adds a
member variable to the DIL Interpreter indicating whether or not
updating program variables is allowed. For invocations from the LLDB
command prompt (through "frame variable") we want to allow it, but from
other places we might not. Therefore we also add new StackFrame
ExpressionPathOption, eExpressionPathOptionsAllowVarUpdates, which we
add to calls from CommandObjectFrame, and which is checked in
GetValueForVariableExpressionPath. Finally, we also add a parameter,
can_update_vars, with a default value of true, to
ValueObject::SetValueFromInteger, as that will be the main function used
to by assignment in DIL.
We already log the import attempt. This patch logs the failure to load
the script since otherwise the log may be misleading. Didn't think it
was worth adding a test-case for this.
This plugin creates types based on information from target XML, which is
parsed only once per session. It has internal logic to reuse created
types, but the plugin itself was being remade every time a type was
requested.
When debugging a remote Darwin device (iOS, macOS, etc), lldb needs to
find a local copy of all the system libraries (the system's shared
cache) so we don't need to read them over gdb-remote serial protocol at
the start of every debug session.
Xcode etc normally creates these expanded shared caches in
~/Library/Developer/Xcode/<OS> DeviceSupport/<OS VER> (<OS
BUILD>)/Symbols
So when lldb sees a file like /usr/lib/libSystem.B.dylib, it may find a
copy at in
~/L/D/Xcode/iOS DeviceSupport/26.2
(23B87)/Symbols/usr/lib/libSystem.B.dylib
There may be multiple expanded shared caches in these DeviceSupport
directories, so we try to parse the "os version" and "os build" out of
the filepath name, and look in a directory that matches the target
device's OS Version as an optimization, to avoid opening the given file
in other DeviceSupport directories.
There is a new layout where the cpu arch exists as a subdirectory under
the "<OS VER> (<OS BUILD>)" directory. e.g.
~/L/D/Xcode/iOS DeviceSupport/26.2 (23B87)/arm64e/Symbols/...
and it is possible that we could have multiple arch names for a given
build -- for instance, an Apple Watch that can have either arm64e or
arm64_32 shared caches.
The existing code also had a very simplistic way of parsing "<OS VER>
(<OS BUILD>)" from the directory name that hasn't been kept up to date
with how the directory names have changed over the years. We have some
like "Watch4,2 10.0 (21R329)" or "10.0 (21R329) universal" which may not
parse with the older parser.
This PR looks for target arch subdirs under the given directories,
passes the os version/build version string separately because it may not
be the final component in the directory name any more, and updates the
directory parser that finds the version and build numbers.
rdar://171821410
In `internalConsole` mode (especially in VSCode), lldb-dap should not
use the ConPTY to read the process' output. This is because the
internalConsole is not a real terminal, there is no reason to use
terminal emulation, which will add arbitrary line returns to the output.
Instead, this patch introduces the `eLaunchFlagUsePipes` flag in
ProcessLaunchInfo which tells ProcessLaunchWindows to use regular pipes
instead of a ConPTY to get the stdin and stdout of the debuggee.
The result is that output which is supposed to be on a single line is
properly rendered.
---
The following example is when debugging a program through lldb-dap on
Windows. The program prints the numbers 0 through 999 on a single line.
# Before
<img width="2214" height="672" alt="Screenshot 2026-03-13 at 17 07 35"
src="https://github.com/user-attachments/assets/26292d11-2288-46ee-a6d2-0b66bfa41288"
/>
The line is split if it's longer than 80 characters (default terminal
size).
# After
<img width="2215" height="689" alt="Screenshot 2026-03-13 at 17 12 39"
src="https://github.com/user-attachments/assets/c9cad9af-b1ce-4c7b-91d5-f684e48e64ca"
/>
The line is correctly printed as a single line.
rdar://172491166
While here:
* Move the constructor to the public section. Almost all ThreadPlan
classes have public constructors.
* Use `std::make_shared()`. It is modern and more efficient.
`lldb-private-types.h` includes `lldb-private.h`, which in turn includes
`lldb-private-types.h`. Because of that, `lldb-public.h` included by
`lldb-private.h` after `lldb-private-types.h` is not actually included.
The practical consequence of this is that types defined in
`lldb-public-types.h` (for example, `addr_t` needed downstream) are not
available in `lldb-private-types.h`.
Fix this by "including what you use", which is `lldb-types.h`.
Also deserialize them back again on reading.
The implementation is based on the existing implementation of `#pragma
weak` serialization.
Fixes issue #186742.
---------
Co-authored-by: Chuanqi Xu <yedeng.yd@linux.alibaba.com>
Part 4. This converts all the remaining simple uses (the ones that ended
with a newline).
What remains in tree are the outliers that expect multiple ending
newlines, or are building a message in pieces.
- it is always passed as zero
- a lot of plugins aren't using it correctly
- the data extractor class already has the capability to look at a
subset of bytes
Add extra guards in case a call to function fails. For example, the
result of `ReadMemory()` cannot be trusted when `error.Fail()` is true,
and this change ensures the code executes properly according to the
value of the error.
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
After this change, Address::SetSection() had only one use left (in a
unit test) and was removed. Address::ClearSection() had no uses, now
also removed. (It is unlikely that someone needs to change the section
without simultaneously changing the section offset, and for that we have
a constructor.)
This is to highlight places where we (probably unintentionally)
construct an `Address` object from an already resolved address, making
it unresolved again.
See the changes in `DynamicLoaderDarwin.cpp` for a quick example.
Also, use this constructor instead of `Address(lldb::addr_t file_addr,
const SectionList *section_list)` when `section_list` is `nullptr`.
Add a new PlatformWebInspectorWasm, which is a Wasm platform that
automatically connects to the WebInspector platform server.
The existing "wasm" platform handles WebAssembly generally and allows
you to configure a runtime to launch under. The "webinspector-wasm"
platform does the inverse, and only supports attaching to an already
running WebAssembly instance in Safari. The workflow here is always
`platform process list` followed by `platform process attach`. This
explains why you can only force create this platform and it's never
automatically selected when loading a Wasm target.
The cache path we get from the `llvm::sys::path::cache_directory()`
library function is not writeable on some Windows bots as they point us
to the Default user's AppData: C:\Users\Default\AppData\Local\lldb.
This patch avoids the problem and downloads into the temporary directory
that we query from `llvm::sys::path::system_temp_directory()`. Once we
introduce real caching, this would have changed anyway.
The stream path in NativeFile::SeekFromEnd was missing a `return result`
statement after the fseek block, causing it to fall through to the error
handler which overwrites the error status with "invalid file handle"
even on success. Both SeekFromStart and SeekFromCurrent correctly return
after their stream blocks.
while no active callers to this function, It is still worth fixing this.
