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.
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.
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
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)
```
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
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.
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`.
Improving stability of the TestDAP_launch_commands test.
When collecting output for verifying 'stopCommands' we were not waiting
for the output to finish, which could cause issues if the test is
running very fast.
EvaluateRequests handler now uses the target's context if no valid
frameId is provided, enabling evaluation of
global variables without requiring a valid stack frame.
In repl mode it now uses the last `successful` variable or command
expression, if the provided user's expression is empty.
Try to evaluate the expression if the evaluation context is `Unknown`
We are waiting for both stopped event at once.
We may not get both events within the (0.25 seconds) time interval to
fetch more events. Retry with the `DEFAULT TIMEOUT` if we got one of the
event.
Increase the `EVENT_QUIET_PERIOD`'s value for ASAN mode
Fixes#179648
Depends on:
* https://github.com/llvm/llvm-project/pull/177921
* https://github.com/llvm/llvm-project/pull/177926
(only last commit is relevant for this review)
This patch emits a workaround suggestion (in the form of a `note:`
diagnostic) when an expression fails due to trying to mutate state/call
functions with CV-qualifiers that are disallowed by C++ language rules
based on the context the expression is evaluated in. The note looks as
follows:
```
(lldb) expr next.method()
˄
╰─ error: 'this' argument to member function 'method' has type 'const Bar', but function is not marked const
note: Ran expression as 'C++14'.
note: note: 'method' declared here
note: Possibly trying to mutate object in a const context. Try running the expression with: expression --c++-ignore-context-qualifiers -- <your expression>
```
We stopped marking `__lldb_expr` with the function qualifiers of the
method LLDB is stopped in ever since
`8bdcd522510f923185cdfaec66c4a78d0a0d38c0`. The assumption was that it
wasn't ever required for correctness (i.e., LLDB should just always
pretend it's in a mutable context). But since function qualifiers affect
overloading in C++, this assumption can lead to unexpected expression
evaluator behaviour. E.g., if a function is overloaded on qualifiers
(`const` vs. `non-const`), the expression evaluator would currently
always call the non-CV qualified overload.
This patch adds function qualifiers to `$__lldb_class::$__lldb_expr`
that resemble the qualifiers of the method that we're stopped in.
However, mutating variables or calling arbitrary member functions from
CV-qualified methods can be useful/is something users already may be
used to. To provide users with the ability to ignore the CV-qualifiers
of the current context, we will provide an expression evaluator flag
that switches this off in a follow-up patch.
The motivation here is that we don't want to pollute the SBAPI with
getters/setters for expression evaluation options that only apply to a
single language. The ultimate goal would be to have plugins register
additional options to the `expression` command when the plugin is
loaded. This patch only provides the minimal `SBExpressionOptions`
interface to set an option with an arbitrary name, which the language
plugin knows how to interpret. The underlying options dictionary is an
`StructuredData::Dictionary` so we can map strings to values of any
type. But the SBAPI just exposes setting a boolean value. Future
overloads of `SetLanguageOption` can provide setters for more types.
The boolean setter/getter will be used for the C++-specific option being
introduced in: https://github.com/llvm/llvm-project/pull/177926
This patch re-implements `TypeSystemClang::IsFloatingPointType` by
forwarding it to `clang::Type::isFloatingType`. The main difference is
that the latter returns false for float vector types. The motovation
here (apart from implementation simplicity) is that this is currently a
foot-gun because most callsites probably don't consider treating float
vector types. Callers should test for vectors explicitly using
`IsVectorType` (or use `GetTypeInfo`).
This patch makes all the callers of `IsFloatingPointType` now check
`GetTypeInfo() & eTypeIsFloat`. This is set for float vector types too,
so behaviour doesn't change.
To make sure we audit all the call-sites in `ValueObject.cpp`, I added a
helper `HasFloatRepresentation` (named after the
`clang::Type::hasFloatingRepresentation` API), which does the
`GetTypeInfo` check, and added a FIXME to it.
Updates the 'stopped' event to use structure types.
Additionally, I adjusted the description to include the full
`GetStopDescription` that can have more details.
When a user holds an SBFrame reference and then triggers an inferior
function
call (via expression evaluation or GetExtendedBacktraceThread),
variables in
that frame become inaccessible with "register fp is not available"
errors.
This happens because inferior function calls execute through
ThreadPlanCallFunction, which calls ClearStackFrames() during cleanup to
invalidate the unwinder state. ExecutionContextRef objects in the old
SBFrames
were tracking StackFrameLists via weak_ptr, which became stale when
ClearStackFrames() created new instances.
The fix uses stable StackFrameList identifiers that persist across
ClearStackFrames():
- ID = 0: Normal unwinder frames (constant across all instances)
- ID = sequential counter: Scripted frame provider instances
ExecutionContextRef now stores the frame list ID instead of a weak_ptr,
allowing
it to resolve to the current StackFrameList with fresh unwinder state
after an
inferior function call completes.
The Thread object preserves the provider chain configuration
(m_provider_chain_ids and m_next_provider_id) across ClearStackFrames()
so
that recreated StackFrameLists get the same IDs. When providers need to
be
recreated, GetStackFrameList() rebuilds them from the persisted
configuration.
This commit also fixes a deadlock when Python scripted frame providers
call
back into LLDB during frame fetching. The m_list_mutex is now released
before
calling GetFrameAtIndex() on the Python scripted frame provider to
prevent
same-thread deadlock. A dedicated m_unwinder_frames_sp member ensures
GetFrameListByIdentifier(0) always returns the current unwinder frames,
and
proper cleanup in DestroyThread() and ClearStackFrames() to prevent
modules
from lingering after a Thread (and its StackFrameLists) gets destroyed.
Added test validates that variables remain accessible after
GetExtendedBacktraceThread triggers an inferior function call to fetch
libdispatch Queue Info.
rdar://167027676
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This reapplies #175292 with the fixed test. The original test used
integer types with different bit widths on different platforms.
----- Original message:
This allows expressions that use these conversions to be executed when
JIT is not available.
This restores files that were unintentionally added to commit
21a74f527839b5b8dd882e62a25093d980c79078, 'Revert "[lldb] Add FP
conversion instructions to IR interpreter (#175292)"'
Closes#119784
Probably closes#147105 as well, but I couldn't test due to #156473:
This PR fixes two bugs:
1. It generates unique variable reference IDs per suspended debuggee
state.
2. It stores all created variables in a stopped state instead of
dropping variables in unselected scopes. So it can properly handle all
scope/variable requests
It does this by storing all variables in their respective scopes and
using that mapping in request handlers that relied on the old mapping.
It dynamically creates new variable/scope IDs instead of resetting IDs
whenever a new scope is created.
I also removed some unused code as well.
---------
Co-authored-by: Med Ismail Bennani <ismail@bennani.ma>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Co-authored-by: Ebuka Ezike <yerimyah1@gmail.com>
When setting the enabled state of a breakpoint name via the API, the
change was not being propagated to breakpoints using that name.
This was inconsistent with the CLI behaviour where `breakpoint name
configure --enable/--disable` correctly updates all associated
breakpoints.
This patch adds plumbing to support the implementations of StackFrame::Get{*}Variable{*} on ScriptedFrame. The major pieces required are:
- A modification to ScriptedFrameInterface, so that we can actually call the python methods.
- A corresponding update to the python implementation to call the python methods.
- An implementation in ScriptedFrame that can get the variable list on construction inside ScriptedFrame::Create, and pass that list into the ScriptedFrame so it can get those values on request.
There is a major caveat, which is that if the values from the python side don't have variables attached, right now, they won't be passed into the scripted frame to be stored in the variable list. Future discussions around adding support for 'extended variables' when printing frame variables may create a reason to change the VariableListSP into a ValueObjectListSP, and generate the VariableListSP on the fly, but that should be addressed at a later time.
This patch also adds tests to the frame provider test suite to prove these changes all plumb together correctly.
Related radar: rdar://165708771
## Description
Contribution to this topic [Rich Disassembler for
LLDB](https://discourse.llvm.org/t/rich-disassembler-for-lldb/76952),
this part.
```
The rich disassembler output should be exposed as structured data and made available through LLDB’s scripting API so more tooling could be built on top of this
```
----
This pr replaces #174847
As was suggested in [this
comment](https://github.com/llvm/llvm-project/pull/174847#issuecomment-3757015552),
implement access to variable annotations from `SBInstruction` class
itself.
Notes:
- ✅ did run black formatter on the python file;
## Testing
Run test with
```sh
./build/bin/lldb-dotest -v -p TestVariableAnnotationsDisassembler.py lldb/test/API/functionalities/disassembler-variables
```
all tests (9 existing + 1 newly added) are passing
<details>
<summary>screenshot 2026-01-23</summary>
build from the latest commit 08f00730b5768a8e3f7039d810084fabaaa24470
<img width="1506" height="562" alt="image"
src="https://github.com/user-attachments/assets/69516353-3432-47df-ae45-c40b51ec14c4"
/>
</details>
<details>
<summary>screenshot 2026-01-29</summary>
build from the latest commit f48a1a2c10f96a457ca6844be2ccc9406d3d57a0
<img width="1232" height="740" alt="image"
src="https://github.com/user-attachments/assets/9d104ce6-36c3-430b-98fe-f028f83a6b6d"
/>
</details>
---------
Signed-off-by: Nikita B <n2h9z4@gmail.com>
This patch adds the coreFilePath, if applicable, to the target
statistics for LLDB. My primary motivation here is sanity check user
reports when they say I had an issue with a specific corefile and then
validating it was in fact that specifies corefile, as right now there is
no guaruntee the filename and the process/target name will be the same.
non-darwin platforms may have incorrect stop information location
heuristics. Enable assertion once UBSan stopInfo heuristic is updated.
I hit this locally, I don't see it hitting any CI bot but should, Mostly
likely the CI linux bots may not have `compiler_rt` run time enabled.
see
https://github.com/llvm/llvm-project/pull/177964#discussion_r2732271531
the ubsan decorator previously assumes the platform is macOS.
macOS has an extra underscore in symbols names match two or more.
uses the llvm-nm that is built instead of the system's nm.
These test the existing behaviour before I work on #177570.
I chose "breakpoint set" because it has options with ANSI underlines
in the description.
The tests cover no ANSI (use-colour off) and with ANSI (use-color on).
The latter is where we have problems right now.
This patch enables ELF core files to be loaded and still show
executables and shared libraries. Functionality includes:
- Load executable and shared libraries from memory if ELF headers are
available
- Create placeholder for missing shared libraries and executable.
Previously you just wouldn't get anything in the "image list" if no
executable was provided.
In the exceptionInfo request I've added additional information for crash
data, instrumentation data and more detailed exception data.
For example, when UBSan is enabled, you now see additional information
in the exception stack trace about the detected issue:
<img width="1728" height="538" alt="Screenshot 2026-01-15 at 3 05 08 PM"
src="https://github.com/user-attachments/assets/b761af2c-90ac-4eb7-9926-3ab133f1b753"
/>
I included a new test for stopping at `lldb::eStopReasonInstrumentation`
and ensuring we have additional information reported.
---------
Co-authored-by: Ebuka Ezike <yerimyah1@gmail.com>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Investigating some of the biggest slow downs during tests, the biggest
offender is 'wait_for_stopped' requiring a negative assertion around the
'stopped' event.
It currently waits for a negative predicate to fail before continuing.
This means it must wait for the full DEFAULT_TIMEOUT (50s) before the
test is allowed to continue.
To mitigate this, I added a new `collect_events` helper that will wait
for the given event to occur with the DEFAULT_TIMEOUT, then wait for a
quiet period (0.25s) before returning.
This greatly reduces the amount of idle waiting during tests.
Additionally, looking a the performance of individual test files,
`TestDAP_launch` is the slowest overall test. No individual test is that
slow, but the fact it has so many tests in the same file results in the
test harness waiting for that one file to finish.
To mitigate that, I split `TestDAP_launch` into individual test files
that run in parallel, reducing the runtime locally from over 2mins to
~5s.
Originally added in a81bd7f1014f316b42bf7274f76a340b833e663b /
https://reviews.llvm.org/D35525, this test either was not strict enough,
or lldb's behaviour has drifted since.
I think the intention was to check exactly when the output of "help
format" would wrap. Which should happen when we have printed up to the
terminal width, minus a few characters because we walk backwards to the
closest whitespace point to break at (so we don't split a word).
I've updated the test to check the exact outputs and cover printing one
line and two instances where we need to split different amounts onto a
second line.
Python's internal stderr may differ from sys.stderr.
When Python writes errors, it uses its internal stderr rather than the
overwritten sys.stderr.
This may not be the same file/handle
Fix the test to explicitly write to the specified stderr.
# Summary
This patch ensures lldb will not try to read from a PseudoConsole if it
has not been opened.
# Original issue
https://github.com/llvm/llvm-project/pull/168729 introduces support for
the Windows ConPTY in `lldb-dap`. This caused a regression in `lldb`
which was not caught by our tests:
https://github.com/llvm/llvm-project/issues/175652.
This patch fixes https://github.com/llvm/llvm-project/issues/175652.
`lldb_private::ProcessLauncherWindows::LaunchProcess` connects the
debuggee to a PseudoConsole only if:
```cpp
if (hPC != INVALID_HANDLE_VALUE && launch_info.GetNumFileActions() == 0 && launch_info.GetFlags().Test(lldb::eLaunchFlagLaunchInTTY))
```
lldb needs to check the same condition in
`lldb_private::PlatformWindows::DebugProcess` to ensure that it does not
read from a PseudoConsole which has not been opened.
# Side effect
This patch reverts what https://github.com/llvm/llvm-project/pull/168729
did by adding ConPTY support.
https://github.com/llvm/llvm-project/pull/175812 is the proper fix,
however it's causing tests failures which we can't reliably reproduce at
desk. Given https://github.com/llvm/llvm-project/pull/168729 breaks
`22.x` lldb, it's better to revert the change ahead of the release of
`22.x` rather than pushing for the proper fix.
"memory region" can be given an address once and then when repeated,
it will try to find a region just beyond the last one it printed.
This continues until the end of the address space.
Then it gives you an error showing the usage, which is odd because
you just saw a bunch of "memory region" with no options work.
So I've improved the error a bit to imply its to do with the repetition.
Then described the repeating behaviour in the help text.
