Support target extended-remote launch connecting to gdbserver started…

[fzuuzf]

… with the --multi option

Patch is a 'works for me' solution to

1. Manually start 'gdbserver --multi :2345' on the remote target. 2) Debug the program from vscode by the following launch entry:

{
    "name": "Launch on remote target, which has gdbserver --multi :2345 running",
    "type": "gdbtarget",
    "request": "launch",
    "program": "${workspaceFolder}/out/build/x64_clang++/program",
    "gdbNonStop": true,
    "openGdbConsole": true,
    "target": {
	"type": "extended-remote",
	"parameters": [
		"192.168.22.1:2345"
	]
    }
    "initCommands": [
	"set remote exec-file /target/path/to/program"
    ]
}

[jreineckearm]

Thanks for the creating the PR, @fzuuzf .
From the description here and due to the lack of a separate issue, it is not clear to me in what way it didn't work for you before.
Have you tried "request": "attach" instead? That's how you normally attach to an already running GDB server like in your scenario. See also the corresponding extension docs.

[fzuuzf]

Yes, I tried "request": "attach". It worked with the executable specified as a gdbserver argument.
I did not find a way to make "request": "attach" work with the gdbserver started with the --multi option.
Also with gdbserver started with the --multi option there is no prog nor pid parameter. I think, conceptually it is a launch, because the gdb tells the gdbserver, which executable to run and there is no prog nor pid parameter.
Don't you agree?
"gdbserver --multi :port" requires gdb to start the program with the 'run' command. In GDBDebugSessionBase.continueIfNeeded() this happens, if this.isAttach is false.

[fzuuzf]

The force push better handles the false setting of this.isAttach.

[cwalther]

I don’t know yet what the proper solution is, but I am also not convinced yet that it is this. There seems to be some overloading of what "request": "launch" means. In the context of "type": "gdbtarget", as far as I understand, it has up to now meant “launch gdbserver (or some other stub)”, not “launch the program”. In your case, that is clearly a problematic choice. However, changing it now, but only in one particular case, as you do here, seems confusing and potentially breaking existing configurations.

Maybe we need a new configuration option for this case, to avoid disturbing existing configurations?

It probably adds to the confusion that we also seem to be a bit sloppy in our terminology regarding “attach”. Strictly speaking, as far as I understand, “attach” is what happens between stub and program. What happens between GDB and stub is called “connect”.

For what it’s worth, we (Indel) use target extended-remote for attaching to an embedded system (but not in target.type, but in an internal command invoked from target.connectCommands), but I don’t know what the historical reasons for that were (it seems like it shouldn’t make a difference).

[jreineckearm]

I see your point @fzuuzf . But I am also a bit reluctant to interpret "type": "extended-remote", from now on as "attach to gdbserver started with --multi". Especially as I'd expect more convenience as a user than selecting the target program with initCommands.

Having written that, would it make sense to additionally add something like programPath below (setting name certainly up for discussion) to indicate that program gets launched on the remote target:

"openGdbConsole": true,
    "target": {
        "type": "extended-remote",
        "programPath": "/target/path/to/program"
        "parameters": [
            "192.168.22.1:2345"
        ]
    }

And then use the following criteria to skip launching a gdbserver

• no target>server given
• programPath set
• extended-remote type set

I know it's a little more effort and may require a bit more documentation about use cases. But may reduce the odds to cause regressions.

[cwalther]

These criteria still feel a bit inscrutable to me. I was thinking of something like adding a new option target.launchServer with values undefined|true|false. When unset, everything would work as before, so no existing configurations are broken. When set, then launchServer (true or false) determines whether the server (stub) is launched and request (launch or attach) determines whether the program is launched. But I haven’t thought about it very thoroughly.

[jonahgraham]

I'm moving this to draft until we get some more consensus on what the correct way forward on this item is. In addition @fzuuzf a signed ECA is needed.