Debugger API for extensions needs to support selection of 32-bit or 64-bit debug host

[rkeithhill]

In working on the PowerShell extension, we need to allow users to be able to choose whether to launch a 32-bit or a 64-bit debug host. Certain PowerShell modules will only load into one or the other.

I see that there is support for different program: settings per OS:

"debuggers": [{
    "type": "gdb",
    "windows": {
        "program": "./bin/gdbDebug.exe",
    },

What I would like to see is windows remain as "use the default OS architecture" and you add windows (x86) to allow extension developers to specify a different, x86 host exe on 64-bit Windows e.g.:

"debuggers": [{
    "type": "gdb",
    "windows": {
        "program": "./bin/gdbDebug.exe",
    },
    "windows (x86)": {
        "program": "./bin/gdbDebug.x86.exe",
    },

Ideally, on a 32-bit system, the use of windows (x86) would never appear to the end user just as linux or osx would not appear as debug targets. However on 64-bit Windows the user would need to be able to select between the 64-bit debug host and the 32-bit (x86) debug host. I'm not sure what the "UI" would be for this.

One option is that we just add another debugger intialConfiguration. So for the PowerShell extension, we would have:

"initialConfigurations": [
    {
        "name": "PowerShell",
        "type": "PowerShell",
        "request": "launch",
        "program": "${file}"
    },
    {
        "name": "PowerShell (x86)",
        "type": "PowerShell",
        "request": "launch",
        "program": "${file}"
    }                    
]

The problem is that with this approach - using windows and windows (x86) to distinguish between host architectures - is that the type: setting would not be any different. Both hosts would be defined under type: "PowerShell". I'm not familiar enough with the debugger section of the package.json format to figure this out.

I could create two different debugger sections, one type PowerShell and the other type PowerShell (x86). However that forces a one time choice when the launch.json file gets configured and that doesn't seem right. The user is likely going to want to switch between OS native and x86 depending on the script they are debugging.

Another option, would require smarts in the Debug viewlet's toolbar dropdown. It would recognize both windows and windows (x86) and take a single "name" e.g.:

"initialConfigurations": [
    {
        "name": "PowerShell",
        "type": "PowerShell",
        "request": "launch",
        "program": "${file}"
    }             
]

... and create two entries in the dropdown: PowerShell and PowerShell (x86). Hmm, not sure I like that option myself.

Another option is to allow the initialConfigurations sections to specify programArgs: to the launched program. Then we could write a small CMD file to take the args and launch the correct debug host exe. That we can create PowerShell and PowerShell (x86) named configurations that will automatically show up in the Debuggers' debug target dropdown list.

Or another option is to have an initialConfiguration section property that would allow the selection of windows or windows (x86).

[daviwil]

Keith explains the need for this really well. We've already had requests from users to be able to choose between the 64-bit and 32-bit PowerShell hosts in the debugger since that has an impact on whether certain features can be used in the PowerShell runtime. If there's a good way for us to solve this problem using the existing launch.json design, we'll be happy to use that for the time being.

[isidorn]

First of all sorry for the slow response.
Ok, I see the need for this feature, ideally you would just specify

"debuggers": [{
    "type": "gdb",
    "windows": {
        "program": "./bin/gdbDebug.exe",
    },
    "windows (x86)": {
        "program": "./bin/gdbDebug.x86.exe",
    },

And vscode would pick the right program. The issue for this is that I am not sure if we can distinguish if we are running inside 64 bit win or 32 bit win.
@bpasero do we already have this data somewhere in env. or could I just use something like this to figure it out https://stackoverflow.com/questions/24956691/how-to-determine-whether-i-have-64bit-or-32-bit-node-executable-installed

If this is not possible then we need to think about UI and let the user choose the architecture. Optimally we would just do it for him.

[daviwil]

I learned this method of determining the bitness of the host Windows OS through Node.js despite the app running as x86:

if (process.env.hasOwnProperty('PROCESSOR_ARCHITEW6432')) {
    // 64-bit Windows
}

More info: http://blog.differentpla.net/blog/2013/03/10/processor-architew6432/

[rkeithhill]

Even if you are running on 64-bit windows, there will be times when the user specifically wants to use the 32-bit (x86) debug host. For PowerShell this is usually when they are using a module that only runs in a 32-bit host. So auto-picking is nice but the user should have a way to override/specify which host architecture they need.

[bpasero]

@isidorn yes you can either use arch property to find out the arch of the node.js process or probably sniff for environment variables to find out the arch of the OS.

[isidorn]

So adding win (x86) and we auto choosing it based on the platform we can do for Feb.
But I am not a big fan of adding UI affordance on top just for the special case when the user specifically wants to use the 32-bit host when on a 64 bit platform.
@weinand ideas on how to tackle this using the current mechanisms are welcome

[weinand]

@isidorn yes, we should support the "win (x86)" OS type for February as discussed here, but I don't like the white space in the key "win (x86)". I suggest to use something like "win-x86" instead.

For the problem that the user wants to override VSCode's automatic x86/64-selection I suggest the following:

The extension contributes the two debug types "gdb-x86" and "gdb-x64" in addition to "gdb" like this:

"debuggers": [{
    "type": "gdb",
    "windows": {
        "program": "./bin/gdbDebug.exe",
    },
    "windows-x86": {
        "program": "./bin/gdbDebug.x86.exe",
    }
},
{
    "type": "gdb-x86",
    "windows": {
        "program": "./bin/gdbDebug.x86.exe",
    },
    "windows-x86": {
        "program": "./bin/gdbDebug.x86.exe",
    }
},
{
    "type": "gdb-x64",
    "windows": {
        "program": "./bin/gdbDebug.exe",
    },
    "windows-x86": {
        "program": "./bin/gdbDebug.exe",
    }
}

With this he can use a type "gdb-x86" or "gdb-x64" to force a specific version independent from the underlying architecture.

[isidorn]

Looks good to me

[rkeithhill]

Just to clarify, the "February" milestone is technically the one after the current milestone in progress, which is the "January" milestone, right?

[weinand]

@rkeithhill that's correct. But you will be able to try the feature as soon as it's available in the alpha channel.

CC @isidorn

[egamma]

@weinand fyi the alpha channel currently isn't public 😃 (it is still under discussion how we want to do, frame it).

[isidorn]

@weinand TS complains about win-x86, because of the minus in n a property name, so I went with winx86. TS also complains about win(x86) - no brackets allowed in property names

[weinand]

@isidorn why is TypeScript involved here?

[isidorn]

@weinand because my code is in typescript and I want to have the JSON object nicely typed

[rkeithhill]

Question about the semantics of this:

{
    "type": "gdb-x64",
    "windows": {
        "program": "./bin/gdbDebug.exe",
    },
    "windows-x86": {
        "program": "./bin/gdbDebug.exe",
    }
}

It doesn't make sense to allow the user to select a 64-bit debugger if they are running on a 32-bit OS, right? Would it be enough to remove the windows-x86 section from this debugger definition for the type gdb-x64 to not appear as an option on 32-bit Windows? This implies that "windows" always means 64-bit Windows. Is that correct?

[isidorn]

Using @weinand workaround a user on a 32-bit os will still be able to choose gdb-x64 if he wishes, since that will be contributed as a seperate debugger.
And I believe you are right for the gdb-x64 option the windows-x86 section is not needed.

[isidorn]

I have pushed the winx86 as the name. Please let me know if somebody has a better suggestion, that optimally also conforms with the TS spec for property names.