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
This patch fixes the problem, when after a `setVariable` request
pointers and references to the variable are not updated. VSCode doesn't
send a `variables` request after a `setVariable` request, so we should
trigger it explicitly via`invalidated` event .Also, updated
`writeMemory` request in similar way.
See
https://github.com/llvm/llvm-project/pull/156803#issuecomment-3275911510
for full context.
Summary:
* In https://github.com/llvm/llvm-project/pull/156803, we see a builtbot
failure for `TestDAP_server.py` on Debian. Note that macOS and other
Linux distributions (like CentOS, or whatever Linux the [required
buildbot](https://github.com/llvm/llvm-project/actions/runs/17594257911/job/49982560193#logs)
uses) seem to pass the tests.
* In the 3 newly added tests, the most complex test case passed, while
the other easier ones failed.
```
PASS: LLDB (/home/worker/2.0.1/lldb-x86_64-debian/build/bin/clang-x86_64) :: test_connection_timeout_multiple_sessions (TestDAP_server.TestDAP_server.test_connection_timeout_multiple_sessions)
FAIL: LLDB (/home/worker/2.0.1/lldb-x86_64-debian/build/bin/clang-x86_64) :: test_connection_timeout_long_debug_session (TestDAP_server.TestDAP_server.test_connection_timeout_long_debug_session)
FAIL: LLDB (/home/worker/2.0.1/lldb-x86_64-debian/build/bin/clang-x86_64) :: test_connection_timeout_at_server_start (TestDAP_server.TestDAP_server.test_connection_timeout_at_server_start)
```
* The error is that `process.wait(timeout)` timed out during the
teardown of the tests.
* The above suggests that maybe the root cause is that the timeout is
set too strictly (and that maybe the server termination on Debian is
slower than the other Linux distribution for some reason).
* This patch loosens that timeout from 2s to 5s. Let's see if this
works.
* FWIW, I cannot verify the root cause, because I don't have a Debian
machine.
# Usage
This is an optional new command line option to use with `--connection`.
```
--connection-timeout <timeout> When using --connection, the number of seconds to
wait for new connections after the server has started and after all clients
have disconnected. Each new connection will reset the timeout. When the
timeout is reached, the server will be closed and the process will exit.
Not specifying this argument or specifying non-positive values will cause
the server to wait for new connections indefinitely.
```
A corresponding extension setting `Connection Timeout` is added to the
`lldb-dap` VS Code extension.
# Benefits
Automatic release of resources when lldb-dap is no longer being used
(e.g. release memory used by module cache).
# Test
See PR.
Flakey on our Windows on Arm bot:
https://lab.llvm.org/buildbot/#/builders/141/builds/11378
======================================================================
ERROR: test_supported_capability_other_archs (TestDAP_stepInTargets.TestDAP_stepInTargets.test_supported_capability_other_archs)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2090, in tearDown
Base.tearDown(self)
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1105, in tearDown
hook() # try the plain call and hope it works
^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\lldbdap_testcase.py", line 521, in cleanup
self.dap_server.terminate()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\dap_server.py", line 1602, in terminate
raise DebugAdapterProcessError(process.returncode)
dap_server.DebugAdapterProcessError: lldb-dap returned non-zero exit status 1.
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
----------------------------------------------------------------------
See #137660
Flakey on our Windows on Arm bot:
https://lab.llvm.org/buildbot/#/builders/141/builds/11377
ERROR: test_step_over_inlined_function (TestDAP_step.TestDAP_step.test_step_over_inlined_function)
Test stepping over when the program counter is in another file.
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2090, in tearDown
Base.tearDown(self)
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1105, in tearDown
hook() # try the plain call and hope it works
^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\lldbdap_testcase.py", line 521, in cleanup
self.dap_server.terminate()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\dap_server.py", line 1602, in terminate
raise DebugAdapterProcessError(process.returncode)
dap_server.DebugAdapterProcessError: lldb-dap returned non-zero exit status 1.
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
----------------------------------------------------------------------
See #137660.
Has been flakey on our Windows on Arm bot:
https://lab.llvm.org/buildbot/#/builders/141/builds/11373
```
======================================================================
ERROR: test_stopOnEntry (TestDAP_launch.TestDAP_launch.test_stopOnEntry)
Tests the default launch of a simple program that stops at the
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2090, in tearDown
Base.tearDown(self)
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1105, in tearDown
hook() # try the plain call and hope it works
^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\lldbdap_testcase.py", line 521, in cleanup
self.dap_server.terminate()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\dap_server.py", line 1602, in terminate
raise DebugAdapterProcessError(process.returncode)
dap_server.DebugAdapterProcessError: lldb-dap returned non-zero exit status 1.
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
----------------------------------------------------------------------
```
See #137660
TLDR
----------
This PR adds `--no-lldbinit` as a new CLI flag to the `lldb-dap`
Motivation
-----------
Rcently Users reported being unable to control `.lldbinit` file sourcing
when debugging through VS Code.
https://github.com/llvm/llvm-project/issues/155802.
VS Code extensions cannot easily inject custom parameters into the DAP
initialize request. Adding `--no-lldbinit` as a CLI flag solves this
problem by allowing the decision to skip `.lldbinit` files to be made at
debugger startup, before any initialization requests are processed.
VS Code extensions can control this behavior by specifying the flag
through `debugAdapterArgs` or similar mechanisms in launch
configurations.
```
{
"type": <extension-type>,
"request": "launch",
"name": "Debug with --no-lldbinit",
"program": "${workspaceFolder}/your-program",
"debugAdapterArgs": ["--no-lldbinit"]
}
```
Summary
----------
This PR introduces a new command-line flag `--no-lldbinit` (with alias
`-x`) to `lldb-dap`. The flag prevents automatic parsing of `.lldbinit`
files during debugger initialization, giving users control over whether
their LLDB initialization scripts are loaded.
### Key Changes:
1. **CLI Option Definition** (`Options.td`): Added the `--no-lldbinit`
flag with `-x` alias
2. **Core Implementation** (`DAP.cpp`): Added support for storing and
using the no-lldbinit flag
3. **Initialization Handler** (`InitializeRequestHandler.cpp`): Modified
to respect the flag during debugger initialization
4. **Main Tool** (`lldb-dap.cpp`): Added argument parsing for the new
flag
5. **Test Infrastructure** (`dap_server.py & lldbdap_testcase.py`):
Enhanced test framework to support additional arguments
Test Plan
---------
### New Test Coverage (`TestDAP_launch.py`)
**Test Method:** `test_no_lldbinit_flag()`
**Test Strategy:**
1. **Setup**: Creates a temporary `.lldbinit` file with specific
settings that would normally be loaded
2. **Execution**: Launches lldb-dap with the `--no-lldbinit` flag
3. **Verification**: Confirms that the settings from `.lldbinit` are NOT
applied, proving the flag works correctly
**Test Environment:**
* Uses a temporary home directory with a custom `.lldbinit` file
* Sets specific LLDB settings (`stop-disassembly-display never`,
`target.x86-disassembly-flavor intel`)
* Launches debug adapter with `--no-lldbinit` flag via `additional_args`
parameter
**Validation Approach:**
* Executes `settings show stop-disassembly-display` command during
initialization
* Verifies the output does NOT contain "never" (which would indicate
`.lldbinit` was sourced)
* Confirms that initialization commands are still executed properly
### Testing Infrastructure Enhancements
**File Modifications:**
* `dap_server.py`: Enhanced to accept `additional_args` parameter for
passing extra CLI flags
* `lldbdap_testcase.py`: Updated `build_and_create_debug_adapter()`
method to support additional arguments and environment variables
### Unit Test Integration
**Unit Test Updates** (`DAPTest.cpp`):
* Added initialization of the new flag in test setup to ensure
consistent test behavior
**Test Run**
<img width="1759" height="1373" alt="Screenshot 2025-08-29 at 5 56
18 PM"
src="https://github.com/user-attachments/assets/769b319a-5009-4ade-aff8-c5f548b38123"
/>
---------
Co-authored-by: Piyush Jaiswal <piyushjais@meta.com>
It is flakey lately on our Windows on Arm bot:
https://lab.llvm.org/buildbot/#/builders/141/builds/11169
======================================================================
ERROR: test_startDebugging (TestDAP_startDebugging.TestDAP_startDebugging.test_startDebugging)
Tests the "startDebugging" reverse request. It makes sure that the IDE can
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2067, in tearDown
Base.tearDown(self)
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1105, in tearDown
hook() # try the plain call and hope it works
^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\lldbdap_testcase.py", line 518, in cleanup
self.dap_server.terminate()
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\tools\lldb-dap\dap_server.py", line 1593, in terminate
raise DebugAdapterProcessError(process.returncode)
dap_server.DebugAdapterProcessError: lldb-dap returned non-zero exit status 1.
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
----------------------------------------------------------------------
See https://github.com/llvm/llvm-project/issues/137660.
I am aware that I am disabling these tests with little thought, and I would
like to be more careful with it but I don't have the knowledge to really
debug these issues.
Having buildbot results we can properly triage is more important to
me personally than finding whatever the underlying issue is. I'm sure
DAP experts will figure it out eventually.
Re-land the symbol table feature in lldb-dap after it was
[reverted](2b8e806942)
because of a crash in the `aarch64` tests, which was caused by
dereferencing `SBSymbol::GetName` which might return `nullptr` for an
invalid symbol.
This patch reapplies the original commits and adds the missing null
check.
Also adding `skipIfWindows` for the module symbols tests, since LLDB
doesn't recognize the symbols from a.out there.
Originally commited in 362b9d78b4ee9107da2b5e90b3764b0f0fa610fe and then
reverted in cb63b75e32a415c9bfc298ed7fdcd67e8d9de54c.
This re-lands a subset of the changes to
dap_server.py/DebugCommunication and addresses the python3.10
compatibility issue.
This includes less type annotations since those were the reason for the
failures on that specific version of python.
I've done additional testing on python3.8, python3.10 and python3.13 to
further validate these changes.
This test has been flakey on our bot:
https://lab.llvm.org/buildbot/#/builders/18/builds/20410
```
======================================================================
FAIL: test_extra_launch_commands (TestDAP_launch.TestDAP_launch)
Tests the "launchCommands" with extra launching settings
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/test/API/tools/lldb-dap/launch/TestDAP_launch.py", line 482, in test_extra_launch_commands
self.verify_commands("stopCommands", output, stopCommands)
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py", line 228, in verify_commands
self.assertTrue(
AssertionError: False is not true : verify 'frame variable' found in console output for 'stopCommands'
Config=arm-/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/bin/clang
----------------------------------------------------------------------
```
Likely a timing issue waiting for the command output on a slower
machine.
General tracking issue - https://github.com/llvm/llvm-project/issues/137660
Reapply "[lldb] Update JSONTransport to use MainLoop for reading."
(#152155)
This reverts commit cd40281685f642ad879e33f3fda8d1faa136ebf4.
This also includes some updates to try to address the platforms with
failing tests.
I updated the JSONTransport and tests to use std::function instead of
llvm:unique_function. I think the tests were failing due to the
unique_function not being moved correctly in the loop on some platforms.
This is a major change on how we represent nested name qualifications in
the AST.
* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.
This patch offers a great performance benefit.
It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.
This has great results on compile-time-tracker as well:
This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.
It has some other miscelaneous drive-by fixes.
About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.
There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.
How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.
The rest and bulk of the changes are mostly consequences of the changes
in API.
PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.
Fixes#136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757
Resolves#141955
- Adds data to breakpoints `Source` object, in order for assembly
breakpoints, which rely on a temporary `sourceReference` value, to be
able to resolve in future sessions like normal path+line breakpoints
- Adds optional `instructions_offset` parameter to `BreakpointResolver`
This has been very flakey lately:
======================================================================
ERROR: test_writeMemory (TestDAP_memory.TestDAP_memory)
Tests the 'writeMemory' request
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/test/API/tools/lldb-dap/memory/TestDAP_memory.py", line 202, in test_writeMemory
mem_response = self.writeMemory(
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py", line 545, in writeMemory
response = self.dap_server.request_writeMemory(
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py", line 850, in request_writeMemory
return self.send_recv(command_dict)
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py", line 403, in send_recv
raise ValueError(desc)
ValueError: no response for "writeMemory"
Config=arm-/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/bin/clang
======================================================================
ERROR: test_writeMemory (TestDAP_memory.TestDAP_memory)
Tests the 'writeMemory' request
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2067, in tearDown
Base.tearDown(self)
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1105, in tearDown
hook() # try the plain call and hope it works
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py", line 486, in cleanup
self.dap_server.request_disconnect(terminateDebuggee=True)
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py", line 799, in request_disconnect
return self.send_recv(command_dict)
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py", line 397, in send_recv
self.send_packet(command)
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py", line 349, in send_packet
self.send.flush()
BrokenPipeError: [Errno 32] Broken pipe
Config=arm-/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/bin/clang
----------------------------------------------------------------------
General tracking issue - https://github.com/llvm/llvm-project/issues/137660
This updates JSONTransport to use a MainLoop for reading messages.
This also allows us to read in larger chunks than we did previously.
With the event driven reading operations we can read in chunks and store
the contents in an internal buffer. Separately we can parse the buffer
and split the contents up into messages.
Our previous version approach would read a byte at a time, which is less
efficient.
Currently, the "stopped" event returned when a breakpoint is hit will
always return only the ID of first breakpoint returned from
`GetStopReasonDataAtIndex`. This is slightly different from the
behaviour in `lldb`, where multiple breakpoints can exist at a single
instruction address and all are returned as part of the stop reason when
that address is hit.
This patch allows all multiple hit breakpoints to be returned in the
"stopped" event, both in the hitBreakpointIds field and in the
description, using the same formatting as lldb e.g. "breakpoint 1.1
2.1". I'm not aware of any effect this will have on debugger plugins; as
far as I can tell, it makes no difference within the VS Code UI - this
just fixes a minor issue encountered while writing an `lldb-dap` backend
for Dexter.
This updates all the existing memory reference fields to use
`lldb::addr_t` directly.
A few places were using `std::string` and decoding the value in the
request handler and other places had unique ways of parsing addresses.
This unifies all of these references with the `DecodeMemoryReference`
helper in JSONUtils.h.
Additionally, for the types I updated, I tried to simplify the POD types
some and moved default values out of RequestHandlers and into the
protocol POD types.
This adds new protocol types for the 'variables' request.
While implementing this, I removed the '$__lldb_extension' field we
returned on the 'variables' request, since I think all the data can be
retrieved from other DAP requests.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
When there is a function that is inlined at the current program counter.
If you get the current `line_entry` using the program counter's address
it will point to the location of the inline function that may be in
another file. (this is in implicit step-in and should not happen what
step over is called).
Use the current frame to get the `line_entry`
This patch fixes a possible data race between main and event handler
threads. Terminated event can be sent from `Disconnect` function or
event handler. Consequently, there are some possible sequences of
events. We must check events twice, because without getting an exited
event, `exit_status` will be None. But, we don't know the order of
events (for example, we can get terminated event before exited event),
so we check events by filter. It is correct, because terminated event
will be sent only once (guarded by `llvm::call_once`).
This patch moved from
[145010](https://github.com/llvm/llvm-project/pull/145010) and based on
idea from this
[comment](https://github.com/llvm/llvm-project/pull/145010#discussion_r2159637210).
.. from the guts of GDBRemoteCommunication to ~top level.
This is motivated by #131519 and by the fact that's impossible to guess
whether the author of a symlink intended it to be a "convenience
shortcut" -- meaning it should be resolved before looking for related
files; or an "implementation detail" -- meaning the related files should
be located near the symlink itself.
This debate is particularly ridiculous when it comes to lldb-server
running in platform mode, because it also functions as a debug server,
so what we really just need to do is to pass /proc/self/exe in a
platform-independent manner.
Moving the location logic higher up achieves that as lldb-platform (on
non-macos) can pass `HostInfo::GetProgramFileSpec`, while liblldb can
use the existing complex logic (which only worked on liblldb anyway as
lldb-platform doesn't have a lldb_private::Platform instance).
Another benefit of this patch is a reduction in dependency from
GDBRemoteCommunication to the rest of liblldb (achieved by avoiding the
Platform dependency).
The
[protocol](https://microsoft.github.io/debug-adapter-protocol//specification.html#Types_Source)
expects that `sourceReference` be less than `(2^31)-1`, but we currently
represent memory address as source reference, this can be truncated
either when sending through json or by the client. Instead, generate new
source references based on the memory address.
Make the `ResolveSource` function return an optional source.
# Benefit
This patch fixes:
1. After `platform select ios-simulator`, `platform process list` will
now print processes which are running in the iOS simulator. Previously,
no process will be listed.
2. After `platform select ios-simulator`, `platform attach --name
<name>` will succeed. Previously, it will error out saying no process is
found.
# Several bugs that is being fixed
1. During the process listing, add `aarch64` to the list of CPU types
for which iOS simulators are checked for.
2. Given a candidate process, when checking for simulators, the original
code will find the desired environment variable (`SIMULATOR_UDID`) and
set the OS to iOS, but then the immediate next environment variable will
set it back to macOS.
3. For processes running on simulator, set the triple's `Environment` to
`Simulator`, so that such processes can pass the filtering [in this
line](https://fburl.com/8nivnrjx). The original code leave it as the
default `UnknownEnvironment`.
# Manual test
**With this patch:**
```
royshi-mac-home ~/public_llvm/build % bin/lldb
(lldb) platform select ios-simulator
(lldb) platform process list
240 matching processes were found on "ios-simulator"
PID PARENT USER TRIPLE NAME
====== ====== ========== ============================== ============================
40511 28844 royshi arm64-apple-ios-simulator FocusPlayground // my toy iOS app running on simulator
... // omit
28844 1 royshi arm64-apple-ios-simulator launchd_sim
(lldb) process attach --name FocusPlayground
Process 40511 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
frame #0: 0x0000000104e3cb70 libsystem_kernel.dylib`mach_msg2_trap + 8
libsystem_kernel.dylib`mach_msg2_trap:
-> 0x104e3cb70 <+8>: ret
... // omit
```
**Without this patch:**
```
$ bin/lldb
(lldb) platform select ios-simulator
(lldb) platform process list
error: no processes were found on the "ios-simulator" platform
(lldb) process attach --name FocusPlayground
error: attach failed: could not find a process named FocusPlayground
```
# Unittest
See PR.
```
Traceback (most recent call last):
File "/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/dotest.py", line 8, in <module>
lldbsuite.test.run_suite()
File "/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py", line 1064, in run_suite
visit("Test", dirpath, filenames)
File "/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py", line 706, in visit
visit_file(dir, name)
File "/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/packages/Python/lldbsuite/test/dotest.py", line 649, in visit_file
module = __import__(base)
^^^^^^^^^^^^^^^^
File "/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/tools/lldb-dap/runInTerminal/TestDAP_runInTerminal.py", line 14, in <module>
class TestDAP_runInTerminal(lldbdap_testcase.DAPTestCaseBase):
File "/home/worker/2.0.1/lldb-x86_64-debian/llvm-project/lldb/test/API/tools/lldb-dap/runInTerminal/TestDAP_runInTerminal.py", line 29, in TestDAP_runInTerminal
@skipIfAsan
^^^^^^^^^^
NameError: name 'skipIfAsan' is not defined
```
These fail with on the macOS ASAN CI with following error:
```
07:10:31 ======================================================================
07:10:31 FAIL: test_runInTerminalWithObjectEnv (TestDAP_runInTerminal.TestDAP_runInTerminal)
07:10:31 Tests the "runInTerminal" reverse request. It makes sure that the IDE can
07:10:31 ----------------------------------------------------------------------
07:10:31 Traceback (most recent call last):
07:10:31 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 149, in wrapper
07:10:31 return func(*args, **kwargs)
07:10:31 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/test/API/tools/lldb-dap/runInTerminal/TestDAP_runInTerminal.py", line 83, in test_runInTerminalWithObjectEnv
07:10:31 self.build_and_launch(program, runInTerminal=True, env={"FOO": "BAR"})
07:10:31 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py", line 488, in build_and_launch
07:10:31 return self.launch(program, **kwargs)
07:10:31 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-dap/lldbdap_testcase.py", line 470, in launch
07:10:31 self.assertTrue(
07:10:31 AssertionError: False is not true : launch failed (process exited during launch or attach)
07:10:31 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-sanitized/lldb-build/bin/clang
```
These fail ever since they were enabled in https://github.com/llvm/llvm-project/pull/144954.
Skip these again when testing with ASAN.
It is failing on our Windows on Arm bot:
AssertionError: False is not true : launch failed (Unimplemented)
Given that all the others are skipped on Windows, I assume this
failure is expected too.
Replace `isTestSupported` function with `skipIfBuildType` annotation.
Test that uses the `IsTestSupported` function are no longer run, as the
size of lldb-dap binary is now more than `1mb`.
Update the broken test.
Fixes#108621
We could probably check if the test now passes on `linux arm` since it
was disabled because it timed out. I experienced the timeout after
replacing the `IsTestSupported` with `skipIfBuildType`.
