Version 1.9 Build 1556

News	FAQ
Search	Home

Next: Template management Up: Code development Previous: depstat

Subsections

`ldmap`

Determine dependencies between object modules from a namelist.

Synopsis

ldmap [-1] [-h #] [-m | -M] [-o | -O object] [-r] [-s file | directory] [-t] [namelist [namelist ...]]

ldmap reads through a file containing the output produced by nm and determines the dependency hierarchy of .o files. That is, if X is an undefined symbol in a.o, and X is defined in b.o, then a.o depends on b.o.

There is also an option to reverse the dependency analysis so that instead of listing all the object modules required by a particular object module ldmap lists all of the object modules which require a particular object module.

The name list file may be specified as ``-'' whence ldmap will read it from stdin.

The analysis is done in two stages. First the namelist is converted to a list of dependencies of the form

   a.o b.o

meaning that a.o requires b.o. If the -m option is specified the output looks like

   a.o usym b.o

where usym is the undefined symbol in a.o which would cause the linker to load b.o. If the -M option is specified the output also includes lines such as

   a.o dsym a.o

where dsym is a symbol defined in a.o.

Unresolved symbols may be included in the output via the -n option:

   a.o (usym)

The stage 2 analysis consists of iterating through the dependency list to find all object modules required by each particular object module. By default, all object modules in the dependency list are processed, however the analysis may be done for a set of object modules via the -o option.

Since the stage 1 analysis is time-consuming, the intermediate results can be saved for later use in either or both of two forms. In packed form, the stage 1 results are stored in a single file. In the unpacked form, which is the most efficient for the stage 2 analysis, the results for each object module are stored in a separate file in a subdirectory.

Options

-1

Quit after the stage 1 analysis.

-h #

Set a limit to the depth of the dependency hierarchy in the stage 2 analysis.

-m | M

Produce a stage 1 analysis with more information than is needed for stage 2.

-m includes symbol names in the output of the stage 1 analysis, and -M also includes symbols defined in each object module.

The -m and -M options are meant to be used with the -p option to produce a file for visual inspection. The extra information is thrown away when the stage 1 analysis is unpacked.

-n

Include unresolved symbols in the stage 1 analysis. They appear in the stage 1 output in parentheses.

-o object | -O object

Determine dependencies for the specified object module only. Multiple object modules may be specified in a single -o, or multiple -o options may be specified. Either way the analysis is performed for the group as a whole.

If -O is specified the stage 1 analysis will be unpacked, otherwise the packed analysis will be used unless the unpacked analysis is already available.

-p file | -P directory

Preserve the result of the stage 1 analysis.

-p saves the packed result in the specified file.

-P saves the unpacked result in the specified directory.

If the file and/or directory already exist they will be deleted. Both options may be specified together.

-r

Reverse the direction of the dependency analysis. In the stage 1 analysis the namelist is converted to a list of dependencies of the form

      a.o b.o

meaning that a.o is required by b.o. The stage 2 analysis is unaffected. Use of the -r option precludes the use of the -n and -v options.

-s file | -S directory

Skip stage 1 of the analysis.

-s specifies the name of a file containing the stage 1 analysis from a previous invokation of ldmap -p, or the name of a directory containing the unpacked stage 1 analysis from a previous invokation of ldmap -P.

In either case the namefile need not be specified.

A -s option may not be combined with stage 1 analysis options except for the combination -s <file> -P <directory>.

-t

Print timing information.

-v file

A file containing the output of ar tv used for determining sizes. Multiple -v options may be specified.

Notes

ldmap assumes the namelist is in a form similar to that produced by the nm provided with SunOS 5.5. Other versions of nm, even those in earlier versions of SunOS, may produce namelists in an incompatible format.
The output of ldmap may be piped through c++filt to demangle C++ names.

Diagnostics

Status return values
0: success
1: initialization error

Examples

The following determines all dependencies for the gtable application.

   cd $HOME/aips++/code/aips/apps/gtable/
   gmake gtable.o
   cd $HOME/aips++/sun4sol_gnu/bindbg
   nm gtable.o > gtable.nm
   nm /aips++/sun4sol_gnu/lib/libaips.a > libaips.nm
   ldmap -n -o gtable.o gtable.nm libaips.nm

This produces output such as

   gtable.o
      Error2.o
      Excp2.o
      GlishArray.o
      GlishEvent.o
      GlishRecord.o
      String.o
         ArrayPosIter.o
         Array_1020.o
         Array_1030.o
         Array_1050.o
         .
         .
         .
               StreamLogSink.o
               SymLink.o
               Time.o
                  ByteIO.o
                  ObjectID.o
                     Vector_1100.o
                        VectorRtti_1180.o
Count: 235

The levels of indentation are indicative of each cycle of the recursion. Note that the above list contains object modules derived from do-it-yourself template instantiation (see mkinst (p)).

Using libaips.nm generated above, the following saves a reversed stage 1 analysis of libaips.a in unpacked form for later use and then quits.

   ldmap -1 -P libaips.1ru -r libaips.nm

With most of the hard work done, the saved stage 1 analysis may then be used repeatedly to quickly determine all object modules in libaips.a which depend on (i.e. contain symbols resolved by) a specified module. For example DeconvTool.o

   ldmap -s libaips.1ru -o DeconvTool.o

resulting in the following (unusually brief) output:

   DeconvTool.o
      CCleanTool.o
      CleanTool.o
      FTCleanTool.o
         HCleanTool.o
         SDICleanTool.o
   Count: 6

Author

Original: 1996/05/06 by Mark Calabretta, ATNF.

Next: Template management Up: Code development Previous: depstat Contents Index