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


Sent from my iPhone

On Mar 24, 2016, at 9:07 PM, Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> wrote:

I probably missed the early details of this discussion but isn't debugging toward a Docker container meant to use remote debugging with GDB on the host and gdbserver in the container?

Not when the tool chain is _inside_ the container. We need to call foo-bar-baz-gdb inside the container. The gdbserver is provided by OpenOCD on the host, where the host is what is connected to the embedded target hardware.

Inside out from what is normally expected. But this allows Windows/Mac/Linux to build the same binaries and target the same hardware because they are using the same tool chain (container). But we need an OS agnostic IDE == eclipse :)

All these Windows vs Linux problems would go away then, I expect.

Only if you are debugging an application running in the container. We are not.


From: Tracy Miranda <tracy@xxxxxxxxxxxxxxxx>
Sent: Mar 24, 2016 09:56
To: CDT General developers list.
Subject: Re: [cdt-dev] launching a gdb from inside a docker container using DSF/GDB

Hi Tim,

Thanks for the extra context.

On Thu, Mar 24, 2016 at 12:53 PM, Tim Orling <ticotimo@xxxxxxxxx> wrote:

The environment-cd is done in the final launch sequence. The existing dsf-gdb code assumes that gdb is on the same machine as eclipse, and in the docker case while that is true in a physical world sense, it certainly isn't true in other senses. Therefore I think you'll have to update final launch sequence somewhere along the way.

Understood and working in that direction now. But any pointers would be appreciated.

Since you are already using the example as a base, I will continue from there.

In your Final Launch Sequence [1] you should override getExecutionOrder and modify the result of super's getExecutionOrder to remove stepSetEnvironmentDirectory [2] from the array. That will prevent the environment-cd completely. 

Another approach may be to add a translation layer onto the paths from host to container. That is allow Final Launch Sequence to do the environment-cd, but then gives you a chance to translate the path. A good way to do that would be by creating a custom MI Command class like MIEnvironmentCD [3] that translates the string. Then in your custom command factory [4] override createMIEnvironmentCD [5] to return an instance of your new class. You will probably want to update whatever IGDBBackend.getGDBWorkingDirectory() uses to get the path to do the reverse translation too.



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

Back to the top