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]

When I click the Add Debug Configuration icon in the top right of a file for cpplldb, it creates a launch.json with an invalid miDebuggerPath field:

[sean-mcmanus]

The lldb-attach snippet that is generated is missing the "program" field. The other debugger snippet types seem to have that. Or should the schema be updated so that it doesn't show a warning if program isn't needed in this case?

[sean-mcmanus]

List of issues to investigate/fix:

• Regression: clang compilers are not longer available from the Debug File quickpick (Windows only?).
• 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.
• Extension host crashes?/aborts when debugging the TypeScript on Windows (with the vsix it gets stuck with an endless progress bar until Reload Window is done, stop button doesn't work -- same on Mac).
• 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?
• 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).
• Finish testing.
  • Windows
    • With lldb but without python 3.10.
  • Linux
  • Mac
  • With and without lldb available and/or usable.
• 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