This patch deprecates an APInt constructor that has been
soft-deprecated via comments since:
commit 7a16288157
Author: Jeffrey Yasskin <jyasskin@google.com>
Date: Mon Jul 18 21:45:40 2011 +0000
This patch updates a small number of remaining uses.
This commit aggregates the following changes:
1. Fix the format (i.e., indentation) when printing stop hooks via `target
stop-hook list`.
2. Add `IndentScope Stream::MakeIndentScope()` to make managing (and restoring!)
of the indentation level on `Stream` instances more ergonomic and less error
prone.
3. Simplify printing of stop hooks using the new `IndentScope`.
Update all uses of variadic `.Cases` to use the initializer list
overload instead. I plan to mark variadic `.Cases` as deprecated in a
followup PR.
For more context, see https://github.com/llvm/llvm-project/pull/163117.
Fix the `RegisterValue::SetValueFromData` method so that it works also
for 128-bit registers that contain integers.
Without this change, the `RegisterValue::SetValueFromData` method does
not work correctly
for 128-bit registers that contain (signed or unsigned) integers.
---
Steps to reproduce the problem:
(1)
Create a program that writes a 128-bit number to a 128-bit registers
`xmm0`. E.g.:
```
#include <stdint.h>
int main() {
__asm__ volatile (
"pinsrq $0, %[lo], %%xmm0\n\t" // insert low 64 bits
"pinsrq $1, %[hi], %%xmm0" // insert high 64 bits
:
: [lo]"r"(0x7766554433221100),
[hi]"r"(0xffeeddccbbaa9988)
);
return 0;
}
```
(2)
Compile this program with LLVM compiler:
```
$ $YOUR/clang -g -o main main.c
```
(3)
Modify LLDB so that when it will be reading value from the `xmm0`
register, instead of assuming that it is vector register, it will treat
it as if it contain an integer. This can be achieved e.g. this way:
```
diff --git a/lldb/source/Utility/RegisterValue.cpp b/lldb/source/Utility/RegisterValue.cpp
index 0e99451c3b70..a4b51db3e56d 100644
--- a/lldb/source/Utility/RegisterValue.cpp
+++ b/lldb/source/Utility/RegisterValue.cpp
@@ -188,6 +188,7 @@ Status RegisterValue::SetValueFromData(const RegisterInfo ®_info,
break;
case eEncodingUint:
case eEncodingSint:
+ case eEncodingVector:
if (reg_info.byte_size == 1)
SetUInt8(src.GetMaxU32(&src_offset, src_len));
else if (reg_info.byte_size <= 2)
@@ -217,23 +218,6 @@ Status RegisterValue::SetValueFromData(const RegisterInfo ®_info,
else if (reg_info.byte_size == sizeof(long double))
SetLongDouble(src.GetLongDouble(&src_offset));
break;
- case eEncodingVector: {
- m_type = eTypeBytes;
- assert(reg_info.byte_size <= kMaxRegisterByteSize);
- buffer.bytes.resize(reg_info.byte_size);
- buffer.byte_order = src.GetByteOrder();
- if (src.CopyByteOrderedData(
- src_offset, // offset within "src" to start extracting data
- src_len, // src length
- buffer.bytes.data(), // dst buffer
- buffer.bytes.size(), // dst length
- buffer.byte_order) == 0) // dst byte order
- {
- error = Status::FromErrorStringWithFormat(
- "failed to copy data for register write of %s", reg_info.name);
- return error;
- }
- }
}
if (m_type == eTypeInvalid)
```
(4)
Rebuild the LLDB.
(5)
Observe what happens how LLDB will print the content of this register
after it was initialized with 128-bit value.
```
$YOUR/lldb --source ./main
(lldb) target create main
Current executable set to '.../main' (x86_64).
(lldb) breakpoint set --file main.c --line 11
Breakpoint 1: where = main`main + 45 at main.c:11:3, address = 0x000000000000164d
(lldb) settings set stop-line-count-before 20
(lldb) process launch
Process 2568735 launched: '.../main' (x86_64)
Process 2568735 stopped
* thread #1, name = 'main', stop reason = breakpoint 1.1
frame #0: 0x000055555555564d main`main at main.c:11:3
1 #include <stdint.h>
2
3 int main() {
4 __asm__ volatile (
5 "pinsrq $0, %[lo], %%xmm0\n\t" // insert low 64 bits
6 "pinsrq $1, %[hi], %%xmm0" // insert high 64 bits
7 :
8 : [lo]"r"(0x7766554433221100),
9 [hi]"r"(0xffeeddccbbaa9988)
10 );
-> 11 return 0;
12 }
(lldb) register read --format hex xmm0
xmm0 = 0x7766554433221100ffeeddccbbaa9988
```
You can see that the upper and lower 64-bit wide halves are swapped.
---------
Co-authored-by: Matej Košík <matej.kosik@codasip.com>
The BridgeOS SDK is capitalized, but previously failed to parse because
we were looking for bridgeOS. This PR updates the enum value and the
canonical spelling.
rdar://162641896
Right shift operator in `Scalar` didn't check if the value is unsigned
to perform a logical right shift. Use the right shift operator from
`APSInt` that does this check.
When handling CUDA ELF files via objdump or LLDB, the ELF parser in LLVM
needs to distinguish if an ELF file is sass or not, which requires a
triple for sass to exist in llvm. This patch includes all the necessary
changes for LLDB and objdump to correctly identify these files with the
correct triple.
This PR uses the same trick as 7ced9fff95 to ensure the
`g_core_definitions` table is correctly indexed by the Core enum. It's
easy to make a mistake. Case in point: this caught two entries that
appeared in the wrong order.
The LLDB client has support for structured data plugins, but lldb-server
doesn't have corresponding support for it. This patch adds the missing
functionality in LLGS for servers to register their supported plugins
and send corresponding async messages.
- Introduced a new method `IsNVPTX()` in `ArchSpec` to check for NVPTX
architecture.
- Implemented the corresponding method in `ArchSpec.cpp` to utilize the
existing triple architecture checks.
This patch has default initialization values for the "sub", "cpu_mask"
and "sub_mask" member variables of the ArchDefinitionEntry structure.
This can simplify and cleanup the ArchDefinitionEntry arrays by allowing
those that don't override the values to not have to initialize the
values in the definitions if they match the default values.
This patchs also disables clang format to align the values in the
columns for easier readability.
Adds a `--defaults`/`-d` flag to `settings show`. This mode will _optionally_ show a
setting's default value. In other words, this does not always print a default value for
every setting.
A default value is not shown when the current value _is_ the default.
Note: some setting types do not print empty or invalid values. For these setting types,
if the default value is empty or invalid, the same elision logic is applied to printing
the default value.
Add `ValueObject::CreateValueObjectFromScalar` function and adjust
`Scalar::GetData` to be able to both extend and truncate the data bytes
in Scalar to the specified size.
Add support for DW_OP_WASM_location in DWARFExpression. This PR rebases
#78977 and cleans up the unit test. The DWARF extensions are documented
at https://yurydelendik.github.io/webassembly-dwarf/ and supported by
LLVM-based toolchains such as Clang, Swift, Emscripten, and Rust.
…(#144919)"
This was causing a couple of failures on the Ubuntu bots. Reverting
while we wait on a fix for those issues.
This reverts commit 8612926c30.
This PR addresses a race condition encountered when using LLDB through
the Python scripting interface.
I'm relatively new to LLDB, so feedback is very welcome, especially if
there's a more appropriate way to address this issue.
### Bug Description
When running a script that repeatedly calls
`debugger.GetListener().WaitForEvent()` in a loop, and at some point
invokes `process.Kill()` from within that loop to terminate the session,
a race condition can occur if `process.Kill()` is called around the same
time a breakpoint is hit.
### Race Condition Details
The issue arises when the following sequence of events happens:
1. The process's **private state** transitions to `stopped` when the
breakpoint is hit.
2. `process.Kill()` calls `Process::Destroy()`, which invokes
`Process::WaitForProcessToStop()`. At this point:
- `private_state = stopped`
- `public_state = running` (the public state has not yet been updated)
3. The **public stop event** is broadcast **before** the hijack listener
is installed.
4. As a result, the stop event is delivered to the **non-hijack
listener**.
5. The interrupt request sent by `Process::StopForDestroyOrDetach()` is
ignored because the process is already stopped (`private_state =
stopped`).
6. No public stop event reaches the hijack listener.
7. `Process::WaitForProcessToStop()` hangs waiting for a public stop
event, but the event is never received.
8. `process.Kill()` times out after 20 seconds
### Fix Summary
This patch modifies `Process::WaitForProcessToStop()` to ensure that any
pending events in the non-hijack listener queue are processed before
checking the hijack listener. This guarantees that any missed public
state change events are handled, preventing the hang.
### Additional Context
A discussion of this issue, including a script to reproduce the bug, can
be found here:
[LLDB hangs when killing process at the same time a breakpoint is
hit](https://discourse.llvm.org/t/lldb-hangs-when-killing-process-at-the-same-time-a-breakpoint-is-hit)
LLDB uses the LLVM disassembler to determine the size of instructions and
to do the actual disassembly. Currently, if the LLVM disassembler can't
disassemble an instruction, LLDB will ignore the instruction size, assume
the instruction size is the minimum size for that device, print no useful
opcode, and print nothing for the instruction.
This patch changes this behavior to separate the instruction size and
"can't disassemble". If the LLVM disassembler knows the size, but can't
dissasemble the instruction, LLDB will use that size. It will print out
the opcode, and will print "<unknown>" for the instruction. This is much
more useful to both a user and a script.
The impetus behind this change is to clean up RISC-V disassembly when
the LLVM disassembler doesn't understand all of the instructions.
RISC-V supports proprietary extensions, where the TD files don't know
about certain instructions, and the disassembler can't disassemble them.
Internal users want to be able to disassemble these instructions.
With llvm-objdump, the solution is to pipe the output of the disassembly
through a filter program. This patch modifies LLDB's disassembly to look
more like llvm-objdump's, and includes an example python script that adds
a command "fdis" that will disassemble, then pipe the output through a
specified filter program. This has been tested with crustfilt, a sample
filter located at https://github.com/quic/crustfilt .
Changes in this PR:
- Decouple "can't disassemble" with "instruction size".
DisassemblerLLVMC::MCDisasmInstance::GetMCInst now returns a bool for
valid disassembly, and has the size as an out paramter.
Use the size even if the disassembly is invalid.
Disassemble if disassemby is valid.
- Always print out the opcode when -b is specified.
Previously it wouldn't print out the opcode if it couldn't disassemble.
- Print out RISC-V opcodes the way llvm-objdump does.
Code for the new Opcode Type eType16_32Tuples by Jason Molenda.
- Print <unknown> for instructions that can't be disassembled, matching
llvm-objdump, instead of printing nothing.
- Update max riscv32 and riscv64 instruction size to 8.
- Add example "fdis" command script.
- Added disassembly byte test for x86 with known and unknown instructions.
- Added disassembly byte test for riscv32 with known and unknown instructions,
with and without filtering.
- Added test from Jason Molenda to RISC-V disassembly unit tests.
This commit introduces a new log channel for the disassembler in LLDB,
allowing for better logging of disassembler related activities. The
`LLDBLOG` enum has been updated to include the `Disassembler` channel,
and the relevant logging in the `DisassemblerLLVMC` plugin has been
modified to utilize this new channel. This is in preparation for adding
additional disassembler implementations.
Key Changes:
- Added `Disassembler` to the `LLDBLog` enum.
- Updated logging in `DisassemblerLLVMC.cpp` to use the new
`Disassembler` log channel.
Commit 1a7b7e24bc introduced a few casting
warnings and a build issue in Win32 platforms.
Trying to correct the casts to c++ style casts instead of C style casts.
This updates MainLoopWindows to support events for reading from a pipe
(both anonymous and named pipes) as well as sockets.
This unifies both handle types using `WSAWaitForMultipleEvents` which
can listen to both sockets and handles for change events.
This should allow us to unify how we handle watching pipes/sockets on
Windows and Posix systems.
We can extend this in the future if we want to support watching other
types, like files or even other events like a process life time.
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
`SDKSupportsBuiltinModules` always returns true on newer versions of
Darwin based OS. The only way for this call to return `false` would be
to have a version mismatch between lldb and the SDK (recent lldb
manually installed on macOS 14 for instance).
This patch removes this check and hardcodes the value of
`BuiltinHeadersInSystemModules` to `false`.
If we're not touching them, we don't need to do anything special to pass
them along -- with one important caveat: due to how cmake arguments
work, the implicitly passed arguments need to be specified before
arguments that we handle.
This isn't particularly nice, but the alternative is enumerating all
arguments that can be used by llvm_add_library and the macros it calls
(it also relies on implicit passing of some arguments to
llvm_process_sources).
With a debug build on Windows, printing inline diagnostics resulted in an
error, for example:
```
> cd llvm-project\lldb\test\API\functionalities\postmortem\elf-core
> lldb.exe -c altmain.core
> p dummy
LLDB diagnostics will be written to ...
Please include the directory content when filing a bug report
Exception Code: 0x80000003
0x00007FF8FD6633EC, C:\llvm\build\bin\liblldb.dll(0x00007FF8FC2C0000) + 0x13A33EC byte(s), std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<lldb_private::DiagnosticDetail> > >::_Compat() + 0x6C byte(s), C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.43.34808\include\vector, line 202 + 0x5D byte(s)
0x00007FF8FD662ABE, C:\llvm\build\bin\liblldb.dll(0x00007FF8FC2C0000) + 0x13A2ABE byte(s), std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<lldb_private::DiagnosticDetail> > >::operator==() + 0x1E byte(s), C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.43.34808\include\vector, line 166 + 0x0 byte(s)
0x00007FF8FD662B2E, C:\llvm\build\\bin\liblldb.dll(0x00007FF8FC2C0000) + 0x13A2B2E byte(s), std::_Vector_const_iterator<std::_Vector_val<std::_Simple_types<lldb_private::DiagnosticDetail> > >::operator!=() + 0x1E byte(s), C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.43.34808\include\vector, line 176 + 0xF byte(s)
0x00007FF8FD65EE1C, C:\llvm\build\\bin\liblldb.dll(0x00007FF8FC2C0000) + 0x139EE1C byte(s), std::operator!=<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<lldb_private::DiagnosticDetail> > >,std::_Vector_iterator<std::_Vector_val<std::_Simple_types<lldb_private::DiagnosticDetail> > > >() + 0x3C byte(s), C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.43.34808\include\xutility, line 1947 + 0x0 byte(s)
0x00007FF8FD65D4E5, C:\llvm\build\\bin\liblldb.dll(0x00007FF8FC2C0000) + 0x139D4E5 byte(s), lldb_private::RenderDiagnosticDetails() + 0x8F5 byte(s), C:\llvm\src\llvm-project\lldb\source\Utility\DiagnosticsRendering.cpp, line 189 + 0x25 byte(s)
...
```
The comparison operator of the iterators checks that they belong to the
same container, but `remaining_details.pop_back()` invalidates `detail`
making it incompatible with `remaining_details.rend()`.
---------
Co-authored-by: Michael Buch <michaelbuch12@gmail.com>
The `lldbassert` macro in LLDB behaves like a regular `assert` when
assertions are enabled, and otherwise prints a pretty backtrace and
prompts the user to file a bug. By default, this is emitted as a
diagnostic event, but vendors can provide their own behavior, for
example pre-populating a bug report.
Recently, we ran into an issue where an `lldbassert` (in the Swift
language plugin) would fire excessively, to the point that it was
interfering with the usability of the debugger.
Once an `lldbasser` has fired, there's no point in bothering the user
over and over again for the same problem. This PR solves the problem by
introducing a static `std::once_flag` in the macro. This way, every
`lldbasser` will fire at most once per lldb instance.
rdar://148520448
According to [1], the template parameter must be cv-unqualified and one
of unsigned short, unsigned int, unsigned long, or unsigned long long.
Should fix the following MSVC error:
error: static assertion failed due to requirement
'_Is_any_of_v<unsigned char, unsigned short, unsigned int, unsigned
long, unsigned long long>': invalid template argument for
independent_bits_engine: N4659
[1] https://en.cppreference.com/w/cpp/numeric/random/independent_bits_engine
Hoist UUID generation into the UUID class and add a trivial unit test.
This also changes the telemetry code to drop the double underscore if we
failed to generate a UUID and subsequently logs to the Host instead of
Object log channel.
Include the LLDB version in the lldbassert error message, and prompt
users to include it in the bug report. The majority of users that bother
filing a bug report just copy past the stack trace and often forget to
include this important detail. By putting it after the backtrace and
before the prompt, I'm hoping it'll get copy-pasted in.
rdar://146793016
When printing setting variables using the python SBDebugger API if the type is of OptionValueFileSpec
it defaults to null as the value even if it has a value. This patch fixes that.
---------
Signed-off-by: Ebuka Ezike <yerimyah1@gmail.com>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
The `DW_AT_APPLE_sdk` should always be equal to the filename of the
`DW_AT_LLVM_sysroot`. We can use this property to simplify
`XcodeSDK::Merge` to no longer manually adjust the sysroot filename.
Instead we simply update the sysroot filename with merged SDK name.
This should be an NFC change.
This reverts commit 6041c745f3.
Relands the original patch with the test-case data fixed. Weirldy the PR CI
didn't seem to run the unit-tests? In any case, the problem was an
incorrect expectation in the test-case data. Since we have both public
and internal SDK in that test-case, we should `expect_mismatch` to be
`true`.
Reverts llvm/llvm-project#128712
```
******************** TEST 'lldb-unit :: SymbolFile/DWARF/./SymbolFileDWARFTests/10/14' FAILED ********************
Script(shard):
--
GTEST_OUTPUT=json:/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/tools/lldb/unittests/SymbolFile/DWARF/./SymbolFileDWARFTests-lldb-unit-1021-10-14.json GTEST_SHUFFLE=1 GTEST_TOTAL_SHARDS=14 GTEST_SHARD_INDEX=10 GTEST_RANDOM_SEED=62233 /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/tools/lldb/unittests/SymbolFile/DWARF/./SymbolFileDWARFTests
--
Script:
--
/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/tools/lldb/unittests/SymbolFile/DWARF/./SymbolFileDWARFTests --gtest_filter=SDKPathParsingTests/SDKPathParsingMultiparamTests.TestSDKPathFromDebugInfo/6
--
/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp:265: Failure
Expected equality of these values:
found_mismatch
Which is: true
expect_mismatch
Which is: false
/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/unittests/SymbolFile/DWARF/XcodeSDKModuleTests.cpp:265
Expected equality of these values:
found_mismatch
Which is: true
expect_mismatch
Which is: false
```
`GetSDKRoot` uses `xcrun` to find an SDK root path for a given SDK
version string. But if the SDK doesn't exist in the Xcode installations,
but instead lives in the `CommandLineTools`, `xcrun` will fail to find
it. Negative searches for an SDK path cost a lot (a few seconds) each
time `xcrun` is invoked. We do cache negative results in
`find_cached_path` inside LLDB, but we would still pay the price on
every new debug session the first time we evaluate an expression. This
doesn't only cause a noticable delay in running the expression, but also
generates following error:
```
error: Error while searching for Xcode SDK: timed out waiting for shell command to complete
(int) $0 = 42
```
In this patch we avoid these possibly expensive calls to `xcrun` by
checking the `DW_AT_LLVM_sysroot`, and if it exists, using that as the
SDK path. We need an explicit check for the `CommandLineTools` path
before we call `RegisterXcodeSDK`, because that will try to call
`xcrun`. This won't prevent other uses of `GetSDKRoot` popping up that
cause us to make expensive `xcrun` calls, but for now this addresses the
regression in the expression evaluator. We also had to adjust the
`XcodeSDK::Merge` logic to update the sysroot. There is one case for
which this wouldn't make sense: if a CU was compiled with
`CommandLineTools` and a different one with an older internal SDK, in
that case we would update the `CommandLineTools` sysroot with a
`.Internal.sdk` prefix, which won't possibly exist for
`CommandLineTools`. I added a unit-test for this. Not sure if we want to
explicitly detect and disallow this, given it's quite a niche scenario.
rdar://113619904
rdar://113619723
A DriverKit process is a kernel extension that runs in userland, instead
of running in the kernel address space/priv levels, they've been around
a couple of years. From lldb's perspective a DriverKit process is no
different from any other userland level process, but it has a different
Triple so we need to handle those cases in the lldb codebase. Some of
the DriverKit triple handling had been upstreamed to llvm-project, but I
noticed a few cases that had not yet. Cleaning that up.
Revert to the state after d7796855b8 and use the underlying buffer
directly. I was still under the impression that was unsafe, so I did a
drive-by fix, which this commit reverts.
Rename `lldb_assert` to `_lldb_assert` to make it more obvious that you
shouldn't be using this function directly. Instead, you should use the
`lldbassert` macro which becomes a regular assert in a debug/asserts
build.
With this patch, vector registers can be read and written when debugging a live process.
Note: We currently assume that all LoongArch64 processors include the
LSX and LASX extensions.
To add test cases, the following modifications were also made:
lldb/packages/Python/lldbsuite/test/lldbtest.py
lldb/packages/Python/lldbsuite/test/make/Makefile.rules
Reviewed By: DavidSpickett, SixWeining
Pull Request: https://github.com/llvm/llvm-project/pull/120664
Building on top of previous work that exposed expression diagnostics via
SBCommandReturnObject, this patch generalizes the support to expose any
SBError as machine-readable structured data. One use-case of this is to
allow IDEs to better visualize expression diagnostics.
rdar://139997604
