Remote Debugging

Remote debugging is used in situations where a program must be run on a different machine to where it is developed; in these cases it’s typically convenient to run the debugger on the development machine and have it control a debuggee running on the test machine.

Installing undodb-server on the target

undodb-server is the component of UndoDB which tightly controls the debuggee and enables it to be recorded and rewound. For those familiar with remote debugging via GDB, it is analogous to gdbserver. As such it must be installed on the target machine.

Installing can be as simple as copying the undodb-<version> directory to the target machine, or making it available via a file-sharing mechanism such as NFS. Where storage space on the target is limited, the only required files are the version of undodb-server appropriate to your target (see below) and the key file.

It is important that the date and time on the target device are set (approximately) correctly, otherwise undodb-server will refuse to run.

Choosing the appropriate undodb-server executable

Your UndoDB and/or Live Recorder download contains a number of undodb-server executables. You must choose the correct one for your application.

The correct undodb-server executable depends on the architecture for which your debuggee application was compiled, as follows:

OS Debuggee architecture undodb-server executable
Linux x86 64-bit undodb-server_x64
Linux x86 32-bit undodb-server_x32
Linux ARMv7 AArch32 Hard-float undodb-server_armhf
Linux ARMv7 AArch32 Soft-float undodb-server_arm
Linux ARMv8 AArch32 undodb-server_armhf
Linux ARMv8 AArch64 * undodb-server_arm64
Android x86 64-bit Not supported
Android x86 32-bit Not supported
Android ARMv7 AArch32 undodb-server_android_arm
Android ARMv8 AArch32 undodb-server_android_armhf
Android ARMv8 AArch64 * undodb-server_android_arm64
  • Enabled licenses only.

Basic case

Start the server:

undodb-server_<arch> --connect-port <port> <full-path-to-program>


The path to the program being debugged must also be the full path, not a relative path. For example ../my_program will not work, but /home/myuser/myprogram will.

Connect to the server in UndoDB:

udb <path-to-program>
...UndoDB starts...
(udb) target remote <host>:<port>
(udb) run

:title reference:IDE remote debugging

IDEs, including Eclipse and CLion, make certain assumptions about the behaviour of the remote debugging server. These assumptions are based on vanilla gdb’s behaviour. In order to match those expectations, the suggested command-line when launching the server for remote debugging within an IDE is:

undodb-server_<arch> <port-number> <full-path-to-program>

Autostart debuggee

You can also pass the --autostart argument to the server to tell it to run the debuggee immediately:

undodb-server_<arch> --autostart --connect-port <port> <path-to-program>

Hence there’s now no need to issue run in the debugger prompt:

udb <path-to-program>
...UndoDB starts...
(udb) target remote <host>:<port>
(udb) continue


Autostart is required for remote debugging to work correctly from some IDEs, including CLion and Eclipse, and is implicit in the suggested command-line when launching for `IDE remote debugging <IDE remote debugging_>`_ <IDE remote debugging_>.

Attach to debuggee

If the debuggee is already running, we only need to pass its pid to the server:

undodb-server_<arch> --pid <pid> --connect-port <port>

Again there’s no need to issue run in the debugger prompt:

udb <path-to-program>
...UndoDB starts...
(udb) target remote <host>:<port>
(udb) continue

Cross-architecture debugging

A common case with remote debugging is an x86 development machine running the frontend debugger connecting to an ARM board running the program. The only difference in this case is we need to tell UndoDB the architecture:

udb <path-to-program>
...UndoDB starts...
(udb) set architecture arm
(udb) target remote <host>:<port>