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 Jonah,

On Thu, Mar 24, 2016 at 12:57 AM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
Hi Tim,

This sounds very interesting and I like the direction it is going in. 

So do we :)
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.
The ~/.gdbinit is never used by Eclipse CDT as gdb is started with the -nx argument. You can explicitly pass in a full path to a gdbinit in the launch configuration dialog, but you'll still have the same Windows vs Linux path problems doing the source of that file. Also, even if you did pass in a gdbinit, that cannot override any of the commands that final launch sequence will do.

Ahhh. I knew about -nx but forgot. Thank you for reminding me.
A few questions so I can understand and perhaps better share my thoughts.

1. Are you creating your own launch delegate and related dsf machinery?

Brian started with the stand-alone debugger for simplicity.

We are now using the code from org.eclipse.cdt.examples.dsf.gdb as a starting point (in our own namespace), so we have our own launch delegate and everything else from
2. In your use case presumably the build output, user source and tool chains are all in the docker container? How is Eclipse running on the Windows host accessing those files? Is there a path mapping or similar?

Source and Output are on the host. Tool chain(s) is/are inside the container(s). Some containers have support for multiple arch/board. Some of our targets are multi-core. When the toolchain container is launched, the workspace on host is bind mounted to a directory inside the container:

Host = C:/Users/<username>/<workspace>     ==     Container = /<workspace>

Also, we currently run the container with --net=host so the gdb inside the container can access the host ports (to talk to the gdbserver provided by OpenOCD). In the future, containers might not be local  :-)

On Windows, using the Docker Quickstart terminal (based on mingw64/msys2), the tool chain container is launched with:

"docker run -d --name <container_name> -v //c//Users//<username>//<workspace_loc>:/<workspace_loc> --net==host <image_name>"

We are also working with org.eclipse.linuxtools Docker Tooling, but there are issues there as well ATM on Windows/Mac because the containers run inside a VM. Let's keep it simpler by not worrying about that yet. The problem at hand is definitely inside CDT land :)

--Tim (Intel)


On Thursday, 24 March 2016, Tim Orling <ticotimo@xxxxxxxxx> wrote:
We were able to move forward by using "docker exec -i <container_id> gdb", where a symbolic link to the actual toolchain's gdb was put into the container's /usr/bin. (Using the toolchain actual path to <arch_prefix>-gdb failed because eclipse seems to be using OSString to coerce the path to use windows delimiters and the container baulks at that).

gdb version check now works. Yay!

The next problem is with the final launch sequence, as the path to the executable/application/binary is checked and validated to be a Windows path. The container path will differ (it is using a bind mount to access the host workspace).

Error in final launch sequence
 Failed to execute MI command:
 -environment-cd C:/Users/<username>/<workspace_loc>/<project>
 Error message from debugger back end:
 C:/Users/<username>/<workspace_loc>/<project>: No such file or directory.
 C:/Users/<username>/<workspace_loc>/<project>: No such file or directory.

Ideas for next steps? We have been using "Local", when we might need to use "Remote" debugging, but then we get to questions of protocol for communicating to the container (SSH/TCP assumptions in Remote debugging don't apply here).

We also tried putting a .gdbinit in ~/ inside the container to override -environment-cd but the above error happens before .gdbinit is resolved. Somewhere in MI Session initialization. In our case "gdbserver" is OpenOCD running native on (Win/Mac/Linux) host and "gdb" is running inside the container...for the reasons Brian already mentioned.


Tim (Intel)

On Tue, Mar 22, 2016 at 8:58 PM, Avery, Brian <brian.avery@xxxxxxxxx> wrote:

On 3/21/16, 8:41 AM, "cdt-dev-bounces@xxxxxxxxxxx on behalf of Roland
Grunberg" <cdt-dev-bounces@xxxxxxxxxxx on behalf of rgrunber@xxxxxxxxxx>

>> Here's what I'm trying to do that is not succeeding:
>> I am trying to launch a gdb binary that resides in a docker container by
>> setting my gdb binary to :
>> docker-exec -i linux_gdb /usr/bin/gdb
>> This fails with:
>> cannot enable tty mode on non tty input
>> on both the gdb -version check and the actual --mi call.
>> The code that launches gdb does not seem to have a tty/pty  attached to
>> There is code in the spawner class that seems to have this option but
>> is not being used by the gdb launcher.
>> Is there some way to accomplish this?
>I'm able to reproduce this error if I launch with '-i -t' using
>java.lang.Runtime's process launcher. Are you sure you were using just
>'-i' ?
>When I disabled my '-t' option I was getting output from gdb.
Hmm, I need to set up a simpler test case to compare to but I'm pretty
        certain I tried both the -i and the -it version. I can only try this on a
mac at the moment since I am travelling, but it looks like you are
correct. I was *certain* I tried both from the linux Eclipse but maybe I
am mistaken.

>I haven't been playing around with this approach so can't really say
>going on but perhaps someone who knows Spawner better might have some
>> -----
>> why I care is below in case people are wondering:
>> We have linux based docker containers that have cross toolchains for
>> targets installed in them. They also contain gdb for that architecture.
>> Our
>> longer term goal is to have metadata in the toolchain containers so that
>> they can "tell" the plugin what their capabilities are and so a limited
>> cross toolchain configuration UI can be constructed on the fly based on
>> toolchain container the user has chosen.
>> We would like to be able to use the cross toolchains in the container.
>>We are
>> accomplishing this currently using a native stub dispatcher and an
>> builder.  This works currently.
>> We would also like to be able to use the gdb inside the docker
>>container as
>> the gdb executable which Eclipse connects to.  The workspace is bind
>> into the container so the gdb inside the container can see the sources
>> binaries.  This works fine when we are executing from a shell
>> (CLI mode). However, when we are executing it via eclipse (if we do
>> something like gdb = docker exec -I <debug_container> gdb-x86-64) we get
>> failures due to the lack of a tty available to the gdb inside the
>Have you considered having a gdb-server within the container and simply
>connecting to it through a remote debug session ? This should bypass the
>issue you're having with the TTY, and is also similar to the approach the
>CDT's Container Debugging support took [1].

Good question. The main reason is that we are targeting a large number of
architectures and the overhead of maintaining and testing the toolchains
on the native os's is what we are trying to avoid.  The actual code is
typically running on an embedded board and we are talking to the gdbserver
on the board or to openocd on  the host talking jtag to the board.  The
targets don't tend to be containers or suitable to containerizing (if
that's a word).

This made me go back and try the basics again. That helped a lot.

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

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

Jonah Graham
Kichwa Coders Ltd.

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

Back to the top