Starting a Debugging Session

The simplest way to start a dbx session is to type the dbx command at a shell prompt.

To start dbx from a shell, type:

---

$ dbx

---

To start dbx from a shell and load a program to be debugged, type:

---

$ dbx program_name

---

dbx Start-up Sequence

Upon invocation, dbx looks for and reads the installation startup file, dbxrc in the directory install-directory/lib, where the default install-directory is /opt.

Next, dbx searches for the startup file .dbxrc in the current directory, then in $HOME. If the file is not found, it searches for the startup file .dbxinit in the current directory, then in $HOME. Generally, the contents of .dbxrc and .dbxinit files are the same with one major exception. In the .dbxinit file, the alias command is defined to be dalias and not the normal default, which is kalias, the alias command for the Korn shell. A different startup file may be given explicitly with the -s command-line option.

A startup file may contain any dbx command, and commonly contains alias, dbxenv, pathmap, and Korn shell function definitions. However, certain commands require that a program has been loaded or a process has been attached to. All startup files are loaded in before the program or process is loaded. The startup file may also source other files using the source or .(period) command. The startup file is also used to set other dbx options.

As dbx loads program information, it prints a series of messages, such as Reading symbolic information...

Once the program is finished loading, dbx is in a ready state, visiting the "main" block of the program (For C, C++, or Fortran 90: main(); for FORTRAN 77: MAIN()). Typically, you want to set a breakpoint and then issue a run command, such as stop in main and run for a C program.

---

Note -

By default, the loading of debugging information for modules compiled with -xs is delayed in the same way as the debugging information stored in .o files. The dbx environment variable delay_xs lets you turn off the delayed loading of debugging information for modules compiled with -xs and have this information loaded at dbx startup (see "Debugging Without the Presence of .o Files").

---

If a Core File Exists

If a file named core exists in the directory where you start dbx, it is not read in by default; you must explicitly request the core file. Use the where command to see where the program was executing when it dumped core.

To debug a core file, type:

---

$ dbx program_name
 core

---

When you debug a core file, you can also evaluate variables and expressions to see what values they had at the time the program crashed, but you cannot evaluate expressions that make function calls.

Process ID

You can attach a running process to dbx using the process_id (pid) as an argument to the dbx command.

---

$ dbx your_program_name pid

---

You can also attach to a process using its process ID number without knowing the name of the program:

---

$ dbx- pid

---

Because the program name remains unknown to dbx, you cannot pass arguments to the process in a run type command.