Chapter 15 Compilers, Linkers, and Debuggers

This chapter discusses the changes to compilers, linkers, and debuggers.

• "Compilers"

• "Linkers"

• "Debuggers"

Compilers

The single most significant change for developers migrating from the SunOS release 4 to the Solaris 7 operating environment is the unbundling of the C compiler. One of the factors that allowed the compiler to be unbunddled is the dynamic kernel. The compiler is no long required to reconfigure the kernel as devices are now automatically loaded by the kernel as needed.

The Sun WorkShop^TM provides an ANSI C compatible compiler along with an extensive debugging and program development environment. This compiler produces executables in executable and linking format (ELF), the native object format of Solaris 7. lint and the lint libraries are also provided as part of the Sun WorkShop.

For details on the Sun WorkShop, see http://www.sun.com

The guide Making the Transition to ANSI C describes the differences between the C language implemented in the bundled SunOS 4 C compiler and as implemented by the unbundled Sun WorkShop C compiler and should be consulted when porting source. The guide is a developer product available from http://docs.sun.com Sun WorkShop Compiler C 4.2 AnswerBook Collection.

The Sun WorkShop C Compiler provides a special option flag, -Xs, that warns about language constructs that have differing behavior between K&R C and ANSI C. This is described in Sun WorkShop C User's Guide, which is also a developer product available from http://docs.sun.com in the Sun WorkShop Compiler C 4.2 AnswerBook Collection.

Linkers

There are several changes to the link editor, ld(1), in this release. The most important change is its ability to handle the new ELF native file format.

The recommended method for building libraries and executables is through the compiler driver rather than by invoking the linker directly. The compiler automatically supplies several files needed by the linker.

You cannot mix libraries--32-bit programs must link with 32-bit libraries and 64-bit programs must link with 64-bit libraries. ELF32 objects link with other ELF32 objects and ELF64 objects link with other ELF64 objects.

Link Editor Option Differences

Some options have been renamed in the new linker, some have remained the same, and others are no longer needed. Table 15-1 compares the SunOS release 4 ld command to the Solaris 7 ld command.

The sections following Table 15-1 explain how certain linking tasks are affected by the option differences.

Building Shared Libraries

The procedure for building shared libraries in the Solaris 7 operating environment requires the -G option. In the SunOS release 4 software, the linker infers that a shared library is being built if the -e option is absent. As shared libraries may have entry points, this option can no longer be used.

Building Executables

The -Bdynamic and -Bstatic options are still available, but their behavior is different. These options now refer to library inclusions to the executable rather than to the binding. Executable binding is set exclusively with the new -dy and -dn options in the Solaris 7 software. The -dy option is the default. It is required to create a dynamically linked executable. The -dn option is required to create a statically linked executable.

The -Bdynamic and -Bstatic options apply only when using the -dy option. -Bdynamic tells the link editor to include shared libraries, while -Bstatic tells it to include archive libraries. These options act as a toggle governing subsequent -l arguments until the next -Bdynamic or -Bstatic option is encountered.

The following examples show SunOS release 4 and Solaris 7 commands that can be used to create similar executables.

• sunos4.1% ld -Bstatic test.o -lx

  Uses libx.a and creates a static executable

• sunos5.x% cc -dn test.o -lx

  Uses libx.a and creates a static executable

• sunos4.1% ld -Bdynamic test.o -lx

  Uses libx.so and creates a dynamic executable

• sunos5.x% cc test.o -lx

  Uses libx.so and creates a dynamic executable

• sunos4.1% ld -Bdynamic test.o -Bstatic -lx

  Uses libx.a and creates a dynamic executable

• sunos5.x% cc test.o -Bstatic -lx

  Uses libx.a and creates a dynamic executable

Specifying Library Search Paths

In the SunOS release 4 software, directories specified with the -L option were searched at link time and the information retained for use at execution time. This behavior is now divided between the -L and -R options. The -L option specifies the directories to search at link time; the -R option tells the linker the search paths to be retained for use at run time. See "Search Path Rules", in the next section for more information.

As with the -Bdynamic and -Bstatic options, the position of the -L option has significance; it applies only to the subsequent -l options.

Search Path Rules

The dynamic linker and the runtime linker determine their search paths through a different algorithm from that used by the SunOS release 4 linker.

The examples below compare the search paths for the dynamic linker and the runtime linker for SunOS release 4 and the Solaris 7 operating environment. Notice that in the latter, the search path for the link editor and the runtime linker are affected by the LD_LIBRARY_PATH setting. However, the runtime linker permits programs to find shared libraries without having to set LD_LIBRARY_PATH and makes the loading of shared libraries even more efficient. In Solaris 7, use $ORIGIN instead, since you must build your program with a built-in library path relative to where prog is installed. For example .../package/bin/prog uses .../package/lib/libmine.so.1.

SunOS release 4 linker search paths:

• Link Editor: -L, LD_LIBRARY_PATH, /usr/lib, /usr/local/lib

• Runtime Linker: LD_LIBRARY_PATH, -L, /usr/lib, /usr/local/lib

Solaris 7 linker search paths (with LD_LIBRARY_PATH=dirlist1):

• Link Editor: -L, dirlist1, /usr/ccs/lib, /usr/lib

• Runtime Linker: dirlist1, -R, /usr/lib

Solaris 7 linker search paths (with LD_LIBRARY_PATH=dirlist1,dirlist2):

• Link Editor: dirlist1, -L, dirlist2, /usr/ccs/lib, /usr/lib

• Runtime Linker: dirlist1, dirlist2, -R, /usr/lib

Solaris 7 linker search paths using $ORIGIN

• Runtime Linker: -R, $ORIGIN/../lib

Also, with Solaris 7, LD_LIBRARY_PATH_64 is a 64-bit only version of LD_LIBRARY_PATH.

Version Numbering

The SunOS release 4 software supported both major and minor version numbers on shared libraries. The Solaris 7 operating environment supports only the major version number. For binary compatibility support, major and minor version numbers are recognized on SunOS release 4 shared libraries. These libraries are required to retain the SunOS release 4 major and minor version numbers.

Table 15-2 shows versions of SunOS release 4 and Solaris 7 shared libraries.

In SunOS release 4 system software, when the -l option was specified, the build environment linker searched for a library with both major and minor numbers. For example, if -ldl was specified, the library, libdl.so.1.0 was linked. In the Solaris 7 environment, even though major numbers are still supported, the default behavior of the link editor is to ignore version numbers. Using the previous example, the build environment link editor now searches for libdl.so and a symbolic link points to a specific version file.

The recording of a dependency in a dynamic executable or shared object is, by default, the file name of the associated shared object as it is referenced by the link editor. To provide a more consistent means of specifying dependencies, shared objects can record within themselves the file name by which they should be referenced at runtime. This is specified with the -h option when linking the library file.

Symbolic links have been created for most libraries in this release. You should build any new shared libraries with major numbers, then create a symbolic link to the version of the library that is used most often.

Examples

A new utility, dump(1), makes it easier to debug object files or to check the static and dynamic linking, see "Backing Up and Restoring Files"). The dump -L option displays the information needed by the runtime linker that is contained in the executable. This information is contained in the dynamic section of an ELF file. The RPATH entry displays search paths specified by the -R option to ld.

The following example:

• Builds a shared library, libx.so.1, using libx.o

• Creates a link from libx.so.1 to libx.so

• Shows dump output, including the SONAME field, which stores the information passed with the -h option.

examples% cc -G -o libx.so.1 -h libx.so.1 libx.o

examples% cp libx.so.1 /mylibs
examples% ln -s /mylibs/libx.so.1 /mylibs/libx.so
examples% dump -Lv libx.so.1

libx.so.1:

  **** DYNAMIC SECTION INFORMATION ****
.dynamic :
[INDEX] Tag      Value
[1]     INIT     0x3b8
[2]     FINI     0x3f4
[3]     SONAME   libx.so.1
[4]     HASH     0x94
[5]     STRTAB   0x33c
[6]     SYMTAB   0x14c
[7]     STRSZ    0x62
[8]     SYMENT   0x10
[9]     PLTGOT   0x10404
[10]    PLTSZ    0xc
[11]    PLTREL   0x7
[12]    JMPREL   0x3ac
[13]    RELA     0x3a0
[14]    RELASZ   0x18
[15]    RELAENT  0xc

If a library needs other dynamic libraries, they should be specified along with an RPATH, as the next example shows.

The next example compiles prog.c, dynamically linking libx.so (as built in the previous example), and specifies that the binary retain the current directory information for execution. This example shows the output of dump from the compiled program, prog.c. Here, the information stored in the SONAME field of the previous example is shown as NEEDED by prog. When prog is run, it will use libx.so.1 even if libx.so is linked to a different version.

examples% cc -o prog prog.c -L/mylibs -R/mylibs -lx
example% dump -Lv prog

prog:

  **** DYNAMIC SECTION INFORMATION ****
.dynamic :
[INDEX]   Tag   Value
[1]  NEEDED   libx.so.1
[2]  NEEDED   libc.so.1
[3]  INIT     0x1b1ac
[4]  FINI     0x1b248
[5]  RPATH    /mylibs
[6]  HASH     0x100e8
[7]  STRTAB   0x17f90
[8]  SYMTAB   0x12be0
[9]  STRSZ    0x31e1
[10] SYMENT   0x10
[11] DEBUG    0x0
[12] PLTGOT   0x2b25c
[13] PLTSZ    0x30
[14] PLTREL   0x7
[15] JMPREL   0x1b180
[16] RELA     0x1b174
[17] RELASZ   0x3c
[18] RELAENT  0xc

Debuggers

This section describes changes to debugging tools.

dbx and dbxtool

The dbx and dbxtool tools are no longer available with default system software. Enhanced versions of these tools are available as part of Sun WorkShop, an unbundled product.

adb and kadb

The adb and kadb tools are available in the Solaris 7 operating environment. They offer the same capabilities as the SunOS release 4 tools. kadb has been enhanced to recognize multiple processors. The processor ID is displayed in the kadb prompt. In the following examples, it is 0.

To make kernel debugging under the Solaris 7 operating environment easier:

• Enable savecore (uncomment the savecore lines in the /etc/init.d/sysetup file)

• Boot under kadb (type $c when the system crashes)

• Use adb and crash

Also, adb has been enhanced for 64-bit:

• Extend format letters for ?, /, = modifiers. K used for printing long or pointer in hexadecimal (displays 4 bytes for 32 bit programs and 8 bytes for 64-bit programs).

• Path for 64-bit SPARC macros: /usr/lib/adb/sparcv9 and /usr/platform/platformname/lib/adb/sparcv9.

kadb Macros

The kadb macros described below are particularly useful with the new multithreaded kernel.

thread displays the current thread. The current thread pointer is in SPARC global register g7.

kadb[0]: <g7$<thread

threadlist shows the stack traces of all the kernel threads in the system. This can be a long list.

kadb[0]: $<threadlist

mutex shows you the address of the owning thread. The following example uses the global unsafe driver mutex.

kadb[0]: unsafe_driver$<mutex

kadb[0]: moddebug/W 0x80000000

moddebug

moddebug enables you to watch module loading. See the end of <sys/modctl.h> for legal values for moddebug for debugging purposes only.

Debugging a Live Kernel

Use the following command to debug a live kernel.

# adb -k /dev/ksyms /dev/mem

/dev/ksyms is a pseudo device that contains the complete name list of the running kernel.

truss Command

truss is a new utility, provided to trace system calls performed, signals received, and machine faults incurred. It also has an option that enables entry and exit tracing of user-level function calls executed by the traced process. truss offers several significant improvements over the SunOS release 4 trace(1) command, including the ability to follow forked processes and to deal with multithreaded processes.

Also, the truss utility traces the system calls, signals, and machine faults of a process. It has been enhanced with a new option to enable entry and exit tracing of user-level function calls executed by the traced process.

The following example shows a summary of traced calls for the date command. With the -c option, truss does not display the trace line by line. Instead, it counts the system calls, signals, and faults, and displays a summary.

example% truss -c date
Fri Sep 18 14:31:30 PDT 1992
syscall      seconds   calls  errors
_exit            .00       1
read             .00       7
write            .00       1
open             .03      12
close            .00      12
time             .00       1
brk              .01       4
lseek            .00       1
fstat            .00       4
ioctl            .00       1
execve           .00       1
mmap             .01      17
munmap           .00       8
                ----     ---    ---
sys totals:      .05      70      0
usr time:        .03
elapsed:         .28

See the truss(1) man page for complete details on all truss options. There are a number of other Solaris 7 debugging tools based on proc(4) such as pmap(1).