Changes in JSONUtils.h

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

Tue, 12 Nov 2024 17:15:58 +0000

[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. List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Fri, 08 Nov 2024 21:36:25 +0000

[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 List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Fri, 11 Oct 2024 01:31:26 +0000

[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. List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Mon, 07 Oct 2024 16:38:36 +0000

Make env and source map dictionaries #95137 (#106919)Fixes #95137 List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Tue, 17 Sep 2024 00:18:52 +0000

[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`. List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Mon, 16 Sep 2024 20:56:20 +0000

[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. List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Tue, 10 Sep 2024 19:40:20 +0000

[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. List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Mon, 26 Aug 2024 18:49:39 +0000

[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 Co-authored-by: Santhosh Kumar Ellendula List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Tue, 13 Feb 2024 16:38:02 +0000

[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`. List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Fri, 12 Jan 2024 22:12:30 +0000

[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 ` @ `. List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Tue, 02 Jan 2024 18:06:13 +0000

[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 `"

f175b9647ccdfd67300264b2d3bd76e6f9a3fb93 - Improve VSCode DAP logpoint value summary (#71723)

Thu, 09 Nov 2023 00:48:55 +0000

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 List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Wed, 25 Oct 2023 04:05:54 +0000

[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. List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Thu, 19 Oct 2023 16:48:54 +0000

[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/ List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Thu, 07 Sep 2023 00:13:48 +0000

[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 `, 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: List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Mon, 31 Jul 2023 16:44:06 +0000

[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: wallaceDifferential Revision: https://reviews.llvm.org/D156493 List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Thu, 06 Jul 2023 19:54:13 +0000

[lldb-vscode] Adding support for column break points.Reviewed By: wallaceDifferential Revision: https://reviews.llvm.org/D154029 List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Fri, 07 Apr 2023 20:34:16 +0000

[lldb-vscode] Fix two issues with runInTerminal test.With ptrace_scope = 1 the kernel only allows tracing descendants of aprocess. When using runInTerminal, the target process is not launchedby the debugger, so we need to modify LaunchRunInTerminal to explicitlyallow tracing. This should fix a problem reported inhttps://reviews.llvm.org/D84974#3903716In order to allow only the main lldb-vscode process to attach to thetarget, this change introduces a new `--debugger-pid` flag that needsto be passed with `--launch-target` and `--comm-file`.Also, remove a special case from the launch method in thelldbvscode_testcase test harness. The existing test was usingstopOnEntry, so the first stop didn't happen at the expected breakpointunless the harness did configurationDone first.Differential Revision: https://reviews.llvm.org/D147805 List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

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

Sat, 07 Jan 2023 22:18:35 +0000

[lldb] Use std::optional instead of llvm::Optional (NFC)This patch replaces (llvm::|)Optional< with std::optional<. I'll posta 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 tostd::optional:https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h

f190ce625ab0dc5a5e2b2515e6d26debb34843ab - [lldb] Add #include (NFC)

Sat, 07 Jan 2023 21:43:00 +0000

[lldb] Add #include (NFC)This patch adds #include to those files containingllvm::Optional<...> or Optional<...>.I'll post a separate patch to actually replace llvm::Optional withstd::optional.This is part of an effort to migrate from llvm::Optional tostd::optional:https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 List of files: /llvm-project/lldb/tools/lldb-vscode/JSONUtils.h