The cause is the non-async-signal-safety printf function (et al.). If
the test managed to interrupt the process and inject a signal before the
printf("@started") call returned (but after it has actually written the
output), that string could end up being printed twice (presumably,
because the function did not manage the clear the userspace buffer, and
so the print call in the signal handler would print it once again).
This patch fixes the issue by replacing the printf call in the signal
handler with a sprintf+write combo, which should not suffer from that
problem (though I wouldn't go as far as to call it async signal safe).
The TestGdbRemote_vContThreads.py were introduced to test NetBSD process
plugin's capability of sending per-thread and per-process signals.
However, at some point the tests started failing. From retrospective,
it is possible that they were relying on some bug in the plugin's
original signal handling.
Fix the tests not to expect the process to terminate after receiving
the signals. Instead, scan for output indicating that the signals were
received and match thread IDs in it. Enable 'signal to all threads'
test everywhere as it works fine on Linux. Add a new test for vCont
packet without specific thread IDs. Introduce a helper function
to cover the common part of tests.
While this does not fix all the problems on NetBSD, it enables a subset
of the tests on other systems. I am planning to add more tests
to the group while implementing multiprocess extension for vCont.
Differential Revision: https://reviews.llvm.org/D98749
Summary:
The request "evaluate" supports a "context" attribute, which is sent by VSCode. The attribute is defined here https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Evaluate
The "clipboard" context is not yet supported by lldb-vscode, so we can forget about it for now. The 'repl' (i.e. Debug Console) and 'watch' (i.e. Watch Expression) contexts must use the expression parser in case the frame's variable path is not enough, as the user expects these expressions to never fail. On the other hand, the 'hover' expression is invoked whenever the user hovers on any keyword on the UI and the user is fine with the expression not being fully resolved, as they know that the 'repl' case is the fallback they can rely on.
Given that the 'hover' expression is invoked many many times without the user noticing it due to it being triggered by the mouse, I'm making it use only the frame's variable path functionality and not the expression parser. This should speed up tremendously the responsiveness of a debug session when the user only sets source breakpoints and inspect local variables, as the entire debug info is not needed to be parsed.
Regarding tests, I've tried to be as comprehensive as possible considering a multi-file project. Fortunately, the results from the "hover" case are enough most of the times.
Differential Revision: https://reviews.llvm.org/D98656
Skip the AVX-related lldb-server test on non-x86 architectures, as they
do not support AVX. While technically the test worked on Linux because
the AVX check would simply return false, other platforms do not provide
such a straightforward way of checking for AVX (especially remotely),
and the results of such check may need to be interpreted specially
for the platform in question.
Differential Revision: https://reviews.llvm.org/D97450
Use realpath() when spawning the executable create_after_attach
to workaround a FreeBSD plugin (and possibly others) problem.
If the executable is started via a path containing a symlink, it is
added to the module list twice -- via the real and apparent path.
This in turn cases the requested breakpoint to resolve twice.
Use realpath() for main program path in lldb-vscode breakpoint tests
to workaround a similar problem. If the passed path does not match
the realpath, lldb-vscode does not report the breakpoints as verified
and causes tests to fail.
Since the underlying problems are non-trivial to fix and the purpose
of these tests is not to reproduce symlink problems, let's apply
trivial workarounds to make them pass.
Differential Revision: https://reviews.llvm.org/D97230
VSCode was not being informed whenever a location had been resolved (after being initated as non-resolved), so even though it was actually resolved, the IDE would show a hollow dot (instead of a red dot) because it didn't know about the change.
Differential Revision: https://reviews.llvm.org/D96680
lldb-server can use a named pipe to communicate the port number it is
listening on. This windows bits of this are already implemented, but we
did not have a test for that, most likely because python does not have
native pipe functionality.
This patch implements the windows bits necessary to test this. I'm using
the ctypes package to call the native APIs directly to avoid a
dependency to non-standard python packages. This introduces some amount
of boilerplate, but our named pipe use case is fairly limited, so we
should not end up needing to wrap large chunks of windows APIs.
Surprisingly to changes to lldb-server were needed to make the test
pass.
Differential Revision: https://reviews.llvm.org/D96260
Although it is located under tools/lldb-server, this test is very
different that other lldb-server tests. The most important distinction
is that it does not test lldb-server directly, but rather interacts with
it through the lldb client. It also tests the relevant client
functionality (the platform connect command, which is even admitted in
the test name). The fact that this test is structured as a lldb-server
test means it cannot access most of the goodies available to the
"normal" lldb tests (the runCmd function, which it reimplements; the
run_break_set_by_symbol utility function; etc.).
This patch makes it a full-fledged lldb this, and rewrites the relevant
bits to make use of the standard features. I also move the test into the
"commands" subtree to better reflect its new status.
I switched the watch simulator test from i386 to using x86_64, but
apparently that's not supported on the bots. Rollback to using i386 and
solve the original issue by passing the target, similar to what I did
in TestSimulatorPlatform.py.
Convert `assertTrue(a == b)` to `assertEqual(a, b)` to produce better failure messages.
These were mostly done via regex search & replace, with some manual fixes.
Differential Revision: https://reviews.llvm.org/D95813
stella.stemenova mentioned in https://reviews.llvm.org/D93951 failures on Windows for this test.
I'm fixing the macro definitions and disabling the tests for python
versions lower than 3.7. I'll figure out that actual issue with
python3.6 after the buildbots are fine again.
Depends on D93874.
runInTerminal was using --wait-for, but it was some problems because it uses process polling looking for a single instance of the debuggee:
- it gets to know of the target late, which renders breakpoints in the main function almost impossible
- polling might fail if there are already other processes with the same name
- polling might also fail on some linux machine, as it's implemented with the ps command, and the ps command's args and output are not standard everywhere
As a better way to implement this so that it works well on Darwin and Linux, I'm using now the following process:
- lldb-vscode notices the runInTerminal, so it spawns lldb-vscode with a special flag --launch-target <target>. This flags tells lldb-vscode to wait to be attached and then it execs the target program. I'm using lldb-vscode itself to do this, because it makes finding the launcher program easier. Also no CMAKE INSTALL scripts are needed.
- Besides this, the debugger creates a temporary FIFO file where the launcher program will write its pid to. That way the debugger will be sure of which program to attach.
- Once attach happend, the debugger creates a second temporary file to notify the launcher program that it has been attached, so that it can then exec. I'm using this instead of using a signal or a similar mechanism because I don't want the launcher program to wait indefinitely to be attached in case the debugger crashed. That would pollute the process list with a lot of hanging processes. Instead, I'm setting a 20 seconds timeout (that's an overkill) and the launcher program seeks in intervals the second tepmorary file.
Some notes:
- I preferred not to use sockets because it requires a lot of code and I only need a pid. It would also require a lot of code when windows support is implemented.
- I didn't add Windows support, as I don't have a windows machine, but adding support for it should be easy, as the FIFO file can be implemented with a named pipe, which is standard on Windows and works pretty much the same way.
The existing test which didn't pass on Linux, now passes.
Differential Revision: https://reviews.llvm.org/D93951
Implements the required functions on gdb-remote so the '--include-existing' flag of process attach works correctly on Linux.
Reviewed By: labath, clayborg
Differential Revision: https://reviews.llvm.org/D94672
lldb-vsdode was communicating the list of modules to the IDE with events, which in practice ended up having some drawbacks
- when debugging large targets, the number of these events were easily 10k, which polluted the messages being transmitted, which caused the following: a harder time debugging the messages, a lag after terminated the process because of these messages being processes (this could easily take several seconds). The latter was specially bad, as users were complaining about it even when they didn't check the modules view.
- these events were rarely used, as users only check the modules view when something is wrong and they try to debug things.
After getting some feedback from users, we realized that it's better to not used events but make this simply a request and is triggered by users whenever they needed.
This diff achieves that and does some small clean up in the existing code.
Differential Revision: https://reviews.llvm.org/D94033
The test couldn't find lldb-server as it's path was being overridden by
LLDB_DEBUGSERVER_PATH environment variable (pointing to debugserver).
This test should always use lldb-server, as it tests its platform
capabilities.
There's no need for the environment override, as lldb-server tests
should test the executable they just built, so I just remote the
override capability.
The test was marked as remote-only, which means it was run ~never, and
accumulated various problems. This commit modifies the test to run
locally and includes a couple of other fixes necessary to make it run:
- moves the "invoke" method into the "Base" test class
- adds []'s around the IP address in a couple more places to make things
work with IPv6
The test is now marked as skipped when running the remote test suite. It
would be possible to make it run both locally and remotely, but this
would require writing a lot special logic for the remote case, and that
is not worth it.
This commit vAttachWait in lldb-server, so --waitfor can be used on
Linux
Reviewed By: labath, clayborg
Differential Revision: https://reviews.llvm.org/D93895
Copy changes, including:
- NativeProcessNetBSD::GetLoadedModuleFileSpec()
and NativeProcessNetBSD::GetFileLoadAddress() methods
- split x86 register sets by CPU extensions
- use offset/size-based register reading/writing
Differential Revision: https://reviews.llvm.org/D93541
The tests don't work with remote debugservers. This isn't a problem with
any particular test, but the test infrastructure itself, which is why
each of these tests has a @skipIfDarwinEmbedded decorator.
This patch replaces that with a central category-based solution. It also
moves the ad-hoc windows skipping mechanism there too.
This uses the same approach as the debug info tests to avoid needing to
explicitly spell out the two kinds of tests. I convert a handful of
tests to the new mechanism. The rest will be converted in follow-up
patches.
Nearly all of our lldb-server tests have two flavours (lldb-server and
debugserver). Each of them is tagged with an appropriate decorator, and
each of them starts with a call to a matching "init" method. The init
calls are mandatory, and it's not possible to meaningfully combine them
with a different decorator.
This patch leverages the existing decorators to also tag the tests with
the appropriate debug server tag, similar to how we do with debug info
flavours. This allows us to make the "init" calls from inside the common
setUp method.
The test appears to expect the inferior to be stopped, but the custom
"attach commands" leave it in a running state.
It's unclear how this could have ever worked.
Explicitly consider the libraries reported on the initial rendezvous
breakpoint hit added. This is necessary on FreeBSD since the dynamic
loader issues only a single 'consistent' state rendezvous breakpoint hit
for all the libraries present in DT_NEEDED. It is also helpful on Linux
where it ensures that ld-linux is considered loaded as well
as the shared system libraries reported afterwards.
Reenable memory maps on FreeBSD since this fixed the issue triggered
by them.
Differential Revision: https://reviews.llvm.org/D92187
This reverts commit 09b08833f301ea375137931d26b7193101f82ceb.
This code is wrong on Linux, and causes ld-linux and linux-vdso to be
reported twice. I need to work on it more.
Explicitly consider the libraries reported on the initial eTakeSnapshot
action added, through adding them to the added soentry list
in DYLDRendezvous::SaveSOEntriesFromRemote(). This is necessary
on FreeBSD since the dynamic loader issues only a single 'consistent'
state rendezvous breakpoint hit for all the libraries present
in DT_NEEDED (while Linux issues an added-consistent event pair).
Reenable memory maps on FreeBSD since this fixed the issue triggered
by them.
Differential Revision: https://reviews.llvm.org/D92187
Now that the class does not use a thread, the name is no longer
appropriate. Rename the class to "Server" and make it a long-lived
object (instead of recreating it for every expect_gdbremote_sequence
call). The idea is to make this class a wrapper for all communication
with debug/lldb-server. This will enable some additional cleanups as we
had some duplication between socket_pump non-pump code paths.
Also squeeze in some small improvements:
- use python-level timeouts on sockets instead of the manual select
calls
- use byte arrays instead of strings when working with raw packets
This patch carries forward our aim to remove offset field from qRegisterInfo
packets and XML register description. I have created a new function which
returns if offset fields are dynamic meaning client can calculate offset on
its own based on register number sequence and register size. For now this
function only returns true for NativeRegisterContextLinux_arm64 but we can
test this for other architectures and make it standard later.
As a consequence we do not send offset field from lldb-server (arm64 for now)
while other stubs dont have an offset field so it wont effect them for now.
On the client side we have replaced previous offset calculation algorithm
with a new scheme, where we sort all primary registers in increasing
order of remote regnum and then calculate offset incrementally.
This committ also includes a test to verify all of above functionality
on Arm64.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91241
This patch ovverides GetExpeditedRegisterSet for
NativeRegisterContextLinux_arm64 to send vector granule register in
expedited register set if SVE mode is selected.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D82855
