Re: [cdt-dev] launching a gdb from inside a docker container using DSF/G

[Jonah Graham <jonah@xxxxxxxxxxxxxxxx>]

Hi Tim,

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

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.

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.

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?

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?

Jonah

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.

Regards,

Tim (Intel)

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

Hi,


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

>> 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
>>it.
>> There is code in the spawner class that seems to have this option but
>>that
>> 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
>what's
>going on but perhaps someone who knows Spawner better might have some
>hints.
>
>
>> -----
>> why I care is below in case people are wondering:
>> We have linux based docker containers that have cross toolchains for
>>various
>> 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
>>the
>> 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
>>Eclipse
>> 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
>>mounted
>> into the container so the gdb inside the container can see the sources
>>and
>> binaries.  This works fine when we are executing from a shell
>>environment
>> (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
>>container.
>
>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.
Thanks!
Brian

>
>Cheers,
>--
>Roland Grunberg
>
>[1] https://wiki.eclipse.org/CDT/User/NewIn87#Docker_support
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>To change your delivery options, retrieve your password, or unsubscribe
>from this list, visit
>https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

-- 
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com