Remote Debugging

You can have each of DDD, the inferior debugger, and the debugged program run on different machines.

• Remote Host: Running DDD on a Remote Host
• Remote Debugger: Using a Remote Inferior Debugger
• Remote Program: Debugging a Remote Program

Node:Remote Host, Next:Remote Debugger, Up:Remote Debugging

Running DDD on a Remote Host

You can run DDD on a remote host, using your current host as X display. On the remote host, invoke DDD as

     ddd -display 

**Illegal HTML tag removed :** display

     

where Illegal HTML tag removed : display is the name of the X server to connect to (for instance, Illegal HTML tag removed : hostname:0.0, where Illegal HTML tag removed : hostname is your host).

Instead of specifying -display Illegal HTML tag removed : display, you can also set the DISPLAY environment variable to Illegal HTML tag removed : display.

Node:Remote Debugger, Next:Remote Program, Previous:Remote Host, Up:Remote Debugging

Using DDD with a Remote Inferior Debugger

In order to run the inferior debugger on a remote host, you need remsh (called rsh on BSD systems) access on the remote host.

To run the debugger on a remote host Illegal HTML tag removed : hostname, invoke DDD as

     ddd --host 

**Illegal HTML tag removed :** hostname

**Illegal HTML tag removed :** remote-program

     

If your remote Illegal HTML tag removed : username differs from the local username, use

     ddd --host 

**Illegal HTML tag removed :** hostname

 --login 

**Illegal HTML tag removed :** username

**Illegal HTML tag removed :** remote-program

     

or

     ddd --host 

**Illegal HTML tag removed :** username

@

**Illegal HTML tag removed :** hostname

**Illegal HTML tag removed :** remote-program

     

instead.

There are a few caveats in remote mode:

• The remote debugger is started in your remote home directory. Hence, you must specify an absolute path name for

  Illegal HTML tag removed : remote-program

  (or a path name relative to your remote home directory). Same applies to remote core files. Also, be sure to specify a remote process id when debugging a running program.

• The remote debugger is started non-interactively. Some DBX versions have trouble with this. If you do not get a prompt from the remote debugger, use the --rhost option instead of --host. This will invoke the remote debugger via an interactive shell on the remote host, which may lead to better results.

  Note: using --rhost, DDD invokes the inferior debugger as soon as a shell prompt appears. The first output on the remote host ending in a space character or > and not followed by a newline is assumed to be a shell prompt. If necessary, adjust your shell prompt on the remote host.

• To run the remote program, DDD invokes an xterm terminal emulator on the remote host, giving your current DISPLAY environment variable as address. If the remote host cannot invoke xterm, or does not have access to your X display, start DDD with the --no-exec-window option. The program input/output will then go through the DDD debugger console.

• In remote mode, all sources are loaded from the remote host; file dialogs scan remote directories. This may result in somewhat slower operation than normal.
• To help you find problems due to remote execution, run DDD with the --trace option. This prints the shell commands issued by DDD on standard error.

See Customizing Remote Debugging, for customizing remote mode.

• Customizing Remote Debugging:

Node:Customizing Remote Debugging, Up:Remote Debugger

Customizing Remote Debugging

When having the inferior debugger run on a remote host (see Remote Debugging), all commands to access the inferior debugger as well as its files must be run remotely. This is controlled by the following resources (see Customizing):

| The command to list all core files on the remote host. The string @MASK@ is replaced by a file filter. The default setting is:

          Ddd*listCoreCommand: \
          file @MASK@ | grep '.*:.*core.*' | cut -d: -f1
          

| | --- |

| The command to list all directories on the remote host. The string @MASK@ is replaced by a file filter. The default setting is:

          Ddd*listDirCommand: \
          file @MASK@ | grep '.*:.*directory.*' | cut -d: -f1
          

| | --- |

| The command to list all executable files on the remote host. The string @MASK@ is replaced by a file filter. The default setting is:

          Ddd*listExecCommand: \
          file @MASK@ | grep '.*:.*exec.*' \
            | grep -v  '.*:.*script.*' \
            | cut -d: -f1 | grep -v '.*\.o><#039; <="" pre="">

 |
| --- |



listSourceCommand(class listSourceCommand)
Resource








| The command to list all source files on the remote host. The string @MASK@ is replaced by a file filter. The default setting is:
          Ddd*listSourceCommand: \
          file @MASK@ | grep '.*:.*text.*' | cut -d: -f1
          

 |
| --- |
Node:Remote Program, Previous:Remote Debugger, Up:Remote Debugging
Debugging a Remote Program 
The GDB debugger allows you to run the debugged program on a remote machine (called remote target), while GDB runs on the local machine.
See Remote Debugging, for details. Basically, the following steps are required:

Transfer the executable to the remote target.
Start gdbserver on the remote target.
Start DDD using GDB on the local machine, and load the same executable using the GDB file command.
Attach to the remote gdbserver using the GDB target remote command.

The local .gdbinit file is useful for setting up directory search paths, etc.
Of course, you can also combine DDD remote mode and GDB remote mode, running DDD, GDB, and the debugged program each on a different machine.
Node:Customizing Debugger Interaction, Previous:Remote Debugging, Up:Invocation