usr/src/tools/depcheck/DependencyCheck.txt

   1
   2 CDDL HEADER START
   3
   4 The contents of this file are subject to the terms of the
   5 Common Development and Distribution License, Version 1.0 only
   6 (the "License").  You may not use this file except in compliance
   7 with the License.
   8
   9 You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
  10 or http://www.opensolaris.org/os/licensing.
  11 See the License for the specific language governing permissions
  12 and limitations under the License.
  13
  14 When distributing Covered Code, include this CDDL HEADER in each
  15 file and include the License file at usr/src/OPENSOLARIS.LICENSE.
  16 If applicable, add the following below this CDDL HEADER, with the
  17 fields enclosed by brackets "[]" replaced with your own identifying
  18 information: Portions Copyright [yyyy] [name of copyright owner]
  19
  20 CDDL HEADER END
  21
  22 Copyright 2000 Sun Microsystems, Inc.  All rights reserved.
  23 Use is subject to license terms.
  24
  25 ident   "%Z%%M% %I%     %E% SMI"
  26
  27 What does this tool do for you?
  28
  29 This tool statically analyzes executable files and tries to figure out
  30 dependencies on libraries and other executable files.  It is important to
  31 recognize that the output of this tool may not be the definitive dependency
  32 list, but the output should give you pointers on possible dependencies.
  33
  34 For more information on how this tool works, see "How does this tool work?"
  35 below.
  36
  37
  38
  39 This set of tools contains 7 files:
  40
  41         1. DependencyCheck.txt - the file you are currently reading
  42         2. make_pkg_db - generate database to reflect the software installed
  43         3. SampleLinks - sample link resolution file for
  44                 /var/sadm/install/contents(see notes on make_pkg_db)
  45         4. SamplePkgLinks - sample link resolution file for
  46                 a package pool (see notes on make_pkg_db)
  47         5. get_depend_info - analyze executables, requires database files
  48         6. make_pkg_db.txt - text formatted man page
  49         7. get_depend_info.txt - text formatted man page
  50
  51
  52
  53
  54 How to use this tool:
  55
  56         a. run make_pkg_db with the -dbdir argument
  57         b. read the README notes on make_pkg_db and decide if you
  58            want to resolve the symbolic links
  59         c. run the get_depend_info tool and specify the directory with
  60            the package database files
  61
  62
  63
  64 How does this tool work?
  65
  66 At a high level, this tool uses /usr/bin/ldd and /usr/bin/strings to figure
  67 out what an executable file depends upon.  Since this is a static analysis
  68 there is no way to know if the dependencies identified will actually be
  69 executed.
  70
  71 The strings command will not be run on binaries if the user specifies the
  72 -cons option for get_depend_info.
  73
  74 This tool cannot resolve variable substitions.  For example if a shell script
  75 set "$MYPATH" to "/usr/sbin" and then executes "$MYPATH/df", this tool will
  76 not be able to resolve that the shell script will execute "/usr/sbin/df".
  77
  78 The only way to conclusively know all the dependencies is to do a runtime
  79 analysis. Furthermore, to get the complete set of dependencies, you would need
  80 to run all permutations of the executable being analyzed.  Clearly a definitive
  81 dependency check would be a tremendous amount of work and outside the scope
  82 of this tool.
  83
  84 This tool divides executables into three broad groups - kernel modules,
  85 binaries and shell scripts.
  86
  87 For all three types of files, all the output is verified against the entries
  88 in database generated by make_pkg_db.  This technique allows the tool to verify
  89 that a dependency was part of the Solaris installation and determine which
  90 package a given dependency came from.
  91
  92
  93
  94 A.  Dependency Checks on Kernel Modules
  95
  96 Kernel modules are identified by having a "/kernel/" somewhere in their
  97 path.  If an input is identified as a kernel module, then an ldd is run on
  98 that module.  If the ldd returns output, then the tool parses that output
  99 to see if it can find the library in /kernel or in /usr/kernel.  For example,
 100 if the tool runs on /kernel/drv/mydrv, the ldd will return something like
 101 "misc/mylib".  The tool will look for "mylib"in /kernel/misc/mylib or
 102 /usr/kernel/misc/mylib.
 103
 104 If the ldd returns nothing, then a "strings" command is run on the kernel
 105 module.  Again, the output of the strings is compared against /kernel and
 106 /usr/kernel to see if there is a match.  This method was designed to catch
 107 the "_depends_on" string embedded in some kernel modules.
 108
 109 Note, if the ldd succeeds, then a strings will not run on the kernel module.
 110
 111
 112 B. Binary files
 113
 114 Binary files have both the ldd and strings command run on them.  The output of
 115 both programs is parsed and checked against the contents of the database
 116 generated by make_pkg_db.
 117
 118 If the user specifies the -cons option on get_depend_info, then the strings
 119 analysis will not be done.  This is a more conservative approach which only
 120 uses ldd and therefore has realiable output.
 121
 122
 123 C. Shell scripts
 124
 125 Shell scripts are parsed to remove comments and break the script into tokens
 126 of the file.  All the tokens in the file are cross-checked against the database
 127 generated by make_pkg_db to determine if a dependency exists.
 128
 129