|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
24f9a2f5 |
| 31-Mar-2022 |
Shafik Yaghmour <[email protected]> |
[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB
Applied modernize-use-equals-default clang-tidy check over LLDB.
This check is already present in the lldb/.clang-tidy config.
Dif
[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB
Applied modernize-use-equals-default clang-tidy check over LLDB.
This check is already present in the lldb/.clang-tidy config.
Differential Revision: https://reviews.llvm.org/D121844
show more ...
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
| #
63e51210 |
| 27-Feb-2022 |
Greg Clayton <[email protected]> |
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 ...
|
| #
0ff29057 |
| 01-Mar-2022 |
Stephane Moore <[email protected]> |
[lldb] Hyphenate Objective-C exception breakpoint labels ✍️
Objective-C is officially hyphenated:
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/i
[lldb] Hyphenate Objective-C exception breakpoint labels ✍️
Objective-C is officially hyphenated:
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html#//apple_ref/doc/uid/TP30001163
Reviewed By: mwyman, clayborg
Differential Revision: https://reviews.llvm.org/D113616
show more ...
|
| #
a59014b7 |
| 18-Feb-2022 |
Pavel Labath <[email protected]> |
Revert "Fix race condition when launching and attaching."
It breaks TestVSCode_attach.py.
This reverts commit 9febd1e573fb8b3d1de5844b7bfd33eb998f0106 and
38054556a08884aa15d3ebc720e2f43d0cb5a944.
|
| #
9febd1e5 |
| 15-Feb-2022 |
Greg Clayton <[email protected]> |
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 ...
|
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
| #
b9139acb |
| 03-Aug-2021 |
Jeffrey Tan <[email protected]> |
Fix expression evaluation result expansion in lldb-vscode
VScode now sends a "scopes" DAP request immediately after any expression evaluation.
This scopes request would clear and invalidate any non-
Fix expression evaluation result expansion in lldb-vscode
VScode now sends a "scopes" DAP request immediately after any expression evaluation.
This scopes request would clear and invalidate any non-scoped expandable variables in g_vsc.variables, causing later "variables" request to return empty result.
The symptom is that any expandable variables in VScode watch window/debug console UI to return empty content.
This diff fixes this issue by only clearing the expandable variables at process continue time. To achieve this, we have to repopulate all scoped variables
during context switch for each "scopes" request without clearing global expandable variables.
So the PR puts the scoped variables into its own locals/globals/registers; and all expandable variables into separate "expandableVariables" list.
Also, instead of using the variable index for "variableReference", it generates a new variableReference id each time as the key of "expandableVariables".
As a further new feature, this PR adds a new "expandablePermanentVariables" which has the lifetime of debug session. Any expandable variables from debug console
are added into this list. This enables users to snapshot expanable old variable in debug console and compare with new variables if desire.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D105166
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
| #
bff2b9ad |
| 30-Apr-2021 |
Walter Erquinigo <[email protected]> |
Retry of [lldb-vscode] only report long running progress events
This time adding a check that should prevent the crash found in
https://lab.llvm.org/buildbot/#/builders/68/builds/14182/steps/6/logs/
Retry of [lldb-vscode] only report long running progress events
This time adding a check that should prevent the crash found in
https://lab.llvm.org/buildbot/#/builders/68/builds/14182/steps/6/logs/stdio
Differential Revision: https://reviews.llvm.org/D101128
show more ...
|
| #
f84615a5 |
| 22-Jun-2021 |
Walter Erquinigo <[email protected]> |
Revert "[lldb-vscode] only report long running progress events"
This reverts commit 610d474cfd82f11dc4702e2cf1b2485584d7c243.
lldb-vscode is crashing.
|
| #
610d474c |
| 30-Apr-2021 |
Walter Erquinigo <[email protected]> |
[lldb-vscode] only report long running progress events
When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it
[lldb-vscode] only report long running progress events
When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it
irresponsive while it's processing all this data. As these small jobs
take less than a second to process, the user doesn't even see them,
because the IDE only display the progress of long operations. So it's
better not to send these events.
I'm fixing that by sending only the events that are taking longer than 5
seconds to process.
In a specific run, I got the number of events from ~500k to 100, because
there was only 1 big lib to parse.
I've tried this on several small and massive targets, and it seems to
work fine.
Differential Revision: https://reviews.llvm.org/D101128
show more ...
|
| #
28d9fd00 |
| 21-Jun-2021 |
Walter Erquinigo <[email protected]> |
Revert "[lldb-vscode] attempt to fix flakiness"
Revert "[lldb-vscode] only report long running progress events"
This reverts commit f2c009dbcfd11fd1e8941513dcf49fffe43565a1.
This reverts commit aa46
Revert "[lldb-vscode] attempt to fix flakiness"
Revert "[lldb-vscode] only report long running progress events"
This reverts commit f2c009dbcfd11fd1e8941513dcf49fffe43565a1.
This reverts commit aa4685c0fb3aab5acb90be5fd3eb5ba8bf1e3211.
show more ...
|
| #
aa4685c0 |
| 30-Apr-2021 |
Walter Erquinigo <[email protected]> |
[lldb-vscode] only report long running progress events
When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it
[lldb-vscode] only report long running progress events
When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it
irresponsive while it's processing all this data. As these small jobs
take less than a second to process, the user doesn't even see them,
because the IDE only display the progress of long operations. So it's
better not to send these events.
I'm fixing that by sending only the events that are taking longer than 5
seconds to process.
In a specific run, I got the number of events from ~500k to 100, because
there was only 1 big lib to parse.
I've tried this on several small and massive targets, and it seems to
work fine.
Differential Revision: https://reviews.llvm.org/D101128
show more ...
|
| #
76e47d48 |
| 26-May-2021 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivale
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
show more ...
|
| #
cc88d301 |
| 14-Apr-2021 |
Walter Erquinigo <[email protected]> |
[lldb-vscode] Reduce chattiness of progress events
Progress events internally have a completed count and a total count, which can mean that for a job with 20000 total counts, then there will be 2000
[lldb-vscode] Reduce chattiness of progress events
Progress events internally have a completed count and a total count, which can mean that for a job with 20000 total counts, then there will be 20000 events fired. Sending all these events to the IDE can break it. For example, debugging a huge binary resulted in around 50 million messages, which rendered the IDE useless, as it was spending all of its resources simply parsing messages and updating the UI.
A way to fix this is to send unique percentage updates, which are at most 100 per job, which is not much. I was able to debug that big target and confirm that only unique percentage notifications are sent. I can't write a test for this because the current test is flaky. I'll figure out later how to make the test reliable, but fixing this will unblock us from deploy a new version of lldb-vscode.
Differential Revision: https://reviews.llvm.org/D100443
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3 |
|
| #
e122877f |
| 01-Mar-2021 |
Greg Clayton <[email protected]> |
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 ...
|
|
Revision tags: llvmorg-12.0.0-rc2 |
|
| #
36496cc2 |
| 04-Feb-2021 |
Walter Erquinigo <[email protected]> |
[lldb-vscode] correctly use Windows macros
@mstorsjo found a mistake that I made when trying to fix some Windows
compilation errors encountered by @stella.stamenova.
I was incorrectly using the LLV
[lldb-vscode] correctly use Windows macros
@mstorsjo found a mistake that I made when trying to fix some Windows
compilation errors encountered by @stella.stamenova.
I was incorrectly using the LLVM_ON_UNIX macro. In any case, proper use
of
#if defined(_WIN32)
should be the actual fix.
Differential Revision: https://reviews.llvm.org/D96060
show more ...
|
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3 |
|
| #
0bca9a7c |
| 28-Jan-2021 |
Walter Erquinigo <[email protected]> |
Fix lldb-vscode builds on Windows targeting POSIX
@stella.stamenova found out that lldb-vscode's Win32 macros were failing
when building on windows targetings POSIX platforms.
I'm changing these ma
Fix lldb-vscode builds on Windows targeting POSIX
@stella.stamenova found out that lldb-vscode's Win32 macros were failing
when building on windows targetings POSIX platforms.
I'm changing these macros for LLVM_ON_UNIX, which should be more
accurate.
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1 |
|
| #
39239f9b |
| 04-Jan-2021 |
Walter Erquinigo <[email protected]> |
[lldb-vscode] improve modules request
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 n
[lldb-vscode] improve modules request
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
show more ...
|
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
| #
132e57bc |
| 02-Sep-2020 |
Walter Erquinigo <[email protected]> |
Retry of D84974
- Fix a small issue caused by a conflicting name (GetObject) on Windows.
The fix was to rename the internal GetObject function to
GetNextFunction.
|
| #
5c463d10 |
| 08-Sep-2020 |
Walter Erquinigo <[email protected]> |
Revert "Retry of D84974"
This reverts commit 5b2b4f331d78f326e5e29166bec5ad92c864343d.
This caused a link error in
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/18794/steps/build/
Revert "Retry of D84974"
This reverts commit 5b2b4f331d78f326e5e29166bec5ad92c864343d.
This caused a link error in
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/18794/steps/build/logs/stdio
show more ...
|
| #
5b2b4f33 |
| 02-Sep-2020 |
Walter Erquinigo <[email protected]> |
Retry of D84974
The test is being disabled on Linux, as lldb-vscode has a bug with
--wait-for on LInux.
I'm also fixing some compilation warnings.
|
| #
5f6ca065 |
| 03-Sep-2020 |
Walter Erquinigo <[email protected]> |
Revert de6caf871be79dc7549aebe4e4fb57d52f6ed202 and 51128b670d4f757132e927c4f3dd78d257d37f70 (https://reviews.llvm.org/D84974)
The tests seem to be timing out in all linux bots. Need further analysi
Revert de6caf871be79dc7549aebe4e4fb57d52f6ed202 and 51128b670d4f757132e927c4f3dd78d257d37f70 (https://reviews.llvm.org/D84974)
The tests seem to be timing out in all linux bots. Need further analysis.
Revert "run in terminal"
This reverts commit de6caf871be79dc7549aebe4e4fb57d52f6ed202.
show more ...
|
| #
de6caf87 |
| 02-Sep-2020 |
Walter Erquinigo <[email protected]> |
run in terminal
|
|
Revision tags: llvmorg-11.0.0-rc2 |
|
| #
99614d41 |
| 17-Aug-2020 |
Walter Erquinigo <[email protected]> |
[lldb-vscode] NFC: clang format
Run clang-format on all the c++ file of this project.
|
|
Revision tags: llvmorg-11.0.0-rc1, llvmorg-12-init |
|
| #
77c9aafc |
| 13-Jul-2020 |
Walter Erquinigo <[email protected]> |
Retry ""[lldb-vscode] Fix TestVSCode_module""
Original commit c60216db15132401ff60c08ccef899321f63b6b6.
The test can only run on Darwin because of how it was setup, so I'm
enforcing that.
Summary:
Retry ""[lldb-vscode] Fix TestVSCode_module""
Original commit c60216db15132401ff60c08ccef899321f63b6b6.
The test can only run on Darwin because of how it was setup, so I'm
enforcing that.
Summary:
Test Plan:
Reviewers:
Subscribers:
Tasks:
Tags:
show more ...
|
| #
c60216db |
| 11-Jul-2020 |
Walter Erquinigo <[email protected]> |
Revert "[lldb-vscode] Fix TestVSCode_module"
This reverts commit 881af6eb0030986876d3b80668193e5c3c04a87c.
Revert "[lldb-vscode] Add Compile Unit List to Modules View"
This reverts commit 03ef61033f
Revert "[lldb-vscode] Fix TestVSCode_module"
This reverts commit 881af6eb0030986876d3b80668193e5c3c04a87c.
Revert "[lldb-vscode] Add Compile Unit List to Modules View"
This reverts commit 03ef61033ff5e1e40518f14f642e4ad8d686974c.
Revert "[lldb-vscode] Add Support for Module Event"
This reverts commit f7f80159753ba725f7e32529fcc369bc358efbb3.
The debian buildbot has reported issues with the modules test.
http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/13767/steps/test/logs/stdio
Reverting it for now.
show more ...
|