Support LLDB-DAP as a debugger (OSX/Linux/Windows)

[fearthecowboy]

This adds the ability to debug processes via LLDB using the LLDB-DAP adapter that is bundled with LLVM's LLDB debugger.

This includes:

• additions to the options schema to support the cpplldb debug type
• refinements to the process picker (and ps/cim code) so that the user can actually identify the process they are selecting.
  • the ps code was returning items that were not clear as to which process was which. It now gets the full path of the process if at all possible.
  • expands the length of process arguments to get a better representation of the command line
• some new common code:
  • for searching the PATH for a binary (with predicate to verify on the fly)
  • for searching folders for a binary (with predicate)
  • added a note function to the logger that sets a transient message in the status bar.
• created a links.ts as central place to store links (there are others embedded in the code that should be moved, and then they should all be aka.ms links for security)
• allow the user to specify a program with attach so that the processes can be filtered to what they expect.
• cleaned up use of string constants cppdbg and cppvsdbg so that they use the constants that exist already.
• translates the cpplldb options to lldb-dap options on the fly
• some changes to the debug configuration generation to improve clarity of which debugger is being enabled.
• refactored ConfigurationProvider code so that it's not string-smashing to write JSON.
• LLDB-DAP specific work:
  • it will scan the system to find the LLDB-DAP path by searching the PATH, using xcrun (on OSX) and searching secure/well-known-locations to find the binary
  • it tests any found binary since LLDB-DAP has a dependency on Python3 (and SPECIFICALLY Python310 on Windows) - and if that's not found it doesn't run or say anything.
  • searches for lldb-dap, lldb-dap-##, lldb-vscode, and lldb-vscode-## to support different named binaries (especially on linux)

Important Notes

• the cppvsdbg debugger on Windows can debug LLVM compiled binaries very well, and there is really no reason you want to use the LLDB-DAP on windows - it's just not as good as the other platforms. It's sluggish and has problems with step over and other things.

• LLDB-DAP on windows has a dependency of Python310 - which means if your Python3 installed by the store or whereever is not 3.10 but say 3.13 - it won't work. To fix that, you can run this from an elevated command line:

  • curl https://www.python.org/ftp/python/3.10.11/python-3.10.11-embed-amd64.zip --output - | tar x -C c:\program files\llvm\bin -- this will download the right binary and unpack it into the correct folder -- but this is really a hack.

[sean-mcmanus]

List of issues to investigate/fix:

• Extension host crashes?/aborts when debugging the TypeScript on Windows/Mac/(not Linux). This makes it very difficult to debug both this issue and other issues, i.e. depending on where breakpoints are set it may or may not exit out. It seems like some threading issue, but I don't know how to track it down.
• With the vsix (or when the early exit above isn't hit) it gets stuck with an endless progress bar until Reload Window is done (stop button doesn't work). On Linux, I see it start working after around 20 seconds when compiled with clang++ with a hello world app (not sure if that's the same root issue in the "endless case"), but with g++ it is fast/immediate to start (not sure if there any thing special to investigate for the g++ case).
• Other times on Mac (only?) when I don't hit the above 2 issues, I get the error "Couldn't find a debug adapter descriptor for debug type 'cpplldb' (extension might have failed to activate" and in the bottom right, "No LLDB-DAP debugger found".
• On Mac, I see the Debug Active file button have no effect when clicked.
• Regression: clang compilers are not longer available from the Debug File quickpick (Windows/Mac/Linux).
• Regression: debugging with lldb-mi no longer works and isn't available (Windows only?). But I'm seeing lldb-mi not fully working with 1.26.1, but I see it at least start and show Debug Console logging.
• On Windows (not sure about Linux/Mac yet), using the Debug File only shows Windows and gdb Launch options and not lldb-dap (the bullet point above covers lldb-mi being missing), which seems like a bug to me, and unrelated to the "default" scenario where lldb-mi might be chosen previously.
• The lldb-dap versus LLDB-DAP versus LLDB references need to be reviewed/updated.
• There is no UI notification about python 3.10 needing to be installed on Windows, i.e. "Install Python" button.
• There is no UI notification about LLDB not being found (it's currently a C/C++ logging string at Error level). Where is the Install LLDB button supposed to link to?
• There is no UI notification about LLDB not being usable (it's currently a C/C++ logging string at Debug level). This might be a superset of the python 3.10 case?
• The link to https://aka.ms/vscode-cpptools/TroubleshootingLldbDap doesn't work?
• Remove (or improve?) the transient status bar message. I was seeing it disappear before I had a chance to finish reading it and I don't know of any other extensions that do that. In addition to the status bar space being limited in size and might be filled from other extensions.
• Add telemetry
  • For MIMode (not sure what exactly this involves yet).
  • For cpplldb added to launch.json.
  • For the "Install LLDB" button.
• Does waitFor, coreFile, etc. actually work?
• Are there any issues specific to Rust debugging? Does the Rust extension team have any issues that need addressing?
  • It sounds like natvis isn't supported for lldb-dap and that is required on Windows for Rust debugging.
• Rename the strange reference to remote/remoting (instead of worker/background thread) and other unusual naming like SNARE.
• Should the remoting/search folder code be replaced by a call to which or was there a reason to implement a custom solution (maybe that is required for the regex-based search)?
• Do we need to give users a way to set a specific version of lldb (-dap) to use when multiple are installed, i.e. a setting?
• What versions of lldb(-dap) are supported? How should we handle unsupported versions?
• Is gcc supported? What about other non-gcc/clang-based compilers? Should/can we check if the binary supports lldb debugging? Do we need to test this? Are only certain "dwarf" formats supported?
• When lldb-18 is installed debugging is done on Linux, installing lldb-19 and launching the debugger causes it to fail and stop debugging with no error message; however, doing a Reload Window seems to fix it (this bug might be postponable since it's fixed by Reload Window). I hit the same issue when I uninstall lldb-19 -- ideally it would switch to using lldb-18 without requiring a Reload Window.
• On Linux with lldb-19, I see these warnings in the debugger console (maybe that's just an lldb issue we can ignore?): warning: (x86_64) /lib/x86_64-linux-gnu/libbrotlidec.so.1 unsupported DW_FORM values: 0x1f20 0x1f21
  warning: (x86_64) /lib/x86_64-linux-gnu/libbrotlicommon.so.1 unsupported DW_FORM values: 0x1f20 0x1f21
• Finish code reviewing.
  • Have the previously reported issues been resolved?
  • Are there any security-related issues still? (There were previously).
  • Are there any performance issues still? (There were previously).
  • Are there any localization issues still? (There were previously).
  • Should the LLDB-DAB extension be reviewed to see if there are any differences that should be addressed?
• Finish testing.
  • Windows
    • With lldb but without python 3.10.
  • Linux
  • Mac
  • With and without lldb available and/or usable.
  • With clang and gcc (other non-gcc/clang embededded compilers?)
  • With different versions of lldb (which?).
  • Different dwarf versions or other executable properties that might affect debugging? Do we need to review/test with different compiler flags? Do we need to handle any specific error cases or failed process exit codes from lldb?
  • How should the large number of debugger properties in the launch.json config be reviewed/tested?
• Follow-up features for "later" (not sure when exactly yet):
  • Add an experiment to default to lldb-dap instead of lldb-mi (whenever it currently defaults to lldb-mi instead of showing the dropdown list). This might just be for the Debug button case?
  • Update the existing docs on lldb/lldb-mi for lldb-dap. It seems like any docs linked to in the code would need to be updated for V1 though.
• Pre-exising issues (I assume "won't fix" for V1):
  • Duplicate debug attach options appear in the Debug or Configure Active File dropdown if any attach configs exist in launch.json #13655
• VS Code bugs impacting the feature:
  • Wrong/previous version of the extension is still used for debugger features after Install From VSIX... and Restart Extension vscode#250116