Sun Studio 12: Debugging a Program With dbx

Using Predefined Variables

Certain read-only ksh predefined variables are provided. The following variables are always valid:




Disassembly of the current instruction. 


Current line number in decimal. 


Current “visiting” line number in decimal. 


Contents of the current line. 


Name of the current function. 


Name of the current “visiting” function. 


Name of the class to which $func belongs.


Name of the class to which $vfunc belongs.


Name of the current file. 


Name of the current file being visited. 


Name of the current loadable object. 


Name of the current loadable object being visited. 


Scope of the current PC in back-quote notation. 


Scope of the visited PC in back-quote notation. 


Address of $func in hex.


Name of the function calling $func.


After a dlopen or dlclose event, contains the list of load objects just loaded or unloaded. The first word of dllist is a “+” or a “-” depending on whether a dlopen or a dlclose has occurred.


ID of the most recently created handler. This variable has an undefined value after any command that deletes handlers. Use the variable immediately after creating a handler. dbx cannot capture all of the handler IDs for a command that creates multiple handlers.


List of handler ids that caused the most recent stoppage. The handlers on the list are marked with “*” in the output of the status command.


Process ID of the current process being debugged. 


Lwp ID of the current LWP. 


Thread ID of the current thread. 


lwp ID of a newly created LWP. 


Thread ID of a newly created thread. 


Full path name of the program being debugged. 


Previous value of $prog, which is used to get back to what you were debugging following an exec(), when $prog reverts to “-”. While $prog is expanded to a full path name, $oprog contains the program path as specified on the command line or to the debug command. If exec() is called more than once, there is no way to return to the original program.


True if the dbx binary is 32–bit.


Exit status from the last run of the program. The value is an empty string if the process has not exited. 

As an example, consider that whereami can be implemented as:

function whereami {
  echo Stopped in $func at line $lineno in file $(basename $file)
  echo "$lineno\t$line"

Variables Valid for when Command

The following variables are valid only within the body of a when command.


During the execution of the body, $handlerid is the id of the when command to which the body belongs. These commands are equivalent:

when X -temp { do_stuff; }
when X  { do_stuff; delete $handlerid; }


$booting is set to true if the event occurs during the boot process. Whenever a new program is debugged, it is first run without the user’s knowledge so that the list and location of shared libraries can be ascertained. The process is then killed. This sequence is termed booting.

While booting is occurring, all events are still available. Use this variable to distinguish the sync and the syncrtld events occurring during a debug and the ones occurring during a normal run.

Variables Valid for Specific Events

Certain variables are valid only for specific events as shown in the following tables.

Table B–1 Variables Valid for sig Event




Signal number that caused the event 


Name of $sig


Subcode of $sig if applicable


Name of $sigcode


Process ID of sender of the signal, if appropriate 

Table B–2 Variable Valid for exit Event




Value of the argument passed to _exit(2) or exit(3) or the return value of main

Table B–3 Variable Valid for dlopen and dlclose Events




Pathname of the load object dlopened or dlclosed 

Table B–4 Variables Valid for sysin and sysout Events




System call number 


System call name 

Table B–5 Variable Valid for proc_gone Events




One of signal, exit, kill, or detach 

Table B–6 Variables Valid for thr_create Event




Id of the newly created thread (for example, t@5)


Id of the newly created LWP (for example, l@4)