Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] launching a gdb from inside a docker container using DSF/GDB

Hi Tim,

I was wondering how you have been getting along with these experiments? Do you have something working now?

On the CDT call today Jeff was telling us about the work he has been doing on getting build to work in a container.


Jonah Graham
Kichwa Coders Ltd.

On 26 March 2016 at 07:01, Tim Orling <ticotimo@xxxxxxxxx> wrote:

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 :)

Thanks for the help so far :)

--Tim (Intel)

cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top