Wrong platform-specific properties applied to debug configuration

[bernhardbreuss]

Describe the bug
After VS Code update to 1.99.0, cortex-debug debug configurations use the windows platform-specific properties inside a devcontainer on WSL. Before the update, the linux platform-specific properties were applied as expected.

The platform-specific debug properties from our launch.json:

...
            "windows": {
                "preLaunchCommands": [
                    "source ../../utils/scripts/ab_win.gdb"
                ],
            },
            "linux": {
                "preLaunchCommands": [
                    "source ../../utils/scripts/ab_unix.gdb"
                ],
            },
...

The actual contents of the GDB scripts don't matter. However, they fail if they are executed on the wrong platform. The failure is correctly handled by cortex-debug (debug stops).

Expected behavior
Linux platform-specific properties are used when launching a debug configuration within a devcontainer (through WSL).

Environment:

• Visual Studio Code 1.99.0
• Cortex-Debug Version (this extension) 1.12.1 (1.13.0-pre3 as well)
• OS: Windows 10 with WSL (Debian Bullseye) and devcontainer (Debian Bullseye)
• GDB Version: 15.1
• Compiler Toolchain Version: arm-none-eabi 13.3.Rel1

Additional context
I am writing this issue here, because other extensions (e.g., C/C++ extension from Microsoft) still apply the platform-specific properties correctly.

[sullivanmj]

This is also filed at microsoft/vscode#245873

[haneefdm]

We haven't changed anything in a long time, especially in this area. We use the Node API (that comes with VSCode) to determine the current platform

https://nodejs.org/api/os.html#osplatform

We merge the specified platform properties. If VSCode running in WSL is now reporting something different, not sure what that is and why.

From StackOverflow, it appears that it can happen if the client and server sides of VSCode are out of sync.

https://stackoverflow.com/questions/64108941/visual-studio-code-not-running-working-on-wsl-2

Near as I can tell, this issue is not related to Cortex-Debug but it is a system failure that we can neither detect or correct.

I don't use WSL so, you all know more than I do. WSL as a platform does not exist in Node or VSCode

[alphahex99]

I have the same bug (microsoft/vscode#245873) but no WSL.

Same thing happens on linux.

The "windows" and "linux" parts are both executed on either OS.

[haneefdm]

Okay, good that also happens without WSL. Now, I can quickly see if I can recreate the issue.

[alphahex99]

Split anything into "linux" and "windows" anywhere in .vscode/launch.json to recreate. Both parts will be executed instead of just your OS. Happens on windows and it also happens on linux.

[haneefdm]

Yes, VSCode is doing something weird. Not sure when this bug was introduced but this was not an issue several months ago. Our code has not changed in the meantime, and we relied on VSCode to do the right thing. What I noticed

• Env#1: code launched from a WSL project directory from the command line code . This means that code is not launched truly from a Linuxy environment. Launching from Windows desktop/start menu will launch from the Windows environment. VSCode/Microsoft documents this. This also allows you to use local/WSL/Linux installs for gnutools, st-tools, etc. I used usbipd to bind/attach the STLink board to the WSL side to make st's gdb-server work from the Linux side. To be able to use cortex-debug, I had to install it on the Lunux side as well (I think VSCode prompted me to do that).

  • If you use "windows": {...}, it will be used. Error
  • If you use "linux": {...}, it will be used. Okay
  • If you have both of the above, it seems to use "windows", regardless of order. Error

• Env#2: MacOS.

  • This always uses the "osx":{...}: Correct

My Linux machine is currently dead, so it will take some time to do this test on a pure linux box. I have to setup a VM if I cannot make the Linux box to come alive.

I created a work around in our extension to mask VSCode's bug and you can see the fix in the next pre-release. Watch this page...

https://github.com/Marus/cortex-debug/releases

[haneefdm]

Can you test and give feedback with the following build

https://github.com/Marus/cortex-debug/releases

[alphahex99]

@haneefdm

V1.13.0-pre4 WORKS with February 2025 (version 1.98)

V1.13.0-pre4 WORKS with March 2025 (version 1.99)

You fixed it 👍

[bernhardbreuss]

Can you test and give feedback with the following build

https://github.com/Marus/cortex-debug/releases

Does also work for me in WSL.

[haneefdm]

Thank you all

[alphahex99]

VSCode also addressed this issue here: microsoft/vscode@dc8439c

[haneefdm]

Nice. Thanks for letting me know. But I will leave my changes in there. We NEED to process the OS specific properties ourselves so we can process the rest properly.

The way it is implemented now, we don't care what VSCode does as it will never see the OS specific suff.