During lldb testing on remote targets TestGdbRemoteForkNonStop.py
freezes because in this test we try to create file on remote machine
using absolute file path from local machine. This patch fixes this error
The inferior used in the process launch test prints out its working
directory using the `getcwd` function, which is not allowed to return
symbolic links in the path components. When testing against the output
from `getcwd` we should resolve the full path to match the expected
output.
The source manager test sets a breakpoint on a main-copy.c file that is
copied into the build output directory. The source manager resolves this
path to its real location. When testing the output from the source cache
we need to resolve the expected path in the test to remove symlinks.
Previously, the test compared the JSON output to `setting_value` which
was incorrect. Updated the assertion to validate against the correct
list of paths `[path1, path2]` to ensure accurate test behavior.
Ran the test on the local computer
Signed-off-by: Ebuka Ezike <yerimyah1@gmail.com>
The build bot was failing when running remote test from windows to
linux.
From #131683
---------
Signed-off-by: Ebuka Ezike <yerimyah1@gmail.com>
Co-authored-by: Pavel Labath <pavel@labath.sk>
When printing setting variables using the python SBDebugger API if the type is of OptionValueFileSpec
it defaults to null as the value even if it has a value. This patch fixes that.
---------
Signed-off-by: Ebuka Ezike <yerimyah1@gmail.com>
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
On Mac x86-64, the debugserver reports a register ('ds' at least) but
returns an error when we try to read it. Just skip storing such
registers in snapshots so we won't try to restore them.
In 2013 we added the QSaveRegisterState and QRestoreRegisterState
packets to checkpoint a thread's register state while executing an
inferior function call, instead of using the g packet to read all
registers into lldb, then the G packet to set them again after the func
call.
Since then, lldb has not sent g/G (except as a bug) - it either asks for
registers individually (p/P) or or asks debugserver to save and restore
the entire register set with these lldb extensions.
Felipe recently had a codepath that fell back to using g/G and found
that it does not work with the modern signed fp/sp/pc/lr registers that
we can get -- it sidesteps around the clearing of the non-addressable
bits that we do when reading/writing them, and results in a crash. (
https://github.com/llvm/llvm-project/pull/132079 )
Instead of fixing that issue, I am removing g/G from debugserver because
it's not needed by lldb, and it will would be easy for future bugs to
creep in to this packet that lldb should not use, but it can
accidentally fall back to and result in subtle bugs.
This does mean that a debugger using debugserver on darwin which doesn't
use QSaveRegisterState/QRestoreRegisterState will need to fall back to
reading & writing each register individually. I'm open to re-evaluating
this decision if this proves to be needed, and supporting these lldb
extensions is onerous.
The unicode test sends some unicode input to lldb through pexpect and
expects the output to be echoed back in an error message. This only
works correctly when editline was compiled with wide character support.
This commit modifies the test to require the necessary libedit
configuration.
Change `lldbtest.expect` to require the regexes in `patterns` be found in order – when the
`ordered` parameter is true. This matches the behavior of `substrs`.
The `ordered` parameter is true by default, so this change also fixes tests by either
tweaking the patterns to work in order, or by setting `ordered=False`.
I have often wanted to test with `patterns` and also verify the order. This change
allows that.
This reverts commit
87b7f63a11,
reapplying
7e66cf74fb
with a small (and probably temporary)
change to generate more debug info to help with diagnosing buildbot
issues.
When printing an ObjC object, which is a pointer, lldb has handled it
the same way it treats any other pointer – printing only class name and
pointer address. The object is not expanded, its children are not shown.
This change updates `dwim-print` to print objc pointers by expanding (ie
dereferencing), with the assumption that it's what the user wants.
Note that this is currently possible using the `--ptr-depth`/`-P` flag.
With this change, when `dwim-print` prints root level objc objects, it's
the same effect as using `--ptr-depth 1`.
Split test cases out of TestLldbGdbServer.py and TestGdbRemoteFork.py
into separate files to avoid hitting the 600s timeout limit. The
inferior used by these tests (main.cpp) takes approximately 20s to
compile with a Debug build of clang, causing timeouts when a single test
file contains many tests. By grouping similar tests into separate files,
we can prevent timeouts and improve overall test efficiency.
Instead of having two discrete InputStream and OutputStream helpers,
this merges the two into a unifed 'Transport' handler.
This handler is responsible for reading the DAP message headers, parsing
the resulting JSON and converting the messages into
`lldb_dap::protocol::Message`s for both input and output.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Per the DAP spec, the event 'body' field should contain any additional
data related to the event. I updated the lldb-dap 'statistics' extension
into the terminated event's body like:
```
{
"type": "event",
"seq": 0,
"event": "terminated",
"body": {
"$__lldb_statistics": {...}
}
}
```
This allows us to more uniformly handle event messages.
Remove support for coalescing progress reports in LLDB. This
functionality was motivated by Xcode, which wanted to listen for less
frequent, aggregated progress events at the cost of losing some detail.
See the original RFC [1] for more details. Since then, they've
reevaluated this trade-off and opted to listen for the regular, full
fidelity progress events and do any post processing on their end.
rdar://146425487
These are macOS tests only and are currently failing on the x86_64 CI
and on arm64 on recent versions of macOS/Xcode.
The tests are failing because we're stopping in:
```
Process 17458 stopped
* thread #1: tid = 0xbda69a, 0x00000002735bd000
libsystem_malloc.dylib`purgeable_print_self.cold.1, stop reason = EXC_BREAKPOINT (code=1, subcode=0x2735bd000)
```
instead of the libsanitizers library. This seems to be related to
`-fsanitize-trivial-abi` support
Skip these for now until we figure out the root cause.
Some lldb tests from llgs category fail on RISC-V target due to lack of
necessary condition checks. This patch adapts these tests by taking into
account the peculiarities of the RISC-V architecture
`TestReportData.py` is failing on the macOS CI with:
```
Traceback (most recent call last):
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1784, in test_method
return attrvalue(self)
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 148, in wrapper
return func(*args, **kwargs)
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/API/functionalities/asan/TestReportData.py", line 28, in test_libsanitizers_asan
self.asan_tests(libsanitizers=True)
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/API/functionalities/asan/TestReportData.py", line 60, in asan_tests
self.expect(
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2490, in expect
self.fail(log_msg)
AssertionError: Ran command:
"thread list"
Got output:
Process 3474 stopped
* thread #1: tid = 0x38b5e9, 0x00007ff80f563b52 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
Expecting sub string: "stopped" (was found)
Expecting sub string: "stop reason = Use of deallocated memory" (was not found)
Process should be stopped due to ASan report
```
There isn't much to go off of in the log, so adding more to help us debug this.
We have a binary image on Darwin that has no code, only metadata. It has
a large symbol table with many external symbol names that will not be
needed in the debugger. And it is possible to not have this binary on
the debugger system - so lldb must read all of the symbol names out of
memory, one at a time, which can be quite slow.
We're adding a section __TEXT,__lldb_no_nlist, to this binary to
indicate that lldb should not read the nlist symbols for it when we are
reading out of memory. If lldb is run with an on-disk version of the
binary, we will load the symbol table as we normally would, there's no
benefit to handling this binary differently.
I added a test where I create a dylib with this specially named section,
launch the process. The main binary deletes the dylib from the disk so
lldb is forced to read it out of memory. lldb attaches to the binary,
confirms that the dylib is present in the process and is a memory
Module. If the binary is not present, or lldb found the on-disk copy
because it hasn't been deleted yet, we delete the target, flush the
Debugger's module cache, sleep and retry, up to ten times. I create the
specially named section by compiling an assembly file that puts a byte
in the section which makes for a bit of a messy Makefile (the pre-canned
actions to build a dylib don't quite handle this case) but I don't think
it's much of a problem. This is a purely skipUnlessDarwin test case.
Relanding this change with a restructured Makefiles for the test case
that should pass on the CI bots.
rdar://146167816
This reverts commit 397696bb3d26c1298bf265e4907b0b6416ad59c9.
This breaks the macOS CI bots, I need to use $LDFLAGS in the $LD
invocation when building the dylib to get the dylibs to build on
the CI bots. But I've added "-lno-nlists -lhas-nlists" to the LDFLAGS
for the main binary in the same directory, so using LDFLAGS will
result in a compile error for the dylibs. I'll need to build the
dylibs in a subdir with a different Makefile, will reland with that
change in a bit.
We have a binary image on Darwin that has no code, only metadata. It has
a large symbol table with many external symbol names that will not be
needed in the debugger. And it is possible to not have this binary on
the debugger system - so lldb must read all of the symbol names out of
memory, one at a time, which can be quite slow.
We're adding a section __TEXT,__lldb_no_nlist, to this binary to
indicate that lldb should not read the nlist symbols for it when we are
reading out of memory. If lldb is run with an on-disk version of the
binary, we will load the symbol table as we normally would, there's no
benefit to handling this binary differently.
I added a test where I create a dylib with this specially named section,
launch the process. The main binary deletes the dylib from the disk so
lldb is forced to read it out of memory. lldb attaches to the binary,
confirms that the dylib is present in the process and is a memory
Module. If the binary is not present, or lldb found the on-disk copy
because it hasn't been deleted yet, we delete the target, flush the
Debugger's module cache, sleep and retry, up to ten times. I create the
specially named section by compiling an assembly file that puts a byte
in the section which makes for a bit of a messy Makefile (the pre-canned
actions to build a dylib don't quite handle this case) but I don't think
it's much of a problem. This is a purely skipUnlessDarwin test case.
rdar://146167816
While running lldb-dap over stdin/stdout the `stdout` and `stderr` FD's
are replaced with a pipe that is reading the output to forward to the
dap client. During shutdown we were not properly restoring those FDs,
which means if any component attempted to write to stderr it would
trigger a SIGPIPE due to the pipe being closed during the shutdown
process. This can happen if we have an error reported from the
`DAP::Loop` call that would then log to stderr, such as an error parsing
a malformed DAP message or if lldb-dap crashed and it was trying to
write the stack trace to stderr.
There is one place we were not handling an `llvm::Error` if there was no
logging setup that could trigger this condition.
To address this, I updated the OutputRedirector to restore the FD to the
prior state when `Stop` is called.
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
On macOS, breakpoints are briefly unresolved between process launch and
when the dynamic loader has informed us about the loaded libraries. This
information was being forwarded by lldb-dap, but only partially. In the
event handler, we were listening for the `LocationsAdded` and
`LocationsRemoved` breakpoint events. For the scenario described above,
the latter would trigger and we'd send an event reporting the breakpoint
as unresolved. The problem is that when the breakpoint location is
resolved again, you receive a `LocationsResolved` event, not a
`LocationsAdded` event. As a result, the breakpoint would continue to
show up as unresolved in the DAP client.
I found a test that tried to test part of this behavior, but the test
was broken and disabled. I revived the test and added coverage for the
situation described above.
Fixes#112629
rdar://137968318
This patch adds a finalize method which destroys the underlying RAII
SBProgress. My primary motivation for this is so I can write better
tests that are non-flaky, but after discussing with @clayborg in my DAP
message improvement patch (#124648) this is probably an essential API
despite that I originally argued it wasn't.
We didn't also copy over the next stop hook id, which meant we would
overwrite the stop hooks from the dummy target with stop hooks set after
they are copied over.
When OS plugins are present, it can be helpful to query information
about the backing thread behind an OS thread, if it exists. There is no
mechanism to do so prior to this commit.
As a first step, this commit enhances `thread info` with a
`--backing-thread` flag, causing the command to use the backing thread
of the selected thread, if it exists.
Both spellings are considered correct and acceptable, with adapter being
more common in American English. Given that DAP stands for Debug Adapter
Protocol (with an e) let's go with that as the canonical spelling.
The test was failing because it was looking up the immediate value from
the call instruction as a load address, whereas in fact it was a file
address. This worked on darwin because (with ASLR disabled) the two
addresses are generally the same. On linux, this depends on the build
mode, but with the default (PIE) build type, the two are never the same.
The test also fails on a mac with ASLR enabled.
This path fixes the code to look up the value as a file address.
I am using VSCode with the official vscode-lldb extension. When I try to
list the breakpoints in the debug console get the message:
```
br list
can't evaluate expressions when the process is running.
```
I know that this is wrong and you need to use
```
`br list
(lldb) br list
No breakpoints currently set.
```
but the error message is misleading. I cleaned up the code and now the
error message is
```
br list
sbframe object is not valid.
```
which is still not perfect, but at least it's not misleading.
The TestDAP_ouput test is flaky due to the order of events during
shutdown. We were stopping the output and error handle redirection after
we finished the disconnect request, which can cause us to miss output
events due to timing. Moving when we stop the redirection to ensure we
have consistent output prior to disconnect responding.
Fixes#128567
This should fix the tests running on windows.
https://lab.llvm.org/buildbot/#/builders/141/builds/6506 is the failure,
the error message does not clearly indicate why the connection failed,
but they are passing for me locally on macOS and passed on linux in the
CI.
