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.
Remove 'lldb-python-scripts' from LLVM_DISTRIBUTION_COMPONENTS when
Python scripting is disabled. Otherwise we get
```
Specified distribution component 'lldb-python-scripts' doesn't have an install target
```
Right now, cross-building `lldb` means either installing a native
`lldb-tblgen` by hand (non-trivial, as CMake is painful) or first
building all of native clang because of how the CMake rules work, which
is not fun.
In keeping with the pattern established by llvm-tblgen and clang-tblgen,
install lldb-tblgen to ease cross-compilation.
Co-authored-by: Ross Burton <ross.burton@arm.com>
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.
First added in #153585 for Darwin only. All Linux AArch64 systems also
have Top Byte Ignore enabled in userspace so the test "just works"
there.
FreeBSD has very recently gained Top Byte Ignore support:
4c6c27d3fb
However it's so recent, I don't want to assume it'll be available on any
random FreeBSD system out there.
There isn't really a good place to put this test, so I put it in the top
level of API, next to the other non-address bit test that didn't have a
good home either.
Based on testing on processors that use pointer metadata, and with all
the work done to delay calls to FixDataAddress, this is no longer
necessary.
Note that, with debugserver in particular, this is an NFC change: the
code path here is for frame zero, and debugserver will strip metadata
when reading fp from frame zero anyway.
Even if Python scripting is disabled, we still need a Python interpreter
to build, for example to generate SBLanguages.h or fix up the framework
headers.
I've intentionally split this into two commits to make it easier that
this is an NFC patch; don't think we need to preserve them separately
though upon merging.
**Added emulator unwinding support for RISCV files.**
Emulated Instructions:
ADD (addi sp, sp, imm)
STORE (sd ra, offset(sp))
LOAD (ld ra, offset(sp)).
We had to overwrite SetInstructions() since UnwindAssemblyInstEmulation
calls EvaluateInstruction() directly after calling SetInstruction(), but
it never calls ReadInstruction(). This means that the m_decoded member
variable in the instruction emulator is never properly initialized. By
overriding SetInstruction(), we decode the instruction bytes and set
m_decoded directly. This ensures that subsequent emulation (including
unwinding) operates on the correct instruction.
We also had to change the the OpCode GetOpcodeBytes function since
recent changes made it so GetOpcodeBytes will return None for type
eType16_32Tuples (an alternative and longer way, would've been to type
check during the overwritten SetInstruction() and call a DataExtractor
with .GetU16(&offset) to set the inst_data.
Added a test - TestSimpleRiscvFunction (took inspiration from:
[link](https://github.com/llvm/llvm-project/blob/main/lldb/unittests/UnwindAssembly/ARM64/TestArm64InstEmulation.cpp))
[----------] 1 test from TestRiscvInstEmulation
[ RUN ] TestRiscvInstEmulation.TestSimpleRiscvFunction
[ OK ] TestRiscvInstEmulation.TestSimpleRiscvFunction (1 ms)
[----------] 1 test from TestRiscvInstEmulation (1 ms total)
[----------] Global test environment tear-down
[==========] 63 tests from 5 test suites ran. (11 ms total)
[ PASSED ] 63 tests.
---------
Co-authored-by: Bar Soloveychik <barsolo@fb.com>
The first call, in InitializeNonZerothFrame, is inside a logging branch.
For that, it's better to log the real value instead of the fixed one.
The second call, inside RegisterContextUnwind::ReadFrameAddress, is
computing an address which is then passed to
ReadRegisterValueFromMemory, which boils down to a Process::ReadMemory,
which fixes the address if it wants to. The current variable names are
misleading, making readers believe it is the cfa value itself that is
being passed to Fix*Address; that's not the case. This commit renames
the variable to make this abundantly clear.
The `ProcessElfCore::FindModuleUUID` function can be called by multiple
threads at the same time when `target.parallel-module-load` is true. We
were using the `operator[]` to lookup the UUID which will mutate the map
when the key is not present. This is unsafe in a multi-threaded contex
so we now use a read-only `find` operation and explicitly return an
invalid UUID when the key is not present.
The `m_uuids` map can follow a create-then-query pattern. It is
populated in the `DoLoadCore` function which looks like it is only
called in a single-threaded context so we do not need extra locking as
long as we keep the other accesses read-only.
Other fixes I considered
* Use a lock to protect access - We don't need to modify the map after
creation so we can allow concurrent read-only access.
* Store the map in a const pointer container to prevent accidental
mutation in other places.
- Only accessed in one place currently so just added a comment.
* Store the UUID in the NT_FILE_Entry after building the mapping
correctly in `UpdateBuildIdForNTFileEntries`. - The map lets us avoid a
linear search in `FindModuleUUID`.
This commit also reverts the temporary workaround from #159395 which
disabled parallel module loading to avoid the test failure.
Fixes#159377
If `pr_name` is longer than 16, it would be a non-null terminated
string. Assigning it to `std::string m_executable_name` would cause an
overflow read. Instead, just copy the name from thread_data.name.
To repro, run the `elf-core/TestLinuxCore.py` with asan
(Question: why is the new variable needed in the first place? can't the
thread_data.name be used?)
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.
This reverts the following commits:
a0a82ee19d6f2ff1013407ba4c973bfe5428423f
757bb36a58c7d7151a28c6a5fc7caa2e1f44de87
83b48b13f3a70bf56053e92593270c519859cfd7
b45f1fb377636a34c01e34b89341c97d19975554
d2e153981e62fb2ea781ef456ff744f9893e0733
e2d1bbebbb099c7010a31fad62a9128166ef14a0
71cae12442e7476e6397fd73db05e127bfe2d035
7dd879bdc01297a551196a60bb5a5a90ca4dd1ed
f3b542e3148cfc244f63cb7c987ccf8ebc71942b
Where I had disabled specific tests due to them being flakey on our
Windows on Arm bot.
Clearly this strategy isn't working because
every day I see a new random test failing.
Until something can be done about this, disable
every lldb-dap test on Windows on Arm. The coverage we get is just not
worth spamming contributors
who have nothing to do with lldb-dap.
See #137660
When creating LLDB types from `LF_MODIFIER` records, the type name of
the modified type was used. This didn't include the modifiers
(`const`/`volatile`/`__unaligned`). With this PR, they're included.
The DIA plugin had a test for this. That test also assumed that function
types had a name. I removed that check here, because function/procedure
types themselves in PDB don't have a name:
```
0x1015 | LF_ARGLIST [size = 20, hash = 0xBCB6]
0x0074 (int): `int`
0x1013: `int* __restrict`
0x1014: `int& __restrict`
0x1016 | LF_PROCEDURE [size = 16, hash = 0x3F611]
return type = 0x0003 (void), # args = 3, param list = 0x1015
calling conv = cdecl, options = None
```
I assume DIA gets the name from the function symbol itself. In the
native plugin, that name isn't included and multiple functions with the
same signature will reuse one type, whereas DIA would create a new type
for each function. The
[Shell/SymbolFile/PDB/func-symbols.test](b29c7ded31/lldb/test/Shell/SymbolFile/PDB/func-symbols.test)
also relies on this.
When quitting LLDB on Windows while a process was still running, LLDB
would take unusually long to exit. This was due to a temporary deadlock:
The main thread was destroying the processes. In doing so, it iterated
over the target list:
88c64f76ed/lldb/source/Core/Debugger.cpp (L1095-L1098)
This locks the list for the whole iteration. Finalizing the process
would eventually lead to `DebuggerThread::StopDebugging`, which
terminates the process and waits for it to exit:
88c64f76ed/lldb/source/Plugins/Process/Windows/Common/DebuggerThread.cpp (L196)
The debugger loop (on a separate thread) would see that the process
exited and call
[`ProcessWindows::OnExitProcess`](88c64f76ed/lldb/source/Plugins/Process/Windows/Common/ProcessWindows.cpp (L656-L673)).
This calls the static function
[`Process::SetProcessExitStatus`](0a7a7d56fc/lldb/source/Target/Process.cpp (L1098-L1126)).
This tries to find the process by its ID from the debugger's target
list. Doing so requires locking the list, so the debugger thread would
then be stuck on
0a7a7d56fc/lldb/source/Target/TargetList.cpp (L403)
After 5s, the main thread would give up waiting. So every exit where the
process was still running would be delayed by about 5s.
Since `ProcessWindows` would find itself when calling
`SetProcessExitStatus`, we can call `SetExitStatus` directly.
This can also make some tests run faster. For example, the DIA PDB tests
previously took 15s to run on my PC (24 jobs) and now take 5s. For all
shell tests, the difference isn't that big (only about 3s), because most
don't run into this and the tests run in parallel.
uintptr_t is usually a good idea when handling pointers, but lldb has to
handle 64-bit addresses that might be from a remote system, on a 32-bit
system.
So I've changed a few instances here to use addr_t which is 64-bit
everywhere.
Before we got:
https://lab.llvm.org/buildbot/#/builders/18/builds/21247
```
../llvm-project/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp:81:28: error: constexpr variable 'g_mte_tag_mask' must be initialized by a constant expression
81 | static constexpr uintptr_t g_mte_tag_mask = (uintptr_t)0x0f << g_mte_tag_shift;
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../llvm-project/lldb/source/Plugins/Process/Utility/StopInfoMachException.cpp:81:61: note: shift count 56 >= width of type 'uintptr_t' (aka 'unsigned int') (32 bits)
81 | static constexpr uintptr_t g_mte_tag_mask = (uintptr_t)0x0f << g_mte_tag_shift;
| ^
1 error generated.
```
Original code added by #159117.
…lts (#159460)""
The original had an issue on "AArch-less" bots.
Fixed it with some ifdefs around the presence of the AArch ABI plugin.
This reverts commit 1a4685df13282ae5c1d7dce055a71a7130bfab3c.
This fixes an issue where the MCP server would stop the main loop after
the first client disconnects.
This moves the MainLoop out of the Server instance and lifts the server
up into the ProtocolServerMCP object instead. This allows us to register
the client with the main loop used to accept and process requests.
When evaluating any DWARF expression that ended in OP_deref and whose
previous value on the dwarf stack -- the pointer address for the deref
-- was a load address, we were treating the result itself as a pointer,
calling Process:FixCodeAddress(result). This is wrong: there's no
guarantee that the result is a pointer itself.
Recognize an MTE tag fault Mach exception. A tag fault is an error
reported by Arm's Memory Tagging Extension (MTE) when a memory access
attempts to use a pointer with a tag that doesn't match the tag stored
with the memory. LLDB will print the tag and address to make the issue
easier to diagnose.
This was hand tested by debugging an MTE enabled binary on an iPhone 17
running iOS 26.
rdar://113575216
This avoids the following warnings from Clang:
../../lldb/source/Host/windows/Host.cpp:324:3: warning: default label in switch which covers all enumeration values [-Wcovered-switch-default]
324 | default:
| ^
../../lldb/source/Host/common/File.cpp:662:26: warning: cast from 'const void *' to 'char *' drops const qualifier [-Wcast-qual]
662 | .write((char *)buf, num_bytes);
| ^
Since #157170 this test has been flakey on several LLDB buildbots. I
suspect it's to do with mutli-threading, there are more details in
#159377.
Disable parallel loading for now so we are not spamming people making
unrelated changes.
This adds the ability to recognize (and create ValueObjects for) boolean
literals ("true", "false") to DIL. This is a preliminary step to adding
type casting (and also for the ternary op).
Adding support for launching lldb with `-O protocol start MCP` if a
valid ~/.lldb/lldb-mcp-*.json` file is not found.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This PR is a part of the effort to make the VFS used in the compiler
more explicit and consistent.
Instead of creating the VFS deep within the compiler (in
`CompilerInstance::createFileManager()`), clients are now required to
explicitly call `CompilerInstance::createVirtualFileSystem()` and
provide the base VFS from the outside.
This PR also helps in breaking up the dependency cycle where creating a
properly configured `DiagnosticsEngine` requires a properly configured
VFS, but creating properly configuring a VFS requires the
`DiagnosticsEngine`.
Both `CompilerInstance::create{FileManager,Diagnostics}()` now just use
the VFS already in `CompilerInstance` instead of taking one as a
parameter, making the VFS consistent across the instance sub-object.
These no longer compile because the warning now defaults to an error
after #157364, so downgrade the error to a warning for now; I’m not
familiar enough with either LLDB or MacOS to fix these warnings properly
(assuming they’re unintended).
This patch causes the various AST dump commands (`target modules dump
ast`/`target dump typesystem`) to be color-highlighted. I added a `bool
show_color` parameter to `SymbolFile::DumpClangAST` and
`TypeSystem::Dump`. In `TypeSystemClang` I temporarily sets the
`getShowColors` flag on the owned Clang AST (using an RAII helper) for
the duration of the AST dump. We use `Debugger::GetUseColors` to decide
whether to color the AST dump.
This brings back the tool for listing debuggers.
This is helpful when an LLM doesn't support resources, like gemini-cli.
I also fixed an issue with `ServerInfoHandle` not always cleaning up the
`~/lldb/lldb-mcp-<pid>.json` file correctly.
If LLDB is built without the DIA SDK enabled, then the native plugin is
used regardless of `plugin.symbol-file.pdb.reader` or
`LLDB_USE_NATIVE_PDB_READER`. This made the test fail on Windows when
the DIA SDK was disabled
(https://github.com/llvm/llvm-project/issues/114906#issuecomment-3241796062).
This PR changes the requirement for the test from `target-windows` to
`diasdk` (only used in this test).
This pages improve the LLDB website documentation readability and
discoverability by breaking down the very long python-reference page
into multiple subpages each explaining a specific topic.
The long term goal is to have tutorials for every scripting extension.
This also converts the pages to markdown, since it's easier to write.
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
It's possible for this logic to fail if the build system runs this
script in parallel. One instance could create the directory in between
another instance's checking of its existence and attempt at creation.
Instead, always try to create it and ignore any FileExistsErrors.
rdar://160120161
- 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.
C++11 allows the use of Universal Character Names (UCNs) in identifiers,
including function names.
According to the spec the behavior of std::isalpha(ch) and
std::isalnum(ch) is undefined if the argument's value is neither
representable as unsigned char nor equal to EOF. To use these functions
safely with plain chars (or signed chars), the argument should first be
converted to unsigned char.
A DependentTemplateSpecializationType (DTST) is basically just a
TemplateSpecializationType (TST) with a hardcoded DependentTemplateName
(DTN) as its TemplateName.
This removes the DTST and replaces all uses of it with a TST, removing a
lot of duplication in the implementation.
Technically the hardcoded DTN is an optimization for a most common case,
but the TST implementation is in better shape overall and with other
optimizations, so this patch ends up being an overall performance
positive:
<img width="1465" height="38" alt="image"
src="https://github.com/user-attachments/assets/084b0694-2839-427a-b664-eff400f780b5"
/>
A DTST also didn't allow a template name representing a DTN that was
substituted, such as from an alias template, while the TST does allow it
by the simple fact it can hold an arbitrary TemplateName, so this patch
also increases the amount of sugar retained, while still being faster
overall.
Example (from included test case):
```C++
template<template<class> class TT> using T1 = TT<int>;
template<class T> using T2 = T1<T::template X>;
```
Here we can now represent in the AST that `TT` was substituted for the
dependent template name `T::template X`.
