History log of /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h (Results 1 – 25 of 53)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4
# faaf2dbf 12-Nov-2024 John Harrison <harjohn@google.com>

[lldb-dap] Refactoring JSONUtils to not use `g_dap` and instead passing in required arguments. (#115561)

This is part of a larger refactor to remove the global `g_dap` variable.


# b99d4112 08-Nov-2024 John Harrison <harjohn@google.com>

[lldb-dap] Refactoring breakpoints to not use the `g_dap` reference. (#115208)

Refactoring breakpoints to not use the `g_dap` reference.

Instead, when a breakpoint is constructed it will be passe

[lldb-dap] Refactoring breakpoints to not use the `g_dap` reference. (#115208)

Refactoring breakpoints to not use the `g_dap` reference.

Instead, when a breakpoint is constructed it will be passed a DAP
reference that it should use for its lifetime.

This is part of a larger refactor to remove the global `g_dap` variable
to allow us to create multiple DAP instances.

---------

Co-authored-by: Pavel Labath <pavel@labath.sk>

show more ...


Revision tags: llvmorg-19.1.3, llvmorg-19.1.2
# 9f8ae784 11-Oct-2024 Adrian Vogelsgesang <avogelsgesang@salesforce.com>

[lldb-dap] Implement value locations for function pointers (#104589)

This commit adds `valueLocationReference` to function pointers and
function references. Thereby, users can navigate directly to

[lldb-dap] Implement value locations for function pointers (#104589)

This commit adds `valueLocationReference` to function pointers and
function references. Thereby, users can navigate directly to the
pointed-to function from within the "variables" pane.

In general, it would be useful to also a add similar location references
also to member function pointers, `std::source_location`,
`std::function`, and many more. Doing so would require extending the
formatters to provide such a source code location.

There were two RFCs about this a while ago:

https://discourse.llvm.org/t/rfc-extending-formatters-with-a-source-code-reference/68375
https://discourse.llvm.org/t/rfc-sbvalue-metadata-provider/68377/26

However, both RFCs ended without a conclusion. As such, this commit now
implements the lowest-hanging fruit, i.e. function pointers. If people
find it useful, I will revive the RFC afterwards.

show more ...


# d4c17891 07-Oct-2024 Da-Viper <57949090+Da-Viper@users.noreply.github.com>

Make env and source map dictionaries #95137 (#106919)

Fixes #95137


Revision tags: llvmorg-19.1.1, llvmorg-19.1.0
# 0cc2cd78 17-Sep-2024 Adrian Vogelsgesang <avogelsgesang@salesforce.com>

[lldb-dap] Provide `declarationLocation` for variables (#102928)

This commit implements support for the "declaration location" recently
added by microsoft/debug-adapter-protocol#494 to the debug ad

[lldb-dap] Provide `declarationLocation` for variables (#102928)

This commit implements support for the "declaration location" recently
added by microsoft/debug-adapter-protocol#494 to the debug adapter
protocol.

For the `declarationLocationReference` we need a variable ID similar to
the `variablesReference`. I decided to simply reuse the
`variablesReference` here and renamed `Variables::expandable_variables`
and friends accordingly. Given that almost all variables have a
declaration location, we now assign those variable ids to all variables.

While `declarationLocationReference` effectively supersedes
`$__lldb_extensions.declaration`, I did not remove this extension, yet,
since I assume that there are some closed-source extensions which rely
on it.

I tested this against VS-Code Insiders. However, VS-Code Insiders
currently only supports `valueLoctionReference` and not
`declarationLocationReference`, yet. Locally, I hence published the
declaration locations as value locations, and VS Code Insiders navigated
to the expected places. Looking forward to proper VS Code support for
`declarationLocationReference`.

show more ...


# 3acb1eac 16-Sep-2024 Adrian Vogelsgesang <avogelsgesang@salesforce.com>

[lldb-dap] Support inspecting memory (#104317)

Add support for the `readMemory` request which allows VS-Code to
inspect memory. Also, add `memoryReference` to variables and `evaluate`
responses, s

[lldb-dap] Support inspecting memory (#104317)

Add support for the `readMemory` request which allows VS-Code to
inspect memory. Also, add `memoryReference` to variables and `evaluate`
responses, such that the binary view can be opened from the variables
view and from the "watch" pane.

show more ...


# 5b4100cc 10-Sep-2024 John Harrison <harjohn@google.com>

[lldb-dap] Improve `stackTrace` and `exceptionInfo` DAP request handlers (#105905)

Refactoring `stackTrace` to perform frame look ups in a more on-demand
fashion to improve overall performance.

[lldb-dap] Improve `stackTrace` and `exceptionInfo` DAP request handlers (#105905)

Refactoring `stackTrace` to perform frame look ups in a more on-demand
fashion to improve overall performance.

Additionally adding additional information to the `exceptionInfo`
request to report exception stacks there instead of merging the
exception stack into the stack trace. The `exceptionInfo` request is
only called if a stop event occurs with `reason='exception'`, which
should mitigate the performance of `SBThread::GetCurrentException`
calls.

Adding unit tests for exception handling and stack trace supporting.

show more ...


Revision tags: llvmorg-19.1.0-rc4
# 89c27d6b 26-Aug-2024 Santhosh Kumar Ellendula <quic_sellendu@quicinc.com>

[lldb-dap] Enabling instruction breakpoint support to lldb-dap. (#105278)

Added support for "supportsInstructionBreakpoints" capability and now it
this command is triggered when we set instruction

[lldb-dap] Enabling instruction breakpoint support to lldb-dap. (#105278)

Added support for "supportsInstructionBreakpoints" capability and now it
this command is triggered when we set instruction breakpoint.
We need this support as part of enabling disassembly view debugging.
Following features should work as part of this feature enablement:

1. Settings breakpoints in disassembly view: Unsetting the breakpoint is
not happening from the disassembly view. Currently we need to unset
breakpoint manually from the breakpoint List. Multiple breakpoints are
getting set for the same $

2. Step over, step into, continue in the disassembly view

The format for DisassembleRequest and DisassembleResponse at
https://raw.githubusercontent.com/microsoft/vscode/master/src/vs/workbench/contrib/debug/common/debugProtocol.d.ts
.

Ref Images:
Set instruction breakpoint in disassembly view:

![image](https://github.com/user-attachments/assets/833bfb34-86f4-40e2-8c20-14b638a612a2)

After issuing continue:

![image](https://github.com/user-attachments/assets/884572a3-915e-422b-b8dd-d132e5c00de6)

---------

Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-hyd.qualcomm.com>
Co-authored-by: Santhosh Kumar Ellendula <sellendu@hu-sellendu-lv.qualcomm.com>

show more ...


Revision tags: 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
# d58c128b 13-Feb-2024 Zequan Wu <zequanwu@google.com>

[lldb-dap][NFC] Add Breakpoint struct to share common logic. (#80753)

This adds a layer between `SounceBreakpoint`/`FunctionBreakpoint` and
`BreakpointBase` to have better separation and encapsulat

[lldb-dap][NFC] Add Breakpoint struct to share common logic. (#80753)

This adds a layer between `SounceBreakpoint`/`FunctionBreakpoint` and
`BreakpointBase` to have better separation and encapsulation so we are
not directly operating on `SBBreakpoint`.

I basically moved the `SBBreakpoint` and the methods that requires it
from `BreakpointBase` to `Breakpoint`. This allows adding support for
data watchpoint easier by sharing the logic inside `BreakpointBase`.

show more ...


Revision tags: llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# 40a361ac 12-Jan-2024 John Harrison <harjohn@google.com>

[lldb-dap] Updating VariableDescription to use GetDescription() as a fallback. (#77026)

When generating a `display_value` for a variable the current approach
calls `SBValue::GetValue()` and `SBValu

[lldb-dap] Updating VariableDescription to use GetDescription() as a fallback. (#77026)

When generating a `display_value` for a variable the current approach
calls `SBValue::GetValue()` and `SBValue::GetSummary()` to generate a
`display_value` for the `SBValue`. However, there are cases where both
of these return an empty string and the fallback is to print a pointer
and type name instead (e.g. `FooBarType @ 0x00321`).

For swift types, lldb includes a langauge runtime plugin that can
generate a description of the object but this is only used with
`SBValue::GetDescription()`.

For example:
```
$ lldb swift-binary
... stop at breakpoint ...
lldb> script
>>> event = lldb.frame.GetValueForVariablePath("event")
>>> print("Value", event.GetValue())
Value None
>>> print("Summary", event.GetSummary())
Summary None
>>> print("Description", event) # __str__ calls SBValue::GetDescription()
Description (main.Event) event = (name = "Greetings", time = 2024-01-04 23:38:06 UTC)
```

With this change, if GetValue and GetSummary return empty then we try
`SBValue::GetDescription()` as a fallback before using the previous
logic of printing `<type> @ <addr>`.

show more ...


# ffd173ba 02-Jan-2024 Walter Erquinigo <a20012251@gmail.com>

[lldb-dap] Emit more structured info along with variables (#75244)

In order to allow smarter vscode extensions, it's useful to send
additional structured information of SBValues to the client.
Spe

[lldb-dap] Emit more structured info along with variables (#75244)

In order to allow smarter vscode extensions, it's useful to send
additional structured information of SBValues to the client.
Specifically, I'm now sending error, summary, autoSummary and
inMemoryValue in addition to the existing properties being sent. This is
cheap because these properties have to be calculated anyway to generate
the display value of the variable, but they are now available for
extensions to better analyze variables. For example, if the error field
is not present, the extension might be able to provide cool features,
and the current way to do that is to look for the `"<error: "` prefix,
which is error-prone.

This also incorporates a tiny feedback from
https://github.com/llvm/llvm-project/pull/74865#issuecomment-1850695477

show more ...


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5
# f175b964 09-Nov-2023 jeffreytan81 <jeffreytan@meta.com>

Improve VSCode DAP logpoint value summary (#71723)

Currently VSCode logpoint uses `SBValue::GetValue` to get the value for
printing. This is not providing an intuitive result for std::string or
ch

Improve VSCode DAP logpoint value summary (#71723)

Currently VSCode logpoint uses `SBValue::GetValue` to get the value for
printing. This is not providing an intuitive result for std::string or
char * -- it shows the pointer value instead of the string content.

This patch improves by prefers `SBValue::GetSummary()` before using
`SBValue::GetValue()`.

---------

Co-authored-by: jeffreytan81 <jeffreytan@fb.com>

show more ...


Revision tags: llvmorg-17.0.4
# 10664813 25-Oct-2023 Walter Erquinigo <a20012251@gmail.com>

[lldb-vscode] Allow specifying a custom escape prefix for LLDB commands (#69238)

We've been using the backtick as our escape character, however that
leads to a weird experience on VS Code, because

[lldb-vscode] Allow specifying a custom escape prefix for LLDB commands (#69238)

We've been using the backtick as our escape character, however that
leads to a weird experience on VS Code, because on most hosts, as soon
as you type the backtick on VS Code, the IDE will introduce another
backtick. As changing the default escape character might be out of
question because other plugins might rely on it, we can instead
introduce an option to change this variable upon lldb-vscode
initialization.
FWIW, my users will be using : instead ot the backtick.

show more ...


# 01263c6c 19-Oct-2023 Jonas Devlieghere <jonas@devlieghere.com>

[lldb] Rename lldb-vscode to lldb-dap (#69264)

Rename lldb-vscode to lldb-dap. This change is largely mechanical. The
following substitutions cover the majority of the changes in this
commit:

[lldb] Rename lldb-vscode to lldb-dap (#69264)

Rename lldb-vscode to lldb-dap. This change is largely mechanical. The
following substitutions cover the majority of the changes in this
commit:

s/VSCODE/DAP/
s/VSCode/DAP/
s/vscode/dap/
s/g_vsc/g_dap/

Discourse RFC:
https://discourse.llvm.org/t/rfc-rename-lldb-vscode-to-lldb-dap/74075/

show more ...


Revision tags: llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0
# cf5d8def 07-Sep-2023 Walter Erquinigo <a20012251@gmail.com>

[lldb-vscode] Show a fake child with the raw value of synthetic types (#65552)

Currently, if the user wants to inspect the raw version of a synthetic
variable, they have to go to the debug console

[lldb-vscode] Show a fake child with the raw value of synthetic types (#65552)

Currently, if the user wants to inspect the raw version of a synthetic
variable, they have to go to the debug console and type `frame var
<variable>`, which is not a great experience. Taking inspiration from
CodeLLDB, this adds a `[raw]` child to every synthetic variable so that
this kind of inspection can be done visually.

Some examples:

<img width="500" alt="Screenshot 2023-09-06 at 7 56 25 PM"
src="https://github.com/llvm/llvm-project/assets/1613874/7fefb7c5-0da7-49c7-968b-78ac88348fea">
<img width="479" alt="Screenshot 2023-09-06 at 6 58 25 PM"
src="https://github.com/llvm/llvm-project/assets/1613874/6e650567-16e1-462f-9bf5-4a3a605cf6fc">

show more ...


Revision tags: llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2
# ca71dc1b 31-Jul-2023 John Harrison <harjohn@google.com>

[lldb-vscode] Adding support for the "disassemble" request.

Instead of creating psuedo source files for each stack frame this change adopts the new DAP “disassemble” request, allowing clients to ins

[lldb-vscode] Adding support for the "disassemble" request.

Instead of creating psuedo source files for each stack frame this change adopts the new DAP “disassemble” request, allowing clients to inspect assembly instructions of files with debug info in addition to files without debug info.

[[ https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Disassemble | spec ]]

See attached screenshot of the disassembly view. {F28473848}

Reviewed By: wallace

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

show more ...


Revision tags: llvmorg-17.0.0-rc1, llvmorg-18-init
# da59370b 06-Jul-2023 John Harrison <harjohn@google.com>

[lldb-vscode] Adding support for column break points.

Reviewed By: wallace

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


Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2
# 53aa22cd 07-Apr-2023 Jorge Gorbe Moya <jgorbe@google.com>

[lldb-vscode] Fix two issues with runInTerminal test.

With ptrace_scope = 1 the kernel only allows tracing descendants of a
process. When using runInTerminal, the target process is not launched
by t

[lldb-vscode] Fix two issues with runInTerminal test.

With ptrace_scope = 1 the kernel only allows tracing descendants of a
process. When using runInTerminal, the target process is not launched
by the debugger, so we need to modify LaunchRunInTerminal to explicitly
allow tracing. This should fix a problem reported in
https://reviews.llvm.org/D84974#3903716

In order to allow only the main lldb-vscode process to attach to the
target, this change introduces a new `--debugger-pid` flag that needs
to be passed with `--launch-target` and `--comm-file`.

Also, remove a special case from the launch method in the
lldbvscode_testcase test harness. The existing test was using
stopOnEntry, so the first stop didn't happen at the expected breakpoint
unless the harness did configurationDone first.

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

show more ...


Revision tags: 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
# 2fe83274 07-Jan-2023 Kazu Hirata <kazu@google.com>

[lldb] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/

[lldb] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/ADT/Optional.h", etc.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


# f190ce62 07-Jan-2023 Kazu Hirata <kazu@google.com>

[lldb] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optiona

[lldb] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


# 343523d0 05-Dec-2022 Kazu Hirata <kazu@google.com>

[lldb] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of ma

[lldb] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


Revision tags: llvmorg-15.0.6
# 22887ff9 16-Nov-2022 Pavel Labath <pavel@labath.sk>

Revert "Send statistics in initialized event"

The test is failing on linux.

This reverts commits 7fe3586cda5b683766ec6b6d5ca2d98c2baaf162 and
d599ac41aabddeb2442db7b31faacf143d63abe4.


Revision tags: llvmorg-15.0.5
# 7fe3586c 16-Nov-2022 George Hu <huyubohyb@gmail.com>

Send statistics in initialized event

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


Revision tags: llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1
# 4bc86ae8 10-Sep-2022 Wanyi Ye <wanyi@fb.com>

[lldb-vscode] Send Selected Statistics Dump in Terminated Event

This patch will gather debug info & breakpoint info from the statistics dump (from `(SBTarget.GetStatistics())` func) and send to DAP

[lldb-vscode] Send Selected Statistics Dump in Terminated Event

This patch will gather debug info & breakpoint info from the statistics dump (from `(SBTarget.GetStatistics())` func) and send to DAP in terminated event.

The statistics content can be huge (especially the `modules`) and dumping in full JSON can create delay in the IDE's debugging UI. (For more details, please read: https://github.com/llvm/llvm-project/commit/7bbd0fba986c241162b77b7e424ad82bc7e17b41 ). Hence, we will filter out large contents before returning it in terminated event.

It will keep all the metadata fields (those starts with "total"). For large contents, it uses the opt-out strategy. Currently it only removes the "modules" field. This way every time a new top-level field being added, we will be able to capture them from DAP log without changing lldb-vscode.

The DAP terminated event should look like
```
{
"event":"terminated",
"seq":0,
"statistics": {
"memory": <JSON string>
"targets": <JSON string>, // it's a JSON array, breakpoints info included in each target
<metadata_key: value> // pairs
},
"type":"event"
}
```

All the info above will be append to statistics field in the terminated event

Test Plan

Debugged a simple hello world program from VSCode. Exit debug session in two ways: 1) run to program exit; 2) user initiated debug session end (quit debugging before program exit).
Check DAP log and see both debug sessions have statistics returned in terminated event.

Here's an example when debugging the test program:

```
{"event":"terminated","seq":0,"statistics":{"memory":"{\"strings\":{\"bytesTotal\":1843200,\"bytesUnused\":897741,\"bytesUsed\":945459}}","targets":"[{\"breakpoints\":[{\"details\":{\"Breakpoint\":{\"BKPTOptions\":{\"AutoContinue\":false,\"ConditionText\":\"\",\"EnabledState\":true,\"IgnoreCount\":0,\"OneShotState\":false},\"BKPTResolver\":{\"Options\":{\"NameMask\":[56],\"Offset\":0,\"SkipPrologue\":true,\"SymbolNames\":[\"foo\"]},\"Type\":\"SymbolName\"},\"Hardware\":false,\"Names\":[\"vscode\"],\"SearchFilter\":{\"Options\":{},\"Type\":\"Unconstrained\"}}},\"id\":1,\"internal\":false,\"numLocations\":1,\"numResolvedLocations\":1,\"resolveTime\":0.002232},{\"details\":{\"Breakpoint\":{\"BKPTOptions\":{\"AutoContinue\":false,\"ConditionText\":\"\",\"EnabledState\":true,\"IgnoreCount\":0,\"OneShotState\":false},\"BKPTResolver\":{\"Options\":{\"Column\":0,\"Exact\":false,\"FileName\":\"/data/users/wanyi/llvm-sand/external/llvm-project/lldb/test/API/tools/lldb-vscode/terminated-event/main.cpp\",\"Inlines\":true,\"LineNumber\":5,\"Offset\":0,\"SkipPrologue\":true},\"Type\":\"FileAndLine\"},\"Hardware\":false,\"Names\":[\"vscode\"],\"SearchFilter\":{\"Options\":{},\"Type\":\"Unconstrained\"}}},\"id\":2,\"internal\":false,\"numLocations\":0,\"numResolvedLocations\":0,\"resolveTime\":0.23203799999999999},{\"details\":{\"Breakpoint\":{\"BKPTOptions\":{\"AutoContinue\":false,\"ConditionText\":\"\",\"EnabledState\":true,\"IgnoreCount\":0,\"OneShotState\":false},\"BKPTResolver\":{\"Options\":{\"Language\":\"c\",\"NameMask\":[4,4,4,4,4,4],\"Offset\":0,\"SkipPrologue\":false,\"SymbolNames\":[\"_dl_debug_state\",\"rtld_db_dlactivity\",\"__dl_rtld_db_dlactivity\",\"r_debug_state\",\"_r_debug_state\",\"_rtld_debug_state\"]},\"Type\":\"SymbolName\"},\"Hardware\":false,\"SearchFilter\":{\"Options\":{\"ModuleList\":[\"/usr/lib64/ld-2.28.so\"]},\"Type\":\"Modules\"}}},\"id\":-1,\"internal\":true,\"kindDescription\":\"shared-library-event\",\"numLocations\":1,\"numResolvedLocations\":1,\"resolveTime\":0.00026699999999999998}],\"expressionEvaluation\":{\"failures\":0,\"successes\":0},\"firstStopTime\":0.087458974999999994,\"frameVariable\":{\"failures\":0,\"successes\":0},\"launchOrAttachTime\":0.052953161999999998,\"moduleIdentifiers\":[94554748126576,94554747837792,94554747149216,139800112130176,139800112161056,139800112206064,139800112340224,139800112509552,139800112236528],\"signals\":[{\"SIGSTOP\":1}],\"sourceMapDeduceCount\":0,\"stopCount\":8,\"targetCreateTime\":0.00057700000000000004,\"totalBreakpointResolveTime\":0.234537}]","totalDebugInfoByteSize":1668056,"totalDebugInfoEnabled":3,"totalDebugInfoIndexLoadedFromCache":0,"totalDebugInfoIndexSavedToCache":0,"totalDebugInfoIndexTime":0.027963000000000002,"totalDebugInfoParseTime":0.34354800000000002,"totalModuleCount":10,"totalModuleCountHasDebugInfo":3,"totalSymbolTableIndexTime":0.056050000000000003,"totalSymbolTableParseTime":0.23930000000000001,"totalSymbolTableStripped":0,"totalSymbolTablesLoadedFromCache":0,"totalSymbolTablesSavedToCache":0},"type":"event"}
```

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

show more ...


# 03c7cd3a 04-Nov-2022 George Hu <huyubohyb@gmail.com>

Revert "[lldb-vscode] Send Statistics Dump in terminated event"

This reverts commit e3ccbae309273900a42e30b606c15c873d57f1ea.

There is a bug which is failing the test running on mac.


123