Unix Programming Frequently Asked Questions - Part VI

Unix Programming Frequently Asked Questions - Part VI

6. Use of tools

6.1 How can I debug the children after a fork?

Depending on the tools available there are various ways:

Your debugger may have options to select whether to follow the parent orthe child process (or both) after a fork(), which may besufficient for some purposes.

Alternatively, your debugger may have an option which allows you toattach to a running process. This can be used to attach to the childprocess after it has been started. If you don't need to examine the verystart of the child process, this is usually sufficient. Otherwise, youmay wish to insert a sleep() call after the fork() in thechild process, or a loop such as the following:

{
    volatile int f = 1;
    while(f);
}

which will hang the child process until you explicitly set f to 0using the debugger.

Remember, too, that actively using a debugger isn't the only way to finderrors in your program; utilities are available to trace system callsand signals on many unix flavours, and verbose logging is also oftenuseful.

6.2 How to build library from other libraries?

Assuming we're talking about an archive (static) library, the easiestway is to explode all the constituent libraries into their originalobjects using `ar x' in an empty directory, and combine them allback together. Of course, there is the potential for collision offilenames, but if the libraries are large, you probably don't want to becombining them in the first place....

6.3 How to create shared libraries / dlls?

The precise method for creating shared libraries varies betweendifferent systems. There are two main parts to the process; firstly theobjects to be included in the shared library must be compiled, usuallywith options to indicate that the code is to be position-independent;secondly, these objects are linked together to form the library.

Here's a trivial example that should illustrate the idea:

/* file shrobj.c */

const char *myfunc()
{
    return "Hello World";
}

/* end shrobj.c */

/* file hello.c */

#include <stdio.h>

extern const char *myfunc();

main()
{
    printf("%s\n", myfunc());
    return 0;
}

/* end hello.c */

$ gcc -fpic -c shrobj.c
$ gcc -shared -o libshared.so shrobj.o
$ gcc hello.c libshared.so
$ ./a.out
Hello World

By far the best method if you want the library and build procedure to beanything approaching portable is to use GNU Libtool. This is a smallsuite of utilities which know about the platform-dependent aspects ofbuilding shared libraries; you can distribute the necessary bits withyour program, so that when the installer configures the package, he orshe can decide what libraries to build. Libtool works fine on systemswhich do not support shared libraries. It also knows how to hook intoGNU Autoconf and GNU Automake (if you use those tools to manage yourprogram's build procedure).

If you don't want to use Libtool, then for compilers other than gcc, youshould change the compiler options as follows:

AIX 3.2 using xlc (unverified)

Drop the `-fpic', and use `-bM:SRE -bE:libshared.exp' instead of `-shared'. You also need to create a file `libshared.exp' containing the list of symbols to export, in this case `myfunc'.In addition, use `-e _nostart' when linking the library (on newerversions of AIX, I believe this changes to `-bnoentry').

SCO OpenServer 5 using the SCO Development System (unverified)

Shared libraries are only available on OS5 if you compile to ELF format,which requires the `-belf' option. Use `-Kpic' instead of `-fpic', and `cc -belf -G' for the link step.

Solaris using SparcWorks compilers

Use `-pic' instead of `-fpic', and use `ld -G' instead of `gcc -shared'.

(Submission of additional entries for the above table is encouraged.)

Other issues to watch out for:

• AIX and (I believe) Digital Unix don't require the -fpic option, becauseall code is position independent.
• AIX normally requires that you create an `export file', which is a listof symbols to be exported from the shared library. Some versions of thelinker (possibly only the SLHS linker, svld?) have an option to exportall symbols.
• If you want to refer to your shared library using the conventional`-l' parameter to the linker, you will have to understand howshared libraries are searched for at runtime on your system. The mostcommon method is by using the LD_LIBRARY_PATH environmentvariable, but there is usually an additional option to specify this atlink time.
• Most implementations record the expected runtime location of the sharedlibrary internally. Thus, moving a library from one directory to anothermay prevent it from working. Many systems have an option to the linkerto specify the expected runtime location (the `-R' linker option onSolaris, for example, or the LD_RUN_PATH environment variable).
• ELF and a.out implementations may have a linker option `-Bsymbolic'which causes internal references within the library to be resolved.Otherwise, on these systems, all symbol resolution is deferred to thefinal link, and individual routines in the main program can overrideones in the library.

6.4 Can I replace objects in a shared library?

Generally, no.

On most systems (except AIX), when you link objects to form a sharedlibrary, it's rather like linking an executable; the objects don'tretain their individual identity. As a result, it's generally notpossible to extract or replace individual objects from a shared library.

6.5 How can I generate a stack dump from within a running program?

Some systems provide library functions for unwinding the stack, so thatyou can (for example) generate a stack dump in an error-handlingfunction. However, these are highly system-specific, and only a minorityof systems have them.

A possible workaround is to get your program to invoke a debuggeron itself -- the details still vary slightly between systems, butthe general idea is to do this:

void dump_stack(void)
{
    char s[160];

    sprintf(s, "/bin/echo 'where\ndetach' | dbx -a %d", getpid());
    system(s);
        
    return;
}

You will need to tweak the commands and parameters to dbx according toyour system, or even substitute another debugger such as gdb,but this is still the most general solution to this particular problemthat I've ever seen. Kudos to Ralph Corderoy for this one :-)

Here's a list of the command lines required for some systems:

Most systems using dbx

"/bin/echo 'where\ndetach' | dbx /path/to/program %d"

AIX

"/bin/echo 'where\ndetach' | dbx -a %d"

IRIX

"/bin/echo 'where\ndetach' | dbx -p %d"