Remote debugging C++ applications with Eclipse CDT/RSE/RDT

12,582

Solution 1

Sanity check with CLI

Before you do anything, make sure you:

  • cross compile the application correctly and that it runs. You don't necessarily need to do this using Eclipse.
  • get GDB remote debugging working properly from the command line

This answer supposes that you can do on the development board:

sudo apt-get install gdbserver
gdbserver :1234 path/to/executable

And on host:

aarch64-linux-gnu-gdb \
  -ex "target remote board-hostname:1234" \
  -ex "file path/to/cross/compiled/executable" \
  -ex 'tb main' \
  -ex c

and then step debug everything correctly.

Eclipse setup

Tested in Ubuntu 16.04 host, Eclipse Oxygen 4.7.0 (downloaded from website), gdbserver 7.12, aarch64-linux-gnu-gdb 7.6.

I have successfully used all of the following methods:

  • manual
  • automatic
    • password auth
    • public key auth

Manual

With this method, we have to launch gdbserver on the target before running debug on Eclipse.

Pro: dispenses configuring SSH connections through Eclipse to allow Eclipse to

Con: you have to relaunch gdbserver every time debugging starts. This could be overcome if Eclipse understood gdbserver --multi, but I don't think it does?

Due to its simplicity, I recommend that you get this method working first.

Open the debug configurations, then create a new "C / C++ Remote Application".

Under the tab "Main":

  • select the "Name", "Project" and "C/C++ Application" as usual for a local debug

  • at the bottom launcher, click "Select other", check "Use configuration specific settings" and pick "GDB (DSF) Manual Remote Debugging Launcher"

    Why we do this: the automatic launcher first connects to the board with SSH and launches the gdbserver for you.

    enter image description here

Under the tab "Debugger":

  • "GDB debugger": same as used from CLI on host, aarch64-linux-gnu-gdb for this example

  • Sub-tab "Connection": set hostname and port as passed to the host on CLI (board-hostname and 1234)

    enter image description here

    enter image description here

Finally, manually launch gdbserver on the target just as we did from the CLI:

gdbserver :1234 path/to/executable

and start the debugger from Eclipse normally.

You have to restart gdbserver every time you terminate the program.

Automatic with password auth

This is the best method for development boards, which have fixed publicly known passwords.

It connects to the target with SSH and a password, and launches gdbserver on the target automatically every time, which is super convenient!

Target gdbserver stdout goes to the Eclipse "Console" window, which further reduces window switching.

In Eclipse set:

Automatic with public key

Very similar to the password authentication, except that you must go to: "Connection", "New", and choose "Public key based authentication"

Pros:

  • overcomes the "Secure storage was unable to save the master password" if you have an encrypted private key (unsafe, but fine for
  • for servers, you likely have already setup the public key

Cons:

  • key setup may hurt the first time
  • must redo key setup whenever devboard is nuked

SSH can connect without a password if you:

Before using this method, make sure that your authorized keys work from the command line, i.e. you should now be able to do:

ssh user@host

without typing any password.

Change the current working directory of the process

How to set the current working directory of the program when remote debugging with gdbserver Automatic Launcher in Eclipse CDT?

Solution 2

Unfortunately, this question did not yet result in the desired solution. Nevertheless, you might be interested in how I actually "solved" the problem:

We are now directly developing on the Linux boxes, doing everything remotely. We set up desktop users on the Linux boxes and login via VNC to run Eclipse and use it as front-end to gdb. While VNC is not the best solution (maybe we try NX later) this solution frees us from any problems with gdbserver or RSE/RDT.

Solution 3

You can try this plugin with Eclipse, for parallel application version here is a link

It works fine in the developing from Windows machine to program on Linux

Solution 4

"debug via "C++ remote" Error: Program not specified (do I need local code for that?)"

Yes, because symbols are loaded from a local copy of code.

In debugger tab of this type of launch configuration you will find the settings for remote server and port. Use machine name and port you specified when you started gdbserver.

AFAIK this will still not work as gdb running on your local windows machine will not support debugging linux programs. You will need a cross build of gdb (configured and build with host=mingw-or-something and target=linux).

Solution 5

As of now (Luna M6), Eclipse CDT+RDT+RSE seems to be a chain missing some links when you need to:

  • Run IDE on your desktop PC
  • Use the remote toolchain on target system to build instead of installing a local cross toolchain
  • Automate Debug and run to be performed on the remote system by a single click (start gdbserver, attach to it, and provide console output)

These requirements are quite common nowadays regarding the abundance of Linux ARM boards such as Raspberry Pi and OLinuxino. These boards usually have enough resources to run a toolchain but not enough to provide a remote desktop environment to run the IDE remotely.

My final solution: After several days of effort, I finally gave up Eclipse CDT+RDT+RSE for NetBeans C/C++ Remote Development Environment which works like a charm for me.

Share:
12,582
jarek
Author by

jarek

Programming I program client and server side code in Go, Python, Java, JavaScript, CoffeeScript, SQL, Bash, Awk, Scala, C++ and many other languages using VSCode or Vim. Other skills: Linux, Git, Google Cloud, BigQuery, Kafka, PostgreSQL, Jenkins, Ansible, Hadoop (Cloudera). Science In 2017, I finished my dissertation on "Visualization-Driven Data Aggregation", digging deep into data management topics, such as dimensionality reduction, data aggregation, and relational algebra, but also into computer graphics topics, such as line rendering, line simplification, and data visualization in general. I publish scientific papers on top-level conferences, such as VLDB and IEEE BigData.

Updated on June 12, 2022

Comments

  • jarek
    jarek almost 2 years

    I am fighting with Eclipse (in Windows) to make it connect to my Linux box and compile and debug C++ code there remotely.

    What I have working:

    • CDT/RSE/RDT installed (Eclipse Juno, CDT 8.1.2, PTP(RDT) 6.0.4, RSE 3.4)
    • rdt-server runs on Linux box (perl ./daemon.pl 4075)
    • create local C++ projects (Makefile based)
    • compile and debug local C++ projects
    • create remote projects (using the "Linux" connection to the rdt-server)
    • compile remote projects (Makefile based)

    Some manual things I can do (without Eclipse):

    • "remote" debug my compiled projects: ssh mybox 'cd /path/to/project; gdb main'
    • start a gdbserver: ssh mybox 'cd /path/to/project; gdbserver fqdn:10000 main'

    What is not working: Debug in Eclipse

    • debug via "C++ application" Error: Program not specified (because I have a no local code)
    • debug via "C++ remote" Error: Program not specified (do I need local code for that?)
    • debug via "C++ attach" (Debugger: "gdbserver")
      • gdbserver running on linuxbox
      • gdb can not talk to the gdbserver (cygwin gdb 7.5, linux gdb/gdbserver 7.3); warning: Architecture rejected target-supplied description.
    • debug via "C++ attach" (Debugger: "gdb") will try to attach to my Windows processes.

    Other things that might cause problems:

    • I am using the ssh binary provided with MSYS/Git (not on PATH)
    • Cygwin is not on PATH

    I really would like to do remote debugging in Eclipse for my C++ projects. Do you have any suggestions how to proceed from here?

  • jarek
    jarek about 11 years
    OK, I also think, a cross-build would be too complicated. I am trying to go the pure remote way since I did not want build anything on the Windows machine, which would lead to even more problems (and would take forever for bigger software on my corporate laptop)