Support remote debugging?

[thegecko]

Is there any interest in extending this adapter to support remote debugging using gdb server (or other server implementations)?

I've created a PR(#109) which introduces the ability to connect to an existing gdb server, but there was a short discussion around whether the adapter should also manage launching the gdb server process where possible.

So if this feature is in scope of this adapter, should it support remote attach, launch or both?

1. Attach would introduce an additional remote argument for gdb to connect to and change the startup / load commands accordingly (as in the PR).
   Management of starting the remote process and stopping it would be outside of the scope of the adapter.

2. Launch would introduce the ability to start a gdb server and would need some further arguments adding, gdb server executable and gdb server arguments at a minimum.
   In this case would the adapter then be responsible for determining the port to open for client-server communication (scanning for unused ones as necessary) or would that still be the responsibility of the hosting application?
   Finally, how would the adapter know when the gdb server application is ready? I've seen methods which scan the port being used for activity and an alternative way would be to scan stdout from the server for a known ready string (although this can differ between gdb server implementations and may need to be an additional argument).

Implementation of the above could be quite onerous, so I wanted to make sure we have a plan before starting.

@dschaefer @marechal-p your thoughts?

[dschaefer]

Full disclosure :), at QNX we've built an extension to this adapter that handles QNX remotes. We use a slightly different protocol (target qnx), and a different way to get the binaries to the remotes. But the bulk of the rest of the logic is inherited from the GDB adapter.

I'm guessing we could do the same for gdbserver, or even remotes that connect to hardware debuggers or gdb stubs. We could have a few debugger types which start up a different subclasses of GDBDebugSession to manage the connection to the remote and whatever is needed to launch.

I think the Ericsson guys have more experience with such things with Linux. Interested in their thoughts.

[thegecko]

I'd be interested to know how you extend the adapter as this sounds like exactly what we need to do.

[paul-marechal]

Just so that I understand a bit better:

to manage the connection to the remote and whatever is needed to launch.

@dschaefer Are you talking about having the debug adapter launching the gdb server itself, or remote connecting to something already running and then launching the inferior?

[dschaefer]

We just subclassed GDBDebugSession and overrode the launch and attach methods. And we subclassed GDBBackend for extra GDB commands we support. We then have a different entry point in the adapter that starts up our debug session. Pretty simple.

[dschaefer]

@marechal-p I'm talking about you guys being the experts in that :). I'm not sure what the Ericsson team has done in the past. But what I do remember is that the server can start up process too, maybe, no? So it's always running. Maybe we need to support both. Anything's possible if people come with use cases to support.

[dschaefer]

BTW, I'm also thinking, for testing purposes, we could start up a gdbserver on the same machine as gdb so we can test remote commands.

[paul-marechal]

@dschaefer I'm relatively new to native development at Ericsson, but some use cases on our side went along allowing the adapter to maybe initiate an ssh connection, opening gdb server there, launching the inferior and finally connecting to it.

I've heard about pyocd for embedded development as well, where you have to start the pseudo gdb server locally and then connecting to it using gdb client.

I originally thought these would be out of scope for the adapter, but maybe not after all.

[paul-marechal]

@dschaefer regarding the testing for remote features, since we already start an actual gdb process, starting a gdb server wouldn't be a crazy idea :)

[thegecko]

@marechal-p I assume you know pyocd is what we are using at Arm for this? :)

[thegecko]

@dschaefer Subclassing in the same way could be the best way for us to go here. I don't want to introduce a lot of niche code for our use case.

[paul-marechal]

@thegecko I remember you telling me indeed. And maybe I misjudged what was the debug adapter's responsibility when we discussed about this, my bad. @dschaefer do you think the adapter should be able to setup everything, such as launching the gdb server by itself and remote connecting to it?

To support the use case where a gdb server must be ran locally and have the adapter connect to it, I first thought about wrapping the setup inside a script of some sort. We would point the debug adapter to that script instead of the actual gdb executable, and the script would:

• Start the local gdb server (remote is localhost and the port is whatever it wants to use, no constraint)
• Start the gdb client and connects it to the local gdb server
• Hook gdb client's I/O to the adapter (making the script appear as a regular gdb executable)

But that's for when the setup require a locally running gdb server, to avoid hardcoding all the launch logic in the adapter. But do you see things differently?

But the adapter would certainly have to support actual remote debugging by attaching to an already running gdb server, that's a no-brainer.

[paul-marechal]

Thinking about it yes, maybe just subclassing and adding any specific logic there would do the trick.

[thegecko]

OK, I'll close the remote PR in favour of subclassing this adapter to enable that functionality.

[jonahgraham]

I would like to reopen this discussion. At the moment there is no open source (in CDT anyway) version of subclassed adapter. I am working on migration path for remote debugging in Eclipse IDE and therefore have made my own subclass.

I would like to contribute that back to this repo rather than start a new repo with (essentially) one file.

I will be doing a PR soon with these changes - my PR includes launching the server (e.g. JLlink's one) and has at least some tests (using gdbserver).

[thegecko]

@jonahgraham There is an OSS sub-classed adapter here:

https://github.com/eclipse-cdt/cdt-gdb-vscode

Albeit without remote support.

[jonahgraham]

Thanks @thegecko - I would put the cdt-gdb-vscode as a consumer of the adapter rather than an extender - although that is quite a fine line I am treading :-) Reason being that cdt-gdb-vscode uses cdt-gdb-adapter completely as is, no modification or extension to it. Indeed the remote debugging I am doing will also be exposed in there.

[jonahgraham]

To provide some of my own answers to previous questions - even those not addressed to me ;-)

[...] would the adapter then be responsible for determining the port to open [...]

Yes, the adapter should be able to do this. Ref the cortex-debug extension for example. Also, this is a feature all IDE clients would need, so having it in the adapter makes sense to me.

how would the adapter know when the gdb server application is ready?

This is straightforward in the case that the adapter is monitoring the server for something - e.g. the "Listening on port 12345" message as you recommend. My initial solution uses a regexp to identify that moment from stdout/stderr + has an optional delay in ms.

Are you talking about having the debug adapter launching the gdb server itself, or remote connecting to something already running and then launching the inferior?

I am not Doug ;-) but I am proposing having both. The "launchRequest" would do both, and the "attachRequest" would be to a gdbserver launched or running in another way.

do you think the adapter should be able to setup everything, such as launching the gdb server by itself and remote connecting to it?

Yes, eventually anyway.

[paul-marechal]

Having played around with this, it can make the configuration a bit bloated to have many different launch methods within just the two launch and attach types.

Here are some launch scenarios we were thinking about:

• Launch locally
• Launch remotely via an already running gdb server
• Connect via ssh and start gdb server and then also launch the program

Just these already add quite some configuration options, that sometime only apply to one scenario: remoteProgram would be the program equivalent but on the remote, but in this case I would prefer to rename program to localProgram as well, removing ambiguity when you have to specify both options.

Then people subclassing the adapter might add even more configuration options...

One thing I tried was to contribute different debug types so that I could provide configurations that made sense depending on the use cases. Types like gdb and remote-gdb.

Am I the only one having a problem with too many "unscoped" options?

[jonahgraham]

Agreed, which is why I agree about the two entry points and two different types you mention - but both entry points should be shipped in this package.

Am I the only one having a problem with too many "unscoped" options?

What does this refer to?

[paul-marechal]

Am I the only one having a problem with too many "unscoped" options?

What does this refer to?

To the eventual "bloated" configuration.

[paul-marechal]

I agree about the two entry points and two different types you mention

Is the only way to contribute different types to have different entry points?

This is what I did, but wasn't sure.

[jonahgraham]

Is the only way to contribute different types to have different entry points?

AFAIK yes.

To the eventual "bloated" configuration.

Because you mentioned "scopes" I wasn't sure if you know you can add hierarchy in the launch configuration parameters? e.g. https://github.com/microsoft/vscode-cpptools/blob/3d40ac231af7d74a8290f046ce528ad15272f139/Extension/package.json#L739

[paul-marechal]

I know, I was also thinking about playing with the hierarchy in order to organize the different options.

Just not sure what was better: trying to organize one big configuration or managing different types.

[dschaefer]

Keeping the launch types separate is ideal. Startup for local and remote are very different. I think it makes sense to add this to the adapter as Jonah is suggesting. CDT has a long history of supporting embedded development where remote is king.

Something to also think about is supporting hardware debuggers that have gdb remote interfaces. That would be similar to Paul's already running gdbserver. OpenOCD would be a great example of this and something we could maybe integrate into the public test suite.

[thegecko]

@jonahgraham Our extended debug adapter for CMSIS device debugging implements functionality as you describe. The source code can be seen here: https://github.com/ARMmbed/cmsis-debug-adapter

Focussing on debugging remote things does affect the scope of this project and easily pull in dependencies, features and complexity not needed for normal C debugging.

I propose that this functionality is pulled into a new adapter which extends from this one, perhaps remote-debug-adapter which can also live on the eclipse GH organisation.

I'd be keen to be involved in building and maintaining such a project, so would be happy to use our adapter as a starting point.

The scopes of the two projects could then be something along the lines of:

cdt-gdb-adapter

• Core gdb debugging functionality via MI
• Ability to launch or connect to a local program via PID
• Ability to connect to an already running remote debug server via host:port

remote-debug-adapter

• Extends cdt-gdb-adapter
• Adds ability to manage lifecycle of gdb servers
• Functionality to discover ports to open, etc.
• Includes dependencies specific to working with embedded devices

..with configuration options accordingly.

[jonahgraham]

I agree about the extended scope, but I think it should be in the same project with different entry points. That is what I have committed - now you can launch debugAdapter or debugTargetAdapter for target debugging. Note that the debugTargetAdapter has two modes, launch and attach. Launch will spawn the gdbserver and attach will connect gdb to an already running one.

There is certainly some scope for integrating some of the work you have done in your extension into this project if you are willing to relicense it.

[thegecko]

if you are willing to relicense it.

It's MIT

[jonahgraham]

The majority of supporting remote debugging was added in PR #122. If there are additional items needed, new more focused issues should be created.