General startup syntax

While the general syntax for starting up adb is quite simple,

 adb  objectfile corefile  

there are subtle differences, depending on what is being debugged . Let's cover the most common scenarios.

User program debugging

Quite often, adb is used to analyze user program core dumps. When a program dumps core, often the user will see an error message such as "Segmentation violation, Core dumped. " The program core dumps are stored in the current working directory and are called core . This core file, paired with the object file or executable binary that fell over, can be examined by using adb .

adb can also be used to run user programs, allowing for breakpoints to be set, execution to be controlled, and data to be examined and modified on-the-fly .

The syntax used when invoking adb to examine a user program and its core file is quite simple. All you need is the executable binary, your object file, and an image of memory used by the program, the core file. If the core file is not specified, adb will look for a file named core in the current directory. If a dash, "-", is specified for the core file, adb will use the system memory to execute the object file. Here are a couple of examples.

 adb a.out core 

 adb myprogram - 

We will be using the second example later on in Chapter 11, "Symbol Tables."

While adb will work if there is no symbol table in the executable image, it won't be able to identify variables or functions by name . This makes identification of the location of failure extremely difficult, especially if the program is fairly large and you aren't an assembly language guru with tons of time on your hands.

If a stack traceback or examination of memory reports answers and addresses solely in hexadecimal, check the executable image to see if the symbol table has been removed from the object file. This removal of the symbol table is done via the UNIX strip command. Once the symbol table is strip 'ed, there is no way to get it back in the object file.

If you find you need to debug a program that has no symbol table and you have the source code for the program, you would be wise to recompile it with the appropriate options so that the symbol table is attached. Do not strip the symbol table from the resulting object file. Run the newly compiled binary and work with any core files it generates. The time you spend recompiling will very quickly be returned to you as time saved from trying to hack your way through a strip 'ed object file.

Examining system crash dump postmortem files

When examining postmortem system crash dumps, invoke adb with its -k option so that special kernel memory mapping is done within adb . On Solaris 1 systems, the object file is called vmunix. X , where X is the crash number assigned by the savecore program. On Solaris 2 systems, the object file is called unix. X . Both flavors of Solaris name the system crash dump core file vmcore. X .

We've already seen several examples of the syntax for starting up adb on a set of postmortem files. In general, the syntax is:

 adb -k unix.  X  vmcore.  X  

Examining a live system: Solaris 1

The same general startup syntax is used to access a live, running system. However, the name of the object files is quite different in Solaris 1 and Solaris 2, so let's talk about them one at a time.

For Solaris 1, the startup command follows .

 adb -k /vmunix /dev/mem 

Here, since there is no crash file, the object file is the actual, booted , executing kernel, /vmunix , and the core file, /dev/mem , is the contents of physical memory at the current time.

You may have noted that there are two memory files in the /dev directory. These are /dev/kmem and /dev/mem . They are used for different purposes and only one will work with adb . The / dev/kmem device file is the "kernel virtual memory" for the current running kernel; thus, it accepts only virtual addresses in kernel space. The other device file, /dev/mem , corresponds to actual physical memory.

Since adb expects to find a core file created from a copy of physical memory pages, it automatically performs physical-to-virtual address translations internally in order to locate data. Therefore, you must give adb the file corresponding to physical memory so that the translations will get you something real.

Examining a live system: Solaris 2

Solaris 2 systems are very different at the kernel level from Solaris 1 systems. The kernel is much more modular than before, so various pieces that are loaded into memory do not necessarily come from the same file or even from the same directory.

/kernel/unix , the closest thing to Solaris 1's /vmunix file, is now only the "core" or heart of the system and will not contain the code or the symbols for other loadable modules or drivers. A new pseudo-device, / dev/ksyms, corresponds to the symbol table of all the currently loaded modules in the system.

In addition to being a file containing all of the kernel symbols, the /dev/ksyms device, when opened, effectively prevents modules from being unloaded on-the-fly. This helps to guarantee that the symbol table of what's in memory won't change from underneath you while you are trying to analyze it.

Be aware, however, that since modules are still being loaded on demand, the kernel may still increase in size while you are poking around, as previously unrequired sections are fetched from disk. So, new symbols may be added, but old ones won't disappear as long as /dev/ksyms is open .

The adb command to analyze a running Solaris 2 system is:

 adb -k /dev/ksyms /dev/mem