As seen in #177570, this code has a bunch of corner cases, does not
handle ANSI codes properly and does not handle unicode at all. That's
enough to fix that we need some tests to make it clear where we're
starting from.
The body of OutputFormattedUsageText is moved into a utility in the
AnsiTerminal.h header and tests added to the existing
AnsiTerminalTest.cpp.
Some results are known to be wrong. Some that cause crashes are
commented out, to be enabled once fixed.
Add a step to drain the init sequences emitted by the ConPTY before
attaching it to the debuggee.
A ConPTY (PseudoConsole) emits init sequences which flush the screen and
contain the name of the program (ESC[2J for clear screen, ESC[H for
cursor home and more). It's not desirable to filter them out: if a
debuggee also emits them, lldb would filter that output as well. To work
around this, the ConPTY is drained by attaching a dummy process to it,
consuming the init sequences and then attaching the actual debuggee.
---------
Co-authored-by: Nerixyz <nero.9@hotmail.de>
This patch changes the return type of methods returning `std:wstring` to
`std::string` in `PythonPathSetup.cpp`.
This follows lldb's style of converting to `std::wstring` at the last
moment.
Several languages support some sort of "breakpoint" function, which adds
ISA-specific instructions to generate an interrupt at runtime. However,
on some platforms, these instructions don't increment the program
counter. When LLDB sets these instructions it isn't a problem, as we
remove them before continuing, then re-add them after stepping over the
location. However, for breakpoint sequences that are part of the
inferior process, this doesn't happen - and so users might be left
unable to continue past the breakpoint without manually interfering with
the program counter.
This patch adds logic to LLDB to intercept SIGTRAPs, inspect the bytes
of the inferior at the program counter, and if the instruction looks
like a BRK or BKPT or similar, increment the pc by the size of the
instruction we found. This unifies platform behaviour (e.g. on x86_64,
LLDB debug sessions already look like this) and improves UX (in my
opinion, but I think it beats messing with stuff every break).
Some ISAs (like AArch64) require slightly different handling, as while
there are multiple possible instructions, we should be careful only to
find the ones likely to have been emitted by a compiler backend, and not
those inserted from (for example) the UB sanitizer, or any others.
There is an existing builtin-debugtrap test which was under the macos
folder before. I've now moved that to "functionalities", made it pure C
only, and updated it a little bit so that it works regardless of
platform.
What I've not done is change the existing code in debugserver which was
added by Jason Molenda about five years ago
(https://reviews.llvm.org/D91238, 92b036d). It might not be required any
more after this change. Reading the history there, it seems like it was
agreed that this behaviour (skipping over unknown bps) was the desired
end goal.
Fixes#56268
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This should fix a failure on the macOS buildbots (see
https://github.com/llvm/llvm-project/pull/179524#issuecomment-3882784085).
I can't test this, but the only plugins not enabled on Linux and Windows
are `ProcessKDP`, `PlatformDarwin`, and `PlatformDarwinKernel`. Looking
at the path for KDP, it uses `GetPluginNameStatic` as the last name in
the path. This is `kdp-remote` instead of `kdp`.
In #168245, I attempted to dump the available settings to Markdown. That
required a full build of LLDB. However, to build the docs, only the swig
wrappers should need to be compiled. The comment was that we should be
able to use the definitions from the TableGen files.
Currently, the property definitions in don't have information about the
path where they will be available. They only contain a `Definition`
which groups properties, so they can be added to
`OptionValueProperties`.
With this PR, I'm adding the path for each property definition. For
example, `symbols.enable-external-lookup` would have `Name =
enable-external-lookup, Path = symbols`. In LLDB itself, we don't need
this path, we only need it for the documentation. To avoid mismatches
between the actual path and the declared one, I added a debug-only check
when a property group is added to a parent
(`OptionValueProperties::AppendProperty`).
The TableGen emitter for the properties now additionally emits
`g_{definition}_properties_def`, which includes both the array of
properties and the expected path. This constant has to be used to
initialize a `OptionValueProperties`.
I couldn't test this for everything (e.g. IntelPT or ProcessKDP), but
the necessary changes are simple: (1) set the `Path` in the TableGen
file, (2) update `initialize` to use `_def`.
Get the shared cache filepath and uuid that the inferior process is
using from debugserver, try to open that shared cache on the lldb host
mac and if the UUID matches, index all of the binaries in that shared
cache. When looking for binaries loaded in the process, get them from
the already-indexed shared cache.
Every time a binary is loaded, PlatformMacOSX may query the shared cache
filepath and uuid from the Process, and pass that to
HostInfo::GetSharedCacheImageInfo() if available (else fall back to the
old HostInfo::GetSharedCacheImageInfo method which only looks at lldb's
own shared cache), to get the file being requested.
ProcessGDBRemote caches the shared cache filepath and uuid from the
inferior, once it has a non-zero UUID. I added a lock for this ivar
specifically, so I don't have 20 threads all asking for the shared cache
information from debugserver and updating the cached answer. If we never
get back a non-zero UUID shared cache reply, we will re-query at every
library loaded notification. debugserver has been providing the shared
cache UUID since 2013, although I only added the shared cache filepath
field last November.
Note that a process will not report its shared cache filepath or uuid at
initial launch. As dyld gets a chance to execute a bit, it will start
returning binaries -- it will be available at the point when libraries
start loading. (it won't be available yet when the binary & dyld are the
only two binaries loaded in the process)
I tested this by disabling lldb's scan of its own shared cache
pre-execution -- only loading the system shared cache when the inferior
process reports that it is using that. I got 6-7 additional testsuite
failures running lldb like that, because no system binaries were loaded
before exeuction start, and the tests assumed they would be.
rdar://148939795
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This reverts commit cc7292056683f592c33055bb6456d509201654ec.
This patch causes two tests to unexpectedly pass:
1. lldb-api.functionalities/tsan/cpp_global_location/TestTsanCPPGlobalLocation.py
2. lldb-api.functionalities/tsan/global_location/TestTsanGlobalLocation.py
Reverting to fix premerge. Not fixing forward so someone who is familiar
with LLDB can take a look and make sure those tests now should pass.
Previously the test was written in a way that may be flaky, fixed with
the following changes.
- The breakpoint are placed on functions and set during the
configuration stage of the protocol.
- Add the rpath to the test binary.
- Check we also hit the breakpoint we set directly using lldb.
This patch adds cross platform (Darwin, Linux, Windows) commands in
`Makefile.rules` which is used to build lldb test targets.
This maps POSIX commands like `mkdir -p` to their Windows equivalent,
which allows to create cross platform `Makefile` for lldb's test
targets. This is currently not needed by any test but might become
useful later as we are working on enabling more lldb Windows tests.
This was originally done in the `swiftlang/llvm-project` fork
(https://github.com/swiftlang/llvm-project/pull/12127)
VS Code and node versions should be synchronized. We use node >= 18.19,
so expected VS Code version is 1.90.0. I checked it using this
[info](https://github.com/ewanharris/vscode-versions).
Fixes#179700
Simple fix, if we are in batch mode, don't go into an interactive
session after checking if there are commands to run.
Testing it is more tricky. I tried a shell test as I thought it would be
simplest. However to be able to FileCheck I had to pipe and the pipe
turns off the prompt because it's non-interactive. The prompt is the
thing that must not be printed.
So I've just spawned lldb as a subprocess. If it doesn't quit quickly
then something is wrong. The timeout is high not because it should
normally take that long, but because sometimes a process will get
stalled for a while and I don't want this to be flaky.
(though in theory it can get stalled for much longer than a minute)
If it does time out, the process will be cleaned up automatically. See
https://docs.python.org/3/library/subprocess.html#subprocess.run
> A timeout may be specified in seconds, it is internally
> passed on to Popen.communicate(). If the timeout expires,
> the child process will be killed and waited for.
Add handling for `STT_TLS` (thread-local storage) symbols in the ELF
symbol parsing code. Previously, TLS symbols like `errno` from glibc
were not recognized because `STT_TLS` was not handled in the symbol type
switch statement.
This treats TLS symbols as data symbols (`eSymbolTypeData`), similar to
`STT_OBJECT`. The actual TLS address resolution is already implemented
in `DynamicLoaderPOSIXDYLD::GetThreadLocalData()` which uses the DWARF
`DW_OP_form_tls_address` opcode to calculate thread-local addresses.
Ran my python script from
https://github.com/llvm/llvm-project/pull/97043 over the repo again and
there were 2 duplicate test-cases that have been introduced since I last
did this.
Also one of the WASM classes had a duplicate method which I just
removed.
When I changed lldb so that the StopInfo's compute their own stop reason
data (before it was oddly done in SBThread::GetStopReasonData...) I
didn't notice that StopInfoMachException was relying on that routine's
default of returning the Value as the 0th exception data, and didn't
actually return its own data.
This fixes that, and makes us report the exception type, and the code
and subcode if the exception has them. I also added a test for this.
rdar://169755672
This ivar was passed to the thread function for the private state thread
- mostly because the equivalent variable was passed in in the original
version of the code. But it was never used, so I didn't notice that the
ivar equivalent wasn't being initialized. I'm going to keep the ivar
because it will be useful when debugging to easily see whether you are
on the main or secondary private state thread.
So in this change, I set m_is_secondary_thread properly in the
constructor, but remove passing it to the thread function since it
wasn't needed there.
Fails on Windows with below error. Probably because we're not
constructing the AST from DWARF correctly for templates. Or perhaps
something to do with the DWARF index.
```
******************** TEST 'lldb-api :: lang/cpp/template-diagnostic-hint/TestTemplateDiagnosticHint.py' FAILED ********************
Script:
--
C:/Users/tcwg/scoop/apps/python/current/python.exe C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/llvm-project/lldb\test\API\dotest.py -u CXXFLAGS -u CFLAGS --env LLVM_LIBS_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./lib --env LLVM_INCLUDE_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/include --env LLVM_TOOLS_DIR=C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin --arch aarch64 --build-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex --lldb-module-cache-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-lldb\lldb-api --clang-module-cache-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/lldb-test-build.noindex/module-cache-clang\lldb-api --executable C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/lldb.exe --compiler C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/clang.exe --dsymutil C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin/dsymutil.exe --make C:/Users/tcwg/scoop/shims/make.exe --llvm-tools-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./bin --lldb-obj-root C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/tools/lldb --lldb-libs-dir C:/Users/tcwg/llvm-worker/lldb-aarch64-windows/build/./lib --cmake-build-type Release --skip-category=watchpoint C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\template-diagnostic-hint -p TestTemplateDiagnosticHint.py
--
Exit Code: 1
Command Output (stdout):
--
lldb version 23.0.0git (https://github.com/llvm/llvm-project.git revision 4afce0cb3de8e9a849b5150471672f4bb6ee591b)
clang revision 4afce0cb3de8e9a849b5150471672f4bb6ee591b
llvm revision 4afce0cb3de8e9a849b5150471672f4bb6ee591b
Skipping the following test categories: watchpoint, libc++, libstdcxx, dwo, dsym, gmodules, debugserver, objc, fork, pexpect
--
Command Output (stderr):
--
UNSUPPORTED: LLDB (C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: test_dsym (TestTemplateDiagnosticHint.TestCase.test_dsym) (test case does not fall in any category of interest for this run)
FAIL: LLDB (C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: test_dwarf (TestTemplateDiagnosticHint.TestCase.test_dwarf)
UNSUPPORTED: LLDB (C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe-aarch64) :: test_dwo (TestTemplateDiagnosticHint.TestCase.test_dwo) (test case does not fall in any category of interest for this run)
======================================================================
FAIL: test_dwarf (TestTemplateDiagnosticHint.TestCase.test_dwarf)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1844, in test_method
return attrvalue(self)
^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\template-diagnostic-hint\TestTemplateDiagnosticHint.py", line 14, in test
self.expect(
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2569, in expect
self.fail(log_msg)
AssertionError: Ran command:
"expression some_template_func<int, long>(5)"
Got output:
note: Ran expression as 'C++14'.
error: <user expression 0>:1:1: use of undeclared identifier 'some_template_func'
1 | some_template_func<int, long>(5)
| ^~~~~~~~~~~~~~~~~~
Expecting sub string: "does not name a template but is followed by template arguments" (was not found)
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
----------------------------------------------------------------------
Ran 3 tests in 0.601s
FAILED (failures=1, skipped=2)
```
When working with a MainLoop, if the file reaches the EOF it will
immediately fire the read handle callback. We cannot readily determine
if the file is at EOF or if the file is pointing to a socket/pipe that
has consumed all the current data in the buffer but the remote end has
not yet hung up. This is causing JSONTransport to continuously fire the
OnRead callback trigging repeated calls to the
`MessageHandler::OnClose`.
Since MainLoop does not perform the actual read, we need to adjust the
behavior of JSONTransport to fully own the read handle.
This change moves the ownership of the `MainLoop::ReadHandleUP` and
additionally own a reference to the `MainLoop` itself to ensure the loop
outlives the JSONTransport object.
This allows us to remove the handle immediately when we detect an EOF /
hang up has occurred.
Before:
```
(lldb) expression some_template_func<int, long>(5)
˄
╰─ error: 'some_template_func' does not name a template but is followed by template arguments
note: Ran expression as 'C++14'.
note: note: non-template declaration found by name lookup
```
After:
```
(lldb) expression some_template_func<int, long>(5)
˄
╰─ error: 'some_template_func' does not name a template but is followed by template arguments
note: Ran expression as 'C++14'.
note: note: non-template declaration found by name lookup
note: Naming template instantiation not yet supported. Template functions can be invoked via their mangled name. E.g., expression _Z3fooIiEvi(5)
```
There isn't a great way to get to the actual function being named (and
its mangled name) since we're just dealing with raw text. So I just
print an example mangled name.
This doesn't work for all template instantiations. E.g.,:
```
(lldb) p f.method<long>(10)
˄ ˄
│ ╰─ error: expected '(' for function-style cast or type construction
╰─ error: no member named 'method' in 'Foo<int>'
note: Ran expression as 'C++14'.
```
This is a consequence of how we construct the AST for template methods.
Once we fix that, this hint will get emitted there too.
Note this will also trigger in cases where no function is being called
(hence I used the defensive phrase "Template functions can be invoked").
rdar://135725807
Currently versions under 13 are EOLed (see [FreeBSD Release
Information](https://www.freebsd.org/releases/)).
FreeBSD 13 will be EOLed by April 30th (see [Supported FreeBSD
releases](https://www.freebsd.org/security/#sup)) while LLVM 23 is
expected to be released in August 25th according to the LLVM calendar.
Thus assumed that minimum supported FreeBSD version is 14.
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
Since ce03a862372a6f36d2fcf80dc80052aa155fcae8 and
427bb1cc1b09ea68b8a13a667810681ba4074f6b, mips64 support for POSIX is
orphaned. Remove any POSIX_mips64 code and other code we missed in those
commits.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
The end line entry calculated from the instruction's end address is
unreliable and could produce incorrect source ranges. especially if the
instruction spans multiple lines.
We can end in situations where the current end line is the next start
line and the source line is show to the client twice. confusing users
what maps to what.
| With EndLine |
| :------------: |
| <img width="892" height="486" alt="Screenshot 2026-02-05 at 21 37 08"
src="https://github.com/user-attachments/assets/f2fef592-5754-4168-bf93-2baba4742c5d"
/> |
| Without Endline |
| :---------------: |
| <img width="892" height="486" alt="Screenshot 2026-02-05 at 21 59 29"
src="https://github.com/user-attachments/assets/538dd462-9c7f-4483-804c-65fd83b5f2f2"
/>|
Or the endline is smaller than the startline.
```json
{
"address": "0x5555555557B4",
"column": 3,
"endLine": 2,
"instruction": "add rsp, 0x20 ",
"instructionBytes": "48 83 c4 20",
"line": 17,
"location": {
"name": "test.cpp",
"path": "/buildbot/test_process/test.cpp"
}
},
```
The functionality was removed in
d3173f4ab61c17337908eb7df3f1c515ddcd428c after being broken for a long
time.
There's a small risk someone is still passing the option, but I think
it's time to remove it and they can fix their scripts.
Taking advantage of a few new SPI in macOS 26.4 libdyld, it is possible
for lldb to load binaries out of a shared cache binary blob, instead of
needing discrete files on disk. lldb has had one special case where it
has done this for years -- if the debugee process and lldb itself are
using the same shared cache, it could create ObjectFiles based on its
own memory contents. This new method requires only the shared cache on
disk, not depending on it being mapped into lldb's address space
already.
In HostInfoMacOSX.mm, we create an array of binaries in lldb's shared
cache, by one of two methods depending on the availability of SPI/SDKs.
This PR adds a new third method for loading lldb's shared cache off disk
as a proof of concept. It will prefer this new method when the needed
SPI are available at runtime. There is also a user setting to disable
this new method in case we uncover a problem as it is deployed.
I did change the internal store of the shared cache files from a single
array, to being organized by shared cache UUIDs, so we can have multiple
shared caches indexed in the future.
In HostInfoBase.h's SharedCacheImageInfo class, you can now create an
ImageInfo with a DataExtractorSP or a void* baton. I added GetUUID and
GetExtractor methods, and the latter will use the libdyld SPI to map the
segments for a specific binary into lldb's memory and return a
DataExtractorSP.
The setting is currently called symbols.shared-cache-binary-loading.
In DynamicLoaderDarwin::FindTargetModuleForImageInfo there was an
ordering mistake where we would always consult the HostInfoMacOSX.mm
shared cache provider, instead of checking lldb's own global module
cache first when looking for a binary, resulting in creating a new
Module repeatedly for shared cache binaries with the new method, parsing
the symbol table repeatedly. I fixed the ordering so we look at existing
Modules before we check the shared cache for one.
In ObjectFileMachOTest, it tests a TEXT and a DATA symbol, checking that
the contents of the function/data object match the bytes we got from the
shared cache. The test was using a DATA_DIRTY symbol, which was fine
when using lldb's own shared cache memory, but when we worked on the
shared cache binary on-disk directly, we were seeing different values
for the bytes because of relocations in there. I changed this to a
constant DATA symbol.
rdar://148939795
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Co-authored-by: Alex Langford <nirvashtzero@gmail.com>
This test was already disabled going from windows -> linux because it
was timing out there.
The PR: https://github.com/llvm/llvm-project/pull/179799 seems to have
exacerbated whatever this stall was, and now we're seeing it when
debugging from a linux host to a remote linux as well.
The native local host tests works correctly on all the bots that we
have, however. So I'm disabling the remote test till we can figure out
why this is problematic.
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
We have a problem when some code on the private state thread needs to
run an expression. The private state thread is the one that fetches
"raw" events from the Process Plugin and decides how to handle them. But
if the private state thread needs to fetch the processed events to drive
running an expression, it can't also be the thread processing the raw
events.
We solve this by swapping in a modal private state thread just to handle
the events from the expression evaluation. That worked until you could
cause the expression evaluation to happen from Python, because then it
wasn't just the fetching of events that matter, but also the state of
the process and the state of the runlocks. The modal private state
thread is really a modal version of the thread and its associated state.
This patch gathers all the relevant control parameters into a structure
which we can swap in and out when needed.
It also adds a test using the new "was_hit" breakpoint resolver
affordance, which, since it acts as an asynchronous breakpoint callback,
gets run on the private state thread, showing that with the change we
can call expressions in the `was_hit` callback without problems.
We want to reload the call stack whenever the frame providers are
updated. To do so, we now emit a `eBroadcastBitStackChanged` on all
threads whenever any changes to the frame providers take place.
I found this very useful while iterating on a frame provider in
lldb-dap. So far, the new frame provider only took effect after
continuing execution. Now the backtrace in VS-Code gets refreshed
immediately upon running `target frame-provider add`.
