From
https://github.com/llvm/llvm-project/pull/148554#issuecomment-3083261858
- this adds an option for API tests to be run with the both PDB readers
on Windows. As there are a lot of failures with PDB, this is an opt-in
per test.
To get PDB, `-g -gcodeview` has to be used on Clang. `-gcodeview` alone
isn't enough, because it won't cause clang to pass `-debug` to the
linker.
#149498 tracks the (currently) failing tests.
In lldb-dap tests, we sometimes spawn subprocesses directly but do not
always correctly clean them up.
This can cause some tests, like the `TestDAP_disconnect.test_attach` to
hang and not properly respect timeouts.
To fix this, I am passing the `lldbtest.Base.spawnSubprocess` helper to
the adapter client so it can be used spawn subprocesses in a way that we
can ensure they're cleaned up.
When stopped in a hidden frame (either because we selected the hidden
frame or hit a breakpoint inside it), a user most likely is intersted in
exploring the immediate frames around it. But currently issuing
`up`/`down` commands will unconditionally skip over all hidden frames.
This patch makes it so `up`/`down` commands don't skip hidden frames if
the frame we started it was a hidden frame.
Noticed this while looking into test stability that the 'entry' stop
reason is not triggering correctly. This should ensure we correctly
trigger the 'entry' stop reason when launching a process with
`"stopOnEntry": true`. I've also updated the tests to ensure we receive
the 'entry' stop reason to catch this regression.
… concurrency." (#165688)""
This reverts commit 17dbd8690e36f8e514fb47f4418f78420d0fc019.
This was causing timeouts on the premerge runners. Reverting for now
until the timeouts trigger within lit and/or we have a better testing
strategy for this.
In #165604, a test was skipped on Windows, because the native PDB plugin
didn't set sizes on symbols. While the test isn't compiled with debug
info, it's linked with `-gdwarf`, causing a PDB to be created on
Windows. This PDB will only contain the public symbols (written by the
linker) and section information. The symbols themselves don't have a
size, however the DIA SDK sets a size for them.
It seems like, for these data symbols, the size given from DIA is the
distance to the next symbol (or the section end).
This PR implements the naive approach for the native plugin. The main
difference is in function/code symbols. There, DIA searches for a
corresponding `S_GPROC32` which have a "code size" that is sometimes
slightly smaller than the difference to the next symbol.
Cherry-picks this fix from the Apple LLDB fork. Ever since we upstreamed
https://github.com/llvm/llvm-project/pull/164011, this test is failing
on our pre-DWARFv5 bots:
```
13:47:54 ======================================================================
13:47:54 FAIL: test_frame_var_after_stop_at_implementation_dsym (TestRealDefinition.TestRealDefinition)
13:47:54 Test that we can find the implementation for an objective C type
13:47:54 ----------------------------------------------------------------------
13:47:54 Traceback (most recent call last):
13:47:54 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
13:47:54 return attrvalue(self)
13:47:54 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/objc/real-definition/TestRealDefinition.py", line 60, in test_frame_var_after_stop_at_implementation
13:47:54 self.expect(
13:47:54 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2416, in expect
13:47:54 self.runCmd(
13:47:54 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1006, in runCmd
13:47:54 self.assertTrue(self.res.Succeeded(), msg + output)
13:47:54 AssertionError: False is not true : Variable(s) displayed correctly
13:47:54 Error output:
13:47:54 error: <user expression 0>:1:12: "_hidden_ivar" is not a member of "(id) _bar"
13:47:54 1 | foo->_bar->_hidden_ivar
13:47:54 | ^
```
Original commit message:
For a while, tests were run with `target.prefer-dynamic-value`
overridden to `no-dynamic-values` – but the override was removed in
[D132382](https://reviews.llvm.org/D132382). At that time, tests that
failed were individually opted in to `no-dynamic-values`.
I don't recall specifics about `TestRealDefinition`, but it currently
fails with `no-dynamic-values`, and that is correct behavior. This
change removes the `no-dynamic-values` override.
the function signature for `GetStopDescription` is
`lldb::SBThread::GetStopDescription(char *dst_or_null, size_t len)`.
To get a description you need to call the function first time to get the
buffer size. a second time to get the description.
This is little worse from the python size as the signature is
`lldb.SBThread.GetStopDescription(int: len) -> list[str]` the user has
to pass the max size as possible with no way of checking if it is
enough.
This patch adds a new api
`lldb.SBThread.GetStopDescription(desc: lldb.SBStream()) -> bool` `bool
lldb::SBThread::GetStopDescription(lldb::SBStream &description)` which
handles this case.
Adds new Test case for lua.
Most of the cases were where a C++ file was being compiled with the C substitution.
There were a few cases of the opposite though.
LLDB seems to be the only real culprit in the LLVM codebase for these mismatches.
Rest of the LLVM presumably sticks at least language-specific options in the common substitutions
making the mistakes immediately apparent.
I found these by using Clang frontend configuration files containing language-specific options for
both C and C++ (e.g. `-std=c2y` and `-std=c++26`).
This reverts commit f205be095609aa61dfac3ae729406e0af2dcd15f.
This new select mechanism has exposed the fact that the resources
the Arm Linux bot has can vary a lot. We do limit it to a low number
of parallel tests but in this case, I think it's write performance
somewhere.
Reland the changes since they work elsewhere, and disable lldb-dap
tests on Arm Linux while I fix our buildbot.
These tests had only ever been run on SVE or SVE+SME systems.
While investigating #138717 I found they failed on an SME only
system.
This happens because before the first stop we try to initialise
SVE registers while outside of streaming mode. Which causes a
SIGILL.
To fix this, require SVE to be present.
I could go in and make these work on SME only, but it's more
complex and I will be adding SME only specific tests in
future anyway.
Currently all `runInTerminal` test are skipped in debug builds because,
when attaching it times out parsing the debug symbols of lldb-dap.
Add this test since it is running in teminal.
We currently use a background thread to read the DAP output. This means
the test thread and the background thread can race at times and we may
have inconsistent timing due to these races.
To improve the consistency I've removed the reader thread and instead
switched to using the `selectors` module that wraps `select` in a
platform independent way.
After the default PDB plugin changed to the native one (#165363), this
test failed, because it uses the size of public symbols and the native
plugin sets the size to 0 (as PDB doesn't include this information
explicitly). A PDB was built because the final executable in that test
was linked with `-gdwarf`.
Test added in #164905, skipped by #165318, but that change did not
guard the import. This import is run when we parse the file which
happens before any skips are applied.
Turns out there's a bug in the current lldb sources that if you fork,
set the stdio file handles to close on exec and then exec lldb with some
commands and the `--batch` flag, lldb will stall on exit. The first
cause of the bug is that the Python session handler - and probably other
places in lldb - think 0, 1, and 2 HAVE TO BE the stdio file handles,
and open and close and dup them as needed. NB: I am NOT trying to fix
that bug. I'm not convinced running the lldb driver headless is worth a
lot of effort, it's just as easy to redirect them to /dev/null, which
does work.
But I would like to keep lldb from stalling on the way out when this
happens. The reason we stall is that we have a MainLoop waiting for
signals, and we try to Interrupt it, but because stdio was closed, the
interrupt pipe for the MainLoop gets the file descriptor 0, which gets
closed by the Python session handler if you run some script command. So
the Interrupt fails.
We were running the Write to the interrupt pipe wrapped in
`llvm::cantFail`, but in a no asserts build that just drops the error on
the floor. So then lldb went on to call std:🧵:join on the still
active MainLoop, and that stalls
I made Interrupt (and AddCallback & AddPendingCallback) return a bool
for "interrupt success" instead. All the places where code was
requesting termination, I added checks for that failure, and skip the
std:🧵:join call on the MainLoop thread, since that is almost
certainly going to stall at this point.
I didn't do the same for the Windows MainLoop, as I don't know if/when
the WSASetEvent call can fail, so I always return true here. I also
didn't turn the test off for Windows. According to the Python docs all
the API's I used should work on Windows... If that turns out not to be
true I'll make the test Darwin/Unix only.
Failing on macOS Clang-15 and Clang-17 bots with:
```
07:26:20 ======================================================================
07:26:20 FAIL: test_frame_var (TestFrameVarDILGlobalVariableLookup.TestFrameVarDILGlobalVariableLookup)
07:26:20 ----------------------------------------------------------------------
07:26:20 Traceback (most recent call last):
07:26:20 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 156, in wrapper
07:26:20 return func(*args, **kwargs)
07:26:20 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/commands/frame/var-dil/basics/GlobalVariableLookup/TestFrameVarDILGlobalVariableLookup.py", line 48, in test_frame_var
07:26:20 self.expect_var_path("ExtStruct::static_inline", value="16")
07:26:20 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2599, in expect_var_path
07:26:20 value_check.check_value(self, eval_result, str(eval_result))
07:26:20 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 302, in check_value
07:26:20 test_base.assertSuccess(val.GetError())
07:26:20 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2607, in assertSuccess
07:26:20 self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
07:26:20 AssertionError: '<user expression 0>:1:1: use of undeclared identifier 'ExtStruct::static_inline'
07:26:20 1 | ExtStruct::static_inline
07:26:20 | ^' is not success
```
I suspect Clang-17 (and earlier) used DWARFv4 on macOS by default. So we
would use the Apple accelerator tables, which didn't index `ExtStruct`
(based on what I observed locally). We already XFAIL this test for
DWARFv4, hence XFAIL it also for older Clang versions.
Test fails on the DWARFv2 and DWARFv5 macOS bot with:
```
07:00:39 FAIL: test_frame_var (TestFrameVarDILGlobalVariableLookup.TestFrameVarDILGlobalVariableLookup)
07:00:39 ----------------------------------------------------------------------
07:00:39 Traceback (most recent call last):
07:00:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 156, in wrapper
07:00:39 return func(*args, **kwargs)
07:00:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/commands/frame/var-dil/basics/GlobalVariableLookup/TestFrameVarDILGlobalVariableLookup.py", line 48, in test_frame_var
07:00:39 self.expect_var_path("ExtStruct::static_inline", value="16")
07:00:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2599, in expect_var_path
07:00:39 value_check.check_value(self, eval_result, str(eval_result))
07:00:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 302, in check_value
07:00:39 test_base.assertSuccess(val.GetError())
07:00:39 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2607, in assertSuccess
07:00:39 self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))
07:00:39 AssertionError: '<user expression 0>:1:1: use of undeclared identifier 'ExtStruct::static_inline'
07:00:39 1 | ExtStruct::static_inline
07:00:39 | ^' is not success
07:00:39 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/lldb-build/bin/clang
```
Possibly something to do with accelerator table differences between the versions.
Prior to https://github.com/llvm/llvm-project/pull/164998, recent LLDB
versions would fail to parse synthesized property setters correctly. The
only way this failure would manifest is an error to the console:
```
error: main.o [0x00000000000000cd]: invalid Objective-C method DW_TAG_subprogram (DW_TAG_subprogram), please file a bug and attach the file at the start of this error message
```
There weren't any Objective-C tests that failed when the original regression (https://github.com/llvm/llvm-project/pull/100355) landed. This patch adds a test that explicitly checks that the type of the setter is sensible.
This test fails without https://github.com/llvm/llvm-project/pull/164998
and passes with it.
I decided not to check for the absence of the console error because that kind of test would be fragile to the removal of (or any changes to) the error message.
When SWIG is installed but not any Lua interpreter, the cmake script in
`lldb/cmake/modules/FindLuaAndSwig.cmake` will execute
`find_program(LUA_EXECUTABLE, ...)` and this will set the
`LUA_EXECUTABLE` variable to `LUA_EXECUTABLE-NOTFOUND`.
Ensure that in this case we are skipping the Lua tests requiring the
interpreter.
While testing baremetal lldb, I came across a situation that if an
instruction could not be disassembled, lldb will print nothing as an
output which might be a bit strange. I added at least printing warning
in this case.
This patch adds a check in lldb's API test CMakeLists file to ensure
that `dirname` is in the PATH, which is not obvious on Windows.
---------
Co-authored-by: nerix <nero.9@hotmail.de>
This commit makes use of the newly created MultiMemRead packet to
provide an efficient implementation of MultiMemRead inside
ProcessGDBRemote.
Testing is tricky, but it is accomplished two ways:
1. Some Objective-C tests would fail if this were implemented incorrectly,
as there is already an in-tree use of the base class implementation of
MultiMemRead, which is now getting replaced by the derived class.
2. One Objective-C test is modified so that we ensure the packet is
being sent by looking at the packet logs. While not the most elegant
solution, it is a strategy adopted in other tests as well. This gets
around the fact that we cannot instantiate / unittest a mock
ProcessGDBRemote.
Depends on https://github.com/llvm/llvm-project/pull/163651
The test did not work as intended when the empty function `done()`
contained prologue/epilogue code, because a breakpoint was set before
the last instruction of the function, which caused the test to pass even
with the fix from #126838 having been reverted.
The test is intended to check a case when a breakpoint is set on a
return instruction, which is the very last instruction of a function.
When stepping out from this breakpoint, there is interaction between
`ThreadPlanStepOut` and `ThreadPlanStepOverBreakpoint` that could lead
to missing the stop location in the outer frame; the detailed
explanation can be found in #126838.
On `Linux/AArch64`, the source is compiled into:
```
> objdump -d main.o
0000000000000000 <done>:
0: d65f03c0 ret
```
So, when the command `bt set -n done` from the original test sets a
breakpoint to the first instruction of `done()`, this instruction
luckily also happens to be the last one.
On `Linux/x86_64`, it compiles into:
```
> objdump -d main.o
0000000000000000 <done>:
0: 55 push %rbp
1: 48 89 e5 mov %rsp,%rbp
4: 5d pop %rbp
5: c3 ret
```
In this case, setting a breakpoint by function name means setting it
several instructions before `ret`, which does not provoke the
interaction between `ThreadPlanStepOut` and
`ThreadPlanStepOverBreakpoint`.
https://github.com/llvm/llvm-project/pull/140443 makes use of the CMake
variable `Python3_EXECUTABLE_DEBUG`, which was introduced in CMake
version 3.30. On systems with an inferior version of cmake, the lit
tests will try to run with an empty `config.python_executable`.
This PR adds a warning and falls back to using `Python3_EXECUTABLE` if
the CMake version is less than `3.30`.
While debugging the tests for #155000 I found it helpful to have both
sides
of the simulated gdb-rsp traffic rather than just the responses so I've
extended
the packetLog in MockGDBServerResponder to record traffic in both
directions.
Tests have been updated accordingly
StopInfoBreakpoint keeps a BreakpointLocationCollection for all the
breakpoint locations at the BreakpointSite that was hit. It is also
lives through the time a given thread is stopped, so there are plenty of
opportunities for one of the owning breakpoints to get deleted.
But BreakpointLocations don't keep their owner Breakpoints alive, so if
the BreakpointLocationCollection can live past when some code gets a
chance to delete an owner breakpoint, and then you ask that location for
some breakpoint information, it will access freed memory.
This wasn't a problem before PR #158128 because the StopInfoBreakpoint
just kept the BreakpointSite that was hit, and when you asked it
questions, it relooked up that list. That was not great, however,
because if you hit breakpoints 5 & 6, deleted 5 and then asked which
breakpoints got hit, you would just get 6. For that and other reasons
that PR changed to storing a BreakpointLocationCollection of the
breakpoints that were hit. That's better from a UI perspective but
caused this potential problem.
I fix it by adding a variant of the BreakpointLocationCollection that
also holds onto a shared pointer to the Breakpoints that own the
locations that were hit, thus keeping them alive till the
StopInfoBreakpoint goes away.
This fixed the ASAN assertion. I also added a test that works harder to
cause trouble by deleting breakpoints during a stop.
When the user send `thread return <expr>` command this changes the stack
length but the UI does not update.
Send stack invalidated event to the client to update the stack.
Despite #163452, this is still timing out on our Arm bot. Probably
because schedling is unpredicatable, but that's just reality so
I'm not going to fight that.
--
Exit Code: -9
Timeout: Reached timeout of 600 seconds
======================================================================
ERROR: test_by_name_waitFor (TestDAP_attach.TestDAP_attach)
Tests waiting for, and attaching to a process by process name that
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2066, in tearDown
Base.tearDown(self)
File "/home/tcwg-buildbot/worker/lldb-arm-ubuntu/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1106, 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 499, 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 926, 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 548, in _send_recv
raise ValueError(f"no response for {request!r}")
ValueError: no response for {'command': 'disconnect', 'type': 'request', 'arguments': {'terminateDebuggee': True}, 'seq': 3}
Config=arm-/home/tcwg-buildbot/worker/lldb-arm-ubuntu/build/bin/clang
----------------------------------------------------------------------
I don't think this is an Arm thing specifically, but it's the most
diplomatic way to stop false negatives from this test.
(Note, this upstreams code that has been deployed on Apple's Swift LLDB
for many years at this point).
When a `ValueObject` computes its "complete type"
(`MaybeCalculateCompleteType`), it gives the language runtimes a chance
to override the type known to it. The current implementation of
`ObjCLanguageRuntime::GetRuntimeType`, however, didn't consult the
`AppleObjCDeclVendor` to look for types.
As demonstrated in the attached test, when we don't have debug-info for
a base class type (most commonly happens when inheriting from system
framework types) we would not be able to deduce ivars of that type.
However, the runtime knows about the ivars, so we should be able to
retrieve them.
There's still a couple of caveats for future follow-up/investigation:
1. `frame var` isn't able to access such backing ivars explicitly (even
if they do exist)
2. When compiling with `-gmodules`, LLDB gets confused about what is
correct source of information for these decls is.
rdar://162069497
The test will fail if libc++ starts to use a lambda in `<array>`. This
will become the case because
- libc++'s `array::fill` uses `std::fill_n`, and
- `std::fill_n` is to be optimized for segment iterators, and
- the natural approach for such optimization uses lambdas.
Until ASTImport of `clang::LambdaExpr` nodes gets properly fix, this
will need to be skipped.
Various DAP tests are specifying their own timeouts, with values ranging
from "1" to "20". Most of them seem arbitrary, but some come with a
comment.
The performance characters of running these tests in CI are
unpredictable (they generally run much slower than developers expect)
and really not something we can make assumptions about. I suspect these
timeouts are a contributing factor to the flakiness of the DAP tests.
This PR unifies the timeouts around a central value in the DAP server.
Fixes#162523
