Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support building on linux build machine and debugging on linux target machine #109

Closed
odhanson opened this issue Feb 27, 2017 · 4 comments
Closed

Comments

@odhanson
Copy link
Member

In the embedded world, usually you cannot build on the target machine. You will build on a host machine and then load and debug on the target machine.

Since we won't always have a cross compiler available for windows, It would be very beneficial if we could use a Linux build box to build the project (for example a docker container or a VM) which has all the build environment configured, but support remote debugging a target machine. We should also support attaching to an already running process on a target and debugging it.

So basically the idea is to use Linux as the build environment, but use windows with visual studio as the IDE and debugging environment.

@AliAskari
Copy link

This is very similar to issue #87. What I have ended up doing:

  1. Wrote a post build script that copies the built binary from the build environment (docker container/VM) to the debug environment.
  2. Created two separate configurations in Visual Studio, namely Remote Debug and Remote Build. In the settings for Remote Build I have the information about my build remote (hostname, username, password, build script, and also the post build script), and in the Remote Debug I only have the information about the debug machine (hostname, username, password, path to program).

This has solved all of my problems. Whenever I want to build I select the Remote Build configuration and when I want to debug I select Remote Debug and it has worked quite good. The only problem is that visual studio doesn't know the latest state of the binary and always tells me that the binary is our of date/build was not successful.

In Visual Studio 2017 you have the option to attach to the process on a remote machine.

@robotdad
Copy link
Member

robotdad commented Mar 2, 2017

@AliAskari thank you, this is exactly the sort of workaround for this we've been suggesting until we enable separate build/debug targets. I have an example here similar to what you describe. https://github.com/robotdad/LinuxCrossCompile

@odhanson
Copy link
Member Author

odhanson commented Mar 3, 2017

@robotdad thanks for your example. It was quite enlightening.

I have a question though, I didn't catch how you configured the remote gdb debugger. We typically have a cross-compiled gdbserver running on the target, and a gdb running locally on the host. However, we don't use the standard gdb installed with ubuntu, but use the gdb which is provided as part of our cross-compile toolchain. So I guess I will need to build this gdb with cygwin or mingw and run it as part of vs debugging session ?

@reid-p
Copy link

reid-p commented Apr 26, 2017

Managed to do something locally to workaround this.
Our setup is cross compiling on x64 linux box and running on embedded arm system.
We set our project using gdb and replaced the the gdb on the linux box and run gdbserver on the arm system.
The script connects the matching gdb tool for the remote and runs the first couple of command need to connect to the remote. After that everything seem to just work as expected.
Hitting run results in make being run on the linux cross compile box which also updates the remote target files.
Then VS starts gdb on the cross compile box and auto connects to the remote target.
No switching between configs required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants