launching a gdb from inside a docker container using DSF/GDB

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

launching a gdb from inside a docker container using DSF/GDB

Avery, Brian
Hi,

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?
-----
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.


Thanks for any help/pointers!
-brian
_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: launching a gdb from inside a docker container using DSF/GDB

Roland Grunberg
> 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.

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].

Cheers,
--
Roland Grunberg

[1] https://wiki.eclipse.org/CDT/User/NewIn87#Docker_support
_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: launching a gdb from inside a docker container using DSF/GDB

Avery, Brian
Hi,


On 3/21/16, 8:41 AM, "[hidden email] on behalf of Roland
Grunberg" <[hidden email] on behalf of [hidden email]>
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
>[hidden email]
>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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: launching a gdb from inside a docker container using DSF/GDB

Tim Orling
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 <[hidden email]> wrote:
Hi,


On 3/21/16, 8:41 AM, "[hidden email] on behalf of Roland
Grunberg" <[hidden email] on behalf of [hidden email]>
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
>[hidden email]
>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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: launching a gdb from inside a docker container using DSF/GDB

Jonah Graham
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 <[hidden email]> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;brian.avery@intel.com&#39;);" target="_blank">brian.avery@...> wrote:
Hi,


On 3/21/16, 8:41 AM, "<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cdt-dev-bounces@eclipse.org&#39;);" target="_blank">cdt-dev-bounces@... on behalf of Roland
Grunberg" <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cdt-dev-bounces@eclipse.org&#39;);" target="_blank">cdt-dev-bounces@... on behalf of <a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;rgrunber@redhat.com&#39;);" target="_blank">rgrunber@...>
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
><a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cdt-dev@eclipse.org&#39;);" target="_blank">cdt-dev@...
>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
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;cdt-dev@eclipse.org&#39;);" target="_blank">cdt-dev@...
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


_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: launching a gdb from inside a docker container using DSF/GDB

Tim Orling
Hi Jonah,

On Thu, Mar 24, 2016 at 12:57 AM, Jonah Graham <[hidden email]> 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 http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/dsf-gdb/org.eclipse.cdt.examples.dsf.gdb/src/org/eclipse/cdt/examples/dsf/gdb?h=cdt_8_8
  
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)

Jonah




On Thursday, 24 March 2016, Tim Orling <[hidden email]> 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 <[hidden email]> wrote:
Hi,


On 3/21/16, 8:41 AM, "[hidden email] on behalf of Roland
Grunberg" <[hidden email] on behalf of [hidden email]>
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
>[hidden email]
>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
[hidden email]
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


_______________________________________________
cdt-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: launching a gdb from inside a docker container using DSF/GDB

Tracy Miranda-3
Hi Tim,

Thanks for the extra context.


On Thu, Mar 24, 2016 at 12:53 PM, Tim Orling <[hidden email]> 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.

HTH

Jonah







_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: launching a gdb from inside a docker container using DSF/GDB

Jonah Graham
Oops, that last message really was from me.

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

On 24 March 2016 at 13:55, Tracy Miranda <[hidden email]> wrote:
Hi Tim,

Thanks for the extra context.


On Thu, Mar 24, 2016 at 12:53 PM, Tim Orling <[hidden email]> 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.

HTH

Jonah







_______________________________________________
cdt-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: launching a gdb from inside a docker container using DSF/GDB

Marc Khouzam
In reply to this post by Tracy Miranda-3

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?

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

BR,
Marc

From: Tracy Miranda <[hidden email]>
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 <[hidden email]> 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.

HTH

Jonah







_______________________________________________
cdt-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: launching a gdb from inside a docker container using DSF/GDB

Tim Orling
N

Sent from my iPhone

On Mar 24, 2016, at 9:07 PM, Marc Khouzam <[hidden email]> 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.

BR,
Marc

From: Tracy Miranda <[hidden email]>
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 <[hidden email]> 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.

HTH

Jonah






_______________________________________________
cdt-dev mailing list
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: launching a gdb from inside a docker container using DSF/GDB

Tim Orling

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

<snip>
 * 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
<snip>

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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: launching a gdb from inside a docker container using DSF/GDB

Jonah Graham
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.

Thanks
Jonah





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

On 26 March 2016 at 07:01, Tim Orling <[hidden email]> 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).

<snip>
 * 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
<snip>

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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev