For the record, Jonah was on the right track and I really appreciate his insight and thorough walkthrough. Introducing a translation layer which takes a host path and transmogrifies it into the Docker container path is working. But Marc is partially right as well. We did indeed need to be using a Remote launch to connect to the OpenOCD gdbserver port, but this is more like one of the special cases described in the header of IGDBBackend (And detailed in Bug 240092).
* Here are some special cases: <br>
* Example #1: GDB is usually launched on the host machine where Eclipse is
* running, but it can also be launched on a remote machine through, say, SSH. <br>
* Example #2: GDB is usually launched in the host file system, but it can also
* be launched in a chroot'ed file system such as Scratchbox (see
I took the org.eclipse.cdt.examples.dsf.gdb code and made it apply to a remoteApplicationLaunch instead of a localApplicationLaunch. So far, I have -gdb-version and -environment-cd (MIEnvironmentCD) working. The next stumbling block is -file-exec-and-symbols (MIFileExecAndSymbols), for which it looks like we will need to subclass GDBBackend_HEAD so we can @Override getProgramFile() if I am on the right track. Exactly how to do that isn't quite clear, but things are beginning to make sense.
Of course at some point we will probably need to translate back the other way from container path to host path and that should be interesting to implement. Especially in an elegant way. Right now I'm using a hammer and spackle.
None of this would have worked without Roland's helpful suggestion of using "docker exec -i". Our builds are a lot more responsive to the user now too :)