This patch ensures we can find decls in submodules during expression
evaluation. Previously, submodules would have all their decls marked as
`Hidden`. When Clang asked LLDB for decls, it would see them in the
submodule but `clang::Sema` would reject them because they weren't
`Visible` (specifically, `getAcceptableDecl` would fail during
`CppNameLookup`). Here we just mark the submodule as visible to work
around this problem.
This reverts commit 4b6c608615a285d81132acf8e33b81b2ec2c9bf9 and
follow-up commits 159de3633640a5cb2d322ebe8cc4ec0c1c9a896d and
c9e1c52e2e75a91a44a98df818cc9bd11655e51d because this breaks
TestDAP_stepInTargets.py on Darwin.
https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/as-lldb-cmake
Trimming unused imports, adjusting the test to use the `DEFAULT_TIMEOUT`
instead of a custom timeout and adjusting the flow to stopOnEntry for
improving consistency.
Previously, we incorrectly handled the disconnect operation if we signal
lldb-dap running in server mode.
Updated to correctly disconnect the attach vs launch behavior on server
shutdown.
Failing on the macOS matrix bot for Clang-15 with the following error:
```
07:16:08 FAIL: LLDB (/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/bin/clang-arm64) :: test_jump_offset_dwarf (TestThreadJump.ThreadJumpTestCase)
07:16:08 UNSUPPORTED: LLDB (/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/bin/clang-arm64) :: test_jump_offset_dwo (TestThreadJump.ThreadJumpTestCase) (test case does not fall in any category of interest for this run)
07:16:08 Restore dir to: /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/lldb-build/tools/lldb/test
07:16:08 ======================================================================
07:16:08 FAIL: test_jump_offset_dsym (TestThreadJump.ThreadJumpTestCase)
07:16:08 Test Thread Jump by negative or positive offset
07:16:08 ----------------------------------------------------------------------
07:16:08 Traceback (most recent call last):
07:16:08 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1804, in test_method
07:16:08 return attrvalue(self)
07:16:08 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/functionalities/thread/jump/TestThreadJump.py", line 112, in test_jump_offset
07:16:08 self.expect(f"print {var_2}", substrs=[var_2_value])
07:16:08 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2512, in expect
07:16:08 self.fail(log_msg)
07:16:08 AssertionError: Ran command:
07:16:08 "print var_2"
07:16:08
07:16:08 Got output:
07:16:08 (int) 20
07:16:08
07:16:08 Expecting sub string: "40" (was not found)
```
The problem was in calling GetLoadAddress on a value in the error state,
where `ValueObject::GetLoadAddress` could end up accessing the
uninitialized "address type" by-ref return value from `GetAddressOf`.
This probably happened because each function expected the other to
initialize it.
We can guarantee initialization by turning this into a proper return
value.
I've added a test, but it only (reliably) crashes if lldb is built with
ubsan.
Attempt to improve tests by synchronously waiting for breakpoints to
resolve. Not sure if it will fix all the tests but I think it should
make the tests more stable
Or more precisely, when linking with link.exe, but Windows
is our closest proxy for that right now.
This test requires the DWARF info to work, on the Windows on Arm
buildbot it fails:
```
AssertionError: Ran command:
"expr func(1, 2)"
Got output:
error: <user expression 0>:1:1: use of undeclared identifier 'func'
1 | func(1, 2)
| ^~~~
Expecting start string: "error: <user expression 0>:1:1: 'func' has unknown return type" (was not found)
```
This reverts commit 8a49db35f45e56c92522c6079e51553e80c07aec.
Due to failures on Arm and AArch64 Linux:
https://lab.llvm.org/buildbot/#/builders/59/builds/18540https://lab.llvm.org/buildbot/#/builders/18/builds/16759
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py", line 22, in assertEvaluateFailure
self.assertNotIn(
AssertionError: 'result' unexpectedly found in {'memoryReference': '0xFFFFF7CB3060', 'result': '0x0000000000000000', 'type': 'int *', 'variablesReference': 7}
FAIL: test_generic_evaluate_expressions (TestDAP_evaluate.TestDAP_evaluate)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py", line 228, in test_generic_evaluate_expressions
self.run_test_evaluate_expressions(enableAutoVariableSummaries=False)
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py", line 117, in run_test_evaluate_expressions
self.assertEvaluateFailure("list") # local variable of a_function
File "/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/llvm-project/lldb/test/API/tools/lldb-dap/evaluate/TestDAP_evaluate.py", line 22, in assertEvaluateFailure
self.assertNotIn(
AssertionError: 'result' unexpectedly found in {'memoryReference': '0xFFFFF7CB3060', 'result': '0x0000000000000000', 'type': 'int *', 'variablesReference': 7}
Config=aarch64-/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/bin/clang
The second one is because our bots have the libc debug info package installed,
the first, no idea.
Inferred submodule declarations are emitted in DWARF as `DW_TAG_module`s
without `DW_AT_LLVM_include_path`s. Instead the parent DIE will have the
include path. This patch adds support for such setups. Without this, the
`ClangModulesDeclVendor` would fail to `AddModule` the submodules (i.e.,
compile and load the submodules). This would cause errors such as:
```
note: error: Header search couldn't locate module 'TopLevel'
```
The test added here also tests
https://github.com/llvm/llvm-project/pull/141220. Without that patch
we'd fail with:
```
note: error: No module map file in /Users/jonas/Git/llvm-worktrees/llvm-project/lldb/test/API/lang/cpp/decl-from-submodule
```
Unfortunately the embedded clang instance doesn't allow us to use the
decls we find in the modules. But we'll try to fix that in a separate
patch.
rdar://151022173
When a target thread returned an empty but not `nullptr` string as its
name, the thread would show up with an empty name in lldb-dap.
I don't know how this works on macOS and Linux, but on Windows,
[`TargetThreadWindows::GetName`](deedc8a181/lldb/source/Plugins/Process/Windows/Common/TargetThreadWindows.cpp (L178-L204))
returns a non-null pointer to an empty string, because on MSVC's STL,
`std::string{}.c_str()` returns a pointer to inside the object (the SSO
storage).
This changes the check in `CreateThread`, when no custom thread
formatter is set, to check for the length of the thread and queue name
instead of it being `nullptr`.
Improving the readability and correctness of DebugCommunication by
adding type annotations to many parts of the library and trying to
improve the implementation of a few key areas of the code to better
handle correctness.
Specifically, this refactored the
`DebugCommunication._handle_recv_packet` function to ensure consistency
with the reader thread when handling state changes and improved the
`DebugCommunication._recv_packet` helper to make it easier to follow by
adding some additional helpers.
This reverts commit 57f3151a3144259f4e830fc43a1424e4c1f15985.
LLDB was hitting an assert when compiling the `std` module. The `std`
module was being pulled in because we use `#import <cstdio>` in the test
to set a breakpoint on `puts`. That's redundant and to work around the
crash we just remove that include. The underlying issue of compiling the
`std` module still exists and I'll investigate that separately. The
reason it started failing after the `ClangModulesDeclVendor` patch is that we would previously just fail to load the modulemap (and thus not load any of the modules). Now we do load the modulemap (and modules) when we prepare for parsing the expression.
after PR 138209 stopped applying data formatters
for T** by default, and this test expects that to
work. We'll need to figure out if we want to drop
this test, or adapt NSError/other objc formatters to
descend an extra level or two of depth.
Currently, the type `T`'s summary formatter will be matched for `T`,
`T*`, `T**` and so on. This is unexpected in many data formatters. Such
unhandled cases could cause the data formatter to crash. An example
would be the lldb's built-in data formatter for `std::optional`:
```
$ cat main.cpp
#include <optional>
int main() {
std::optional<int> o_null;
auto po_null = &o_null;
auto ppo_null = &po_null;
auto pppo_null = &ppo_null;
return 0;
}
$ clang++ -g main.cpp && lldb -o "b 8" -o "r" -o "v pppo_null"
[lldb crash]
```
This change adds an options `--pointer-match-depth` to `type summary
add` command to allow users to specify how many layer of pointers can be
dereferenced at most when matching a summary formatter of type `T`, as
Jim suggested
[here](https://github.com/llvm/llvm-project/pull/124048/#issuecomment-2611164133).
By default, this option has value 1 which means summary formatter for
`T` could also be used for `T*` but not `T**` nor beyond. This option is
no-op when `--skip-pointers` is set as well.
I didn't add such option for `type synthetic add`, `type format add`,
`type filter add`, because it useful for those command. Instead, they
all have the pointer match depth of 1. When printing a type `T*`, lldb
never print the children of `T` even if there is a synthetic formatter
registered for `T`.
The use of `-lobjc` resulted in this test failing to build on Linux. The
flag is not necessary, this removes the flag with the expectation it
will fix the test on Linux.
Use the current frame's language to lookup commands provided by language plugins.
This means commands like `language {objc,cplusplus} <command>` can be used directly, without using the `language <lang>` prefix.
For example, when stopped on a C++ frame, `demangle _Z1fv` will run `language cplusplus demangle _Z1fv`.
rdar://149882520
This test has been flaky on Linaro's Windows on Arm bot and I was
able to reproduce it within 10 or so runs locally.
When it fails it's because we failed to read the value of int_arr[100].
When that happens the memory looks like this:
```
[0x0000006bf88fd000-0x0000006bf8900000) rw- <-- sp (0x0000006bf88ffe20)
[0x0000006bf8900000-0x0000025fec900000) --- <-- int_arr[100] (0x0000006bf8900070)
```
The first region is the stack and the stack pointer is pointing
within that region, as expected.
The second region is where we are trying to read int_arr[100] from
and this is not mapped because we're trying to read above the start
of the stack.
Sometimes the test passes I think because ASLR / DYNAMICBASE moves
the start of the stack down enough so there is some readable memory
at the top.
https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase?view=msvc-170
Note "Because ASLR can't be disabled on ARM, ARM64, or ARM64EC
architectures,
/DYNAMICBASE:NO isn't supported for these targets.". Which means on this
bot,
the layout is definitely being randomised.
We don't need to be testing indexes this large. So I've changed the two
test indexes to 3 (1 beyond the end) and 10 (a larger distance beyond
the end).
We know that index 42 always worked on the bot, so 10 should be fine,
and
did not fail locally.
This has been flaky on Linaro's Windows on Arm bot, failing
with errors all along these lines:
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\commands\frame\var-dil\basics\ArraySubscript\TestFrameVarDILArraySubscript.py", line 56, in test_subscript
self.expect_var_path("int_arr[100]", True, type="int")
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\commands\frame\var-dil\basics\ArraySubscript\TestFrameVarDILArraySubscript.py", line 15, in expect_var_path
value_dil = super().expect_var_path(expr, value=value, type=type)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2589, in expect_var_path
value_check.check_value(self, eval_result, str(eval_result))
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 301, in check_value
test_base.assertSuccess(val.GetError())
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2597, in assertSuccess
self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
AssertionError: 'read memory from 0x68119c00b0 failed (0 of 4 bytes read)' is not success
I think this is because we are trying to read off of the top of the
stack which is unmapped memory on Windows.
I have a fix I'm going to put in review shortly.
Fixes#45326
When you thread jump by calling
`j +2` or `thread jump --by +2` the offset is not recognised. This
commit fixes that.
---------
Signed-off-by: Ebuka Ezike <yerimyah1@gmail.com>
less-than-14.4. Our CI bot is running macOS 14.1 but I still see
FAILs from this text in the CI logs? It may be that the CI is
really seeing TestTemplateWithSameArg.py fail and is highlighting
this XFAIL test even though it's expected. But I'm not interested
enough, I'll try just skipping it altogether on < macOS 14.4. This
does mean I'm skipping it on intel where the kernel never had the
issue involved.
The architectures provided to skipIf / expectedFail are regular
expressions (v. _match_decorator_property() in decorators.py
so on Darwin systems "arm64" would match the skips for "arm" (32-bit
Linux). Update these to "arm$" to prevent this, and also update
three tests (TestBuiltinFormats.py, TestCrossDSOTailCalls.py,
TestCrossObjectTailCalls.py) that were skipped for arm64 via this
behavior, and need to be skipped or they will fail.
This was moviated by the new TestDynamicValue.py test which has
an expected-fail for arm, but the test was passing on arm64 Darwin
resulting in failure for the CIs.
When running a process that would exit before LLDB could stop the
target, it would try to interpret (and subsequently format) the exit
code as a Win32 error. However, processes on Windows won't return Win32
errors in that case. They will often return an
[NTSTATUS](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-erref/596a1078-e883-4972-9bbc-49e60bebca55).
One common case for this to occur is when a DLL is missing. In that
case, the process will start successfully, but it will exit with
`STATUS_DLL_NOT_FOUND`.
LLDB would previously return "unknown error", because it tried to
[`FormatMessage`](https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessage)
`0xC0000135` which doesn't work, so it fell back to "unknown error".
This PR changes the error to be the string "Process prematurely exited
with {0:x}" and doesn't try to format the exit code. One could
`FormatMessage` an `NTSTATUS` by passing `FORMAT_MESSAGE_FROM_HMODULE`
and a handle to `ntdll.dll`, however, I don't think we can get the
required format arguments (e.g. the missing DLL name - `%hs`).
If libstdc++ is compiled with `_GLIBCXX_DEBUG` flag it puts the containers in the namespace `std::__debug`. this causes the summary and synthetic formatters not to match the types. The formatters is updated to optionally match the `__debug::`.
The formatters now clashed with the libc++ containers namespace regex which uses `std::__1` namespace
The libc++ formatter is loaded first, then the libstdc++ since the priority of the formatters in lldb is the last one added.
Fixes#60841
This is still leftover from the days when the libc++ and libstdc++
formatters were both written in python and in separate categories. Since
then we group libstdc++ and libc++ formatters into the same cateogry.
This patch removes references to the obsolete `gnu-libstdc++` category
from the docs (and a test).
See [this
thread](https://github.com/llvm/llvm-project/pull/140761#discussion_r2102386080)
for more context
In lldb-dap, we have existing tests that are known to be unstable when
lldb and lldb-dap are built in the Debug configuration.
This decorator lets us skip those tests in CI jobs that are to slow with
those configurations.
This was split out from #140777 to make the patches smaller.
* Changes the default synthetic symbol names to contain their file
address
This is a new PR after the first PR (#137512) was reverted because it
didn't update the way unnamed symbols were searched in the symbol table,
which relied on the index being in the name.
This time also added extra test to make sure the symbol is found as
expected
- `CreateRunInTerminalReverseRequest` is passed a `StringMap` by value,
whose keys are owned and deallocated after return.
- Target args are wrongly specified as reverse request (launcher) args.
- Test case error message did not catch up with a0aa5f8.
All runInTerminal tests are passing with this applied.
New test added by https://github.com/llvm/llvm-project/pull/139969.
On Windows we need debug information to be able to break on the
function (we don't need it for main, but I assume that's a special case).
So disable the test on Windows.
I tried a few tricks like making a global label in assembly, but
that doesn't show up without debug info either.
This reapplies https://github.com/llvm/llvm-project/pull/138892, which
was reverted in
5fb9dca14a
due to failures on windows.
Windows loads modules from the Process class, and it does that quite
early, and it kinda makes sense which is why I'm moving the clearing
code even earlier.
The original commit message was:
Minidump files contain explicit information about load addresses of
modules, so it can load them itself. This works on other platforms, but
fails on darwin because DynamicLoaderDarwin nukes the loaded module list
on initialization (which happens after the core file plugin has done its
work).
This used to work until
https://github.com/llvm/llvm-project/pull/109477, which enabled the
dynamic loader
plugins for minidump files in order to get them to provide access to
TLS.
Clearing the load list makes sense, but I think we could do it earlier
in the process, so that both Process and DynamicLoader plugins get a
chance to load modules. This patch does that by calling the function
early in the launch/attach/load core flows.
This fixes TestDynamicValue.py:test_from_core_file on darwin.
The GreenDragon CI bots are currently passing because the installed
Xcode is a bit old, and doesn't have the watchpoint handling
bug that was fixed April with this test being added.
But on other CI running newer Xcode debugservers, this test will
fail. Skip this test if we're using an out of tree debugserver.
