[lldb][tests] Automatically call compute_mydir (NFC)

Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.

Differential Revision: https://r

[lldb][tests] Automatically call compute_mydir (NFC)

Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.

Differential Revision: https://reviews.llvm.org/D128077

show more ...

Fix race condition when launching and attaching.

This is a modified version of a previous patch that was reverted: https://reviews.llvm.org/D119797
This version only waits for the process to stop wh

Fix race condition when launching and attaching.

This is a modified version of a previous patch that was reverted: https://reviews.llvm.org/D119797
This version only waits for the process to stop when using "launchCommands" or "attachCommands"...

...and doesn't play with the async mode when doing normal launch/attach.

We discovered that when using "launchCommands" or "attachCommands" that there was an issue where these commands were not being run synchronously. There were further problems in this case where we would get thread events for the process that was just launched or attached before the IDE was ready, which is after "configurationDone" was sent to lldb-vscode.

This fix introduces the ability to wait for the process to stop after "launchCommands" or "attachCommands" are run to ensure that we have a stopped process point that is ready for the debug session to proceed. We spin up the thread that listens for process events before we start the launch or attach, but we don't want stop events being delivered through the DAP protocol until the "configurationDone" packet is received. We now always ignore the stop event with a stop ID of 1, which is the first stop. All normal launch and attach scenarios use the synchronous mode, and "launchCommands and "attachCommands" run an array of LLDB commands in async mode.

This should make our launch with "launchCommands" and attach with "attachCommands" avoid a race condition when the process is being launched or attached.

Differential Revision: https://reviews.llvm.org/D120755

show more ...

Revert "Fix race condition when launching and attaching."

It breaks TestVSCode_attach.py.

This reverts commit 9febd1e573fb8b3d1de5844b7bfd33eb998f0106 and
38054556a08884aa15d3ebc720e2f43d0cb5a944.

Fix race condition when launching and attaching.

We discovered that when using "launchCommands" or "attachCommands" that there was an issue where these commands were not being run synchronously. The

Fix race condition when launching and attaching.

We discovered that when using "launchCommands" or "attachCommands" that there was an issue where these commands were not being run synchronously. There were further problems in this case where we would get thread events for the process that was just launched or attached before the IDE was ready, which is after "configurationDone" was sent to lldb-vscode.

This fix introduces the ability to wait for the process to stop after the run or attach to ensure that we have a stopped process at the entry point that is ready for the debug session to proceed. This also allows us to run the normal launch or attach without needing to play with the async flag the debugger. We spin up the thread that listens for process events before we start the launch or attach, but we stop the first eStateStopped (with stop ID of zero) event from being delivered through the DAP protocol because the "configurationDone" request handler will deliver it manually as the IDE expects a stop after configuration done. The request_configurationDone will also only deliver the stop packet if the "stopOnEntry" is False in the launch configuration.

Also added a new "timeout" to the launch and attach launch configuration arguments that can be set and defaults to 30 seconds. Since we now poll to detect when the process is stopped, we need a timeout that can be changed in case certain workflows take longer that 30 seconds to attach. If the process is not stopped by the timeout, an error will be retured for the launch or attach.

Added a flag to the vscode.py protocol classes that detects and ensures that no "stopped" events are sent prior to "configurationDone" has been sent and will raise an error if it does happen.

This should make our launching and attaching more reliable and avoid some deadlocks that were being seen (https://reviews.llvm.org/D119548).

Differential Revision: https://reviews.llvm.org/D119797

show more ...

[NFC][lldb-vscode] Fix launch test

Using br for creating breakpoints fails if there are other commands that
start with br.

[lldb-vscode] remove failed test

Found in http://green.lab.llvm.org/green/job/lldb-cmake/32891/testReport/lldb-api/tools_lldb-vscode_launch/TestVSCode_launch_py/

the lldb-vscode changed and that te

[lldb-vscode] remove failed test

Found in http://green.lab.llvm.org/green/job/lldb-cmake/32891/testReport/lldb-api/tools_lldb-vscode_launch/TestVSCode_launch_py/

the lldb-vscode changed and that test makes no sense anymore

show more ...

Fix TestVSCode_launch test

Broken in https://lab.llvm.org/buildbot/#/builders/96/builds/6933

We don't really need to run this test on arm, but would be worth fixing
it later.

[lldb-vscode] Add postRunCommands

This diff ass postRunCommands, which are the counterpart of the preRunCommands. TThey will be executed right after the target is launched or attached correctly, whi

[lldb-vscode] Add postRunCommands

This diff ass postRunCommands, which are the counterpart of the preRunCommands. TThey will be executed right after the target is launched or attached correctly, which means that the targets can assume that the target is running.

Differential Revision: https://reviews.llvm.org/D100340

show more ...

[lldb] Re-skip TestVSCode_launch

The test is flaky (sleeps didn't help).

[LLDB] Sleep for 5 second TestVSCode_launch test_progress_events

This increases sleep time to 5 seconds as the test still fails
intermittently. If failure persists then we will disable/fix the
test.

[LLDB] Fix sync issue in TestVSCode_launch.test_progress_events

This fixes flakiness in TestVSCode_launch.test_progress_events
vscode.progress_events some times failed to populate in time for
follow

[LLDB] Fix sync issue in TestVSCode_launch.test_progress_events

This fixes flakiness in TestVSCode_launch.test_progress_events
vscode.progress_events some times failed to populate in time for
follow up iterations.

Adding a minor delay before the the for the loop fixes the issue.

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D99497

show more ...

[lldb] Skip TestVSCode_launch.test_progress_events on linux

It's flaky everywhere, not just arm.

[LLDB] Skip TestVSCode_launch.test_progress_events arm/linux

TestVSCode_launch.test_progress_events is mysteriously failing on arm
linux. I am marking it skipped for the buildbot while looking into

[LLDB] Skip TestVSCode_launch.test_progress_events arm/linux

TestVSCode_launch.test_progress_events is mysteriously failing on arm
linux. I am marking it skipped for the buildbot while looking into
failure.

show more ...

[lldb] Fix TestVSCode.test_progress_events on Linux due to vdso

This currently fails when we get the module for `[vdso]` which doesn't have
any parsing event associated with it as it's just created

[lldb] Fix TestVSCode.test_progress_events on Linux due to vdso

This currently fails when we get the module for `[vdso]` which doesn't have
any parsing event associated with it as it's just created from memory.

show more ...

Add a progress class that can track long running operations in LLDB.

LLDB can often appear deadlocked to users that use IDEs when it is indexing DWARF, or parsing symbol tables. These long running o

Add a progress class that can track long running operations in LLDB.

LLDB can often appear deadlocked to users that use IDEs when it is indexing DWARF, or parsing symbol tables. These long running operations can make a debug session appear to be doing nothing even though a lot of work is going on inside LLDB. This patch adds a public API to allow clients to listen to debugger events that report progress and will allow UI to create an activity window or display that can show users what is going on and keep them informed of expensive operations that are going on inside LLDB.

Differential Revision: https://reviews.llvm.org/D97739

show more ...

[lldb] Use assertIn/NotIn over assertTrue/False (NFC)

For improved failure messages, use `assertIn` over `assertTrue`.

Differential Revision: https://reviews.llvm.org/D96095

[lldb] [test] Link FreeBSD test failures to bugs

Differential Revision: https://reviews.llvm.org/D92740

[lldb] [test] Update XFAILs/skips for FreeBSD

Update expected failures and test skips based on common results
for the old and new FreeBSD plugins.

[LLDB] Disable lldb-vscode test_terminate_commands test on Arm

Summary:
test_terminate_commands is flaky on LLDB Arm buildbot as well. It was already
being skipped for aarch64. I am going to mark it

[LLDB] Disable lldb-vscode test_terminate_commands test on Arm

Summary:
test_terminate_commands is flaky on LLDB Arm buildbot as well. It was already
being skipped for aarch64. I am going to mark it skipped for Arm too.

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D81978

show more ...

Disable a flaky lldb-vscode test on aarch64

Summary:
These tests isflaky only on this arch for some reason. It's testing important features and is not flaky on x86_64, so I'll investigate this arm i

Disable a flaky lldb-vscode test on aarch64

Summary:
These tests isflaky only on this arch for some reason. It's testing important features and is not flaky on x86_64, so I'll investigate this arm issue separatedly.

A flaky run:
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/5540/steps/test/logs/stdio

Diff that created those tests:
https://reviews.llvm.org/D81978

show more ...

Redo of Add terminateCommands to lldb-vscode protocol

Summary:
This redoes https://reviews.llvm.org/D79726 and fixes two things.
- The logic that determines whether to automatically disconnect durin

Redo of Add terminateCommands to lldb-vscode protocol

Summary:
This redoes https://reviews.llvm.org/D79726 and fixes two things.
- The logic that determines whether to automatically disconnect during the tear down is not very dumb compared to the original implementation. Each test will determine whether to do that or not.
- The terminate commands and terminate event were being sent after the disconnect response was sent to the IDE. That was not good, as VSCode stops the debug session as soon as it receives a disconnect response. Now, the terminate event and terminateEvents are being executed before the disconnect response is sent. This ensures that any connection between the IDE and lldb-vscode is alive while the terminate commands are executed. Besides, it also allows displaying the output of the terminate commands on the debug console, as it's still alive.

Reviewers: clayborg, aadsm, kusmour, labath

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D81978

show more ...

Revert "Add terminateCommands to lldb-vscode protocol"

This reverts commit a3609b0ec68522cb417ffe36ce9eb2e25ca61578, because it
makes a number of lldb-vscode tests flaky.

Add terminateCommands to lldb-vscode protocol

Summary: Adding this in line with "stopCommands" and "exitCommands" so that we can run commands at the end of the debugging session.

Reviewers: claybor

Add terminateCommands to lldb-vscode protocol

Summary: Adding this in line with "stopCommands" and "exitCommands" so that we can run commands at the end of the debugging session.

Reviewers: clayborg, wallace, labath

Reviewed By: clayborg, labath

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D79726

show more ...

[lldb] NFC: Fix trivial typo in comments, documents, and messages

Differential Revision: https://reviews.llvm.org/D77460

[lldb-vscode] stop read loop after termination

Summary:
On Linux, when executing lldb-vscode on a remote machine, lldb-vscode doesn't die after the debug session ends. It keeps trying to read JSON i

[lldb-vscode] stop read loop after termination

Summary:
On Linux, when executing lldb-vscode on a remote machine, lldb-vscode doesn't die after the debug session ends. It keeps trying to read JSON input to no avail.
This diff indicates lldb-vscode to stop reading after a termination event has been processed.

Reviewers: clayborg, aadsm, kusmour

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D76314

show more ...