I'm trying to debug a C++ application which is running on a Linux box. This application will not build on OS X. I've got the app running on the Linux box, and I can start gdbserver for remote debugging. But since the application doesn't build on OS X, is there a way to use Eclipse on OS X to still debug the app?
Another way, assuming the remote Linux box is an SSH server and has gdb, is to run gdb on it thru ssh, e.g.
ssh remotelinuxbox gdb -tui prog
Related
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.
I'am trying to debug the qt application which i made and placed on VmWare. I followed this guide https://www.vmware.com/support/ws5/doc/ws_devices_serial_host_app_to_vm.html
https://www.vmware.com/support/ws5/doc/ws_devices_serial_advanced_example_debugging.html
I have the 'cdb' debugger installed so my vmware shared pipe is \\.\pipe\com_1 i'm running the cdb with arguments: cdb -server npipe:pipe=\\.\pipe\com_1 -v C:\tests\clean_deploy\app.exe on the Virtual Machine. I'am assuming that cdb will use the \\.\pipe\com_1 to listen for the connections. On my OS(Windows 7) i run the qt->debugging->attach to remote cdb session and set the connection string like this npipe:server=server,pipe=\\.\pipe\com_1
And i get in qt log:
Debugging Started
Debugging Finished
Without anything.
How do you debug an application on the vmware with cdb server using external pipe, from the qt cdb enviroment ??
I followed the steps in this link
and I manage to debug a binary which resides in linux host from my windows machine from command prompt.
I have gdbserver in linux and I installed gdb with the help of mingw in windows. As I told I can prompt "target remote x.x.x.x:10000 test" to command in windows and debug my test application.
My problem is I can't do the same with eclipse gui, it seems to me it has tones of buttons, options but they make no sense to me.
I am choosing debug_configurations-->C/C++ Remote Application(the only one which allows me to input linux machine ip/port), in "Main" tab to connection I am inputting my linux ip. In same menu under Debugger tab I am inputting my window's gdb path and gdbserver port.
After doing all those I believe I gave enough info to eclipse for connect gdb server but it never enough for eclipse. I am checking gdbserver logs by starting gdbserver with --debug, gdbserver never gets triggered, it does not writes a single line of log. Eclipse even does not starts a connection. But instead it gives me a error like "Error during file upload." which makes no sense to me.
I am using "Eclipse Version: Juno Service Release 2" . Any help will be appreciated .
I believe that the "C/C++ Remote Application" option uses Eclipse's RDT (Remote Development Tools) and RSE (Remote System Explorer) to connect, upload, execute, and debug the application itself. It
If all you want to do is connect to a gdbserver, then create a "C/C++ Attach to Application" debug configuration, and under the Debugger tab, set Debugger to gdbserver.
I also encountered this error message for other reason on Eclipse version 2019-09 R (4.13.0).
I very recommend to read paragraph "How do I debug a remote application?" from this great guide.
It explains which of three remote debugging options you should be using - Automatic Remote Launcher, Manual Remote Launcher and Remote Attach Launcher and how to use each one.
I was using the wrong launcher and hence got the error, while on the remote side gdbserver was listening and waiting for a connection. Switching to Manual Remote Launcher solved it.
for example it says:
If you don't have RSE installed, you cannot use the "Automatic Remote
Launch"
RSE = Remote System Explorer End-User Runtime
Launcher setting is configured from the bottom of the Remote Debug Configuration window - "Using GDB (DSF) Automatic/Manual Remote Debugging Launcher".
What is the difference between gdb mi and gdb server? Can both be used for local debugging?
I have facing problem in troubleshooting the debugging with gdb server on Red Hat. The debugging launcher stops at 72 %.
For local debugging you need neither MI or gdb server. You only need gdb.
MI is used by various GUIs/IDEs to communicate with gdb. This basically changes commands so they can be better parsed by machines (hence the name Machine Interface).
Gdbserver is used to debug remote systems. You only run gdbserver on remote (target) machine (this can for example be some embedded system running linux) and then you connect to gdbserver from GDB on your workstation (serial, ethernet or similar). This allows you to debug on your workstation and only requires target to run simpler gdbserver.
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.