fnf@unisoft.UUCP (12/12/85)
Here is a distribution kit for my macro based debugging package. I have
found it invaluable in porting stuff around to many different systems,
which may or may not have a conventional debugger.
One very useful feature is that a complete execution trace can be
dumped into a normal file, for comparison with a reference run on
a system where the suspect program works correctly, thus isolating
the place where the two executions diverge. I.E.:
On reference system:
myprog -#d:t:F:L:o,goodlogfile <some arguments>
On other system:
myprog -#d:t:F:L:o,badlogfile <some arguments>
Copy other badlogfile to reference system and:
diff goodlogfile badlogfile
SPECIAL AMIGA NOTES:
On the AMIGA or other non-protected machines note the 'D' control
flag, which provides for a delay after each debugger output line.
I set my delay to about half a second (:D,5:) to give the system
time to flush my line out before it crashes due to one of the code
lines executed after the dbug line.
For the AMIGA, the installation procedure is as follows, assuming you
have my "cc", Lattice C frontend:
(1) cc -c dbug.c
(2) copy dbug.o df1:lib/dbug.lib
(3) makedir df1:include/local
(4) copy dbug.h df1:include/local/dbug.h
Then, reference the library using "-ldbug" on the cc command line.
cc -o foo foo.c -ldbug
More parts to follow...
Part 1 of 4 This file
Part 2 of 4 The heart of the distribution, dbug.c & dbug.h
Part 3 of 4 The nroff'd user manual for printing
Part 4 of 4 The rest of the distribution; examples, doc
nroff source, shell scripts, lint source etc
-Fred
===========================================================================
Fred Fish UniSoft Systems Inc, 739 Allston Way, Berkeley, CA 94710 USA
{ucbvax,dual}!unisoft!fnf (415) 644 1230 TWX 11 910 366-2145
===========================================================================fnf@unisoft.UUCP (12/12/85)
#--------CUT---------CUT---------CUT---------CUT--------#
#########################################################
# #
# This is a shell archive file. To extract files: #
# #
# 1) Make a directory for the files. #
# 2) Write a file, such as "file.shar", containing #
# this archive file into the directory. #
# 3) Type "sh file.shar". Do not use csh. #
# #
#########################################################
#
#
echo Extracting dbug.c:
sed 's/^Z//' >dbug.c <<\STUNKYFLUFF
Z/************************************************************************
Z * *
Z * Copyright (c) 1984, Fred Fish *
Z * All Rights Reserved *
Z * *
Z * This software and/or documentation is released into the *
Z * public domain for personal, non-commercial use only. *
Z * Limited rights to use, modify, and redistribute are hereby *
Z * granted for non-commercial purposes, provided that all *
Z * copyright notices remain intact and all changes are clearly *
Z * documented. The author makes no warranty of any kind with *
Z * respect to this product and explicitly disclaims any implied *
Z * warranties of merchantability or fitness for any particular *
Z * purpose. *
Z * *
Z ************************************************************************
Z */
Z
Z
Z/*
Z * FILE
Z *
Z * dbug.c runtime support routines for dbug package
Z *
Z * SCCS
Z *
Z * @(#)dbug.c 1.11 12/10/85
Z *
Z * DESCRIPTION
Z *
Z * These are the runtime support routines for the dbug package.
Z * The dbug package has two main components; the user include
Z * file containing various macro definitions, and the runtime
Z * support routines which are called from the macro expansions.
Z *
Z * Externally visible functions in the runtime support module
Z * use the naming convention pattern "_db_xx...xx_", thus
Z * they are unlikely to collide with user defined function names.
Z *
Z * AUTHOR
Z *
Z * Fred Fish
Z * (Currently at UniSoft Systems, Berkeley Ca.)
Z *
Z */
Z
Z
Z#include <stdio.h>
Z
Z/*
Z * Manifest constants that should not require any changes.
Z */
Z
Z#define FALSE 0 /* Boolean FALSE */
Z#define TRUE 1 /* Boolean TRUE */
Z#define EOS '\000' /* End Of String marker */
Z
Z/*
Z * Manifest constants which may be "tuned" if desired.
Z */
Z
Z#define PRINTBUF 1024 /* Print buffer size */
Z#define INDENT 4 /* Indentation per trace level */
Z#define MAXDEPTH 200 /* Maximum trace depth default */
Z
Z/*
Z * The following flags are used to determine which
Z * capabilities the user has enabled with the state
Z * push macro.
Z */
Z
Z#define TRACE_ON 000001 /* Trace enabled */
Z#define DEBUG_ON 000002 /* Debug enabled */
Z#define FILE_ON 000004 /* File name print enabled */
Z#define LINE_ON 000010 /* Line number print enabled */
Z#define DEPTH_ON 000020 /* Function nest level print enabled */
Z#define PROCESS_ON 000040 /* Process name print enabled */
Z#define NUMBER_ON 000100 /* Number each line of output */
Z
Z#define TRACING (stack -> flags & TRACE_ON)
Z#define DEBUGGING (stack -> flags & DEBUG_ON)
Z#define STREQ(a,b) (strcmp(a,b) == 0)
Z
Z/*
Z * Typedefs to make things more obvious.
Z */
Z
Z#define VOID void /* Can't use typedef for most compilers */
Ztypedef int BOOLEAN;
Z
Z/*
Z * Make it easy to change storage classes if necessary.
Z */
Z
Z#define LOCAL static /* Names not needed by outside world */
Z#define IMPORT extern /* Names defined externally */
Z#define EXPORT /* Allocated here, available globally */
Z#define AUTO auto /* Names to be allocated on stack */
Z#define REGISTER register /* Names to be placed in registers */
Z
Z/*
Z * Variables which are available externally but should only
Z * be accessed via the macro package facilities.
Z */
Z
ZEXPORT FILE *_db_fp_ = stderr; /* Output stream, default stderr */
ZEXPORT char *_db_process_ = "dbug"; /* Pointer to process name; argv[0] */
ZEXPORT BOOLEAN _db_on_ = FALSE; /* TRUE if debugging currently on */
Z
Z/*
Z * Externally supplied functions.
Z */
Z
Z#ifdef unix /* Only needed for unix */
ZIMPORT VOID perror (); /* Print system/library error */
ZIMPORT int chown (); /* Change owner of a file */
ZIMPORT int getgid (); /* Get real group id */
ZIMPORT int getuid (); /* Get real user id */
ZIMPORT int access (); /* Test file for access */
Z#else
ZLOCAL VOID perror (); /* Fake system/library error print routine */
Z#endif
Z
ZIMPORT int fprintf (); /* Formatted print on file */
ZIMPORT char *strcpy (); /* Copy strings around */
ZIMPORT int strlen (); /* Find length of string */
ZIMPORT char *malloc (); /* Allocate memory */
ZIMPORT int atoi (); /* Convert ascii to integer */
Z
Z#ifndef fflush /* This is sometimes a macro */
Z IMPORT int fflush (); /* Flush output for stream */
Z#endif
Z
Z
Z/*
Z * The user may specify a list of functions to trace or
Z * debug. These lists are kept in a linear linked list,
Z * a very simple implementation.
Z */
Z
Zstruct link {
Z char *string; /* Pointer to link's contents */
Z struct link *next_link; /* Pointer to the next link */
Z};
Z
Z
Z/*
Z * Debugging states can be pushed or popped off of a
Z * stack which is implemented as a linked list. Note
Z * that the head of the list is the current state and the
Z * stack is pushed by adding a new state to the head of the
Z * list or popped by removing the first link.
Z */
Z
Zstruct state {
Z int flags; /* Current state flags */
Z int maxdepth; /* Current maximum trace depth */
Z int delay; /* Delay after each output line */
Z int level; /* Current function nesting level */
Z FILE *out_file; /* Current output stream */
Z struct link *functions; /* List of functions */
Z struct link *keywords; /* List of debug keywords */
Z struct link *processes; /* List of process names */
Z struct state *next_state; /* Next state in the list */
Z};
Z
ZLOCAL struct state *stack = NULL; /* Linked list of stacked states */
Z
Z/*
Z * Local variables not seen by user.
Z */
Z
ZLOCAL int lineno = 0; /* Current debugger output line number */
ZLOCAL char *func = "?func"; /* Name of current user function */
ZLOCAL char *file = "?file"; /* Name of current user file */
ZLOCAL BOOLEAN init_done = FALSE;/* Set to TRUE when initialization done */
Z
Z#if unix || AMIGA
ZLOCAL int jmplevel; /* Remember nesting level at setjmp () */
ZLOCAL char *jmpfunc; /* Remember current function for setjmp */
ZLOCAL char *jmpfile; /* Remember current file for setjmp */
Z#endif
Z
ZLOCAL struct link *ListParse ();/* Parse a debug command string */
ZLOCAL char *StrDup (); /* Make a fresh copy of a string */
ZLOCAL VOID OpenFile (); /* Open debug output stream */
ZLOCAL VOID CloseFile (); /* Close debug output stream */
ZLOCAL VOID PushState (); /* Push current debug state */
ZLOCAL VOID ChangeOwner (); /* Change file owner and group */
ZLOCAL BOOLEAN DoTrace (); /* Test for tracing enabled */
ZLOCAL BOOLEAN Writable (); /* Test to see if file is writable */
ZLOCAL char *DbugMalloc (); /* Allocate memory for runtime support */
ZLOCAL char *BaseName (); /* Remove leading pathname components */
Z
Z /* Supplied in Sys V runtime environ */
ZLOCAL char *strtok (); /* Break string into tokens */
ZLOCAL char *strrchr (); /* Find last occurance of char */
Z
Z/*
Z * Miscellaneous printf format strings.
Z */
Z
Z#define MSG1 "%s: missing DBUG_RETURN or DBUG_VOID_RETURN macro in function \"%s\"\n"
Z#define MSG2 "%s: can't open debug output stream \"%s\": "
Z#define MSG3 "%s: can't close debug file: "
Z#define MSG4 "%s: debugger aborting because %s\n"
Z#define MSG5 "%s: can't change owner/group of \"%s\": "
Z
Z/*
Z * Macros and defines for testing file accessibility under UNIX.
Z */
Z
Z#ifdef unix
Z# define A_EXISTS 00 /* Test for file existance */
Z# define A_EXECUTE 01 /* Test for execute permission */
Z# define A_WRITE 02 /* Test for write access */
Z# define A_READ 03 /* Test for read access */
Z# define EXISTS(pathname) (access (pathname, A_EXISTS) == 0)
Z# define WRITABLE(pathname) (access (pathname, A_WRITE) == 0)
Z#else
Z# define EXISTS(pathname) (FALSE) /* Assume no existance */
Z#endif
Z
Z/*
Z * Translate some calls among different systems.
Z */
Z
Z#ifdef unix
Z# define Delay sleep
ZIMPORT unsigned sleep (); /* Pause for given number of seconds */
Z#endif
Z
Z#ifdef AMIGA
ZIMPORT int Delay (); /* Pause for given number of ticks */
Z#endif
Z
Z
Z/*
Z * FUNCTION
Z *
Z * _db_push_ push current debugger state and set up new one
Z *
Z * SYNOPSIS
Z *
Z * VOID _db_push_ (control)
Z * char *control;
Z *
Z * DESCRIPTION
Z *
Z * Given pointer to a debug control string in "control", pushes
Z * the current debug state, parses the control string, and sets
Z * up a new debug state.
Z *
Z * The only attribute of the new state inherited from the previous
Z * state is the current function nesting level. This can be
Z * overridden by using the "r" flag in the control string.
Z *
Z * The debug control string is a sequence of colon separated fields
Z * as follows:
Z *
Z * <field_1>:<field_2>:...:<field_N>
Z *
Z * Each field consists of a mandatory flag character followed by
Z * an optional "," and comma separated list of modifiers:
Z *
Z * flag[,modifier,modifier,...,modifier]
Z *
Z * The currently recognized flag characters are:
Z *
Z * d Enable output from DBUG_<N> macros for
Z * for the current state. May be followed
Z * by a list of keywords which selects output
Z * only for the DBUG macros with that keyword.
Z * A null list of keywords implies output for
Z * all macros.
Z *
Z * f Limit debugging and/or tracing to the
Z * list of named functions. Note that a null
Z * list will disable all functions. The
Z * appropriate "d" or "t" flags must still
Z * be given, this flag only limits their
Z * actions if they are enabled.
Z *
Z * F Identify the source file name for each
Z * line of debug or trace output.
Z *
Z * L Identify the source file line number for
Z * each line of debug or trace output.
Z *
Z * n Print the current function nesting depth for
Z * each line of debug or trace output.
Z *
Z * N Number each line of dbug output.
Z *
Z * p Limit debugger actions to specified processes.
Z * A process must be identified with the
Z * DBUG_PROCESS macro and match one in the list
Z * for debugger actions to occur.
Z *
Z * P Print the current process name for each
Z * line of debug or trace output.
Z *
Z * r When pushing a new state, do not inherit
Z * the previous state's function nesting level.
Z * Useful when the output is to start at the
Z * left margin.
Z *
Z * t Enable function call/exit trace lines.
Z * May be followed by a list (containing only
Z * one modifier) giving a numeric maximum
Z * trace level, beyond which no output will
Z * occur for either debugging or tracing
Z * macros. The default is a compile time
Z * option.
Z *
Z * Some examples of debug control strings which might appear
Z * on a shell command line (the "-#" is typically used to
Z * introduce a control string to an application program) are:
Z *
Z * -#d:t
Z * -#d:f,main,subr1:F:L:t,20
Z * -#d,input,output,files:n
Z *
Z * For convenience, any leading "-#" is stripped off.
Z *
Z */
Z
Z
ZVOID _db_push_ (control)
Zchar *control;
Z{
Z REGISTER char *scan;
Z REGISTER struct link *temp;
Z
Z if (control && *control == '-') {
Z if (*++control == '#') {
Z control++;
Z }
Z }
Z control = StrDup (control);
Z PushState ();
Z scan = strtok (control, ":");
Z for (; scan != NULL; scan = strtok ((char *)NULL, ":")) {
Z switch (*scan++) {
Z case 'd':
Z _db_on_ = TRUE;
Z stack -> flags |= DEBUG_ON;
Z if (*scan++ == ',') {
Z stack -> keywords = ListParse (scan);
Z }
Z break;
Z case 'D':
Z stack -> delay = 0;
Z if (*scan++ == ',') {
Z temp = ListParse (scan);
Z stack -> delay = DelayArg (atoi (temp -> string));
Z FreeList (temp);
Z }
Z break;
Z case 'f':
Z if (*scan++ == ',') {
Z stack -> functions = ListParse (scan);
Z }
Z break;
Z case 'F':
Z stack -> flags |= FILE_ON;
Z break;
Z case 'L':
Z stack -> flags |= LINE_ON;
Z break;
Z case 'n':
Z stack -> flags |= DEPTH_ON;
Z break;
Z case 'N':
Z stack -> flags |= NUMBER_ON;
Z break;
Z case 'o':
Z if (*scan++ == ',') {
Z temp = ListParse (scan);
Z OpenFile (temp -> string);
Z FreeList (temp);
Z } else {
Z OpenFile ("-");
Z }
Z break;
Z case 'p':
Z if (*scan++ == ',') {
Z stack -> processes = ListParse (scan);
Z }
Z break;
Z case 'P':
Z stack -> flags |= PROCESS_ON;
Z break;
Z case 'r':
Z stack -> level = 0;
Z break;
Z case 't':
Z stack -> flags |= TRACE_ON;
Z if (*scan++ == ',') {
Z temp = ListParse (scan);
Z stack -> maxdepth = atoi (temp -> string);
Z FreeList (temp);
Z }
Z break;
Z }
Z }
Z free (control);
Z}
Z
Z
Z
Z/*
Z * FUNCTION
Z *
Z * _db_pop_ pop the debug stack
Z *
Z * DESCRIPTION
Z *
Z * Pops the debug stack, returning the debug state to its
Z * condition prior to the most recent _db_push_ invocation.
Z * Note that the pop will fail if it would remove the last
Z * valid state from the stack. This prevents user errors
Z * in the push/pop sequence from screwing up the debugger.
Z * Maybe there should be some kind of warning printed if the
Z * user tries to pop too many states.
Z *
Z */
Z
ZVOID _db_pop_ ()
Z{
Z REGISTER struct state *discard;
Z
Z discard = stack;
Z if (discard != NULL && discard -> next_state != NULL) {
Z stack = discard -> next_state;
Z _db_fp_ = stack -> out_file;
Z if (discard -> keywords != NULL) {
Z FreeList (discard -> keywords);
Z }
Z if (discard -> functions != NULL) {
Z FreeList (discard -> functions);
Z }
Z if (discard -> processes != NULL) {
Z FreeList (discard -> processes);
Z }
Z CloseFile (discard -> out_file);
Z free ((char *) discard);
Z }
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * _db_enter_ process entry point to user function
Z *
Z * SYNOPSIS
Z *
Z * VOID _db_enter_ (_func_, _file_, _line_, _sfunc_, _sfile_, _slevel_)
Z * char *_func_; points to current function name
Z * char *_file_; points to current file name
Z * int _line_; called from source line number
Z * char **_sfunc_; save previous _func_
Z * char **_sfile_; save previous _file_
Z * int *_slevel_; save previous nesting level
Z *
Z * DESCRIPTION
Z *
Z * Called at the beginning of each user function to tell
Z * the debugger that a new function has been entered.
Z * Note that the pointers to the previous user function
Z * name and previous user file name are stored on the
Z * caller's stack (this is why the ENTER macro must be
Z * the first "executable" code in a function, since it
Z * allocates these storage locations). The previous nesting
Z * level is also stored on the callers stack for internal
Z * self consistency checks.
Z *
Z * Also prints a trace line if tracing is enabled and
Z * increments the current function nesting depth.
Z *
Z * Note that this mechanism allows the debugger to know
Z * what the current user function is at all times, without
Z * maintaining an internal stack for the function names.
Z *
Z */
Z
ZVOID _db_enter_ (_func_, _file_, _line_, _sfunc_, _sfile_, _slevel_)
Zchar *_func_;
Zchar *_file_;
Zint _line_;
Zchar **_sfunc_;
Zchar **_sfile_;
Zint *_slevel_;
Z{
Z if (!init_done) {
Z _db_push_ ("");
Z }
Z *_sfunc_ = func;
Z *_sfile_ = file;
Z func = _func_;
Z file = BaseName (_file_);
Z stack -> level += INDENT;
Z *_slevel_ = stack -> level;
Z if (DoTrace ()) {
Z DoPrefix (_line_);
Z Indent (stack -> level);
Z (VOID) fprintf (_db_fp_, ">%s\n", func);
Z (VOID) fflush (_db_fp_);
Z (VOID) Delay (stack -> delay);
Z }
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * _db_return_ process exit from user function
Z *
Z * SYNOPSIS
Z *
Z * VOID _db_return_ (_line_, _sfunc_, _sfile_, _slevel_)
Z * int _line_; current source line number
Z * char **_sfunc_; where previous _func_ is to be retrieved
Z * char **_sfile_; where previous _file_ is to be retrieved
Z * int *_slevel_; where previous level was stashed
Z *
Z * DESCRIPTION
Z *
Z * Called just before user function executes an explicit or implicit
Z * return. Prints a trace line if trace is enabled, decrements
Z * the current nesting level, and restores the current function and
Z * file names from the defunct function's stack.
Z *
Z */
Z
ZVOID _db_return_ (_line_, _sfunc_, _sfile_, _slevel_)
Zint _line_;
Zchar **_sfunc_;
Zchar **_sfile_;
Zint *_slevel_;
Z{
Z if (!init_done) {
Z _db_push_ ("");
Z }
Z if (stack -> level != *_slevel_ && (TRACING || DEBUGGING)) {
Z (VOID) fprintf (_db_fp_, MSG1, _db_process_, func);
Z (VOID) fflush (_db_fp_);
Z } else if (DoTrace ()) {
Z DoPrefix (_line_);
Z Indent (stack -> level);
Z (VOID) fprintf (_db_fp_, "<%s\n", func);
Z (VOID) fflush (_db_fp_);
Z }
Z (VOID) Delay (stack -> delay);
Z stack -> level = *_slevel_ - INDENT;
Z func = *_sfunc_;
Z file = *_sfile_;
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * _db_printf_ handle print of debug lines
Z *
Z * SYNOPSIS
Z *
Z * VOID _db_printf_ (_line_, keyword, format,
Z * a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11)
Z * int _line_;
Z * char *keyword, *format;
Z * int a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11;
Z *
Z * DESCRIPTION
Z *
Z * When invoked via one of the DBUG macros, tests the keyword
Z * to see if that macro has been selected for processing via
Z * the debugger control string, and if so, handles printing
Z * of the arguments via the format string. The line number
Z * of the DBUG macro in the source is found in _line_.
Z *
Z * Note that the format string SHOULD NOT include a terminating
Z * newline, this is supplied automatically.
Z *
Z * NOTE
Z *
Z * The rather ugly argument declaration is to handle some
Z * magic with respect to the number of arguments passed
Z * via the DBUG macros. The current maximum is 3 arguments
Z * (not including the keyword and format strings).
Z *
Z * If the args being passed by the DBUG macro are actually
Z * doubles (worst case) then there will be a total of 12
Z * ints on the stack for a PDP-11 or 6 ints on a 68000.
Z *
Z */
Z
Z/*VARARGS3*/
ZVOID _db_printf_ (_line_, keyword, format,
Z a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11)
Zint _line_;
Zchar *keyword, *format;
Zint a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11;
Z{
Z if (_db_keyword_ (keyword)) {
Z DoPrefix (_line_);
Z if (TRACING) {
Z Indent (stack -> level + INDENT);
Z } else {
Z (VOID) fprintf (_db_fp_, "%s: ", func);
Z }
Z (VOID) fprintf (_db_fp_, "%s: ", keyword);
Z (VOID) fprintf (_db_fp_, format, a0, a1, a2, a3, a4, a5, a6,a7, a8,
Z a9, a10, a11);
Z (VOID) fprintf (_db_fp_, "\n");
Z (VOID) fflush (_db_fp_);
Z (VOID) Delay (stack -> delay);
Z }
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * ListParse parse list of modifiers in debug control string
Z *
Z * SYNOPSIS
Z *
Z * LOCAL struct link *ListParse (ctlp)
Z * char *ctlp;
Z *
Z * DESCRIPTION
Z *
Z * Given pointer to a comma separated list of strings in "cltp",
Z * parses the list, building a list and returning a pointer to it.
Z * The original comma separated list is destroyed in the process of
Z * building the linked list, thus it had better be a duplicate
Z * if it is important.
Z *
Z * Note that since each link is added at the head of the list,
Z * the final list will be in "reverse order", which is not
Z * significant for our usage here.
Z *
Z */
Z
ZLOCAL struct link *ListParse (ctlp)
Zchar *ctlp;
Z{
Z REGISTER char *start;
Z REGISTER struct link *new;
Z REGISTER struct link *head;
Z
Z head = NULL;
Z while (*ctlp != EOS) {
Z start = ctlp;
Z while (*ctlp != EOS && *ctlp != ',') {
Z ctlp++;
Z }
Z if (*ctlp == ',') {
Z *ctlp++ = EOS;
Z }
Z new = (struct link *) DbugMalloc (sizeof (struct link));
Z new -> string = StrDup (start);
Z new -> next_link = head;
Z head = new;
Z }
Z return (head);
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * InList test a given string for member of a given list
Z *
Z * SYNOPSIS
Z *
Z * LOCAL BOOLEAN InList (linkp, cp)
Z * struct link *linkp;
Z * char *cp;
Z *
Z * DESCRIPTION
Z *
Z * Tests the string pointed to by "cp" to determine if it is in
Z * the list pointed to by "linkp". Linkp points to the first
Z * link in the list. If linkp is NULL then the string is treated
Z * as if it is in the list (I.E all strings are in the null list).
Z * This may seem rather strange at first but leads to the desired
Z * operation if no list is given. The net effect is that all
Z * strings will be accepted when there is no list, and when there
Z * is a list, only those strings in the list will be accepted.
Z *
Z */
Z
ZLOCAL BOOLEAN InList (linkp, cp)
Zstruct link *linkp;
Zchar *cp;
Z{
Z REGISTER struct link *scan;
Z REGISTER BOOLEAN accept;
Z
Z if (linkp == NULL) {
Z accept = TRUE;
Z } else {
Z accept = FALSE;
Z for (scan = linkp; scan != NULL; scan = scan -> next_link) {
Z if (STREQ (scan -> string, cp)) {
Z accept = TRUE;
Z break;
Z }
Z }
Z }
Z return (accept);
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * PushState push current state onto stack and set up new one
Z *
Z * SYNOPSIS
Z *
Z * LOCAL VOID PushState ()
Z *
Z * DESCRIPTION
Z *
Z * Pushes the current state on the state stack, and initializes
Z * a new state. The only parameter inherited from the previous
Z * state is the function nesting level. This action can be
Z * inhibited if desired, via the "r" flag.
Z *
Z * The state stack is a linked list of states, with the new
Z * state added at the head. This allows the stack to grow
Z * to the limits of memory if necessary.
Z *
Z */
Z
ZLOCAL VOID PushState ()
Z{
Z REGISTER struct state *new;
Z
Z new = (struct state *) DbugMalloc (sizeof (struct state));
Z new -> flags = 0;
Z new -> delay = 0;
Z new -> maxdepth = MAXDEPTH;
Z if (stack != NULL) {
Z new -> level = stack -> level;
Z } else {
Z new -> level = 0;
Z }
Z new -> out_file = stderr;
Z new -> functions = NULL;
Z new -> keywords = NULL;
Z new -> processes = NULL;
Z new -> next_state = stack;
Z stack = new;
Z init_done = TRUE;
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * DoTrace check to see if tracing is current enabled
Z *
Z * SYNOPSIS
Z *
Z * LOCAL BOOLEAN DoTrace ()
Z *
Z * DESCRIPTION
Z *
Z * Checks to see if tracing is enabled based on whether the
Z * user has specified tracing, the maximum trace depth has
Z * not yet been reached, the current function is selected,
Z * and the current process is selected. Returns TRUE if
Z * tracing is enabled, FALSE otherwise.
Z *
Z */
Z
ZLOCAL BOOLEAN DoTrace ()
Z{
Z REGISTER BOOLEAN trace;
Z
Z trace = FALSE;
Z if (TRACING) {
Z if (stack -> level / INDENT <= stack -> maxdepth) {
Z if (InList (stack -> functions, func)) {
Z if (InList (stack -> processes, _db_process_)) {
Z trace = TRUE;
Z }
Z }
Z }
Z }
Z return (trace);
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * _db_keyword_ test keyword for member of keyword list
Z *
Z * SYNOPSIS
Z *
Z * BOOLEAN _db_keyword_ (keyword)
Z * char *keyword;
Z *
Z * DESCRIPTION
Z *
Z * Test a keyword to determine if it is in the currently active
Z * keyword list. As with the function list, a keyword is accepted
Z * if the list is null, otherwise it must match one of the list
Z * members. When debugging is not on, no keywords are accepted.
Z * After the maximum trace level is exceeded, no keywords are
Z * accepted (this behavior subject to change). Additionally,
Z * the current function and process must be accepted based on
Z * their respective lists.
Z *
Z * Returns TRUE if keyword accepted, FALSE otherwise.
Z *
Z */
Z
ZBOOLEAN _db_keyword_ (keyword)
Zchar *keyword;
Z{
Z REGISTER BOOLEAN accept;
Z
Z if (!init_done) {
Z _db_push_ ("");
Z }
Z accept = FALSE;
Z if (DEBUGGING) {
Z if (stack -> level / INDENT <= stack -> maxdepth) {
Z if (InList (stack -> functions, func)) {
Z if (InList (stack -> keywords, keyword)) {
Z if (InList (stack -> processes, _db_process_)) {
Z accept = TRUE;
Z }
Z }
Z }
Z }
Z }
Z return (accept);
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * Indent indent a line to the given indentation level
Z *
Z * SYNOPSIS
Z *
Z * LOCAL Indent (indent)
Z * int indent;
Z *
Z * DESCRIPTION
Z *
Z * Indent a line to the given level. Note that this is
Z * a simple minded but portable implementation.
Z * There are better ways.
Z *
Z */
Z
ZLOCAL Indent (indent)
Zint indent;
Z{
Z REGISTER int count;
Z AUTO char buffer[PRINTBUF];
Z
Z for (count = 0; (count < (indent - INDENT)) && (count < (PRINTBUF - 1)); count++) {
Z if ((count % INDENT) == 0) {
Z buffer[count] = '|';
Z } else {
Z buffer[count] = ' ';
Z }
Z }
Z buffer[count] = EOS;
Z (VOID) fprintf (_db_fp_, buffer);
Z (VOID) fflush (_db_fp_);
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * FreeList free all memory associated with a linked list
Z *
Z * SYNOPSIS
Z *
Z * LOCAL FreeList (linkp)
Z * struct link *linkp;
Z *
Z * DESCRIPTION
Z *
Z * Given pointer to the head of a linked list, frees all
Z * memory held by the list and the members of the list.
Z *
Z */
Z
ZLOCAL FreeList (linkp)
Zstruct link *linkp;
Z{
Z REGISTER struct link *old;
Z
Z while (linkp != NULL) {
Z old = linkp;
Z linkp = linkp -> next_link;
Z if (old -> string != NULL) {
Z free (old -> string);
Z }
Z free ((char *) old);
Z }
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * StrDup make a duplicate of a string in new memory
Z *
Z * SYNOPSIS
Z *
Z * LOCAL char *StrDup (string)
Z * char *string;
Z *
Z * DESCRIPTION
Z *
Z * Given pointer to a string, allocates sufficient memory to make
Z * a duplicate copy, and copies the string to the newly allocated
Z * memory. Failure to allocated sufficient memory is immediately
Z * fatal.
Z *
Z */
Z
Z
ZLOCAL char *StrDup (string)
Zchar *string;
Z{
Z REGISTER char *new;
Z
Z new = DbugMalloc (strlen (string) + 1);
Z (VOID) strcpy (new, string);
Z return (new);
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * DoPrefix print debugger line prefix prior to indentation
Z *
Z * SYNOPSIS
Z *
Z * LOCAL DoPrefix (_line_)
Z * int _line_;
Z *
Z * DESCRIPTION
Z *
Z * Print prefix common to all debugger output lines, prior to
Z * doing indentation if necessary. Print such information as
Z * current process name, current source file name and line number,
Z * and current function nesting depth.
Z *
Z */
Z
Z
ZLOCAL DoPrefix (_line_)
Zint _line_;
Z{
Z lineno++;
Z if (stack -> flags & NUMBER_ON) {
Z (VOID) fprintf (_db_fp_, "%5d: ", lineno);
Z }
Z if (stack -> flags & PROCESS_ON) {
Z (VOID) fprintf (_db_fp_, "%s: ", _db_process_);
Z }
Z if (stack -> flags & FILE_ON) {
Z (VOID) fprintf (_db_fp_, "%14s: ", file);
Z }
Z if (stack -> flags & LINE_ON) {
Z (VOID) fprintf (_db_fp_, "%5d: ", _line_);
Z }
Z if (stack -> flags & DEPTH_ON) {
Z (VOID) fprintf (_db_fp_, "%4d: ", stack -> level / INDENT);
Z }
Z (VOID) fflush (_db_fp_);
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * OpenFile open new output stream for debugger output
Z *
Z * SYNOPSIS
Z *
Z * LOCAL VOID OpenFile (name)
Z * char *name;
Z *
Z * DESCRIPTION
Z *
Z * Given name of a new file (or "-" for stdout) opens the file
Z * and sets the output stream to the new file.
Z *
Z */
Z
ZLOCAL VOID OpenFile (name)
Zchar *name;
Z{
Z REGISTER FILE *fp;
Z REGISTER BOOLEAN newfile;
Z
Z if (name != NULL) {
Z if (strcmp (name, "-") == 0) {
Z _db_fp_ = stdout;
Z stack -> out_file = _db_fp_;
Z } else {
Z if (!Writable (name)) {
Z (VOID) fprintf (_db_fp_, MSG2, _db_process_, name);
Z perror ("");
Z (VOID) fflush (_db_fp_);
Z (VOID) Delay (stack -> delay);
Z } else {
Z if (EXISTS (name)) {
Z newfile = FALSE;
Z } else {
Z newfile = TRUE;
Z }
Z fp = fopen (name, "a");
Z if (fp == NULL) {
Z (VOID) fprintf (_db_fp_, MSG2, _db_process_, name);
Z perror ("");
Z (VOID) fflush (_db_fp_);
Z (VOID) Delay (stack -> delay);
Z } else {
Z _db_fp_ = fp;
Z stack -> out_file = fp;
Z if (newfile) {
Z ChangeOwner (name);
Z }
Z }
Z }
Z }
Z }
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * CloseFile close the debug output stream
Z *
Z * SYNOPSIS
Z *
Z * LOCAL VOID CloseFile (fp)
Z * FILE *fp;
Z *
Z * DESCRIPTION
Z *
Z * Closes the debug output stream unless it is standard output
Z * or standard error.
Z *
Z */
Z
ZLOCAL VOID CloseFile (fp)
ZFILE *fp;
Z{
Z if (fp != stderr && fp != stdout) {
Z if (fclose (fp) == EOF) {
Z (VOID) fprintf (stderr, MSG3, _db_process_);
Z perror ("");
Z (VOID) fflush (stderr);
Z (VOID) Delay (stack -> delay);
Z }
Z }
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * DbugExit print error message and exit
Z *
Z * SYNOPSIS
Z *
Z * LOCAL VOID DbugExit (why)
Z * char *why;
Z *
Z * DESCRIPTION
Z *
Z * Prints error message using current process name, the reason for
Z * aborting (typically out of memory), and exits with status 1.
Z * This should probably be changed to use a status code
Z * defined in the user's debugger include file.
Z *
Z */
Z
ZLOCAL VOID DbugExit (why)
Zchar *why;
Z{
Z (VOID) fprintf (stderr, MSG4, _db_process_, why);
Z (VOID) fflush (stderr);
Z (VOID) Delay (stack -> delay);
Z exit (1);
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * DbugMalloc allocate memory for debugger runtime support
Z *
Z * SYNOPSIS
Z *
Z * LOCAL char *DbugMalloc (size)
Z * int size;
Z *
Z * DESCRIPTION
Z *
Z * Allocate more memory for debugger runtime support functions.
Z * Failure to to allocate the requested number of bytes is
Z * immediately fatal to the current process. This may be
Z * rather unfriendly behavior. It might be better to simply
Z * print a warning message, freeze the current debugger state,
Z * and continue execution.
Z *
Z */
Z
ZLOCAL char *DbugMalloc (size)
Zint size;
Z{
Z register char *new;
Z
Z new = malloc ((unsigned int) size);
Z if (new == NULL) {
Z DbugExit ("out of memory");
Z }
Z return (new);
Z}
Z
Z
Z/*
Z * This function may be eliminated when strtok is available
Z * in the runtime environment (missing from BSD4.1).
Z */
Z
ZLOCAL char *strtok (s1, s2)
Zchar *s1, *s2;
Z{
Z static char *end = NULL;
Z REGISTER char *rtnval;
Z
Z rtnval = NULL;
Z if (s2 != NULL) {
Z if (s1 != NULL) {
Z end = s1;
Z rtnval = strtok ((char *) NULL, s2);
Z } else if (end != NULL) {
Z if (*end != EOS) {
Z rtnval = end;
Z while (*end != *s2 && *end != EOS) {end++;}
Z if (*end != EOS) {
Z *end++ = EOS;
Z }
Z }
Z }
Z }
Z return (rtnval);
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * BaseName strip leading pathname components from name
Z *
Z * SYNOPSIS
Z *
Z * LOCAL char *BaseName (pathname)
Z * char *pathname;
Z *
Z * DESCRIPTION
Z *
Z * Given pointer to a complete pathname, locates the base file
Z * name at the end of the pathname and returns a pointer to
Z * it.
Z *
Z */
Z
ZLOCAL char *BaseName (pathname)
Zchar *pathname;
Z{
Z register char *base;
Z
Z base = strrchr (pathname, '/');
Z if (base++ == NULL) {
Z base = pathname;
Z }
Z return (base);
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * Writable test to see if a pathname is writable/creatable
Z *
Z * SYNOPSIS
Z *
Z * LOCAL BOOLEAN Writable (pathname)
Z * char *pathname;
Z *
Z * DESCRIPTION
Z *
Z * Because the debugger might be linked in with a program that
Z * runs with the set-uid-bit (suid) set, we have to be careful
Z * about opening a user named file for debug output. This consists
Z * of checking the file for write access with the real user id,
Z * or checking the directory where the file will be created.
Z *
Z * Returns TRUE if the user would normally be allowed write or
Z * create access to the named file. Returns FALSE otherwise.
Z *
Z */
Z
ZLOCAL BOOLEAN Writable (pathname)
Zchar *pathname;
Z{
Z REGISTER BOOLEAN granted;
Z#ifdef unix
Z REGISTER char *lastslash;
Z#endif
Z
Z#ifndef unix
Z granted = TRUE;
Z#else
Z granted = FALSE;
Z if (EXISTS (pathname)) {
Z if (WRITABLE (pathname)) {
Z granted = TRUE;
Z }
Z } else {
Z lastslash = strrchr (pathname, '/');
Z if (lastslash != NULL) {
Z *lastslash = EOS;
Z } else {
Z pathname = ".";
Z }
Z if (WRITABLE (pathname)) {
Z granted = TRUE;
Z }
Z if (lastslash != NULL) {
Z *lastslash = '/';
Z }
Z }
Z#endif
Z return (granted);
Z}
Z
Z
Z/*
Z * This function may be eliminated when strrchr is available
Z * in the runtime environment (missing from BSD4.1).
Z * Alternately, you can use rindex() on BSD systems.
Z */
Z
ZLOCAL char *strrchr (s, c)
Zchar *s;
Zchar c;
Z{
Z REGISTER char *scan;
Z
Z for (scan = s; *scan != EOS; scan++) {;}
Z while (scan > s && *--scan != c) {;}
Z if (*scan != c) {
Z scan = NULL;
Z }
Z return (scan);
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * ChangeOwner change owner to real user for suid programs
Z *
Z * SYNOPSIS
Z *
Z * LOCAL VOID ChangeOwner (pathname)
Z *
Z * DESCRIPTION
Z *
Z * For unix systems, change the owner of the newly created debug
Z * file to the real owner. This is strictly for the benefit of
Z * programs that are running with the set-user-id bit set.
Z *
Z * Note that at this point, the fact that pathname represents
Z * a newly created file has already been established. If the
Z * program that the debugger is linked to is not running with
Z * the suid bit set, then this operation is redundant (but
Z * harmless).
Z *
Z */
Z
ZLOCAL VOID ChangeOwner (pathname)
Zchar *pathname;
Z{
Z#ifdef unix
Z if (chown (pathname, getuid (), getgid ()) == -1) {
Z (VOID) fprintf (stderr, MSG5, _db_process_, pathname);
Z perror ("");
Z (VOID) fflush (stderr);
Z (VOID) Delay (stack -> delay);
Z }
Z#endif
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * _db_setjmp_ save debugger environment
Z *
Z * SYNOPSIS
Z *
Z * EXPORT void _db_setjmp_ ()
Z *
Z * DESCRIPTION
Z *
Z * Invoked as part of the user's DBUG_SETJMP macro to save
Z * the debugger environment in parallel with saving the user's
Z * environment.
Z *
Z */
Z
ZEXPORT void _db_setjmp_ ()
Z{
Z jmplevel = stack -> level;
Z jmpfunc = func;
Z jmpfile = file;
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * _db_longjmp_ restore previously saved debugger environment
Z *
Z * SYNOPSIS
Z *
Z * EXPORT void _db_longjmp_ ()
Z *
Z * DESCRIPTION
Z *
Z * Invoked as part of the user's DBUG_LONGJMP macro to restore
Z * the debugger environment in parallel with restoring the user's
Z * previously saved environment.
Z *
Z */
Z
ZEXPORT void _db_longjmp_ ()
Z{
Z stack -> level = jmplevel;
Z if (jmpfunc) {
Z func = jmpfunc;
Z }
Z if (jmpfile) {
Z file = jmpfile;
Z }
Z}
Z
Z
Z/*
Z * FUNCTION
Z *
Z * DelayArg convert D flag argument to appropriate value
Z *
Z * SYNOPSIS
Z *
Z * LOCAL int DelayArg (value)
Z * int value;
Z *
Z * DESCRIPTION
Z *
Z * Converts delay argument, given in tenths of a second, to the
Z * appropriate numerical argument used by the system to delay
Z * that that many tenths of a second. For example, on the
Z * AMIGA, there is a system call "Delay()" which takes an
Z * argument in ticks (50 per second). On unix, the sleep
Z * command takes seconds. Thus a value of "10", for one
Z * second of delay, gets converted to 50 on the amiga, and 1
Z * on unix. Other systems will need to use a timing loop.
Z *
Z */
Z
Z#ifdef AMIGA
Z#define HZ (50) /* Probably in some header somewhere */
Z#endif
Z
ZLOCAL int DelayArg (value)
Zint value;
Z{
Z int delayarg = 0;
Z
Z#ifdef unix
Z delayarg = value / 10; /* Delay is in seconds for sleep () */
Z#endif
Z#ifdef AMIGA
Z delayarg = (HZ * value) / 10; /* Delay in ticks for Delay () */
Z#endif
Z return (delayarg);
Z}
Z
Z
Z/*
Z * A dummy delay stub for systems that do not support delays.
Z * With a little work, this can be turned into a timing loop.
Z */
Z
Z#ifndef unix
Z#ifndef AMIGA
ZDelay ()
Z{
Z}
Z#endif
Z#endif
Z
Z
Z/*
Z * FUNCTION
Z *
Z * perror perror simulation for systems that don't have it
Z *
Z * SYNOPSIS
Z *
Z * LOCAL VOID perror (s)
Z * char *s;
Z *
Z * DESCRIPTION
Z *
Z * Perror produces a message on the standard error stream which
Z * provides more information about the library or system error
Z * just encountered. The argument string s is printed, followed
Z * by a ':', a blank, and then a message and a newline.
Z *
Z * An undocumented feature of the unix perror is that if the string
Z * 's' is a null string (NOT a NULL pointer!), then the ':' and
Z * blank are not printed.
Z *
Z * This version just complains about an "unknown system error".
Z *
Z */
Z
Z#ifndef unix
ZLOCAL VOID perror (s)
Zchar *s;
Z{
Z if (s && *s != EOS) {
Z (VOID) fprintf (stderr, "%s: ", s);
Z }
Z (VOID) fprintf (stderr, "<unknown system error>\n");
Z}
Z#endif /* !unix */
STUNKYFLUFF
set `sum dbug.c`
if test 08998 != $1
then
echo dbug.c: Checksum error. Is: $1, should be: 08998.
fi
#
#
echo Extracting dbug.h:
sed 's/^Z//' >dbug.h <<\STUNKYFLUFF
Z/************************************************************************
Z * *
Z * Copyright (c) 1984, Fred Fish *
Z * All Rights Reserved *
Z * *
Z * This software and/or documentation is released into the *
Z * public domain for personal, non-commercial use only. *
Z * Limited rights to use, modify, and redistribute are hereby *
Z * granted for non-commercial purposes, provided that all *
Z * copyright notices remain intact and all changes are clearly *
Z * documented. The author makes no warranty of any kind with *
Z * respect to this product and explicitly disclaims any implied *
Z * warranties of merchantability or fitness for any particular *
Z * purpose. *
Z * *
Z ************************************************************************
Z */
Z
Z
Z/*
Z * FILE
Z *
Z * dbug.h user include file for programs using the dbug package
Z *
Z * SYNOPSIS
Z *
Z * #include <local/dbug.h>
Z *
Z * SCCS ID
Z *
Z * @(#)dbug.h 1.6 10/3/85
Z *
Z * DESCRIPTION
Z *
Z * Programs which use the dbug package must include this file.
Z * It contains the appropriate macros to call support routines
Z * in the dbug runtime library.
Z *
Z * To disable compilation of the macro expansions define the
Z * preprocessor symbol "DBUG_OFF". This will result in null
Z * macros expansions so that the resulting code will be smaller
Z * and faster. (The difference may be smaller than you think
Z * so this step is recommended only when absolutely necessary).
Z * In general, tradeoffs between space and efficiency are
Z * decided in favor of efficiency since space is seldom a
Z * problem on the new machines).
Z *
Z * All externally visible symbol names follow the pattern
Z * "_db_xxx..xx_" to minimize the possibility of a dbug package
Z * symbol colliding with a user defined symbol.
Z *
Z * Because the C preprocessor will not accept macros with a variable
Z * number of arguments, there are separate DBUG_<N> macros for
Z * cases N = {0,1,...NMAX}. NMAX is currently 5.
Z *
Z * AUTHOR
Z *
Z * Fred Fish
Z * (Currently employed by UniSoft Systems, Berkeley, Ca.)
Z * (415) 644-1230 ext 242
Z * ucbvax!unisoft!fnf or dual!unisoft!fnf
Z *
Z */
Z
Z
Z/*
Z * Internally used dbug variables which must be global.
Z */
Z
Z#ifndef DBUG_OFF
Z extern int _db_on_; /* TRUE if debug currently enabled */
Z extern FILE *_db_fp_; /* Current debug output stream */
Z extern char *_db_process_; /* Name of current process */
Z extern int _db_keyword_ (); /* Accept/reject keyword */
Z extern void _db_push_ (); /* Push state, set up new state */
Z extern void _db_pop_ (); /* Pop previous debug state */
Z extern void _db_enter_ (); /* New user function entered */
Z extern void _db_return_ (); /* User function return */
Z extern void _db_printf_ (); /* Print debug output */
Z extern void _db_setjmp_ (); /* Save debugger environment */
Z extern void _db_longjmp_ (); /* Restore debugger environment */
Z# endif
Z
Z
Z/*
Z * These macros provide a user interface into functions in the
Z * dbug runtime support library. They isolate users from changes
Z * in the MACROS and/or runtime support.
Z *
Z * The symbols "__LINE__" and "__FILE__" are expanded by the
Z * preprocessor to the current source file line number and file
Z * name respectively.
Z *
Z * WARNING --- Because the DBUG_ENTER macro allocates space on
Z * the user function's stack, it must precede any executable
Z * statements in the user function.
Z *
Z */
Z
Z# ifdef DBUG_OFF
Z# define DBUG_ENTER(a1)
Z# define DBUG_RETURN(a1) return(a1)
Z# define DBUG_VOID_RETURN return
Z# define DBUG_EXECUTE(keyword,a1)
Z# define DBUG_2(keyword,format)
Z# define DBUG_3(keyword,format,a1)
Z# define DBUG_4(keyword,format,a1,a2)
Z# define DBUG_5(keyword,format,a1,a2,a3)
Z# define DBUG_PUSH(a1)
Z# define DBUG_POP()
Z# define DBUG_PROCESS(a1)
Z# define DBUG_FILE (stderr)
Z# define DBUG_SETJMP setjmp
Z# define DBUG_LONGJMP longjmp
Z# else
Z# define DBUG_ENTER(a) \
Z auto char *_db_func_, *_db_file_; \
Z int _db_level_; \
Z _db_enter_ (a,__FILE__,__LINE__,&_db_func_,&_db_file_,&_db_level_)
Z# define DBUG_LEAVE \
Z (_db_return_ (__LINE__, &_db_func_, &_db_file_, &_db_level_))
Z# define DBUG_RETURN(a1) return (DBUG_LEAVE, (a1))
Z/* define DBUG_RETURN(a1) {DBUG_LEAVE; return(a1);} Alternate form */
Z# define DBUG_VOID_RETURN {DBUG_LEAVE; return;}
Z# define DBUG_EXECUTE(keyword,a1) \
Z if (_db_on_) {if (_db_keyword_ (keyword)) { a1 }}
Z# define DBUG_2(keyword,format) \
Z if (_db_on_) {_db_printf_ (__LINE__, keyword, format);}
Z# define DBUG_3(keyword,format,a1) \
Z if (_db_on_) {_db_printf_ (__LINE__, keyword, format, a1);}
Z# define DBUG_4(keyword,format,a1,a2) \
Z if (_db_on_) {_db_printf_ (__LINE__, keyword, format, a1, a2);}
Z# define DBUG_5(keyword,format,a1,a2,a3) \
Z if (_db_on_) {_db_printf_ (__LINE__, keyword, format, a1, a2, a3);}
Z# define DBUG_PUSH(a1) _db_push_ (a1)
Z# define DBUG_POP() _db_pop_ ()
Z# define DBUG_PROCESS(a1) (_db_process_ = a1)
Z# define DBUG_FILE (_db_fp_)
Z# define DBUG_SETJMP(a1) (_db_setjmp_ (), setjmp (a1))
Z# define DBUG_LONGJMP(a1,a2) (_db_longjmp_ (), longjmp (a1, a2))
Z# endif
STUNKYFLUFF
set `sum dbug.h`
if test 28258 != $1
then
echo dbug.h: Checksum error. Is: $1, should be: 28258.
fi
#
#
echo Extracting Makefile:
sed 's/^Z//' >Makefile <<\STUNKYFLUFF
Z#
Z# FILE
Z#
Z# Makefile Makefile for dbug package
Z#
Z# SCCS ID
Z#
Z# @(#)Makefile 1.10 12/11/85
Z#
Z# DESCRIPTION
Z#
Z# Makefile for the dbug package (under UNIX system V or 4.2BSD).
Z#
Z# Interesting things to make are:
Z#
Z# lib => Makes the runtime support library in the
Z# current directory.
Z#
Z# lintlib => Makes the lint library in the current directory.
Z#
Z# install => Install pieces from current directory to
Z# where they belong.
Z#
Z# doc => Makes the documentation in the current
Z# directory.
Z#
Z# clean => Remove objects, temporary files, etc from
Z# current directory.
Z#
Z# superclean => Remove everything except sccs source files.
Z# Uses interactive remove for verification.
Z
ZAR = ar
ZRM = rm
ZCFLAGS = -O
ZGFLAGS = -s
ZINSTALL = ./install.sh
ZCHMOD = chmod
ZMAKE = make
ZINC = /usr/include/local
ZLIB = /usr/lib
ZRANLIB = ./ranlib.sh
ZMODE = 664
Z
Z# The following is provided for example only, it is set by "doinstall.sh".
ZLLIB = /usr/lib
Z
Z.SUFFIXES: .r .r~ .c .c~
Z
Z.c~.c:
Z $(GET) $(GFLAGS) -p $< >$*.c
Z
Z.r~.r:
Z $(GET) $(GFLAGS) -p $< >$*.r
Z
Z.c~.r:
Z $(GET) $(GFLAGS) -p $< >$*.c
Z sed "s/\\\/\\\e/" <$*.c >$*.r
Z $(RM) -f $*.c
Z
Z.c.r:
Z sed "s/\\\/\\\e/" <$< >$*.r
Z
ZEXAMPLES = example1.r example2.r example3.r
ZOUTPUTS = output1.r output2.r output3.r output4.r output5.r
Z
ZNROFF_INC = main.r factorial.r $(OUTPUTS) $(EXAMPLES)
Z
Z
Z#
Z# The default thing to do is remake the local runtime support
Z# library, local lint library, and local documentation as
Z# necessary.
Z#
Z
Zall : scripts lib lintlib doc
Z
Zlib : libdbug.a
Z
Zlintlib : llib-ldbug.ln
Z
Zdoc : factorial user.t
Z
Z#
Z# Make the local runtime support library "libdbug.a" from
Z# sources.
Z#
Z
Zlibdbug.a : dbug.o
Z rm -f $@
Z $(AR) cr $@ $?
Z $(RANLIB) $@
Z
Z#
Z# Clean up the local directory.
Z#
Z
Zclean :
Z $(RM) -f *.o *.ln *.a *.BAK nohup.out factorial $(NROFF_INC)
Z
Zsuperclean :
Z $(RM) -i ?[!.]*
Z
Z#
Z# Install the new header and library files. Since things go in
Z# different places depending upon the system (lint libraries
Z# go in /usr/lib under SV and /usr/lib/lint under BSD for example),
Z# the shell script "doinstall.sh" figures out the environment and
Z# does a recursive make with the appropriate pathnames set.
Z#
Z
Zinstall : scripts
Z ./doinstall.sh $(MAKE) sysinstall
Z
Zsysinstall: $(INC) $(INC)/dbug.h $(LIB)/libdbug.a \
Z $(LLIB)/llib-ldbug.ln $(LLIB)/llib-ldbug
Z
Z$(INC) :
Z -if test -d $@ ;then true ;else mkdir $@ ;fi
Z
Z$(INC)/dbug.h : dbug.h
Z $(INSTALL) $? $@
Z $(CHMOD) $(MODE) $@
Z
Z$(LIB)/libdbug.a : libdbug.a
Z $(INSTALL) $? $@
Z $(CHMOD) $(MODE) $@
Z
Z$(LLIB)/llib-ldbug.ln : llib-ldbug.ln
Z $(INSTALL) $? $@
Z $(CHMOD) $(MODE) $@
Z
Z$(LLIB)/llib-ldbug : llib-ldbug
Z $(INSTALL) $? $@
Z $(CHMOD) $(MODE) $@
Z
Z#
Z# Make the local lint library.
Z#
Z
Zllib-ldbug.ln : llib-ldbug
Z ./mklintlib.sh $? $@
Z
Z#
Z# Make the test/example program "factorial".
Z#
Z# Note that the objects depend on the LOCAL dbug.h file and
Z# the compilations are set up to find dbug.h in the current
Z# directory even though the sources have "#include <dbug.h>".
Z# This allows the examples to look like the code a user would
Z# write but still be used as test cases for new versions
Z# of dbug.
Z
Zfactorial : main.o factorial.o libdbug.a
Z $(CC) -o $@ main.o factorial.o libdbug.a
Z
Zmain.o : main.c dbug.h
Z $(CC) $(CFLAGS) -c -I. main.c
Z
Zfactorial.o : factorial.c dbug.h
Z $(CC) $(CFLAGS) -c -I. factorial.c
Z
Z
Z#
Z# Rebuild the documentation
Z#
Z
Zuser.t : user.r $(NROFF_INC)
Z nroff -cm user.r >$@
Z
Z#
Z# Run the factorial program to produce the sample outputs.
Z#
Z
Zoutput1.r: factorial
Z factorial 1 2 3 4 5 >$@
Z
Zoutput2.r: factorial
Z factorial -#t:o 2 3 >$@
Z
Zoutput3.r: factorial
Z factorial -#d:t:o 3 >$@
Z
Zoutput4.r: factorial
Z factorial -#d,result:o 4 >$@
Z
Zoutput5.r: factorial
Z factorial -#d:f,factorial:F:L:o 3 >$@
Z
Z#
Z# All files included by user.r depend on user.r, thus
Z# forcing them to be remade if user.r changes.
Z#
Z
Z$(NROFF_INC) : user.r
Z
Z#
Z# Make scripts executable (safeguard against forgetting to do it
Z# when extracting scripts from a source code control system.
Z#
Z
Zscripts:
Z chmod a+x *.sh
Z
STUNKYFLUFF
set `sum Makefile`
if test 23479 != $1
then
echo Makefile: Checksum error. Is: $1, should be: 23479.
fi
echo ALL DONE BUNKY!
exit 0fnf@unisoft.UUCP (12/12/85)
#--------CUT---------CUT---------CUT---------CUT--------#
#########################################################
# #
# This is a shell archive file. To extract files: #
# #
# 1) Make a directory for the files. #
# 2) Write a file, such as "file.shar", containing #
# this archive file into the directory. #
# 3) Type "sh file.shar". Do not use csh. #
# #
#########################################################
#
#
echo Extracting user.t:
sed 's/^Z//' >user.t <<\STUNKYFLUFF
Z
Z
Z
Z D B U G
Z
Z C Program Debugging Package
Z
Z by
Z
Z Fred Fish
Z
Z
Z
Z
Z IIIINNNNTTTTRRRROOOODDDDUUUUCCCCTTTTIIIIOOOONNNN
Z
Z
Z Almost every program development environment worthy of
Z the name provides some sort of debugging facility. Usually
Z this takes the form of a program which is capable of
Z controlling execution of other programs and examining the
Z internal state of other executing programs. These types of
Z programs will be referred to as external debuggers since the
Z debugger is not part of the executing program. Examples of
Z this type of debugger include the aaaaddddbbbb and ssssddddbbbb debuggers
Z provided with the UUUUNNNNIIIIXXXX811119 operating system.
Z
Z
Z One of the problems associated with developing programs
Z in an environment with good external debuggers is that
Z developed programs tend to have little or no internal
Z instrumentation. This is usually not a problem for the
Z developer since he is, or at least should be, intimately
Z familiar with the internal organization, data structures,
Z and control flow of the program being debugged. It is a
Z serious problem for maintenance programmers, who are
Z unlikely to have such familiarity with the program being
Z maintained, modified, or ported to another environment. It
Z is also a problem, even for the developer, when the program
Z is moved to an environment with a primitive or unfamiliar
Z debugger, or even no debugger.
Z
Z
Z On the other hand, _d_b_u_g is an example of an internal
Z debugger. Because it requires internal instrumentation of a
Z program, and its usage does not depend on any special
Z capabilities of the execution environment, it is always
Z available and will execute in any environment that the
Z program itself will execute in. In addition, since it is a
Z complete package with a specific user interface, all
Z programs which use it will be provided with similar
Z debugging capabilities. This is in sharp contrast to other
Z
Z
Z __________
Z
Z 1. UNIX is a trademark of AT&T Bell Laboratories.
Z
Z
Z
Z
Z - 1 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z forms of internal instrumentation where each developer has
Z their own, usually less capable, form of internal debugger.
Z In summary, because _d_b_u_g is an internal debugger it provides
Z consistency across operating environments, and because it is
Z available to all developers it provides consistency across
Z all programs in the same environment.
Z
Z
Z The _d_b_u_g package imposes only a slight speed penalty on
Z executing programs, typically much less than 10 percent, and
Z a modest size penalty, typically 10 to 20 percent. By
Z defining a specific C preprocessor symbol both of these can
Z be reduced to zero with no changes required to the source
Z code.
Z
Z
Z The following list is a quick summary of the
Z capabilities of the _d_b_u_g package. Each capability can be
Z individually enabled or disabled at the time a program is
Z invoked by specifying the appropriate command line
Z arguments.
Z
Z o Execution trace showing function level control
Z flow in a semi-graphically manner using
Z indentation to indicate nesting depth.
Z
Z o Output the values of all, or any subset of, key
Z internal variables.
Z
Z o Limit actions to a specific set of named
Z functions.
Z
Z o Limit function trace to a specified nesting depth.
Z
Z o Label each output line with source file name and
Z line number.
Z
Z o Label each output line with name of current
Z process.
Z
Z o Push or pop internal debugging state to allow
Z execution with built in debugging defaults.
Z
Z o Redirect the debug output stream to standard
Z output (stdout) or a named file. The default
Z output stream is standard error (stderr). The
Z redirection mechanism is completely independent of
Z normal command line redirection to avoid output
Z conflicts.
Z
Z
Z
Z
Z
Z - 2 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z PPPPRRRRIIIIMMMMIIIITTTTIIIIVVVVEEEE DDDDEEEEBBBBUUUUGGGGGGGGIIIINNNNGGGG TTTTEEEECCCCHHHHNNNNIIIIQQQQUUUUEEEESSSS
Z
Z
Z Internal instrumentation is already a familiar concept
Z to most programmers, since it is usually the first debugging
Z technique learned. Typically, "print statements" are
Z inserted in the source code at interesting points, the code
Z is recompiled and executed, and the resulting output is
Z examined in an attempt to determine where the problem is.
Z
Z The procedure is iterative, with each iteration yielding
Z more and more output, and hopefully the source of the
Z problem is discovered before the output becomes too large to
Z deal with or previously inserted statements need to be
Z removed. Figure 1 is an example of this type of primitive
Z debugging technique.
Z
Z
Z
Z #include <stdio.h>
Z
Z main (argc, argv)
Z int argc;
Z char *argv[];
Z {
Z printf ("argv[0] = %d\n", argv[0]);
Z /*
Z * Rest of program
Z */
Z printf ("== done ==\n");
Z }
Z
Z
Z Figure 1
Z Primitive Debugging Technique
Z
Z
Z
Z
Z
Z Eventually, and usually after at least several
Z iterations, the problem will be found and corrected. At
Z this point, the newly inserted print statements must be
Z dealt with. One obvious solution is to simply delete them
Z all. Beginners usually do this a few times until they have
Z to repeat the entire process every time a new bug pops up.
Z The second most obvious solution is to somehow disable the
Z output, either through the source code comment facility,
Z creation of a debug variable to be switched on or off, or by
Z using the C preprocessor. Figure 2 is an example of all
Z three techniques.
Z
Z
Z
Z - 3 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z
Z
Z #include <stdio.h>
Z
Z int debug = 0;
Z
Z main (argc, argv)
Z int argc;
Z char *argv[];
Z {
Z /* printf ("argv = %x\n", argv) */
Z if (debug) printf ("argv[0] = %d\n", argv[0]);
Z /*
Z * Rest of program
Z */
Z #ifdef DEBUG
Z printf ("== done ==\n");
Z #endif
Z }
Z
Z
Z Figure 2
Z Debug Disable Techniques
Z
Z
Z
Z
Z
Z Each technique has its advantages and disadvantages
Z with respect to dynamic vs static activation, source code
Z overhead, recompilation requirements, ease of use, program
Z readability, etc. Overuse of the preprocessor solution
Z quickly leads to problems with source code readability and
Z maintainability when multiple ####iiiiffffddddeeeeffff symbols are to be
Z defined or undefined based on specific types of debug
Z desired. The source code can be made slightly more readable
Z by suitable indentation of the ####iiiiffffddddeeeeffff arguments to match the
Z indentation of the code, but not all C preprocessors allow
Z this. The only requirement for the standard UUUUNNNNIIIIXXXX C
Z preprocessor is for the '#' character to appear in the first
Z column, but even this seems like an arbitrary and
Z unreasonable restriction. Figure 3 is an example of this
Z usage.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 4 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z
Z
Z #include <stdio.h>
Z
Z main (argc, argv)
Z int argc;
Z char *argv[];
Z {
Z # ifdef DEBUG
Z printf ("argv[0] = %d\n", argv[0]);
Z # endif
Z /*
Z * Rest of program
Z */
Z # ifdef DEBUG
Z printf ("== done ==\n");
Z # endif
Z }
Z
Z
Z Figure 3
Z More Readable Preprocessor Usage
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 5 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z FFFFUUUUNNNNCCCCTTTTIIIIOOOONNNN TTTTRRRRAAAACCCCEEEE EEEEXXXXAAAAMMMMPPPPLLLLEEEE
Z
Z
Z We will start off learning about the capabilities of
Z the _d_b_u_g package by using a simple minded program which
Z computes the factorial of a number. In order to better
Z demonstrate the function trace mechanism, this program is
Z implemented recursively. Figure 4 is the main function for
Z this factorial program.
Z
Z
Z
Z #include <stdio.h>
Z /* User programs should use <local/dbug.h> */
Z #include "dbug.h"
Z
Z main (argc, argv)
Z int argc;
Z char *argv[];
Z {
Z register int result, ix;
Z extern int factorial (), atoi ();
Z
Z DBUG_ENTER ("main");
Z DBUG_PROCESS (argv[0]);
Z for (ix = 1; ix < argc && argv[ix][0] == '-'; ix++) {
Z switch (argv[ix][1]) {
Z case '#':
Z DBUG_PUSH (&(argv[ix][2]));
Z break;
Z }
Z }
Z for (; ix < argc; ix++) {
Z DBUG_4 ("args", "argv[%d] = %s", ix, argv[ix]);
Z result = factorial (atoi (argv[ix]));
Z printf ("%d\n", result);
Z }
Z DBUG_RETURN (0);
Z }
Z
Z
Z Figure 4
Z Factorial Program Mainline
Z
Z
Z
Z
Z
Z The mmmmaaaaiiiinnnn function is responsible for processing any
Z command line option arguments and then computing and
Z printing the factorial of each non-option argument.
Z
Z
Z
Z - 6 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z First of all, notice that all of the debugger functions
Z are implemented via preprocessor macros. This does not
Z detract from the readability of the code and makes disabling
Z all debug compilation trivial (a single preprocessor symbol,
Z DDDDBBBBUUUUGGGG____OOOOFFFFFFFF, forces the macro expansions to be null).
Z
Z Also notice the inclusion of the header file ddddbbbbuuuugggg....hhhh
Z from the local header file directory. (The version included
Z here is the test version in the dbug source distribution
Z directory). This file contains all the definitions for the
Z debugger macros, which all have the form DDDDBBBBUUUUGGGG____XXXXXXXX............XXXXXXXX.
Z
Z
Z The DDDDBBBBUUUUGGGG____EEEENNNNTTTTEEEERRRR macro informs that debugger that we have
Z entered the function named mmmmaaaaiiiinnnn. It must be the very first
Z "executable" line in a function, after all declarations and
Z before any other executable line. The DDDDBBBBUUUUGGGG____PPPPRRRROOOOCCCCEEEESSSSSSSS macro is
Z generally used only once per program to inform the debugger
Z what name the program was invoked with. The DDDDBBBBUUUUGGGG____PPPPUUUUSSSSHHHH macro
Z modifies the current debugger state by saving the previous
Z state and setting a new state based on the control string
Z passed as its argument. The DDDDBBBBUUUUGGGG____4444 macro is used to print
Z the values of each argument for which a factorial is to be
Z computed. The DDDDBBBBUUUUGGGG____RRRREEEETTTTUUUURRRRNNNN macro tells the debugger that the
Z end of the current function has been reached and returns a
Z value to the calling function. All of these macros will be
Z fully explained in subsequent sections.
Z
Z To use the debugger, the factorial program is invoked
Z with a command line of the form:
Z
Z factorial -#d:t 1 2 3
Z
Z The mmmmaaaaiiiinnnn function recognizes the "-#d:t" string as a
Z debugger control string, and passes the debugger arguments
Z ("d:t") to the _d_b_u_g runtime support routines via the
Z DDDDBBBBUUUUGGGG____PPPPUUUUSSSSHHHH macro. This particular string enables output from
Z the DDDDBBBBUUUUGGGG____4444 macro with the 'd' flag and enables function
Z tracing with the 't' flag. The factorial function is then
Z called three times, with the arguments "1", "2", and "3".
Z
Z
Z Debug control strings consist of a header, the "-#",
Z followed by a colon separated list of debugger arguments.
Z Each debugger argument is a single character flag followed
Z by an optional comma separated list of argments specific to
Z the given flag. Some examples are:
Z
Z -#d:t:o
Z -#d,in,out:f,main:F:L
Z
Z
Z
Z
Z - 7 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z Note that previously enabled debugger actions can be
Z disabled by the control string "-#".
Z
Z
Z The definition of the factorial function, symbolized as
Z "N!", is given by:
Z
Z N! = N * N-1 * ... 2 * 1
Z
Z Figure 5 is the factorial function which implements this
Z algorithm recursively. Note that this is not necessarily
Z the best way to do factorials and error conditions are
Z ignored completely.
Z
Z
Z
Z #include <stdio.h>
Z /* User programs should use <local/dbug.h> */
Z #include "dbug.h"
Z
Z int factorial (value)
Z register int value;
Z {
Z DBUG_ENTER ("factorial");
Z DBUG_3 ("find", "find %d factorial", value);
Z if (value > 1) {
Z value *= factorial (value - 1);
Z }
Z DBUG_3 ("result", "result is %d", value);
Z DBUG_RETURN (value);
Z }
Z
Z
Z Figure 5
Z Factorial Function
Z
Z
Z
Z
Z
Z One advantage (some may not consider it so) to using
Z the _d_b_u_g package is that it strongly encourages fully
Z structured coding with only one entry and one exit point in
Z each function. Multiple exit points, such as early returns
Z to escape a loop, may be used, but each such point requires
Z the use of an appropriate DDDDBBBBUUUUGGGG____RRRREEEETTTTUUUURRRRNNNN or DDDDBBBBUUUUGGGG____VVVVOOOOIIIIDDDD____RRRREEEETTTTUUUURRRRNNNN
Z macro.
Z
Z
Z To build the factorial program on a UUUUNNNNIIIIXXXX system,
Z compile and link with the command:
Z
Z
Z
Z - 8 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z cc -o factorial main.c factorial.c -ldbug
Z
Z The "-ldbug" argument tells the loader to link in the
Z runtime support modules for the _d_b_u_g package. Executing the
Z factorial program with a command of the form:
Z
Z factorial 1 2 3 4 5
Z
Z generates the output shown in figure 6.
Z
Z
Z
Z 1
Z 2
Z 6
Z 24
Z 120
Z
Z
Z Figure 6
Z factorial 1 2 3 4 5
Z
Z
Z
Z
Z
Z Function level tracing is enabled by passing the
Z debugger the 't' flag in the debug control string. Figure 7
Z is the output resulting from the command "factorial -
Z #t:o 3 2".
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 9 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z
Z
Z | >factorial
Z | | >factorial
Z | | <factorial
Z | <factorial
Z 2
Z | >factorial
Z | | >factorial
Z | | | >factorial
Z | | | <factorial
Z | | <factorial
Z | <factorial
Z 6
Z <main
Z
Z
Z Figure 7
Z factorial -#t:o 3 2
Z
Z
Z
Z
Z
Z Each entry to or return from a function is indicated by
Z '>' for the entry point and '<' for the exit point,
Z connected by vertical bars to allow matching points to be
Z easily found when separated by large distances.
Z
Z
Z This trace output indicates that there was an initial
Z call to factorial from main (to compute 2!), followed by a
Z single recursive call to factorial to compute 1!. The main
Z program then output the result for 2! and called the
Z factorial function again with the second argument, 3.
Z Factorial called itself recursively to compute 2! and 1!,
Z then returned control to main, which output the value for 3!
Z and exited.
Z
Z
Z Note that there is no matching entry point "main>" for
Z the return point "<main" because at the time the DDDDBBBBUUUUGGGG____EEEENNNNTTTTEEEERRRR
Z macro was reached in main, tracing was not enabled yet. It
Z was only after the macro DDDDBBBBUUUUGGGG____PPPPUUUUSSSSHHHH was executing that
Z tracing became enabled. This implies that the argument list
Z should be processed as early as possible since all code
Z preceding the first call to DDDDBBBBUUUUGGGG____PPPPUUUUSSSSHHHH is essentially
Z invisible to ddddbbbbuuuugggg (this can be worked around by inserted a
Z temporary DDDDBBBBUUUUGGGG____PPPPUUUUSSSSHHHH((((aaaarrrrggggvvvv[[[[1111]]]])))) immediately after the
Z DDDDBBBBUUUUGGGG____EEEENNNNTTTTEEEERRRR((((""""mmmmaaaaiiiinnnn"""")))) macro.
Z
Z
Z
Z
Z - 10 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z One last note, the trace output normally comes out on
Z the standard error. Since the factorial program prints its
Z result on the standard output, there is the possibility of
Z the output on the terminal being scrambled if the two
Z streams are not synchronized. Thus the debugger is told to
Z write its output on the standard output instead, via the 'o'
Z flag character. Note that no 'o' implies the default
Z (standard error), a 'o' with no arguments means standard
Z output, and a 'o' with an argument means used the named
Z file. I.E, "factorial -#t:o,logfile 3 2" would write the
Z trace output in "logfile". Because of UUUUNNNNIIIIXXXX implementation
Z details, programs usually run faster when writing to stdout
Z rather than stderr, though this is not a prime consideration
Z in this example.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 11 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z UUUUSSSSEEEE OOOOFFFF DDDDBBBBUUUUGGGG____NNNN MMMMAAAACCCCRRRROOOOSSSS
Z
Z
Z The mechanism used to produce "printf" style output is
Z the DDDDBBBBUUUUGGGG____NNNN macro, where NNNN is replaced by the matching number
Z of arguments to the macro. Unfortunately, the standard UUUUNNNNIIIIXXXX
Z C preprocessor does not allow macros to have variable number
Z of arguments. If it did, then a single macro (such as
Z DBUG_PRINTF) could replace all the DDDDBBBBUUUUGGGG____NNNN macros.
Z
Z
Z To allow selection of output from specific macros, the
Z first argument to every DDDDBBBBUUUUGGGG____NNNN macro is a _d_b_u_g keyword.
Z When this keyword appears in the argument list of the 'd'
Z flag in a debug control string, as in "-
Z #d,keyword1,keyword2,...:t", output from the corresponding
Z macro is enabled. The default when there is no 'd' flag in
Z the control string is to enable output from all DDDDBBBBUUUUGGGG____NNNN
Z macros.
Z
Z
Z Typically, a program will be run once, with no keywords
Z specified, to determine what keywords are significant for
Z the current problem (the keywords are printed in the macro
Z output line). Then the program will be run again, with the
Z desired keywords, to examine only specific areas of
Z interest.
Z
Z
Z The rest of the argument list to a DDDDBBBBUUUUGGGG____NNNN is a standard
Z printf style format string and one or more arguments to
Z print. Note that no explicit newline is required at the end
Z of the format string. As a matter of style, two or three
Z small DDDDBBBBUUUUGGGG____NNNN macros are preferable to a single macro with a
Z huge format string. Figure 8 shows the output for default
Z tracing and debug.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 12 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z
Z
Z | args: argv[2] = 3
Z | >factorial
Z | | find: find 3 factorial
Z | | >factorial
Z | | | find: find 2 factorial
Z | | | >factorial
Z | | | | find: find 1 factorial
Z | | | | result: result is 1
Z | | | <factorial
Z | | | result: result is 2
Z | | <factorial
Z | | result: result is 6
Z | <factorial
Z 6
Z <main
Z
Z
Z Figure 8
Z factorial -#d:t:o 3
Z
Z
Z
Z
Z
Z The output from the DDDDBBBBUUUUGGGG____NNNN macro is indented to match
Z the trace output for the function in which the macro occurs.
Z When debugging is enabled, but not trace, the output starts
Z at the left margin, without indentation.
Z
Z
Z To demonstrate selection of specific macros for output,
Z figure 9 shows the result when the factorial program is
Z invoked with the debug control string "-#d,result:o".
Z
Z
Z
Z factorial: result: result is 1
Z factorial: result: result is 2
Z factorial: result: result is 6
Z factorial: result: result is 24
Z 24
Z
Z
Z Figure 9
Z factorial -#d,result:o 4
Z
Z
Z
Z
Z
Z
Z
Z - 13 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z It is sometimes desirable to restrict debugging and
Z trace actions to a specific function or list of functions.
Z This is accomplished with the 'f' flag character in the
Z debug control string. Figure 10 is the output of the
Z factorial program when run with the control string "-
Z #d:f,factorial:F:L:o". The 'F' flag enables printing of the
Z source file name and the 'L' flag enables printing of the
Z source file line number.
Z
Z
Z
Z factorial.c: 9: factorial: find: find 3 factorial
Z factorial.c: 9: factorial: find: find 2 factorial
Z factorial.c: 9: factorial: find: find 1 factorial
Z factorial.c: 13: factorial: result: result is 1
Z factorial.c: 13: factorial: result: result is 2
Z factorial.c: 13: factorial: result: result is 6
Z 6
Z
Z
Z Figure 10
Z factorial -#d:f,factorial:F:L:o 3
Z
Z
Z
Z
Z
Z The output in figure 10 shows that the "find" macro is
Z in file "factorial.c" at source line 8 and the "result"
Z macro is in the same file at source line 12.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 14 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z SSSSUUUUMMMMMMMMAAAARRRRYYYY OOOOFFFF MMMMAAAACCCCRRRROOOOSSSS
Z
Z
Z This section summarizes the usage of all currently
Z defined macros in the _d_b_u_g package. The macros definitions
Z are found in the user include file ddddbbbbuuuugggg....hhhh from the standard
Z include directory.
Z
Z
Z
Z DBUG_ENTER Used to tell the runtime support module
Z the name of the function being entered.
Z The argument must be of type "pointer to
Z character". The DBUG_ENTER macro must
Z precede all executable lines in the
Z function just entered, and must come
Z after all local declarations. Each
Z DBUG_ENTER macro must have a matching
Z DBUG_RETURN or DBUG_VOID_RETURN macro at
Z the function exit points. DBUG_ENTER
Z macros used without a matching
Z DBUG_RETURN or DBUG_VOID_RETURN macro
Z will cause warning messages from the
Z _d_b_u_g package runtime support module.
Z
Z EX: DBUG_ENTER ("main");
Z
Z DBUG_RETURN Used at each exit point of a function
Z containing a DBUG_ENTER macro at the
Z entry point. The argument is the value
Z to return. Functions which return no
Z value (void) should use the
Z DBUG_VOID_RETURN macro. It is an error
Z to have a DBUG_RETURN or
Z DBUG_VOID_RETURN macro in a function
Z which has no matching DBUG_ENTER macro,
Z and the compiler will complain if the
Z macros are actually used (expanded).
Z
Z EX: DBUG_RETURN (value);
Z EX: DBUG_VOID_RETURN;
Z
Z DBUG_PROCESS Used to name the current process being
Z executed. A typical argument for this
Z macro is "argv[0]", though it will be
Z perfectly happy with any other string.
Z
Z EX: DBUG_PROCESS (argv[0]);
Z
Z DBUG_PUSH Sets a new debugger state by pushing the
Z current ddddbbbbuuuugggg state onto an internal
Z
Z
Z
Z - 15 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z stack and setting up the new state using
Z the debug control string passed as the
Z macro argument. The most common usage
Z is to set the state specified by a debug
Z control string retrieved from the
Z argument list. Note that the leading
Z "-#" in a debug control string specified
Z as a command line argument must nnnnooootttt be
Z passed as part of the macro argument.
Z The proper usage is to pass a pointer to
Z the first character aaaafffftttteeeerrrr the "-#"
Z string.
Z
Z EX: DBUG_PUSH ((argv[i][2]));
Z EX: DBUG_PUSH ("d:t");
Z EX: DBUG_PUSH ("");
Z
Z DBUG_POP Restores the previous debugger state by
Z popping the state stack. Attempting to
Z pop more states than pushed will be
Z ignored and no warning will be given.
Z The DBUG_POP macro has no arguments.
Z
Z EX: DBUG_POP ();
Z
Z DBUG_FILE The DBUG_FILE macro is used to do
Z explicit I/O on the debug output stream.
Z It is used in the same manner as the
Z symbols "stdout" and "stderr" in the
Z standard I/O package.
Z
Z EX: fprintf (DBUG_FILE, "Doing my own
Z I/O!0);
Z
Z DBUG_EXECUTE The DBUG_EXECUTE macro is used to
Z execute any arbitrary C code. The first
Z argument is the debug keyword, used to
Z trigger execution of the code specified
Z as the second argument. This macro must
Z be used cautiously because, like the
Z DBUG_N macros, it is automatically
Z selected by default whenever the 'd'
Z flag has no argument list (I.E., a "-
Z #d:t" control string).
Z
Z EX: DBUG_EXECUTE ("abort", abort ());
Z
Z DBUG_N Used to do printing via the "fprintf"
Z library function on the current debug
Z stream, DBUG_FILE. N may currently be a
Z number in the range 2-5, and specifies
Z
Z
Z
Z - 16 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z the number of arguments in the
Z corresponding macro. The first argument
Z is a debug keyword, the second is a
Z format string, and the remaining
Z arguments, if any, are the values to be
Z printed.
Z
Z EX: DBUG_2 ("eof", "end of file found");
Z EX: DBUG_3 ("type","type is %x", type);
Z EX: DBUG_4 ("stp", "%x -> %s", stp,
Z stp -> name);
Z
Z DBUG_SETJMP Used in place of the setjmp() function
Z to first save the current debugger state
Z and then execute the standard setjmp
Z call. This allows to the debugger to
Z restore it's state when the DBUG_LONGJMP
Z macro is used to invoke the standard
Z longjmp() call. Currently all instances
Z of DBUG_SETJMP must occur within the
Z same function and at the same function
Z nesting level.
Z
Z EX: DBUG_SETJMP (env);
Z
Z DBUG_LONGJMP Used in place of the longjmp() function
Z to first restore the previous debugger
Z state at the time of the last
Z DBUG_SETJMP and then execute the
Z standard longjmp() call. Note that
Z currently all DBUG_LONGJMP macros
Z restore the state at the time of the
Z last DBUG_SETJMP. It would be possible
Z to maintain separate DBUG_SETJMP and
Z DBUG_LONGJMP pairs by having the
Z debugger runtime support module use the
Z first argument to differentiate the
Z pairs.
Z
Z EX: DBUG_LONGJMP (env,val);
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 17 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z DDDDEEEEBBBBUUUUGGGG CCCCOOOONNNNTTTTRRRROOOOLLLL SSSSTTTTRRRRIIIINNNNGGGG
Z
Z
Z The debug control string is used to set the state of
Z the debugger via the DDDDBBBBUUUUGGGG____PPPPUUUUSSSSHHHH macro. This section
Z summarizes the currently available debugger options and the
Z flag characters which enable or disable them. Argument
Z lists enclosed in '[' and ']' are optional.
Z
Z
Z d[,keywords] Enable output from macros with
Z specified keywords. A null list of
Z keywords implies that all keywords are
Z selected.
Z
Z D[,time] Delay for specified time after each
Z output line, to let output drain.
Z Time is given in tenths of a second
Z (value of 10 is one second). Default
Z is zero.
Z
Z f[,functions] Limit debugger actions to the
Z specified list of functions. A null
Z list of functions implies that all
Z functions are selected.
Z
Z F Mark each debugger output line with
Z the name of the source file containing
Z the macro causing the output.
Z
Z L Mark each debugger output line with
Z the source file line number of the
Z macro causing the output.
Z
Z n Mark each debugger output line with
Z the current function nesting depth.
Z
Z N Sequentially number each debugger
Z output line starting at 1. This is
Z useful for reference purposes when
Z debugger output is interspersed with
Z program output.
Z
Z o[,file] Redirect the debugger output stream to
Z the specified file. The default
Z output stream is stderr. A null
Z argument list causes output to be
Z redirected to stdout.
Z
Z p[,processes] Limit debugger actions to the
Z specified processes. A null list
Z
Z
Z
Z - 18 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z implies all processes. This is useful
Z for processes which run child
Z processes. Note that each debugger
Z output line can be marked with the
Z name of the current process via the
Z 'P' flag. The process name must match
Z the argument passed to the
Z DDDDBBBBUUUUGGGG____PPPPRRRROOOOCCCCEEEESSSSSSSS macro.
Z
Z P Mark each debugger output line with
Z the name of the current process. Most
Z useful when used with a process which
Z runs child processes that are also
Z being debugged. Note that the parent
Z process must arrange for the debugger
Z control string to be passed to the
Z child processes.
Z
Z r Used in conjunction with the DDDDBBBBUUUUGGGG____PPPPUUUUSSSSHHHH
Z macro to reset the current indentation
Z level back to zero. Most useful with
Z DDDDBBBBUUUUGGGG____PPPPUUUUSSSSHHHH macros used to temporarily
Z alter the debugger state.
Z
Z t[,N] Enable function control flow tracing.
Z The maximum nesting depth is specified
Z by N, and defaults to 200.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 19 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z HHHHIIIINNNNTTTTSSSS AAAANNNNDDDD MMMMIIIISSSSCCCCEEEELLLLLLLLAAAANNNNEEEEOOOOUUUUSSSS
Z
Z
Z One of the most useful capabilities of the _d_b_u_g package
Z is to compare the executions of a given program in two
Z different environments. This is typically done by executing
Z the program in the environment where it behaves properly and
Z saving the debugger output in a reference file. The program
Z is then run with identical inputs in the environment where
Z it misbehaves and the output is again captured in a
Z reference file. The two reference files can then be
Z differentially compared to determine exactly where execution
Z of the two processes diverges.
Z
Z
Z A related usage is regression testing where the
Z execution of a current version is compared against
Z executions of previous versions. This is most useful when
Z there are only minor changes.
Z
Z
Z It is not difficult to modify an existing compiler to
Z implement some of the functionality of the _d_b_u_g package
Z automatically, without source code changes to the program
Z being debugged. In fact, such changes were implemented in a
Z version of the Portable C Compiler by the author in less
Z than a day. However, it is strongly encouraged that all
Z newly developed code continue to use the debugger macros for
Z the portability reasons noted earlier. The modified
Z compiler should be used only for testing existing programs.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 20 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z CCCCAAAAVVVVEEEEAAAATTTTSSSS
Z
Z
Z The _d_b_u_g package works best with programs which have
Z "line oriented" output, such as text processors, general
Z purpose utilities, etc. It can be interfaced with screen
Z oriented programs such as visual editors by redefining the
Z appropriate macros to call special functions for displaying
Z the debugger results. Of course, this caveat is not
Z applicable if the debugger output is simply dumped into a
Z file for post-execution examination.
Z
Z
Z Programs which use memory allocation functions other
Z than mmmmaaaalllllllloooocccc will usually have problems using the standard
Z _d_b_u_g package. The most common problem is multiply allocated
Z memory.
Z
Z
Z Beware that some of the macros are not context
Z independent. Some of them contain _i_f statements with no
Z _e_l_s_e statements. In particular, the following code segment
Z will not behave as expected:
Z
Z
Z
Z if (something_interesting)
Z DBUG_2 ("ins", "something interesting");
Z else
Z do_normal_processing ();
Z
Z
Z
Z The user code _e_l_s_e will bind to the macro's _i_f to produce
Z code equivalent to:
Z
Z
Z
Z if (something_interesting)
Z if (debugging_on)
Z printf ("something interesting");
Z else
Z do_normal_processing ();
Z
Z
Z
Z The author has received numerous suggestions for changes
Z which would eliminate this danger, most based on obscure
Z features of the language or preprocessor, but has rejected
Z most of these for portability or efficiency reasons. (The
Z author also considers it to be poor programming practice to
Z
Z
Z
Z - 21 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z write code with any control flow statements that do not use
Z braces.) However, if you absolutely must prevent this
Z behavior try changing the macro definitions to something of
Z the form:
Z
Z
Z
Z #define DBUG_2(keyword,format) \
Z do { \
Z if (_db_on_) { \
Z _db_printf_ (__LINE__, keyword, format); \
Z } \
Z } while (0)
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 22 -
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z D B U G
Z
Z C Program Debugging Package
Z
Z by
Z9
Z Fred Fish
Z9
Z
Z
Z _A_B_S_T_R_A_C_T
Z
Z
Z
Z This document introduces _d_b_u_g, a macro based C debugging
Z package which has proven to be a very flexible and useful
Z tool for debugging, testing, and porting C programs.
Z
Z
Z All of the features of the _d_b_u_g package can be enabled
Z or disabled dynamically at execution time. This means that
Z production programs will run normally when debugging is not
Z enabled, and eliminates the need to maintain two separate
Z versions of a program.
Z
Z
Z Many of the things easily accomplished with
Z conventional debugging tools, such as symbolic debuggers,
Z are difficult or impossible with this package, and vice
Z versa. Thus the _d_b_u_g package should _n_o_t be thought of as a
Z replacement or substitute for other debugging tools, but
Z simply as a useful _a_d_d_i_t_i_o_n to the program development and
Z maintenance environment.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z99
Z
Z
Z
Z
Z
Z
STUNKYFLUFF
set `sum user.t`
if test 14630 != $1
then
echo user.t: Checksum error. Is: $1, should be: 14630.
fi
echo ALL DONE BUNKY!
exit 0fnf@unisoft.UUCP (12/12/85)
#--------CUT---------CUT---------CUT---------CUT--------#
#########################################################
# #
# This is a shell archive file. To extract files: #
# #
# 1) Make a directory for the files. #
# 2) Write a file, such as "file.shar", containing #
# this archive file into the directory. #
# 3) Type "sh file.shar". Do not use csh. #
# #
#########################################################
#
#
echo Extracting doinstall.sh:
sed 's/^Z//' >doinstall.sh <<\STUNKYFLUFF
Z
Z# Warning - first line left blank for sh/csh/ksh compatibility. Do not
Z# remove it. fnf@Unisoft
Z
Z# doinstall.sh --- figure out environment and do recursive make with
Z# appropriate pathnames. Works under SV or BSD.
Z
Zif [ -r /usr/include/search.h ]
Zthen
Z # System V
Z $* LLIB=/usr/lib
Zelse
Z # 4.2 BSD
Z $* LLIB=/usr/lib/lint
Zfi
STUNKYFLUFF
set `sum doinstall.sh`
if test 16801 != $1
then
echo doinstall.sh: Checksum error. Is: $1, should be: 16801.
fi
#
#
echo Extracting example1.c:
sed 's/^Z//' >example1.c <<\STUNKYFLUFF
Z#include <stdio.h>
Z
Zmain (argc, argv)
Zint argc;
Zchar *argv[];
Z{
Z printf ("argv[0] = %d\n", argv[0]);
Z /*
Z * Rest of program
Z */
Z printf ("== done ==\n");
Z}
STUNKYFLUFF
set `sum example1.c`
if test 55211 != $1
then
echo example1.c: Checksum error. Is: $1, should be: 55211.
fi
#
#
echo Extracting example2.c:
sed 's/^Z//' >example2.c <<\STUNKYFLUFF
Z#include <stdio.h>
Z
Zint debug = 0;
Z
Zmain (argc, argv)
Zint argc;
Zchar *argv[];
Z{
Z /* printf ("argv = %x\n", argv) */
Z if (debug) printf ("argv[0] = %d\n", argv[0]);
Z /*
Z * Rest of program
Z */
Z#ifdef DEBUG
Z printf ("== done ==\n");
Z#endif
Z}
STUNKYFLUFF
set `sum example2.c`
if test 55108 != $1
then
echo example2.c: Checksum error. Is: $1, should be: 55108.
fi
#
#
echo Extracting example3.c:
sed 's/^Z//' >example3.c <<\STUNKYFLUFF
Z#include <stdio.h>
Z
Zmain (argc, argv)
Zint argc;
Zchar *argv[];
Z{
Z# ifdef DEBUG
Z printf ("argv[0] = %d\n", argv[0]);
Z# endif
Z /*
Z * Rest of program
Z */
Z# ifdef DEBUG
Z printf ("== done ==\n");
Z# endif
Z}
STUNKYFLUFF
set `sum example3.c`
if test 54881 != $1
then
echo example3.c: Checksum error. Is: $1, should be: 54881.
fi
#
#
echo Extracting factorial.c:
sed 's/^Z//' >factorial.c <<\STUNKYFLUFF
Z#include <stdio.h>
Z/* User programs should use <local/dbug.h> */
Z#include "dbug.h"
Z
Zint factorial (value)
Zregister int value;
Z{
Z DBUG_ENTER ("factorial");
Z DBUG_3 ("find", "find %d factorial", value);
Z if (value > 1) {
Z value *= factorial (value - 1);
Z }
Z DBUG_3 ("result", "result is %d", value);
Z DBUG_RETURN (value);
Z}
STUNKYFLUFF
set `sum factorial.c`
if test 12970 != $1
then
echo factorial.c: Checksum error. Is: $1, should be: 12970.
fi
#
#
echo Extracting install.sh:
sed 's/^Z//' >install.sh <<\STUNKYFLUFF
Z
Z# WARNING -- first line intentionally left blank for sh/csh/ksh
Z# compatibility. Do not remove it! FNF, UniSoft Systems.
Z#
Z# Usage is:
Z# install <from> <to>
Z#
Z# The file <to> is replaced with the file <from>, after first
Z# moving <to> to a backup file. The backup file name is created
Z# by prepending the filename (after removing any leading pathname
Z# components) with "OLD".
Z#
Z# This script is currently not real robust in the face of signals
Z# or permission problems. It also does not do (by intention) all
Z# the things that the System V or BSD install scripts try to do
Z#
Z
Zif [ $# -ne 2 ]
Zthen
Z echo "usage: $0 <from> <to>"
Z exit 1
Zfi
Z
Z# Now extract the dirname and basename components. Unfortunately, BSD does
Z# not have dirname, so we do it the hard way.
Z
Zfd=`expr $1'/' : '\(/\)[^/]*/$' \| $1'/' : '\(.*[^/]\)//*[^/][^/]*//*$' \| .`
Zff=`basename $1`
Ztd=`expr $2'/' : '\(/\)[^/]*/$' \| $2'/' : '\(.*[^/]\)//*[^/][^/]*//*$' \| .`
Ztf=`basename $2`
Z
Z# Now test to make sure that they are not the same files.
Z
Zif [ $fd/$ff = $td/$tf ]
Zthen
Z echo "install: input and output are same files"
Z exit 2
Zfi
Z
Z# Save a copy of the "to" file as a backup.
Z
Zif test -f $td/$tf
Zthen
Z if test -f $td/OLD$tf
Z then
Z rm -f $td/OLD$tf
Z fi
Z mv $td/$tf $td/OLD$tf
Z if [ $? != 0 ]
Z then
Z exit 3
Z fi
Zfi
Z
Z# Now do the copy and return appropriate status
Z
Zcp $fd/$ff $td/$tf
Zif [ $? != 0 ]
Zthen
Z exit 4
Zelse
Z exit 0
Zfi
Z
STUNKYFLUFF
set `sum install.sh`
if test 30596 != $1
then
echo install.sh: Checksum error. Is: $1, should be: 30596.
fi
#
#
echo Extracting llib-ldbug:
sed 's/^Z//' >llib-ldbug <<\STUNKYFLUFF
Z/************************************************************************
Z * *
Z * Copyright (c) 1984, Fred Fish *
Z * All Rights Reserved *
Z * *
Z * This software and/or documentation is released into the *
Z * public domain for personal, non-commercial use only. *
Z * Limited rights to use, modify, and redistribute are hereby *
Z * granted for non-commercial purposes, provided that all *
Z * copyright notices remain intact and all changes are clearly *
Z * documented. The author makes no warranty of any kind with *
Z * respect to this product and explicitly disclaims any implied *
Z * warranties of merchantability or fitness for any particular *
Z * purpose. *
Z * *
Z ************************************************************************
Z */
Z
Z
Z/*
Z * FILE
Z *
Z * llib-ldbug lint library source for debugging package
Z *
Z * SCCS ID
Z *
Z * @(#)llib-ldbug 1.4 12/11/85
Z *
Z * DESCRIPTION
Z *
Z * Function definitions for use in building lint library.
Z * Note that these must stay in syncronization with actual
Z * declarations in "dbug.c".
Z *
Z */
Z
Z
Z/*LINTLIBRARY*/
Z
Z#include <stdio.h>
Z#define VOID void
Z#define FALSE 0
Z
Zint _db_on_ = FALSE;
ZFILE *_db_fp_ = stderr;
Zchar *_db_process_ = "dbug";
Z
ZVOID _db_push_ (control)
Zchar *control;
Z{
Z}
Z
ZVOID _db_pop_ ()
Z{
Z}
Z
ZVOID _db_enter_ (_func_, _file_, _line_, _sfunc_, _sfile_, _slevel_)
Zchar *_func_;
Zchar *_file_;
Zint _line_;
Zchar **_sfunc_;
Zchar **_sfile_;
Zint *_slevel_;
Z{
Z}
Z
ZVOID _db_return_ (_line_, _sfunc_, _sfile_, _slevel_)
Zint _line_;
Zchar **_sfunc_;
Zchar **_sfile_;
Zint *_slevel_;
Z{
Z}
Z
Z/*VARARGS3*/
ZVOID _db_printf_ (_line_, keyword, format,
Z a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11)
Zint _line_;
Zchar *keyword, *format;
Zint a0, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10, a11;
Z{
Z}
Z
Zint _db_keyword_ (keyword)
Zchar *keyword;
Z{
Z return (0);
Z}
STUNKYFLUFF
set `sum llib-ldbug`
if test 52300 != $1
then
echo llib-ldbug: Checksum error. Is: $1, should be: 52300.
fi
#
#
echo Extracting main.c:
sed 's/^Z//' >main.c <<\STUNKYFLUFF
Z#include <stdio.h>
Z/* User programs should use <local/dbug.h> */
Z#include "dbug.h"
Z
Zmain (argc, argv)
Zint argc;
Zchar *argv[];
Z{
Z register int result, ix;
Z extern int factorial (), atoi ();
Z
Z DBUG_ENTER ("main");
Z DBUG_PROCESS (argv[0]);
Z for (ix = 1; ix < argc && argv[ix][0] == '-'; ix++) {
Z switch (argv[ix][1]) {
Z case '#':
Z DBUG_PUSH (&(argv[ix][2]));
Z break;
Z }
Z }
Z for (; ix < argc; ix++) {
Z DBUG_4 ("args", "argv[%d] = %s", ix, argv[ix]);
Z result = factorial (atoi (argv[ix]));
Z printf ("%d\n", result);
Z }
Z DBUG_RETURN (0);
Z}
STUNKYFLUFF
set `sum main.c`
if test 57777 != $1
then
echo main.c: Checksum error. Is: $1, should be: 57777.
fi
#
#
echo Extracting mklintlib.sh:
sed 's/^Z//' >mklintlib.sh <<\STUNKYFLUFF
Z
Z# Warning - first line left blank for sh/csh/ksh compatibility. Do not
Z# remove it. fnf@Unisoft
Z
Z# mklintlib --- make a lint library, under either System V or 4.2 BSD
Z#
Z# usage: mklintlib <infile> <outfile>
Z#
Z
Zif test $# -ne 2
Zthen
Z echo "usage: mklintlib <infile> <outfile>"
Z exit 1
Zfi
Z
Zif grep SIGTSTP /usr/include/signal.h >/dev/null
Zthen # BSD
Z if test -r /usr/include/whoami.h # 4.1
Z then
Z /lib/cpp -C -Dlint $1 >hlint
Z (/usr/lib/lint/lint1 <hlint >$2) 2>&1 | grep -v warning
Z else # 4.2
Z lint -Cxxxx $1
Z mv llib-lxxxx.ln $2
Z fi
Zelse # USG
Z cc -E -C -Dlint $1 | /usr/lib/lint1 -vx -Hhlint >$2
Z rm -f hlint
Zfi
Zexit 0 # don't kill make
STUNKYFLUFF
set `sum mklintlib.sh`
if test 51735 != $1
then
echo mklintlib.sh: Checksum error. Is: $1, should be: 51735.
fi
#
#
echo Extracting ranlib.sh:
sed 's/^Z//' >ranlib.sh <<\STUNKYFLUFF
Z
Z# Warning - first line left blank for sh/csh/ksh compatibility. Do not
Z# remove it. fnf@Unisoft
Z
Z# ranlib --- do a ranlib if necessary
Z
Zif [ -r /usr/bin/ranlib ]
Zthen
Z /usr/bin/ranlib $*
Zelif [ -r /bin/ranlib ]
Zthen
Z /bin/ranlib $*
Zelse
Z :
Zfi
STUNKYFLUFF
set `sum ranlib.sh`
if test 13298 != $1
then
echo ranlib.sh: Checksum error. Is: $1, should be: 13298.
fi
#
#
echo Extracting user.r:
sed 's/^Z//' >user.r <<\STUNKYFLUFF
Z.\" @(#)user.r 1.9 12/11/85
Z.\"
Z.\" DBUG (Macro Debugger Package) nroff source
Z.\"
Z.\" nroff -mm user.r >user.t
Z.\"
Z.\" ===================================================
Z.\"
Z.\" === Some sort of black magic, but I forget...
Z.tr ~
Z.\" === Hyphenation control (1 = on)
Z.\".nr Hy 1
Z.\" === Force all first level headings to start on new page
Z.nr Ej 1
Z.\" === Set for breaks after headings for levels 1-3
Z.nr Hb 3
Z.\" === Set for space after headings for levels 1-3
Z.nr Hs 3
Z.\" === Set standard indent for one/half inch
Z.nr Si 10
Z.\" === Set page header
Z.PH "/DBUG User Manual/(preliminary)/\*(DT/"
Z.\" === Set page footer
Z.PF "// - % - //"
Z.\" === Set page offset
Z.\".po 0.60i
Z.\" === Set line length
Z.\".ll 6.5i
Z.TL
ZD B U G
Z.P 0
ZC Program Debugging Package
Z.P 0
Zby
Z.AU "Fred Fish"
Z.AF ""
Z.SA 1
Z.\" === All paragraphs indented.
Z.nr Pt 1
Z.AS 1
ZThis document introduces
Z.I dbug ,
Za macro based C debugging
Zpackage which has proven to be a very flexible and useful tool
Zfor debugging, testing, and porting C programs.
Z
Z.P
ZAll of the features of the
Z.I dbug
Zpackage can be enabled or disabled dynamically at execution time.
ZThis means that production programs will run normally when
Zdebugging is not enabled, and eliminates the need to maintain two
Zseparate versions of a program.
Z
Z.P
ZMany of the things easily accomplished with conventional debugging
Ztools, such as symbolic debuggers, are difficult or impossible with this
Zpackage, and vice versa.
ZThus the
Z.I dbug
Zpackage should
Z.I not
Zbe thought of as a replacement or substitute for
Zother debugging tools, but simply as a useful
Z.I addition
Zto the
Zprogram development and maintenance environment.
Z
Z.AE
Z.MT 4
Z.SK
Z.B
ZINTRODUCTION
Z.R
Z
Z.P
ZAlmost every program development environment worthy of the name
Zprovides some sort of debugging facility.
ZUsually this takes the form of a program which is capable of
Zcontrolling execution of other programs and examining the internal
Zstate of other executing programs.
ZThese types of programs will be referred to as external debuggers
Zsince the debugger is not part of the executing program.
ZExamples of this type of debugger include the
Z.B adb
Zand
Z.B sdb
Zdebuggers provided with the
Z.B UNIX\*F
Z.FS
ZUNIX is a trademark of AT&T Bell Laboratories.
Z.FE
Zoperating system.
Z
Z.P
ZOne of the problems associated with developing programs in an environment
Zwith good external debuggers is that developed programs tend to have
Zlittle or no internal instrumentation.
ZThis is usually not a problem for the developer since he is,
Zor at least should be, intimately familiar with the internal organization,
Zdata structures, and control flow of the program being debugged.
ZIt is a serious problem for maintenance programmers, who
Zare unlikely to have such familiarity with the program being
Zmaintained, modified, or ported to another environment.
ZIt is also a problem, even for the developer, when the program is
Zmoved to an environment with a primitive or unfamiliar debugger,
Zor even no debugger.
Z
Z.P
ZOn the other hand,
Z.I dbug
Zis an example of an internal debugger.
ZBecause it requires internal instrumentation of a program,
Zand its usage does not depend on any special capabilities of
Zthe execution environment, it is always available and will
Zexecute in any environment that the program itself will
Zexecute in.
ZIn addition, since it is a complete package with a specific
Zuser interface, all programs which use it will be provided
Zwith similar debugging capabilities.
ZThis is in sharp contrast to other forms of internal instrumentation
Zwhere each developer has their own, usually less capable, form
Zof internal debugger.
ZIn summary,
Zbecause
Z.I dbug
Zis an internal debugger it provides consistency across operating
Zenvironments,
Zand because it is available to all developers it provides
Zconsistency across all programs in the same environment.
Z
Z.P
ZThe
Z.I dbug
Zpackage imposes only a slight speed penalty on executing
Zprograms, typically much less than 10 percent, and a modest size
Zpenalty, typically 10 to 20 percent.
ZBy defining a specific C preprocessor symbol both of these
Zcan be reduced to zero with no changes required to the
Zsource code.
Z
Z.P
ZThe following list is a quick summary of the capabilities
Zof the
Z.I dbug
Zpackage.
ZEach capability can be individually enabled or disabled
Zat the time a program is invoked by specifying the appropriate
Zcommand line arguments.
Z.SP 1
Z.ML o 1i
Z.LI
ZExecution trace showing function level control flow in a
Zsemi-graphically manner using indentation to indicate nesting
Zdepth.
Z.LI
ZOutput the values of all, or any subset of, key internal variables.
Z.LI
ZLimit actions to a specific set of named functions.
Z.LI
ZLimit function trace to a specified nesting depth.
Z.LI
ZLabel each output line with source file name and line number.
Z.LI
ZLabel each output line with name of current process.
Z.LI
ZPush or pop internal debugging state to allow execution with
Zbuilt in debugging defaults.
Z.LI
ZRedirect the debug output stream to standard output (stdout)
Zor a named file.
ZThe default output stream is standard error (stderr).
ZThe redirection mechanism is completely independent of
Znormal command line redirection to avoid output conflicts.
Z.LE
Z
Z.SK
Z.B
ZPRIMITIVE DEBUGGING TECHNIQUES
Z.R
Z
Z.P
ZInternal instrumentation is already a familiar concept
Zto most programmers, since it is usually the first debugging
Ztechnique learned.
ZTypically, "print\ statements" are inserted in the source
Zcode at interesting points, the code is recompiled and executed,
Zand the resulting output is examined in an attempt to determine
Zwhere the problem is.
Z
ZThe procedure is iterative, with each iteration yielding more
Zand more output, and hopefully the source of the problem is
Zdiscovered before the output becomes too large to deal with
Zor previously inserted statements need to be removed.
ZFigure 1 is an example of this type of primitive debugging
Ztechnique.
Z.DS I N
Z.SP 2
Z.so example1.r
Z.SP 2
Z.ll -5
Z.ce
ZFigure 1
Z.ce
ZPrimitive Debugging Technique
Z.ll +5
Z.SP 2
Z.DE
Z
Z.P
ZEventually, and usually after at least several iterations, the
Zproblem will be found and corrected.
ZAt this point, the newly inserted print statements must be
Zdealt with.
ZOne obvious solution is to simply delete them all.
ZBeginners usually do this a few times until they have to
Zrepeat the entire process every time a new bug pops up.
ZThe second most obvious solution is to somehow disable
Zthe output, either through the source code comment facility,
Zcreation of a debug variable to be switched on or off, or by using the
ZC preprocessor.
ZFigure 2 is an example of all three techniques.
Z.DS I N
Z.SP 2
Z.so example2.r
Z.SP 2
Z.ll -5
Z.ce
ZFigure 2
Z.ce
ZDebug Disable Techniques
Z.ll +5
Z.SP 2
Z.DE
Z
Z.P
ZEach technique has its advantages and disadvantages with respect
Zto dynamic vs static activation, source code overhead, recompilation
Zrequirements, ease of use, program readability, etc.
ZOveruse of the preprocessor solution quickly leads to problems with
Zsource code readability and maintainability when multiple
Z.B #ifdef
Zsymbols are to be defined or undefined based on specific types
Zof debug desired.
ZThe source code can be made slightly more readable by suitable indentation
Zof the
Z.B #ifdef
Zarguments to match the indentation of the code, but
Znot all C preprocessors allow this.
ZThe only requirement for the standard
Z.B UNIX
ZC preprocessor is for the '#' character to appear
Zin the first column, but even this seems
Zlike an arbitrary and unreasonable restriction.
ZFigure 3 is an example of this usage.
Z.DS I N
Z.SP 2
Z.so example3.r
Z.SP 2
Z.ll -5
Z.ce
ZFigure 3
Z.ce
ZMore Readable Preprocessor Usage
Z.ll +5
Z.SP 2
Z.DE
Z
Z.SK
Z.B
ZFUNCTION TRACE EXAMPLE
Z.R
Z
Z.P
ZWe will start off learning about the capabilities of the
Z.I dbug
Zpackage by using a simple minded program which computes the
Zfactorial of a number.
ZIn order to better demonstrate the function trace mechanism, this
Zprogram is implemented recursively.
ZFigure 4 is the main function for this factorial program.
Z.DS I N
Z.SP 2
Z.so main.r
Z.SP 2
Z.ll -5
Z.ce
ZFigure 4
Z.ce
ZFactorial Program Mainline
Z.ll +5
Z.SP 2
Z.DE
Z
Z.P
ZThe
Z.B main
Zfunction is responsible for processing any command line
Zoption arguments and then computing and printing the factorial of
Zeach non-option argument.
Z.P
ZFirst of all, notice that all of the debugger functions are implemented
Zvia preprocessor macros.
ZThis does not detract from the readability of the code and makes disabling
Zall debug compilation trivial (a single preprocessor symbol,
Z.B DBUG_OFF ,
Zforces the macro expansions to be null).
Z.P
ZAlso notice the inclusion of the header file
Z.B dbug.h
Zfrom the local header file directory.
Z(The version included here is the test version in the dbug source
Zdistribution directory).
ZThis file contains all the definitions for the debugger macros, which
Zall have the form
Z.B DBUG_XX...XX .
Z
Z.P
ZThe
Z.B DBUG_ENTER
Zmacro informs that debugger that we have entered the
Zfunction named
Z.B main .
ZIt must be the very first "executable" line in a function, after
Zall declarations and before any other executable line.
ZThe
Z.B DBUG_PROCESS
Zmacro is generally used only once per program to
Zinform the debugger what name the program was invoked with.
ZThe
Z.B DBUG_PUSH
Zmacro modifies the current debugger state by
Zsaving the previous state and setting a new state based on the
Zcontrol string passed as its argument.
ZThe
Z.B DBUG_4
Zmacro is used to print the values of each argument
Zfor which a factorial is to be computed.
ZThe
Z.B DBUG_RETURN
Zmacro tells the debugger that the end of the current
Zfunction has been reached and returns a value to the calling
Zfunction.
ZAll of these macros will be fully explained in subsequent sections.
Z.P
ZTo use the debugger, the factorial program is invoked with a command
Zline of the form:
Z.DS CB N
Zfactorial -#d:t 1 2 3
Z.DE
ZThe
Z.B main
Zfunction recognizes the "-#d:t" string as a debugger control
Zstring, and passes the debugger arguments ("d:t") to the
Z.I dbug
Zruntime support routines via the
Z.B DBUG_PUSH
Zmacro.
ZThis particular string enables output from the
Z.B DBUG_4
Zmacro with the 'd' flag and enables function tracing with the 't' flag.
ZThe factorial function is then called three times, with the arguments
Z"1", "2", and "3".
Z
Z.P
ZDebug control strings consist of a header, the "-#", followed
Zby a colon separated list of debugger arguments.
ZEach debugger argument is a single character flag followed
Zby an optional comma separated list of argments specific
Zto the given flag.
ZSome examples are:
Z.DS CB N
Z-#d:t:o
Z-#d,in,out:f,main:F:L
Z.DE
ZNote that previously enabled debugger actions can be disabled by the
Zcontrol string "-#".
Z
Z.P
ZThe definition of the factorial function, symbolized as "N!", is
Zgiven by:
Z.DS CB N
ZN! = N * N-1 * ... 2 * 1
Z.DE
ZFigure 5 is the factorial function which implements this algorithm
Zrecursively.
ZNote that this is not necessarily the best way to do factorials
Zand error conditions are ignored completely.
Z.DS I N
Z.SP 2
Z.so factorial.r
Z.SP 2
Z.ll -5
Z.ce
ZFigure 5
Z.ce
ZFactorial Function
Z.ll +5
Z.SP 2
Z.DE
Z
Z.P
ZOne advantage (some may not consider it so) to using the
Z.I dbug
Zpackage is that it strongly encourages fully structured coding
Zwith only one entry and one exit point in each function.
ZMultiple exit points, such as early returns to escape a loop,
Zmay be used, but each such point requires the use of an
Zappropriate
Z.B DBUG_RETURN
Zor
Z.B DBUG_VOID_RETURN
Zmacro.
Z
Z.P
ZTo build the factorial program on a
Z.B UNIX
Zsystem, compile and
Zlink with the command:
Z.DS CB N
Zcc -o factorial main.c factorial.c -ldbug
Z.DE
ZThe "-ldbug" argument tells the loader to link in the
Zruntime support modules for the
Z.I dbug
Zpackage.
ZExecuting the factorial program with a command of the form:
Z.DS CB N
Zfactorial 1 2 3 4 5
Z.DE
Zgenerates the output shown in figure 6.
Z.DS I N
Z.SP 2
Z.so output1.r
Z.SP 2
Z.ll -5
Z.ce
ZFigure 6
Z.ce
Zfactorial 1 2 3 4 5
Z.ll +5
Z.SP 2
Z.DE
Z
Z.P
ZFunction level tracing is enabled by passing the debugger
Zthe 't' flag in the debug control string.
ZFigure 7 is the output resulting from the command
Z"factorial\ -#t:o\ 3\ 2".
Z.DS I N
Z.SP 2
Z.so output2.r
Z.SP 2
Z.ll -5
Z.ce
ZFigure 7
Z.ce
Zfactorial -#t:o 3 2
Z.ll +5
Z.SP 2
Z.DE
Z
Z.P
ZEach entry to or return from a function is indicated by '>' for the
Zentry point and '<' for the exit point, connected by
Zvertical bars to allow matching points to be easily found
Zwhen separated by large distances.
Z
Z.P
ZThis trace output indicates that there was an initial call
Zto factorial from main (to compute 2!), followed by
Za single recursive call to factorial to compute 1!.
ZThe main program then output the result for 2! and called the
Zfactorial function again with the second argument, 3.
ZFactorial called itself recursively to compute 2! and 1!, then
Zreturned control to main, which output the value for 3! and exited.
Z
Z.P
ZNote that there is no matching entry point "main>" for the
Zreturn point "<main" because at the time the
Z.B DBUG_ENTER
Zmacro was reached in main, tracing was not enabled yet.
ZIt was only after the macro
Z.B DBUG_PUSH
Zwas executing that tracing became enabled.
ZThis implies that the argument list should be processed as early as
Zpossible since all code preceding the first call to
Z.B DBUG_PUSH
Zis
Zessentially invisible to
Z.B dbug
Z(this can be worked around by
Zinserted a temporary
Z.B DBUG_PUSH(argv[1])
Zimmediately after the
Z.B DBUG_ENTER("main")
Zmacro.
Z
Z.P
ZOne last note,
Zthe trace output normally comes out on the standard error.
ZSince the factorial program prints its result on the standard
Zoutput, there is the possibility of the output on the terminal
Zbeing scrambled if the two streams are not synchronized.
ZThus the debugger is told to write its output on the standard
Zoutput instead, via the 'o' flag character.
ZNote that no 'o' implies the default (standard error), a 'o'
Zwith no arguments means standard output, and a 'o'
Zwith an argument means used the named file.
ZI.E, "factorial\ -#t:o,logfile\ 3\ 2" would write the trace
Zoutput in "logfile".
ZBecause of
Z.B UNIX
Zimplementation details, programs usually run
Zfaster when writing to stdout rather than stderr, though this
Zis not a prime consideration in this example.
Z
Z.SK
Z.B
ZUSE OF DBUG_N MACROS
Z.R
Z
Z.P
ZThe mechanism used to produce "printf" style output is the
Z.B DBUG_N
Zmacro, where
Z.B N
Zis replaced by the matching number of
Zarguments to the macro.
ZUnfortunately, the standard
Z.B UNIX
ZC preprocessor does not allow macros
Zto have variable number of arguments.
ZIf it did, then a single macro (such as DBUG_PRINTF) could replace all
Zthe
Z.B DBUG_N
Zmacros.
Z
Z.P
ZTo allow selection of output from specific macros, the first argument
Zto every
Z.B DBUG_N
Zmacro is a
Z.I dbug
Zkeyword.
ZWhen this keyword appears in the argument list of the 'd' flag in
Za debug control string, as in "-#d,keyword1,keyword2,...:t",
Zoutput from the corresponding macro is enabled.
ZThe default when there is no 'd' flag in the control string is to
Zenable output from all
Z.B DBUG_N
Zmacros.
Z
Z.P
ZTypically, a program will be run once, with no keywords specified,
Zto determine what keywords are significant for the current problem
Z(the keywords are printed in the macro output line).
ZThen the program will be run again, with the desired keywords,
Zto examine only specific areas of interest.
Z
Z.P
ZThe rest of the argument list to a
Z.B DBUG_N
Zis a standard printf style
Zformat string and one or more arguments to print.
ZNote that no explicit newline is required at the end of the format string.
ZAs a matter of style, two or three small
Z.B DBUG_N
Zmacros are preferable
Zto a single macro with a huge format string.
ZFigure 8 shows the output for default tracing and debug.
Z.DS I N
Z.SP 2
Z.so output3.r
Z.SP 2
Z.ll -5
Z.ce
ZFigure 8
Z.ce
Zfactorial -#d:t:o 3
Z.ll +5
Z.SP 2
Z.DE
Z
Z.P
ZThe output from the
Z.B DBUG_N
Zmacro is indented to match the trace output
Zfor the function in which the macro occurs.
ZWhen debugging is enabled, but not trace, the output starts at the left
Zmargin, without indentation.
Z
Z.P
ZTo demonstrate selection of specific macros for output, figure
Z9 shows the result when the factorial program is invoked with
Zthe debug control string "-#d,result:o".
Z.DS I N
Z.SP 2
Z.so output4.r
Z.SP 2
Z.ll -5
Z.ce
ZFigure 9
Z.ce
Zfactorial -#d,result:o 4
Z.ll +5
Z.SP 2
Z.DE
Z
Z.P
ZIt is sometimes desirable to restrict debugging and trace actions
Zto a specific function or list of functions.
ZThis is accomplished with the 'f' flag character in the debug
Zcontrol string.
ZFigure 10 is the output of the factorial program when run with the
Zcontrol string "-#d:f,factorial:F:L:o".
ZThe 'F' flag enables printing of the source file name and the 'L'
Zflag enables printing of the source file line number.
Z.DS I N
Z.SP 2
Z.so output5.r
Z.SP 2
Z.ll -5
Z.ce
ZFigure 10
Z.ce
Zfactorial -#d:f,factorial:F:L:o 3
Z.ll +5
Z.SP 2
Z.DE
Z
Z.P
ZThe output in figure 10 shows that the "find" macro is in file
Z"factorial.c" at source line 8 and the "result" macro is in the same
Zfile at source line 12.
Z
Z.SK
Z.B
ZSUMMARY OF MACROS
Z.R
Z
Z.P
ZThis section summarizes the usage of all currently defined macros
Zin the
Z.I dbug
Zpackage.
ZThe macros definitions are found in the user include file
Z.B dbug.h
Zfrom the standard include directory.
Z
Z.SP 2
Z.BL 20
Z.LI DBUG_ENTER\
ZUsed to tell the runtime support module the name of the function
Zbeing entered.
ZThe argument must be of type "pointer to character".
ZThe
ZDBUG_ENTER
Zmacro must precede all executable lines in the
Zfunction just entered, and must come after all local declarations.
ZEach
ZDBUG_ENTER
Zmacro must have a matching
ZDBUG_RETURN
Zor
ZDBUG_VOID_RETURN
Zmacro
Zat the function exit points.
ZDBUG_ENTER
Zmacros used without a matching
ZDBUG_RETURN
Zor
ZDBUG_VOID_RETURN
Zmacro
Zwill cause warning messages from the
Z.I dbug
Zpackage runtime support module.
Z.SP 1
ZEX:\ DBUG_ENTER\ ("main");
Z.SP 1
Z.LI DBUG_RETURN\
ZUsed at each exit point of a function containing a
ZDBUG_ENTER
Zmacro
Zat the entry point.
ZThe argument is the value to return.
ZFunctions which return no value (void) should use the
ZDBUG_VOID_RETURN
Zmacro.
ZIt
Zis an error to have a
ZDBUG_RETURN
Zor
ZDBUG_VOID_RETURN
Zmacro in a function
Zwhich has no matching
ZDBUG_ENTER
Zmacro, and the compiler will complain
Zif the macros are actually used (expanded).
Z.SP 1
ZEX:\ DBUG_RETURN\ (value);
Z.br
ZEX:\ DBUG_VOID_RETURN;
Z.SP 1
Z.LI DBUG_PROCESS\
ZUsed to name the current process being executed.
ZA typical argument for this macro is "argv[0]", though
Zit will be perfectly happy with any other string.
Z.SP 1
ZEX:\ DBUG_PROCESS\ (argv[0]);
Z.SP 1
Z.LI DBUG_PUSH\
ZSets a new debugger state by pushing the current
Z.B dbug
Zstate onto an
Zinternal stack and setting up the new state using the debug control
Zstring passed as the macro argument.
ZThe most common usage is to set the state specified by a debug
Zcontrol string retrieved from the argument list.
ZNote that the leading "-#" in a debug control string specified
Zas a command line argument must
Z.B not
Zbe passed as part of the macro argument.
ZThe proper usage is to pass a pointer to the first character
Z.B after
Zthe "-#" string.
Z.SP 1
ZEX:\ DBUG_PUSH\ (\&(argv[i][2]));
Z.br
ZEX:\ DBUG_PUSH\ ("d:t");
Z.br
ZEX:\ DBUG_PUSH\ ("");
Z.SP 1
Z.LI DBUG_POP\
ZRestores the previous debugger state by popping the state stack.
ZAttempting to pop more states than pushed will be ignored and no
Zwarning will be given.
ZThe
ZDBUG_POP
Zmacro has no arguments.
Z.SP 1
ZEX:\ DBUG_POP\ ();
Z.SP 1
Z.LI DBUG_FILE\
ZThe
ZDBUG_FILE
Zmacro is used to do explicit I/O on the debug output
Zstream.
ZIt is used in the same manner as the symbols "stdout" and "stderr"
Zin the standard I/O package.
Z.SP 1
ZEX:\ fprintf\ (DBUG_FILE,\ "Doing my own I/O!\n");
Z.SP 1
Z.LI DBUG_EXECUTE\
ZThe DBUG_EXECUTE macro is used to execute any arbitrary C code.
ZThe first argument is the debug keyword, used to trigger execution
Zof the code specified as the second argument.
ZThis macro must be used cautiously because, like the
ZDBUG_N
Zmacros,
Zit is automatically selected by default whenever the 'd' flag has
Zno argument list (I.E., a "-#d:t" control string).
Z.SP 1
ZEX:\ DBUG_EXECUTE\ ("abort",\ abort\ ());
Z.SP 1
Z.LI DBUG_N\
ZUsed to do printing via the "fprintf" library function on the
Zcurrent debug stream,
ZDBUG_FILE.
ZN may currently be a number in the range 2-5, and specifies the
Znumber of arguments in the corresponding macro.
ZThe first argument is a debug keyword, the second is a format string,
Zand the remaining arguments, if any, are the values to be printed.
Z.SP 1
ZEX:\ DBUG_2\ ("eof",\ "end\ of\ file\ found");
Z.br
ZEX:\ DBUG_3\ ("type","type\ is\ %x", type);
Z.br
ZEX:\ DBUG_4\ ("stp", "%x\ ->\ %s", stp, stp\ ->\ name);
Z.LI DBUG_SETJMP\
ZUsed in place of the setjmp() function to first save the current
Zdebugger state and then execute the standard setjmp call.
ZThis allows to the debugger to restore it's state when the
ZDBUG_LONGJMP macro is used to invoke the standard longjmp() call.
ZCurrently all instances of DBUG_SETJMP must occur within the
Zsame function and at the same function nesting level.
Z.SP 1
ZEX:\ DBUG_SETJMP\ (env);
Z.LI DBUG_LONGJMP\
ZUsed in place of the longjmp() function to first restore the
Zprevious debugger state at the time of the last DBUG_SETJMP
Zand then execute the standard longjmp() call.
ZNote that currently all DBUG_LONGJMP macros restore the state
Zat the time of the last DBUG_SETJMP.
ZIt would be possible to maintain separate DBUG_SETJMP and DBUG_LONGJMP
Zpairs by having the debugger runtime support module use the first
Zargument to differentiate the pairs.
Z.SP 1
ZEX:\ DBUG_LONGJMP\ (env,val);
Z.LE
Z
Z.SK
Z.B
ZDEBUG CONTROL STRING
Z.R
Z
Z.P
ZThe debug control string is used to set the state of the debugger
Zvia the
Z.B DBUG_PUSH
Zmacro.
ZThis section summarizes the currently available debugger options
Zand the flag characters which enable or disable them.
ZArgument lists enclosed in '[' and ']' are optional.
Z.SP 2
Z.BL 22
Z.LI d[,keywords]
ZEnable output from macros with specified keywords.
ZA null list of keywords implies that all keywords are selected.
Z.LI D[,time]
ZDelay for specified time after each output line, to let output drain.
ZTime is given in tenths of a second (value of 10 is one second).
ZDefault is zero.
Z.LI f[,functions]
ZLimit debugger actions to the specified list of functions.
ZA null list of functions implies that all functions are selected.
Z.LI F
ZMark each debugger output line with the name of the source file
Zcontaining the macro causing the output.
Z.LI L
ZMark each debugger output line with the source file line number of
Zthe macro causing the output.
Z.LI n
ZMark each debugger output line with the current function nesting depth.
Z.LI N
ZSequentially number each debugger output line starting at 1.
ZThis is useful for reference purposes when debugger output is
Zinterspersed with program output.
Z.LI o[,file]
ZRedirect the debugger output stream to the specified file.
ZThe default output stream is stderr.
ZA null argument list causes output to be redirected to stdout.
Z.LI p[,processes]
ZLimit debugger actions to the specified processes.
ZA null list implies all processes.
ZThis is useful for processes which run child processes.
ZNote that each debugger output line can be marked with the name of
Zthe current process via the 'P' flag.
ZThe process name must match the argument passed to the
Z.B DBUG_PROCESS
Zmacro.
Z.LI P
ZMark each debugger output line with the name of the current process.
ZMost useful when used with a process which runs child processes that
Zare also being debugged.
ZNote that the parent process must arrange for the debugger control
Zstring to be passed to the child processes.
Z.LI r
ZUsed in conjunction with the
Z.B DBUG_PUSH
Zmacro to reset the current
Zindentation level back to zero.
ZMost useful with
Z.B DBUG_PUSH
Zmacros used to temporarily alter the
Zdebugger state.
Z.LI t[,N]
ZEnable function control flow tracing.
ZThe maximum nesting depth is specified by N, and defaults to
Z200.
Z.LE
Z.SK
Z.B
ZHINTS AND MISCELLANEOUS
Z.R
Z
Z.P
ZOne of the most useful capabilities of the
Z.I dbug
Zpackage is to compare the executions of a given program in two
Zdifferent environments.
ZThis is typically done by executing the program in the environment
Zwhere it behaves properly and saving the debugger output in a
Zreference file.
ZThe program is then run with identical inputs in the environment where
Zit misbehaves and the output is again captured in a reference file.
ZThe two reference files can then be differentially compared to
Zdetermine exactly where execution of the two processes diverges.
Z
Z.P
ZA related usage is regression testing where the execution of a current
Zversion is compared against executions of previous versions.
ZThis is most useful when there are only minor changes.
Z
Z.P
ZIt is not difficult to modify an existing compiler to implement
Zsome of the functionality of the
Z.I dbug
Zpackage automatically, without source code changes to the
Zprogram being debugged.
ZIn fact, such changes were implemented in a version of the
ZPortable C Compiler by the author in less than a day.
ZHowever, it is strongly encouraged that all newly
Zdeveloped code continue to use the debugger macros
Zfor the portability reasons noted earlier.
ZThe modified compiler should be used only for testing existing
Zprograms.
Z
Z.SK
Z.B
ZCAVEATS
Z.R
Z
Z.P
ZThe
Z.I dbug
Zpackage works best with programs which have "line\ oriented"
Zoutput, such as text processors, general purpose utilities, etc.
ZIt can be interfaced with screen oriented programs such as
Zvisual editors by redefining the appropriate macros to call
Zspecial functions for displaying the debugger results.
ZOf course, this caveat is not applicable if the debugger output
Zis simply dumped into a file for post-execution examination.
Z
Z.P
ZPrograms which use memory allocation functions other than
Z.B malloc
Zwill usually have problems using the standard
Z.I dbug
Zpackage.
ZThe most common problem is multiply allocated memory.
Z
Z.P
ZBeware that some of the macros are not context independent.
ZSome of them contain
Z.I if
Zstatements with no
Z.I else
Zstatements.
ZIn particular, the following code segment will not behave as
Zexpected:
Z.DS I N
Z.SP 2
Zif (something_interesting)
Z DBUG_2 ("ins", "something interesting");
Zelse
Z do_normal_processing ();
Z.SP 2
Z.DE
ZThe user code
Z.I else
Zwill bind to the macro's
Z.I if
Zto produce code equivalent to:
Z.DS I N
Z.SP 2
Zif (something_interesting)
Z if (debugging_on)
Z printf ("something interesting");
Z else
Z do_normal_processing ();
Z.SP 2
Z.DE
ZThe author has received numerous suggestions for changes which would
Zeliminate this danger, most based on obscure features of the language
Zor preprocessor, but has rejected most of these for portability or
Zefficiency reasons.
Z(The author also considers it to be poor programming practice to write
Zcode with any control flow statements that do not use braces.)
ZHowever, if you absolutely must prevent this behavior try changing
Zthe macro definitions to something of the form:
Z.DS I N
Z.SP 2
Z#define DBUG_2(keyword,format) \e
Z do { \e
Z if (_db_on_) { \e
Z _db_printf_ (__LINE__, keyword, format); \e
Z } \e
Z } while (0)
Z.SP 2
Z.DE
Z.CS
STUNKYFLUFF
set `sum user.r`
if test 05909 != $1
then
echo user.r: Checksum error. Is: $1, should be: 05909.
fi
echo ALL DONE BUNKY!
exit 0fnf@unisoft.UUCP (12/17/85)
Seems like I blew it and tried to post the nroff'd document with
lots of ^H's and a few escapes. Anyway, here is one stripped of
all control characters. You may have to fiddle with it to get it
to print correctly, as I might have messed up the page boundries.
#--------CUT---------CUT---------CUT---------CUT--------#
#########################################################
# #
# This is a shell archive file. To extract files: #
# #
# 1) Make a directory for the files. #
# 2) Write a file, such as "file.shar", containing #
# this archive file into the directory. #
# 3) Type "sh file.shar". Do not use csh. #
# #
#########################################################
#
#
echo Extracting user.t:
sed 's/^Z//' >user.t <<\STUNKYFLUFF
Z
Z
Z
Z D B U G
Z
Z C Program Debugging Package
Z
Z by
Z
Z Fred Fish
Z
Z
Z
Z
Z INTRODUCTION
Z
Z
Z Almost every program development environment worthy of
Z the name provides some sort of debugging facility. Usually
Z this takes the form of a program which is capable of
Z controlling execution of other programs and examining the
Z internal state of other executing programs. These types of
Z programs will be referred to as external debuggers since the
Z debugger is not part of the executing program. Examples of
Z this type of debugger include the adb and sdb debuggers
Z provided with the UNIX operating system.
Z
Z
Z One of the problems associated with developing programs
Z in an environment with good external debuggers is that
Z developed programs tend to have little or no internal
Z instrumentation. This is usually not a problem for the
Z developer since he is, or at least should be, intimately
Z familiar with the internal organization, data structures,
Z and control flow of the program being debugged. It is a
Z serious problem for maintenance programmers, who are
Z unlikely to have such familiarity with the program being
Z maintained, modified, or ported to another environment. It
Z is also a problem, even for the developer, when the program
Z is moved to an environment with a primitive or unfamiliar
Z debugger, or even no debugger.
Z
Z
Z On the other hand, dbug is an example of an internal
Z debugger. Because it requires internal instrumentation of a
Z program, and its usage does not depend on any special
Z capabilities of the execution environment, it is always
Z available and will execute in any environment that the
Z program itself will execute in. In addition, since it is a
Z complete package with a specific user interface, all
Z programs which use it will be provided with similar
Z debugging capabilities. This is in sharp contrast to other
Z
Z
Z __________
Z
Z 1. UNIX is a trademark of AT&T Bell Laboratories.
Z
Z
Z
Z
Z - 1 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z forms of internal instrumentation where each developer has
Z their own, usually less capable, form of internal debugger.
Z In summary, because dbug is an internal debugger it provides
Z consistency across operating environments, and because it is
Z available to all developers it provides consistency across
Z all programs in the same environment.
Z
Z
Z The dbug package imposes only a slight speed penalty on
Z executing programs, typically much less than 10 percent, and
Z a modest size penalty, typically 10 to 20 percent. By
Z defining a specific C preprocessor symbol both of these can
Z be reduced to zero with no changes required to the source
Z code.
Z
Z
Z The following list is a quick summary of the
Z capabilities of the dbug package. Each capability can be
Z individually enabled or disabled at the time a program is
Z invoked by specifying the appropriate command line
Z arguments.
Z
Z o Execution trace showing function level control
Z flow in a semi-graphically manner using
Z indentation to indicate nesting depth.
Z
Z o Output the values of all, or any subset of, key
Z internal variables.
Z
Z o Limit actions to a specific set of named
Z functions.
Z
Z o Limit function trace to a specified nesting depth.
Z
Z o Label each output line with source file name and
Z line number.
Z
Z o Label each output line with name of current
Z process.
Z
Z o Push or pop internal debugging state to allow
Z execution with built in debugging defaults.
Z
Z o Redirect the debug output stream to standard
Z output (stdout) or a named file. The default
Z output stream is standard error (stderr). The
Z redirection mechanism is completely independent of
Z normal command line redirection to avoid output
Z conflicts.
Z
Z
Z
Z
Z
Z - 2 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z PRIMITIVE DEBUGGING TECHNIQUES
Z
Z
Z Internal instrumentation is already a familiar concept
Z to most programmers, since it is usually the first debugging
Z technique learned. Typically, "print statements" are
Z inserted in the source code at interesting points, the code
Z is recompiled and executed, and the resulting output is
Z examined in an attempt to determine where the problem is.
Z
Z The procedure is iterative, with each iteration yielding
Z more and more output, and hopefully the source of the
Z problem is discovered before the output becomes too large to
Z deal with or previously inserted statements need to be
Z removed. Figure 1 is an example of this type of primitive
Z debugging technique.
Z
Z
Z
Z #include <stdio.h>
Z
Z main (argc, argv)
Z int argc;
Z char *argv[];
Z {
Z printf ("argv[0] = %d\n", argv[0]);
Z /*
Z * Rest of program
Z */
Z printf ("== done ==\n");
Z }
Z
Z
Z Figure 1
Z Primitive Debugging Technique
Z
Z
Z
Z
Z
Z Eventually, and usually after at least several
Z iterations, the problem will be found and corrected. At
Z this point, the newly inserted print statements must be
Z dealt with. One obvious solution is to simply delete them
Z all. Beginners usually do this a few times until they have
Z to repeat the entire process every time a new bug pops up.
Z The second most obvious solution is to somehow disable the
Z output, either through the source code comment facility,
Z creation of a debug variable to be switched on or off, or by
Z using the C preprocessor. Figure 2 is an example of all
Z three techniques.
Z
Z
Z
Z - 3 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z
Z
Z #include <stdio.h>
Z
Z int debug = 0;
Z
Z main (argc, argv)
Z int argc;
Z char *argv[];
Z {
Z /* printf ("argv = %x\n", argv) */
Z if (debug) printf ("argv[0] = %d\n", argv[0]);
Z /*
Z * Rest of program
Z */
Z #ifdef DEBUG
Z printf ("== done ==\n");
Z #endif
Z }
Z
Z
Z Figure 2
Z Debug Disable Techniques
Z
Z
Z
Z
Z
Z Each technique has its advantages and disadvantages
Z with respect to dynamic vs static activation, source code
Z overhead, recompilation requirements, ease of use, program
Z readability, etc. Overuse of the preprocessor solution
Z quickly leads to problems with source code readability and
Z maintainability when multiple #ifdef symbols are to be
Z defined or undefined based on specific types of debug
Z desired. The source code can be made slightly more readable
Z by suitable indentation of the #ifdef arguments to match the
Z indentation of the code, but not all C preprocessors allow
Z this. The only requirement for the standard UNIX C
Z preprocessor is for the '#' character to appear in the first
Z column, but even this seems like an arbitrary and
Z unreasonable restriction. Figure 3 is an example of this
Z usage.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 4 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z
Z
Z #include <stdio.h>
Z
Z main (argc, argv)
Z int argc;
Z char *argv[];
Z {
Z # ifdef DEBUG
Z printf ("argv[0] = %d\n", argv[0]);
Z # endif
Z /*
Z * Rest of program
Z */
Z # ifdef DEBUG
Z printf ("== done ==\n");
Z # endif
Z }
Z
Z
Z Figure 3
Z More Readable Preprocessor Usage
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 5 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z FUNCTION TRACE EXAMPLE
Z
Z
Z We will start off learning about the capabilities of
Z the dbug package by using a simple minded program which
Z computes the factorial of a number. In order to better
Z demonstrate the function trace mechanism, this program is
Z implemented recursively. Figure 4 is the main function for
Z this factorial program.
Z
Z
Z
Z #include <stdio.h>
Z /* User programs should use <local/dbug.h> */
Z #include "dbug.h"
Z
Z main (argc, argv)
Z int argc;
Z char *argv[];
Z {
Z register int result, ix;
Z extern int factorial (), atoi ();
Z
Z DBUG_ENTER ("main");
Z DBUG_PROCESS (argv[0]);
Z for (ix = 1; ix < argc && argv[ix][0] == '-'; ix++) {
Z switch (argv[ix][1]) {
Z case '#':
Z DBUG_PUSH (&(argv[ix][2]));
Z break;
Z }
Z }
Z for (; ix < argc; ix++) {
Z DBUG_4 ("args", "argv[%d] = %s", ix, argv[ix]);
Z result = factorial (atoi (argv[ix]));
Z printf ("%d\n", result);
Z }
Z DBUG_RETURN (0);
Z }
Z
Z
Z Figure 4
Z Factorial Program Mainline
Z
Z
Z
Z
Z
Z The main function is responsible for processing any
Z command line option arguments and then computing and
Z printing the factorial of each non-option argument.
Z
Z
Z
Z - 6 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z First of all, notice that all of the debugger functions
Z are implemented via preprocessor macros. This does not
Z detract from the readability of the code and makes disabling
Z all debug compilation trivial (a single preprocessor symbol,
Z DBUG_OFF, forces the macro expansions to be null).
Z
Z Also notice the inclusion of the header file dbug.h
Z from the local header file directory. (The version included
Z here is the test version in the dbug source distribution
Z directory). This file contains all the definitions for the
Z debugger macros, which all have the form DBUG_XX...XX.
Z
Z
Z The DBUG_ENTER macro informs that debugger that we have
Z entered the function named main. It must be the very first
Z "executable" line in a function, after all declarations and
Z before any other executable line. The DBUG_PROCESS macro is
Z generally used only once per program to inform the debugger
Z what name the program was invoked with. The DBUG_PUSH macro
Z modifies the current debugger state by saving the previous
Z state and setting a new state based on the control string
Z passed as its argument. The DBUG_4 macro is used to print
Z the values of each argument for which a factorial is to be
Z computed. The DBUG_RETURN macro tells the debugger that the
Z end of the current function has been reached and returns a
Z value to the calling function. All of these macros will be
Z fully explained in subsequent sections.
Z
Z To use the debugger, the factorial program is invoked
Z with a command line of the form:
Z
Z factorial -#d:t 1 2 3
Z
Z The main function recognizes the "-#d:t" string as a
Z debugger control string, and passes the debugger arguments
Z ("d:t") to the dbug runtime support routines via the
Z DBUG_PUSH macro. This particular string enables output from
Z the DBUG_4 macro with the 'd' flag and enables function
Z tracing with the 't' flag. The factorial function is then
Z called three times, with the arguments "1", "2", and "3".
Z
Z
Z Debug control strings consist of a header, the "-#",
Z followed by a colon separated list of debugger arguments.
Z Each debugger argument is a single character flag followed
Z by an optional comma separated list of argments specific to
Z the given flag. Some examples are:
Z
Z -#d:t:o
Z -#d,in,out:f,main:F:L
Z
Z
Z
Z
Z - 7 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z Note that previously enabled debugger actions can be
Z disabled by the control string "-#".
Z
Z
Z The definition of the factorial function, symbolized as
Z "N!", is given by:
Z
Z N! = N * N-1 * ... 2 * 1
Z
Z Figure 5 is the factorial function which implements this
Z algorithm recursively. Note that this is not necessarily
Z the best way to do factorials and error conditions are
Z ignored completely.
Z
Z
Z
Z #include <stdio.h>
Z /* User programs should use <local/dbug.h> */
Z #include "dbug.h"
Z
Z int factorial (value)
Z register int value;
Z {
Z DBUG_ENTER ("factorial");
Z DBUG_3 ("find", "find %d factorial", value);
Z if (value > 1) {
Z value *= factorial (value - 1);
Z }
Z DBUG_3 ("result", "result is %d", value);
Z DBUG_RETURN (value);
Z }
Z
Z
Z Figure 5
Z Factorial Function
Z
Z
Z
Z
Z
Z One advantage (some may not consider it so) to using
Z the dbug package is that it strongly encourages fully
Z structured coding with only one entry and one exit point in
Z each function. Multiple exit points, such as early returns
Z to escape a loop, may be used, but each such point requires
Z the use of an appropriate DBUG_RETURN or DBUG_VOID_RETURN
Z macro.
Z
Z
Z To build the factorial program on a UNIX system,
Z compile and link with the command:
Z
Z
Z
Z - 8 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z cc -o factorial main.c factorial.c -ldbug
Z
Z The "-ldbug" argument tells the loader to link in the
Z runtime support modules for the dbug package. Executing the
Z factorial program with a command of the form:
Z
Z factorial 1 2 3 4 5
Z
Z generates the output shown in figure 6.
Z
Z
Z
Z 1
Z 2
Z 6
Z 24
Z 120
Z
Z
Z Figure 6
Z factorial 1 2 3 4 5
Z
Z
Z
Z
Z
Z Function level tracing is enabled by passing the
Z debugger the 't' flag in the debug control string. Figure 7
Z is the output resulting from the command "factorial -
Z #t:o 3 2".
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 9 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z
Z
Z | >factorial
Z | | >factorial
Z | | <factorial
Z | <factorial
Z 2
Z | >factorial
Z | | >factorial
Z | | | >factorial
Z | | | <factorial
Z | | <factorial
Z | <factorial
Z 6
Z <main
Z
Z
Z Figure 7
Z factorial -#t:o 3 2
Z
Z
Z
Z
Z
Z Each entry to or return from a function is indicated by
Z '>' for the entry point and '<' for the exit point,
Z connected by vertical bars to allow matching points to be
Z easily found when separated by large distances.
Z
Z
Z This trace output indicates that there was an initial
Z call to factorial from main (to compute 2!), followed by a
Z single recursive call to factorial to compute 1!. The main
Z program then output the result for 2! and called the
Z factorial function again with the second argument, 3.
Z Factorial called itself recursively to compute 2! and 1!,
Z then returned control to main, which output the value for 3!
Z and exited.
Z
Z
Z Note that there is no matching entry point "main>" for
Z the return point "<main" because at the time the DBUG_ENTER
Z macro was reached in main, tracing was not enabled yet. It
Z was only after the macro DBUG_PUSH was executing that
Z tracing became enabled. This implies that the argument list
Z should be processed as early as possible since all code
Z preceding the first call to DBUG_PUSH is essentially
Z invisible to dbug (this can be worked around by inserted a
Z temporary DBUG_PUSH(argv[1]) immediately after the
Z DBUG_ENTER("main") macro.
Z
Z
Z
Z
Z - 10 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z One last note, the trace output normally comes out on
Z the standard error. Since the factorial program prints its
Z result on the standard output, there is the possibility of
Z the output on the terminal being scrambled if the two
Z streams are not synchronized. Thus the debugger is told to
Z write its output on the standard output instead, via the 'o'
Z flag character. Note that no 'o' implies the default
Z (standard error), a 'o' with no arguments means standard
Z output, and a 'o' with an argument means used the named
Z file. I.E, "factorial -#t:o,logfile 3 2" would write the
Z trace output in "logfile". Because of UNIX implementation
Z details, programs usually run faster when writing to stdout
Z rather than stderr, though this is not a prime consideration
Z in this example.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 11 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z USE OF DBUG_N MACROS
Z
Z
Z The mechanism used to produce "printf" style output is
Z the DBUG_N macro, where N is replaced by the matching number
Z of arguments to the macro. Unfortunately, the standard UNIX
Z C preprocessor does not allow macros to have variable number
Z of arguments. If it did, then a single macro (such as
Z DBUG_PRINTF) could replace all the DBUG_N macros.
Z
Z
Z To allow selection of output from specific macros, the
Z first argument to every DBUG_N macro is a dbug keyword.
Z When this keyword appears in the argument list of the 'd'
Z flag in a debug control string, as in "-
Z #d,keyword1,keyword2,...:t", output from the corresponding
Z macro is enabled. The default when there is no 'd' flag in
Z the control string is to enable output from all DBUG_N
Z macros.
Z
Z
Z Typically, a program will be run once, with no keywords
Z specified, to determine what keywords are significant for
Z the current problem (the keywords are printed in the macro
Z output line). Then the program will be run again, with the
Z desired keywords, to examine only specific areas of
Z interest.
Z
Z
Z The rest of the argument list to a DBUG_N is a standard
Z printf style format string and one or more arguments to
Z print. Note that no explicit newline is required at the end
Z of the format string. As a matter of style, two or three
Z small DBUG_N macros are preferable to a single macro with a
Z huge format string. Figure 8 shows the output for default
Z tracing and debug.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 12 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z
Z
Z | args: argv[2] = 3
Z | >factorial
Z | | find: find 3 factorial
Z | | >factorial
Z | | | find: find 2 factorial
Z | | | >factorial
Z | | | | find: find 1 factorial
Z | | | | result: result is 1
Z | | | <factorial
Z | | | result: result is 2
Z | | <factorial
Z | | result: result is 6
Z | <factorial
Z 6
Z <main
Z
Z
Z Figure 8
Z factorial -#d:t:o 3
Z
Z
Z
Z
Z
Z The output from the DBUG_N macro is indented to match
Z the trace output for the function in which the macro occurs.
Z When debugging is enabled, but not trace, the output starts
Z at the left margin, without indentation.
Z
Z
Z To demonstrate selection of specific macros for output,
Z figure 9 shows the result when the factorial program is
Z invoked with the debug control string "-#d,result:o".
Z
Z
Z
Z factorial: result: result is 1
Z factorial: result: result is 2
Z factorial: result: result is 6
Z factorial: result: result is 24
Z 24
Z
Z
Z Figure 9
Z factorial -#d,result:o 4
Z
Z
Z
Z
Z
Z
Z
Z - 13 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z It is sometimes desirable to restrict debugging and
Z trace actions to a specific function or list of functions.
Z This is accomplished with the 'f' flag character in the
Z debug control string. Figure 10 is the output of the
Z factorial program when run with the control string "-
Z #d:f,factorial:F:L:o". The 'F' flag enables printing of the
Z source file name and the 'L' flag enables printing of the
Z source file line number.
Z
Z
Z
Z factorial.c: 9: factorial: find: find 3 factorial
Z factorial.c: 9: factorial: find: find 2 factorial
Z factorial.c: 9: factorial: find: find 1 factorial
Z factorial.c: 13: factorial: result: result is 1
Z factorial.c: 13: factorial: result: result is 2
Z factorial.c: 13: factorial: result: result is 6
Z 6
Z
Z
Z Figure 10
Z factorial -#d:f,factorial:F:L:o 3
Z
Z
Z
Z
Z
Z The output in figure 10 shows that the "find" macro is
Z in file "factorial.c" at source line 8 and the "result"
Z macro is in the same file at source line 12.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 14 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z SUMMARY OF MACROS
Z
Z
Z This section summarizes the usage of all currently
Z defined macros in the dbug package. The macros definitions
Z are found in the user include file dbug.h from the standard
Z include directory.
Z
Z
Z
Z DBUG_ENTER Used to tell the runtime support module
Z the name of the function being entered.
Z The argument must be of type "pointer to
Z character". The DBUG_ENTER macro must
Z precede all executable lines in the
Z function just entered, and must come
Z after all local declarations. Each
Z DBUG_ENTER macro must have a matching
Z DBUG_RETURN or DBUG_VOID_RETURN macro at
Z the function exit points. DBUG_ENTER
Z macros used without a matching
Z DBUG_RETURN or DBUG_VOID_RETURN macro
Z will cause warning messages from the
Z dbug package runtime support module.
Z
Z EX: DBUG_ENTER ("main");
Z
Z DBUG_RETURN Used at each exit point of a function
Z containing a DBUG_ENTER macro at the
Z entry point. The argument is the value
Z to return. Functions which return no
Z value (void) should use the
Z DBUG_VOID_RETURN macro. It is an error
Z to have a DBUG_RETURN or
Z DBUG_VOID_RETURN macro in a function
Z which has no matching DBUG_ENTER macro,
Z and the compiler will complain if the
Z macros are actually used (expanded).
Z
Z EX: DBUG_RETURN (value);
Z EX: DBUG_VOID_RETURN;
Z
Z DBUG_PROCESS Used to name the current process being
Z executed. A typical argument for this
Z macro is "argv[0]", though it will be
Z perfectly happy with any other string.
Z
Z EX: DBUG_PROCESS (argv[0]);
Z
Z DBUG_PUSH Sets a new debugger state by pushing the
Z current dbug state onto an internal
Z
Z
Z
Z - 15 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z stack and setting up the new state using
Z the debug control string passed as the
Z macro argument. The most common usage
Z is to set the state specified by a debug
Z control string retrieved from the
Z argument list. Note that the leading
Z "-#" in a debug control string specified
Z as a command line argument must not be
Z passed as part of the macro argument.
Z The proper usage is to pass a pointer to
Z the first character after the "-#"
Z string.
Z
Z EX: DBUG_PUSH ((argv[i][2]));
Z EX: DBUG_PUSH ("d:t");
Z EX: DBUG_PUSH ("");
Z
Z DBUG_POP Restores the previous debugger state by
Z popping the state stack. Attempting to
Z pop more states than pushed will be
Z ignored and no warning will be given.
Z The DBUG_POP macro has no arguments.
Z
Z EX: DBUG_POP ();
Z
Z DBUG_FILE The DBUG_FILE macro is used to do
Z explicit I/O on the debug output stream.
Z It is used in the same manner as the
Z symbols "stdout" and "stderr" in the
Z standard I/O package.
Z
Z EX: fprintf (DBUG_FILE, "Doing my own
Z I/O!0);
Z
Z DBUG_EXECUTE The DBUG_EXECUTE macro is used to
Z execute any arbitrary C code. The first
Z argument is the debug keyword, used to
Z trigger execution of the code specified
Z as the second argument. This macro must
Z be used cautiously because, like the
Z DBUG_N macros, it is automatically
Z selected by default whenever the 'd'
Z flag has no argument list (I.E., a "-
Z #d:t" control string).
Z
Z EX: DBUG_EXECUTE ("abort", abort ());
Z
Z DBUG_N Used to do printing via the "fprintf"
Z library function on the current debug
Z stream, DBUG_FILE. N may currently be a
Z number in the range 2-5, and specifies
Z
Z
Z
Z - 16 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z the number of arguments in the
Z corresponding macro. The first argument
Z is a debug keyword, the second is a
Z format string, and the remaining
Z arguments, if any, are the values to be
Z printed.
Z
Z EX: DBUG_2 ("eof", "end of file found");
Z EX: DBUG_3 ("type","type is %x", type);
Z EX: DBUG_4 ("stp", "%x -> %s", stp,
Z stp -> name);
Z
Z DBUG_SETJMP Used in place of the setjmp() function
Z to first save the current debugger state
Z and then execute the standard setjmp
Z call. This allows to the debugger to
Z restore it's state when the DBUG_LONGJMP
Z macro is used to invoke the standard
Z longjmp() call. Currently all instances
Z of DBUG_SETJMP must occur within the
Z same function and at the same function
Z nesting level.
Z
Z EX: DBUG_SETJMP (env);
Z
Z DBUG_LONGJMP Used in place of the longjmp() function
Z to first restore the previous debugger
Z state at the time of the last
Z DBUG_SETJMP and then execute the
Z standard longjmp() call. Note that
Z currently all DBUG_LONGJMP macros
Z restore the state at the time of the
Z last DBUG_SETJMP. It would be possible
Z to maintain separate DBUG_SETJMP and
Z DBUG_LONGJMP pairs by having the
Z debugger runtime support module use the
Z first argument to differentiate the
Z pairs.
Z
Z EX: DBUG_LONGJMP (env,val);
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 17 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z DEBUG CONTROL STRING
Z
Z
Z The debug control string is used to set the state of
Z the debugger via the DBUG_PUSH macro. This section
Z summarizes the currently available debugger options and the
Z flag characters which enable or disable them. Argument
Z lists enclosed in '[' and ']' are optional.
Z
Z
Z d[,keywords] Enable output from macros with
Z specified keywords. A null list of
Z keywords implies that all keywords are
Z selected.
Z
Z D[,time] Delay for specified time after each
Z output line, to let output drain.
Z Time is given in tenths of a second
Z (value of 10 is one second). Default
Z is zero.
Z
Z f[,functions] Limit debugger actions to the
Z specified list of functions. A null
Z list of functions implies that all
Z functions are selected.
Z
Z F Mark each debugger output line with
Z the name of the source file containing
Z the macro causing the output.
Z
Z L Mark each debugger output line with
Z the source file line number of the
Z macro causing the output.
Z
Z n Mark each debugger output line with
Z the current function nesting depth.
Z
Z N Sequentially number each debugger
Z output line starting at 1. This is
Z useful for reference purposes when
Z debugger output is interspersed with
Z program output.
Z
Z o[,file] Redirect the debugger output stream to
Z the specified file. The default
Z output stream is stderr. A null
Z argument list causes output to be
Z redirected to stdout.
Z
Z p[,processes] Limit debugger actions to the
Z specified processes. A null list
Z
Z
Z
Z - 18 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z implies all processes. This is useful
Z for processes which run child
Z processes. Note that each debugger
Z output line can be marked with the
Z name of the current process via the
Z 'P' flag. The process name must match
Z the argument passed to the
Z DBUG_PROCESS macro.
Z
Z P Mark each debugger output line with
Z the name of the current process. Most
Z useful when used with a process which
Z runs child processes that are also
Z being debugged. Note that the parent
Z process must arrange for the debugger
Z control string to be passed to the
Z child processes.
Z
Z r Used in conjunction with the DBUG_PUSH
Z macro to reset the current indentation
Z level back to zero. Most useful with
Z DBUG_PUSH macros used to temporarily
Z alter the debugger state.
Z
Z t[,N] Enable function control flow tracing.
Z The maximum nesting depth is specified
Z by N, and defaults to 200.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 19 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z HINTS AND MISCELLANEOUS
Z
Z
Z One of the most useful capabilities of the dbug package
Z is to compare the executions of a given program in two
Z different environments. This is typically done by executing
Z the program in the environment where it behaves properly and
Z saving the debugger output in a reference file. The program
Z is then run with identical inputs in the environment where
Z it misbehaves and the output is again captured in a
Z reference file. The two reference files can then be
Z differentially compared to determine exactly where execution
Z of the two processes diverges.
Z
Z
Z A related usage is regression testing where the
Z execution of a current version is compared against
Z executions of previous versions. This is most useful when
Z there are only minor changes.
Z
Z
Z It is not difficult to modify an existing compiler to
Z implement some of the functionality of the dbug package
Z automatically, without source code changes to the program
Z being debugged. In fact, such changes were implemented in a
Z version of the Portable C Compiler by the author in less
Z than a day. However, it is strongly encouraged that all
Z newly developed code continue to use the debugger macros for
Z the portability reasons noted earlier. The modified
Z compiler should be used only for testing existing programs.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 20 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z CAVEATS
Z
Z
Z The dbug package works best with programs which have
Z "line oriented" output, such as text processors, general
Z purpose utilities, etc. It can be interfaced with screen
Z oriented programs such as visual editors by redefining the
Z appropriate macros to call special functions for displaying
Z the debugger results. Of course, this caveat is not
Z applicable if the debugger output is simply dumped into a
Z file for post-execution examination.
Z
Z
Z Programs which use memory allocation functions other
Z than malloc will usually have problems using the standard
Z dbug package. The most common problem is multiply allocated
Z memory.
Z
Z
Z Beware that some of the macros are not context
Z independent. Some of them contain if statements with no
Z else statements. In particular, the following code segment
Z will not behave as expected:
Z
Z
Z
Z if (something_interesting)
Z DBUG_2 ("ins", "something interesting");
Z else
Z do_normal_processing ();
Z
Z
Z
Z The user code else will bind to the macro's if to produce
Z code equivalent to:
Z
Z
Z
Z if (something_interesting)
Z if (debugging_on)
Z printf ("something interesting");
Z else
Z do_normal_processing ();
Z
Z
Z
Z The author has received numerous suggestions for changes
Z which would eliminate this danger, most based on obscure
Z features of the language or preprocessor, but has rejected
Z most of these for portability or efficiency reasons. (The
Z author also considers it to be poor programming practice to
Z
Z
Z
Z - 21 -
Z
Z
Z
Z
Z
Z
Z
Z DBUG User Manual (preliminary) December 11, 1985
Z
Z
Z
Z write code with any control flow statements that do not use
Z braces.) However, if you absolutely must prevent this
Z behavior try changing the macro definitions to something of
Z the form:
Z
Z
Z
Z #define DBUG_2(keyword,format) \
Z do { \
Z if (_db_on_) { \
Z _db_printf_ (__LINE__, keyword, format); \
Z } \
Z } while (0)
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z - 22 -
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z D B U G
Z
Z C Program Debugging Package
Z
Z by
Z
Z Fred Fish
Z
Z
Z
Z ABSTRACT
Z
Z
Z
Z This document introduces dbug, a macro based C debugging
Z package which has proven to be a very flexible and useful
Z tool for debugging, testing, and porting C programs.
Z
Z
Z All of the features of the dbug package can be enabled
Z or disabled dynamically at execution time. This means that
Z production programs will run normally when debugging is not
Z enabled, and eliminates the need to maintain two separate
Z versions of a program.
Z
Z
Z Many of the things easily accomplished with
Z conventional debugging tools, such as symbolic debuggers,
Z are difficult or impossible with this package, and vice
Z versa. Thus the dbug package should not be thought of as a
Z replacement or substitute for other debugging tools, but
Z simply as a useful addition to the program development and
Z maintenance environment.
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
Z
STUNKYFLUFF
set `sum user.t`
if test 50553 != $1
then
echo user.t: Checksum error. Is: $1, should be: 50553.
fi
echo ALL DONE BUNKY!
exit 0