How to set up the Eclipse for remote C debugging with gdbserver?

Question

I am pretty new to Eclipse. Trying to set up to do remote debugging.

Here is situation, I am connecting to remote machine running Linux, I am running Windows.

1) I have installed all the necessary tool for Eclipse, and was able to connect to Linux machine.

2) Remote machine has gdbserver

linux1[1]% gdbserver
Usage:  gdbserver [OPTIONS] COMM PROG [ARGS ...]
        gdbserver [OPTIONS] --attach COMM PID
        gdbserver [OPTIONS] --multi COMM

COMM may either be a tty device (for serial debugging), or
HOST:PORT to listen for a TCP connection.

Options:
  --debug               Enable debugging output.

Do I need to configure anything in gdbserver ???

3) What else should I configure in Eclipse ? for remote debugging ?

4) Does it matter that my GDB version is different from remote Machine GDB ?

Answer 1

CLI sanity check

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 may help: How do you start running the program over again in gdb with 'target remote'?

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 run gdbserver, which is another possible point of failure.

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.

  

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)

  

  

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:

• work around the "Secure storage was unable to save the master password" bug as explained at: How to solve "Secure storage was unable to save the master password" in Eclipse CDT remote application with SSH password debug connection?
• set the launcher to: "Automatic Remote Debugging Launcher"
• set "Remote Absolute File Path for C/C++ Application" to /root/path/to/project/path/to/executable
• "Connection", "New", and choose "Password based authentication"

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 unencrypted private key (unsafe, but fine for devboards)
• 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

so I would prefer this method for servers.

SSH can connect without a password if you:

• set ~/.ssh/authorized_keys on the target to contain the ~/.ssh/id_rsa.pub from the host
• have a non encrypted private key on host, which bypasses our password woes
• set pesky folder permissions correctly: https://unix.stackexchange.com/questions/36540/why-am-i-still-getting-a-password-prompt-with-ssh-with-public-key-authentication

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.