This changes VirtualDataExtractor's GetByteSize to return the virtual
byte size of the buffer (external users only understand the data
contents in terms of the virtual sizes & offsets). There are check
methods in DataExtractor that check they are not going off the end of a
buffer, they usually use the BytesLeft() method. There are a couple of
callers of BytesLeft() externally, but it is predominantly an internal
use API. I have BytesLeft() use the physical size of the buffer, not the
virtual size, for the benefit of the DataExtractor methods. (and to
avoid duplicating all of them down in VirtualDataExtractor)
Another problem is the we call SetData on DataExtractorSP's (e.g. see
the ObjectFile ctor) with the DataBuffer it already has, an offset of 0,
and the GetByteSize. A no-op for a DataExtractor that is already using
that DataBuffer. But SetData would try to use that length as a physical
size, and truncate the buffer that the DataExtractor would accept.
I added VirtualDataExtractor subclass methods for the SetData's, detect
(1) data being added to an uninitialized DataExtractor, (2) the same
data / offset / length as currently being used is added to the
DataExtractor (a no-op), or (3) we're genuinely changing the data source
or setting an offset / length that is different. This final case we're
not ready to handle today, I added asserts for them so we can catch it
in debug builds, and then I clear the LookupTable and add a no-op entry
so this extractor will behave like a plain DataExtractor -- because I
don't know better to do. If we genuinely need to handle this case, and
I'm pretty sure we don't need to, I'd have to assume that we're taking a
subset of the original data source (an offset & length), so we'd need to
update all of the LookupTable entries to reflect the new offsets, and
remove entries that are no longer referring to the subsetted range. I'll
leave that until there's any evidence it's actually needed.
rdar://148939795
This fixes the following error on 32 bit platforms, if compiling with Clang:
llvm-project/lldb/source/Utility/VirtualDataExtractor.cpp:211:55: error: non-constant-expression cannot be narrowed from type 'SizeType' (aka 'unsigned long long') to 'size_t' (aka 'unsigned int') in initializer list [-Wc++11-narrowing]
211 | return {m_start + static_cast<size_t>(entry->data), entry->size};
| ^~~~~~~~~~~
llvm-project/lldb/source/Utility/VirtualDataExtractor.cpp:211:55: note: insert an explicit cast to silence this issue
211 | return {m_start + static_cast<size_t>(entry->data), entry->size};
| ^~~~~~~~~~~
| static_cast<size_t>( )
We have many places where an ObjectFile subclass will take the
DataExtractor representing the entire binary, create a subsection of
that in a new DataExtractor for processing. For instance, an object file
might have symbol table entries with offsets into the string table. A
common code pattern is to create a DataExtractor representing the string
table, and then pulling out the c-strings based on those offsets from
the string table DataExtractor.
When code does this, it creates a new DataExtractor, copies the
Endianness and Wordsize from the original, copies the DataBufferSP from
the original, and specifies a new start and offset into the DataBuffer.
However, if the binary is actaully stored in a VirtualDataExtractor,
this code pattern loses the correct virtual-to-physical table
translation and will not work correctly. This new method simplifies this
common pattern, and correctly takes a subset of a VirtualDataExtractor.
The current implementation only allows a subset of a
VirtualDataExtractor that is contained within a single virtual entry
(LookupTable entry) and returns a DataExtractor with the corret offsets
calculated from the LookupTable. If we need to a VirtualDataExtractor to
create a Subset DataExtractor representing multiple separate virtual
ranges of data, we'll need to copy over the LookupTable entries that
cover all the bytes, and update them to be relative to the new
VirtualDataExtractor. It's a bit of work, and it's not needed right now,
so I'm not tackling that.
I am working on a larger PR which needs this new method. This PR
contains a unit test that uses it.
rdar://148939795
We had a dedicated `StringLexer` class that pretty much just replicates
the `llvm::StringRef` interface. This patch removes the `StringLexer` in
favour of just using `llvm::StringRef`. Much of the string parsing can
be cleaned up, but I tried to keep the changes a small as possible so
just kept the logic and replaced the APIs calls. The only awkward
side-effect of this is that we have to pass a `llvm::StringRef &`
around.
There were some gaps in the API, so added two helper methods to
consume/pop off characters from the front of the StringRef (maybe those
can be added to `llvm::StringRef` in the future).
The `StringLexer` also had a roll-back mechanism used in two places.
That can be handled by just saving a copy of the `StringRef`.
The ObjectFile plugin interface accepts an optional DataBufferSP
argument. If the caller has the contents of the binary, it can provide
this in that DataBufferSP. The ObjectFile subclasses in their
CreateInstance methods will fill in the DataBufferSP with the actual
binary contents if it is not set.
ObjectFile base class creates an ivar DataExtractor from the
DataBufferSP passed in.
My next patch will be a caller that creates a VirtualDataExtractor with
the binary data, and needs to pass that in to the ObjectFile plugin,
instead of the bag-of-bytes DataBufferSP. It builds on the previous
patch changing ObjectFile's ivar from DataExtractor to DataExtractorSP
so I could pass in a subclass in the shared ptr. And it will be using
the VirtualDataExtractor that Jonas added in
https://github.com/llvm/llvm-project/pull/168802
No behavior is changed by the patch; we're simply moving the creation of
the DataExtractor to the caller, instead of a DataBuffer that is
immediately used to set up the ObjectFile DataExtractor. The patch is a
bit complicated because all of the ObjectFile subclasses have to
initialize their DataExtractor to pass in to the base class.
I ran the testsuite on macOS and on AArch64 Ubutnu. (btw David, I ran it
under qemu on my M4 mac with SME-no-SVE again, Ubuntu 25.10, checked
lshw(1) cpu capabilities, and qemu doesn't seem to be virtualizing the
SME, that explains why the testsuite passes)
rdar://148939795
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Introduce VirtualDataExtractor, a DataExtractor subclass that enables
reading data at virtual addresses by translating them to physical buffer
offsets using a lookup table. The lookup table maps virtual address
ranges to physical offsets and enforces boundaries to prevent reads from
crossing entry limits.
The new class inherits from DataExtractor, overriding GetData and
PeekData to provide transparent virtual address translation for most of
the DataExtractor methods. The exception are the unchecked methods, that
bypass those methods and are overloaded as well.
In C++17, static constexpr members are implicitly inline, so they no
longer require an out-of-line definition.
Identified with readability-redundant-declaration.
This patch fixes and eliminates the possibility of SupportFileSP ever
being nullptr. The support file was originally treated like a value
type, but became a polymorphic type and therefore has to be stored and
passed around as a pointer.
To avoid having all the callers check the validity of the pointer, I
introduced the invariant that SupportFileSP is never null and always
default constructed. However, without enforcement at the type level,
that's fragile and indeed, we already identified two crashes where
someone accidentally broke that invariant.
This PR introduces a NonNullSharedPtr to prevent that. NonNullSharedPtr
is a smart pointer wrapper around std::shared_ptr that guarantees the
pointer is never null. If default-constructed, it creates a
default-constructed instance of the contained type. Note that I'm using
private inheritance because you shouldn't inherit from standard library
classes due to the lack of virtual destructor. So while the new
abstraction looks like a `std::shared_ptr`, it is in fact **not** a
shared pointer. Given that our destructor is trivial, we could use
public inheritance, but currently there's no need for it.
rdar://164989579
NFC patch which moves `DiagnosticsRendering` from `Utility` to `Host`.
This refactoring is needed for
https://github.com/llvm/llvm-project/pull/168603. It adds a method to
check whether the current terminal supports Unicode or not. This will be
OS dependent and a better fit for `Host`. Since `Utility` cannot depend
on `Host`, `DiagnosticsRendering` must live in `Host` instead.
This patch adds `LLDBLog::InstrumentationRuntime` as a log channel to
provide an appropriate channel for instrumentation runtime plugins as
previously one did not exist.
A small use of the channel is added to illustrate its use. The logging
added is not intended to be comprehensive.
This is primarily motivated by an `-fbounds-safety` instrumentation
plugin (https://github.com/swiftlang/llvm-project/pull/11835).
rdar://164920875
In this PR we are proposing to change LLDB codebase so that LLDB is able
to print values of integer registers that have more than 64-bits (even
if the number of bits is not equal to 128).
---------
Co-authored-by: Matej Košík <matej.kosik@codasip.com>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This patch deprecates an APInt constructor that has been
soft-deprecated via comments since:
commit 7a16288157efc5fb85fbe3b8b4c37071da7609a6
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.
Summary:
This patch has broken the `libc` build bot. I could work around that but
the changes seem unnecessary.
This reverts commit 9ba844eb3a21d461c3adc7add7691a076c6992fc.
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 7ced9fff95473 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 8612926c306c5191a5fb385dd11467728c59e982.
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 1a7b7e24bcc1041ae0fb90abcfb73d36d76f4a07 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>
