Setting up a Debugging Session

The way in which you set up your debugging session depends on whether you are doing an application debug or whether you are analyzing a process dump. For standard application debugging, you must configure the RDBC daemon. To analyze a process dump, the RDBD server is used.

Setting up an Application Debugging Session

Application debugging uses the RDBC daemon which processes remote debugging requests issued by the GDB debugging tool. It is accessed from a host using Sun RPC over UDP/IP. RDBC must run on a system which includes at least the POSIX_SOCKETS feature (minimal process and I/O managers).

Configuring and Using RDBC

The RDBC daemon can be started automatically or manually.

For RDBC to be started automatically, the conf/sysadm.ini file, read during system initialization by C_INIT, must contain a command which mounts the NFS root. If this mount command is present, edit the conf/sysadm.ini file and add the following line just after the mount command:

rdbc

You cannot use the & character with this command.

RDBC will follow NFS root changes.

To start RDBC manually, as a normal application, type the following at the command line:

$ rsh target_name rdbc

Running RDBC manually enables you to choose when you want to carry out application debugging, freeing up valuable resources.

To stop RDBC, use the akill command. First identify the process ID (pid):

$ rsh target_name aps

Then kill the RDBC process:

$ rsh target_name akill pid

Your application debug session terminates when you stop RDBC.

The input and output of debugged applications is displayed in the terminal in which you started RDBC. If you start RDBC with the -c option, the terminal connection is closed and RDBC runs in the background.

RDBC can be used to debug several applications at the same time from different GDB clients.

Two or more RDBC servers can be run on the same target to provide a separate console for each program being debugged.

See rdbc(1CC) for more information.

Customers who have the source delivery of ChorusOS 5.0 can find information on how to compile GDB for application debugging in the README.CHORUSOS file, located in install_dir/chorus-family/opt/gdb/doc/.

Analyzing a Process Dump

Process dumps enable you to examine processes post-mortem. A process dump is triggered when:

• A process crashes and the CORE_DUMP feature has been set to TRUE.

• The pdump command is issued on a process.

• The pdump API primitive is called by an application.

A core file is generated in the root_dir/tmp directory, by default, and contains information about each of the process's threads and all memory regions associated with the process. Only regions attached to the actor are dumped. Supervisor regions not bound to the process are not dumped.

The iom.maxcoresize tunable specifies the maximum size of a core file. If iom.maxcoresize is set to 0, no core dump can be performed.

The RDBD daemon is used to debug application core dumps. rdbd(1CC) is similar to rdbc(1CC), the remote debugging daemon. However, RDBD runs on the host, whereas RDBC runs on a target. Execution commands (step, cont, next) are also not available in RDBD.

The debugging tool communicates with RDBD on the host. RDBD is responsible for reading the core file generated by the process dump.

Configuring and Using RDBD

The RDBD daemon enables the GDB debugging tool to debug core dumps. It is possible to run several RDBD servers on the same host, provided that each one uses a different communication slot number. The slot number must be used as a port number when configuring the debugging tool to use the debug server.

When you start RDBD, you must specify the exact path to the ChorusOS core dump directory manually, as follows:

$  rdbd [options] core_directory

The following options are available:

-fast-start

Do not check for another RDBD daemon already using the selected communication slot. This significantly accelerates startup.

-force-slot

If another RDBD daemon is already using a given slot, force the new RDBD daemon to steal the slot.

-slot number

Creates a communication slot number instead of using the default 0.

core_directory

Directory containing the core files generated by pdump or generated due to an exception.

RDBD can be run in the background because it does not require access to a terminal.