Add handling for now included GDB redistributable

[jreineckearm]

Fixes

• [Feature Request]: Include GDB builds for Arm in CMSIS Debugger extension #337

Changes

• Enhance environment variable updater to take a list of built-in tools. Subsequent prepend operations overwrite each other.
• Add GDB path handling to environment variables handler.
• Add GDB path handling to gdbtarget config resolver to fill in absolute path to built-in gdb if needed.

Other

• all script to build, download tools, and run test in one go. Forgot one time too many to download the tools and being surprised by things failing.
• Add customResetCommands to some types (not really used).

Screenshots

Checklist

• 🤖 This change is covered by unit tests (if applicable).
• 🤹 Manual testing has been performed (if necessary).
• 🛡️ Security impacts have been considered (if relevant).
• 📖 Documentation updates are complete (if required).
• 🧠 Third-party dependencies and TPIP updated (if required).

[jreineckearm]

Not yet ready for review:

• Initial docs changes (engineering level)
• TPIP information

[qltysh]

Diff Coverage: The code coverage on the diff in this pull request is 100.0%.

Total Coverage: This PR will increase coverage by 1.99%.

File Coverage Changes

Path	File Coverage Δ	Indirect
src/debug-configuration/debug-configuration.factory.ts	0.1
src/debug-configuration/gdbtarget-configuration-provider.ts	8.6
src/debug-configuration/index.ts	100.0	√
src/debug-configuration/subproviders/pyocd-configuration-provider.ts	0.8

🛟 Help

• Diff Coverage: Coverage for added or modified lines of code (excludes deleted files). Learn more.

• Total Coverage: Coverage for the whole repository, calculated as the sum of all File Coverage. Learn more.

• File Coverage: Covered Lines divided by Covered Lines plus Missed Lines. (Excludes non-executable lines including blank lines and comments.)

  • Indirect Changes: Changes to File Coverage for files that were not modified in this PR. Learn more.

[jreineckearm]

For testing:

• use build artifacts from here: https://github.com/Open-CMSIS-Pack/vscode-cmsis-debugger/actions/runs/16221283830
• make sure you have a launch config with "gdb": "arm-none-eabi-gdb" to use the built-in gdb. Or an absolute path to use a different one.
• inspect the command line that was used to launch the gdb with the VS Code Process Explorer.

[jreineckearm]

Will not work OOB on MacOS. Packaging just zipped in the entire tarball. Needs another iteration on the download script.

[KeilChris]

Yep, just got the ENOENT massage.

[thorstendb-ARM]

Tested the Mac installer on M3.
GDB zip/tgz is downloaded to the correct folder but not extracted.
When manually extracting it, this works.

[jreineckearm]

All Unix builds are busted. The only one containing the extracted distribution is the Windows one.
Checked earlier builds from another branch before fixes for Windows. Those look better, must be a problem with that fix.

[jkrech]

Windows seems to work. If I open a new terminal and try to launch gdb from the command line I get:

where arm-none-eabi-gdb 
c:\Users\jkrech\.vscode\extensions\arm.vscode-cmsis-debugger-0.4.1-pr388-g1aa1fd5.0\tools\gdb\bin\arm-none-eabi-gdb.exe

[jreineckearm]

CI should be fixed now. Apologies for the notification spam, but it took a while until I understood how I can dig into this on my local Windows machine. And became desperate along the way and tried a lot of, in hindsight, useless things.

Two relevant changes:

• lmza-native is required as an optional peer dependency for fast-extract if you need to unzip .xz format. Unfortunately, this isn't properly flagged by error messages if attempting to unzip xz anyway. Was only able to spot this by code inspection of fast-extract + sudden increase of tarball when adding the dev dependency to our package.json.
• You need to pass tar.xz as file extension to fast-extract so that it can properly chain 'xz' decompression and untaring.

I suspect a lot of the issues didn't show while initially developing and fixing the download scripts because of heavy caching actions in our CI. The yarn cache may still have held lmza-native from earlier tries. And the additional caching of downloaded + extracted arm-none-eabi-gdb archives may have hidden remaining problems like the chaining of 'xz' and untar failing. We may want to consider separating a download and an extraction cache if that makes sense.

Note: Quite handy to know you can clean such caches from the GitHub GUI. But only found this late in the investigation.

[jreineckearm]

@thorstendb-ARM , @KeilChris , would you mind giving the intended OOB-experience another try on Monday?

[jreineckearm]

Forgot, new VSIX files for testing are here: https://github.com/Open-CMSIS-Pack/vscode-cmsis-debugger/actions/runs/16225620619

[jkrech]

Running the local artifact:
VSCode CMSIS Debugger 0.4.1-pr388-g4e26b09.0
on macOS Apple M1 Pro - Sequoia 15.5
a) arm-none-eabi-gdb
GNU gdb (Arm GNU Toolchain 14.3.Rel1 (Build arm-14.174)) 15.2.90.20241229-git
b) successfully extracted in
~/.vscode/extensions/arm.vscode-cmsis-debugger-0.4.1-pr388-g4e26b09.0/tools/gdb/bin/arm-none-eabi-gdb
c) I am seeing in the VSCode terminal that the gdb is added to the path twice:

where arm-none-eabi-gdb
/Users/jkrech/.vscode/extensions/arm.vscode-cmsis-debugger-0.4.1-pr388-g4e26b09.0/tools/gdb/bin/arm-none-eabi-gdb
/Users/jkrech/.vscode/extensions/arm.vscode-cmsis-debugger-0.4.1-pr388-g4e26b09.0/tools/gdb/bin/arm-none-eabi-gdb

[ReinhardKeil]

Tested on Windows - works as expected. Path is only added once

[jreineckearm]

Thanks for testing the latest VSIX. @thorstendb-ARM , can you please check on Mac if you see the same as @jkrech ?

[KeilChris]

Works for me as well. I had to reboot the machine to make it work, but now everything's OK.

[jreineckearm]

I am going to merge now that I got confirmation for Windows and Mac.
I did a manual inspection of the VSIX files on Friday where I could confirm the "extracted" GDB files were included in the two Linux variants.

Follow-up actions:

• @JonatanAntoni , let's see if we can further improve the download scripts as discussed last week. My changes after the initial commit were mainly to get a build going, less about a long-term solution. I'd also prefer using a more resilient solution using file-type and a single unzipper.
• Investigate where the duplicate entries come from that show for @jkrech on Mac.