Is it possible to run a remote debug session targeting Windows with CLion?
The docs say that I can do any system that has gdbserver:
Remote OS: any supporting gdbserver and SSH
However, when I try to run my remote app, I get an error:
10:53 PM Build finished in 3 sec, 44 ms
10:53 PM Error running 'remote'
1: 'env' is not recognized as an internal or external command,
operable program or batch file.
I can't find a place where I could see the whole command that CLion runs that causes this error.
Here is my configuration:
After some investigation, I have come to the conclusion that it is impossible to remote debug a Windows app with CLion 2021.3.1 (regardless of Host platform).
CLion does not support remote debugging when targeting Windows OS using GDB Server (hence targeting Windows is impossible) due to:
CLion does not handle cases when SSH Server is using a non-Unix shell like CMD.exe or PowerShell. Commands like exec, env, chmod can’t be handled. This can be circumvented by using a Unix shell:
a. Unfortunately, connection fails for MSYS2 Bash and Git Bash when Windows OpenSSH Server is configured to use one as a default shell.
b. Windows WSL SSH Server works. Connection is established, Unix commands are recognized. WSL must be installed. It is not easy to configure WSL when Windows itself is running on virtual machine.
c. MinGW64 SSH Server. Didn’t test it.
Uploading binaries via SFTP fails when OpenSSH Service is used. Can be circumvented with 1.b..
CLion doesn’t consider the binary’s file extension. It always assumes that the binary is built for Linux, hence the attempt to transfer fails, when a binary has an .exe extension (fails to find test, though test.exe was built). This is a major bug that prevents remote debugging targeting Windows. There are, however, ways to work around:
a. Manual renaming before running debug. Unacceptable.
b. Adding a conditional custom CMake command. May work but pollutes the CMakeLists.txt
CLion can’t connect to MinGW GDB Server it has started. Connection times out. However, if the Server was started from a terminal, CLion connects successfully and is able to run debug as intended. This can ONLY be worked around MANUALLY:
a. In Edit Configurations… one must put a stub command in GDB Server:, for example ‘sleep’. In GDB Server args: ‘5’. This will give a time to manually run the gdbserver.exe command via an SSH connection in Terminal.
These issues were reproduced for CLion versions for Windows 10 and Ubuntu 20.04.
3. and 4. are very serious and prevent from remote debugging targeting Windows as it was intended to be done.
This happens when CLion connects to the Server it has started:
This is a work around:
As can be seen from the screenshots, with this approach GDB’s console does not catch the output. You must switch to Terminal to see it.
Related
I have a virtual machine in Microsoft Azure which runs Linux, and has the code of the xv6 operating system.
I want to debug it on my (Windows) computer. How can I connect to to the VM and the GDB/CGDB with my Clion?
I tried to add a Remote Host configuration in Build, Execution, Deployment | Toolchains and managed to connect to the VM, but it Clion requires a path to CMake and the compilers, and I (and Clion) can't find it, and get errors.
This is the error details (appears when I click more...):
I've read several guides/stackoverflows but not found a similar situation/solution.
I have my remote ssh working (can browse files).
I don't get why I need a local Windows application (although I have a compiled .exe it's not the version I want to debug which is only on the Linux server).
When I try and launch a remote debug session it immediately fails with
Exception occurred during launch
Reason:
Error during file upload.
and below in the details
Could not write file: <my windows exe path>
Permission denied
...
The aforementioned file is writable and in any event I also started eclipse as administrator just in case.
In any event the .exe is irrelevant. I just want to debug code remotely.
(I know all about gdbserver...happy to manually kick that off if need be....don't think I'm there yet though)
Below is the options page I'm presented with:
Had the same experience on TI Code Composer Studio Version: 9.3.0.00012.
This seems to happen while uploading the cross compiled binary from host to target. If you set the check box "Skip download to target path" the error should disappear.
I propose to workaround the upload.
Setup a web server on the host, the line python.exe -m http.server --directory \source\hello\Debug\ would be sufficient
Run wget on the target, see screenshot
I've been setting up remote debugging for an embedded Linux target. I've tested that I have the correct combination of gdbserver running on the target and gdb client running on my workstation. I can start the server and on the workstation side run:
(gdb) target remote 10.28.22.226:2345
and I can list source and step just fine.
In Qt Creator I have configured a device. In that window I specify the GDB server executable: gdbserver (see pic).
I also configure the cross debugger in the 'Build & Run' Debuggers tab as shown below:
In this case, I have manually started the gdbserver with my executable on the target with port 2345. To start debugging with Qt Creator, I choose the Debug->Start Debugging->Attach to running Debug server pulldown menu. It gives me the prompt shown below, where I enter the server port (2345). I give it the appropriate kit and local executable (copy of the executable on the remote target).
After I hit OK, it seems to run the gdb client locally with a few commands, then times out trying to communicate with the gdbserver. I have debug logging turned on with the server, so I know the server never sees anything from the client run from Qt Creator. Additionally, I did Window->Views->Debugger Log to help me get a better idea of what was going on. The log shows the correct IP address and port for my device, but I don't see anything that looks like a 'target remote IP:port' call.
I'm looking for a hint or reference here. I seem to be a bit stuck at the moment. Thanks!
EDIT: additional information - I've verified that my gdb client has support for python compiled in. I see that Qt Creator requires python support. I also have further support that nothing ever goes out on the wire from Qt Creator. I did a wireshark capture and don't see anything going to port 2345 on the target.
Alternately, if anyone would share their Qt Creator debugger-log output with me so I can compare, that would be helpful.
Avoid Qt Creator 4.5-beta1. It seems 4.5RC1 doesn't have this problem. I was able to do remote debugging using the method described above just fine.
Even QtCreator 4.5.0 seems to have the same bug.
The only workaround I've found is to start the GDB server manually on the remote target: with "top" I get the pid of the remote process to debug then I run the following command: gdbserver --attach remote ip:remote port pid.
After the server is listening, I finally choose: "Attach to Running Debug" server".
Maybe you can write a server start script on target which include the above statement...
Here is the scenario.
I have a C++ application using CMake that has been setup on Ubuntu server machine. I have setup a remote development interface to it using Netbeans 6.9 on client machine, and I have been able to build it.
The problem is that (as per the setup of CMake script) the executables from the program are going to another directory in the server. When I try to run the program, Netbeans asks me for executables which I can't spot out on client machine (as they are residing on server machine).
Is there a way I can get the executables on local machine OR have a way to give their location to my Netbeans application.
Thanks for your help.
I am on windows XP want to build the programs on linux remote pc
i have eclipse Ganymede, CDT, RSE installed on remote machine... but how to configure all this?
am I doing correct? could anybody suggest
You could access your remote machine using VNC or similar remote desktop infrastructures. That would allow you to work with Eclipse (edit, build, run, debug, etc) as you would in your local machine.
If bandwidth is too narrow or you don't manage the Linux box, you could access via SSH or telnet and work in console mode (with Emacs/Vim, gdb and all that stuff).
Take a look at https://github.com/ericwoodruff/rmake you would configure your IDE and edit code locally but it uses rsync to build on the remote machine. I've used it at HP to build C++ programs across multiple platforms, linux->windows, windows->linux. It works in the command line and I've used an eclipse builder to invoke it as well. If you enable --no-decorate Eclipse can even parse the build output into the problems view.