lari(1) (man pages section 1: User Commands)

man pages section 1: User Commands

lari(1)

NAME

lari– link analysis of runtime interfaces

SYNOPSIS

lari

-bCDsv

-a

-i

-o

file

dir

lari

-CDosv

-m

-d

mapdir

file

DESCRIPTION

The lari utility analyzes the interface requirements of dynamic ELF objects. There are two basic modes of operation. The first mode displays runtime interface information. The second mode generates interface definitions.

Dynamic objects offer symbolic definitions that represent the interface that the object provides for external consumers. At runtime, bindings are established from the symbolic references of one object to the symbolic definitions of another object. lari analyzes both the interface definitions and runtime bindings of the specified objects.

When displaying runtime interface information, lari analyzes each file specified on the command line, or descends into each directory, dir, processing each file it finds. When generating interface definitions, only one input file is allowed.

Without the -D option, lari processes files as dynamic ELF objects using ldd(1). This processing uses the options -r and -e LD_DEBUG=files,bindings,detail to provide information on all bindings established as part of loading the object. Notice that by using ldd, the specified object is not executed, and hence no user controlled loading of objects, by dlopen(3DL) for example, will occur. To capture all binding information from an executing process, the following environment variables can be passed directly to the runtime linker, ld.so.1(1):

LD_DEBUG=files,bindings,detail LD_DEBUG_OUTPUT=lari.dbg \ 
LD_BIND_NOW=yes

The resulting debug output, lari.dbg.pid, can be processed by lari using the -D option. Note: lari attempts to analyze each object that has been processed using the path name defined in the debug output. Each object must therefore be accessible to lari for a complete, accurate analysis to be provided. The debug output file must be generated in the C locale.

When displaying interface information, lari analyzes the interfaces of the processed dynamic objects and, by default, displays any interesting information. See Interesting Information under EXTENDED DESCRIPTION. The information displayed is also suitable for piping to other tools and can aid developers in analyzing process bindings or debugging complex binding scenarios.

The generation of interface definitions by lari can be used to refine the interface requirements of the dynamic objects processed. When creating a dynamic object, you should define an explicit, versioned interface. This definition controls the symbol definitions available to external users and frequently reduces the overall runtime execution cost of the object. Interface definitions may be assigned to an object during its creation by the link-editor using the -M option and the associated mapfile directives. See the Linker and Libraries Guide for more details on versioning using mapfiles. An initial version of these mapfiles can be created by lari.

OPTIONS

The following options are supported.

-a: Displays all interface information for the objects analyzed. Note: The output from this option may be substantial, but it can be useful for piping to other analysis tools.
-b: Limits the interface information to those symbols that have been explicitly bound to. Note: Symbols defined as protected may have been bound to from within the defining object. This binding is satisfied at link-edit time and is therefore not visible to the runtime environment. Protected symbols are displayed with this option.
-C: Demangles C++ symbol names. This option is useful for augmenting runtime interface information. When generating interface definitions, demangled names are added to the mapfiles as comments.
-d mapdir: Defines the directory, mapdir, in which mapfiles are created. By default, the current working directory is used.
-D: Interprets any input files as debugging information rather than as dynamic objects.
-i: Displays interesting interface binding information. This mode is the default if no other output controlling option is supplied. See Interesting Information under EXTENDED DESCRIPTION.
-m: Creates mapfiles for each dynamic object processed. These mapfiles reflect the interface requirements of each object as required by the input file being processed.
-o: Limits the interface information to those symbols that are deemed an overhead. When creating mapfiles, any overhead symbols are itemized as local symbols. See Overhead Information under EXTENDED DESCRIPTION.
-s: Saves the bindings information produced from ldd(1) for further analysis. See FILES.
-v: Ignores any objects that are already versioned. Versioned objects have had their interfaces defined, but may contribute to the interface information displayed. For example, a versioned shared object may reveal overhead symbols for a particular process. Versioned objects are frequently designed for use by multiple processes, and thus their interfaces may extend beyond that which any one process requires. The -v option therefore, can reduce noise when displaying interface information.

The runtime interface information produced from lari has the following format:

[information]: symbol-name [demangled-name]: object-name

Each line describes the interface symbol, symbol-name, together with the object, object-name, in which it is defined. If the -C option is used, the symbol name is accompanied by the symbols demangled name, demangled-name. The information field provides one or more of the following tokens that describe the symbol's use:

cnt:bnd: Two decimal values indicate the symbol count, cnt, and the number of bindings to this object, bnd. The symbol count is the number of occurrences of this symbol definition found in the objects analyzed. A count greater than 1 indicates multiple instances of a symbol definition. The number of bindings indicate the number of objects that have been bound to this symbol definition by the runtime linker.
E: This symbol definition has been bound to from an external object.
S: This symbol definition has been bound to from the same object.
D: This symbol definition has been directly bound to.
I: This object explicitly identifies itself as an interposor. See the -z interpose option of ld(1), and the LD_PRELOAD variable of ld.so.1(1).
C: This symbol definition is the reference data of a copy-relocation.
F: This symbol definition resides in a filtee.
P: This symbol is defined as protected. This symbol may have an internal binding from the object in which it is declared. Any internal bindings with this attribute can not be interposed upon by another symbol definition.
A: This symbol definition is the address of a procedure linkage table entry within a dynamic executable.
U: This symbol lookup originated from a user request, for example, dlsym(3DL).

See the Linker and Libraries Guide for more details of these symbol classifications.

EXTENDED DESCRIPTION

Interesting Information

By default, or specifically using the -i option, lari filters any runtime interface information to present interesting events. This filtering is carried out mainly to reduce the amount of information generated from large applications. In addition, this information is intended to be the focus in debugging complex binding scenarios, and often highlights problem areas. However, classifying what information is interesting for any particular application is an inexact science. You are still free to use the -a option and to search the binding information for events that are unique to the application being investigated.

When an interesting symbol definition is discovered, all other definitions of the same symbol are output.

The focus of interesting interface information is the existence of multiple definitions of a symbol. In this case, one symbol typically interposes on one or more other symbol definitions. This interposition is seen when the binding count, bnd, of one definition is non-zero, while the binding count of all other definitions is zero. Interposition that results from the compilation, or linking environment, is not characterized as interesting. Examples of this include copy relocations ([C]) and the binding to procedure linkage addresses ([A]).

Interposition is often desirable. The intent is to overload, or replace, the symbolic definition from a shared object. Interpositioning objects can be explicitly tagged ([I]), using the -z interpose option of ld(1). These objects will safely interpose on symbols, no matter what order they are loaded in a process. However, be cautious when non-explicit interposition is employed, as this is a consequence of the load-order of the objects that make up the process.

User-created, multiply-defined symbols are output from lari as interesting. In this example, two definitions of interpose1() exist, but only the definition in main is referenced:

[2:1E]: interpose1: ./main
[2:0]: interpose1: ./libA.so

Interposition may also be an undesirable and surprising event, caused by an unexpected symbol name clash. A symptom of this interposition might be that a function is never called although you know a reference to it exists. This scenario can be identified as a multiply defined symbol, as covered in the previous example. However, a more surprising scenario is often encountered when an object both defines and references a specific symbol.

An example of this scenario is if two dynamic objects define and reference the same function, interpose2(). Any reference to this symbol binds to the first dynamic object loaded with the process. In this case, the definition of interpose2() in object libA.so interposes on, and hides, the definition of interpose2() in object libB.so. The output from lari might be:

[2:2ES]: interpose2: ./libA.so
[2:0]: interpose2: ./libB.so

Multiply defined symbols may also be bound to separately. This can be the case when direct bindings is in effect ([D]), or because of a symbol's protected visibility ([P]). In either case, it may be desirable to establish different bindings, or it may come as a surprise to observe that they exist at all. Directly bound symbols, and symbols with protected visibility, are output as interesting information.

Overhead Information

When using the -o option, lari displays symbol definitions that might be considered overhead.

Global symbols that are not referenced are considered an overhead. The symbol information provided within the object unnecessarily adds to the size of the object's text segment. In addition, the symbol information can increase the processing required to search for other symbolic references within the object at runtime.

Global symbols that are only referenced from the same object have the same characteristics. Searching for the symbolic reference at runtime, only to bind to the same object that made the reference, is an additional overhead.

Both of these symbol definitions are candidates for reduction to local scope by defining the object's interface. Interface definitions may be assigned to a file during its creation by the link-editor using the -M option and the associated mapfile directives. See the Linker and Libraries Guide for more details on mapfiles. Use lari with the -m option to create initial versions of these mapfiles.

If lari is being used to generate mapfiles, versioned shared objects will have mapfiles created indicating that their overhead symbols should be reduced to locals. This allows lari to generate mapfiles for comparison with existing interface definitions. Use the -v option to ignore versioned shared objects when creating mapfiles.

Copy-relocations are also viewed as an overhead and generally should be avoided. The size of the copied data is a definition of its interface. This definition restricts the ability to change the data size in newer versions of the shared object in which the data is defined. This restriction, plus the cost of processing a copy relocation, can be avoided by referencing data using a functional interface. The output from lari for a copy relocation might be:

[2:1EC]: __iob: ./main
[2:0]: __iob: ./libA.so.1

Notice that a number of small copy relocations, such as __iob used in the previous example, exist because of historic programming interactions with system libraries.

Another example of overhead information is the binding of a dynamic object to the procedure linkage table entry of a dynamic executable. If a dynamic executable references an external function, a procedure linkage table entry is created. This structure allows the reference binding to be deferred until the function call is actually made. If a dynamic object takes the address of the same referenced function, it binds to the dynamic executables procedure linkage table entry. An example of this type of event is displayed as:

[2:1EA]: foo: ./main
[2:1E]: foo: ./libA.so

A small number of bindings of this type are typically not cause for concern. However, a large number of these bindings, perhaps from a jump-table programming technique, can contribute to start up overhead. Address relocation bindings of this type require relocation processing at application start up, rather than the deferred relocation processing used when calling functions directly. Use of this address also requires an indirection at runtime.

EXAMPLES

Example 1 Analyzing a case of multiple bindings

The following example shows the analysis of a process in which multiple symbol definitions exist. The shared objects libX.so and libY.so both call the function interpose(). This function exists in both the application main, and the shared object libA.so. Because of interposition, both references bind to the definition of interpose() in main.

The shared objects libX.so and libY.so also both call the function foo(). This function exists in the application main, and the shared objects libA.so, libX.so, and libY.so. Because both libX.so and libY.so were built with direct bindings enabled, each object binds to its own definition.

example% lari ./main
[3:0]: foo: ./libA.so
[3:1SD]: foo: ./libX.so
[3:1SD]: foo: ./libY.so
[2:0]: interpose: ./libA.so
[2:2EP]: interpose: ./main

To analyze binding information more thoroughly, the bindings data can be saved and inspected further. For example, the previous output indicates that the function interpose() was called from two objects external to main. Inspecting the binding output reveals where the references to this function originated.

example% lari -s ./main
lari: ./main: bindings information saved as: /usr/tmp/lari.dbg.main
.....
example% fgrep foo /usr/tmp/lari.dbg.main
binding file=./libX.so to file=./main: symbol `interpose'
binding file=./libY.so to file=./main: symbol `interpose'

Note: The bindings output is typically more extensive than shown here, as it is accompanied with process identifier, address and other bindings information.

Example 2 Generating an interface definition

The following example creates interface definitions for an application and its dependency, while ignoring any versioned system libraries. The application main makes reference to the interfaces one(), two(), and three() in foo.so:

example% lari -omv ./main
example% cat mapfile-foo.so
#
# Interface Definition mapfile for:
#       Dynamic Object: ./foo.so
#       Process:        ./main
#

foo.so {
        global:
                one;
                three;
                two;
        local:
                _one;
                _three;
                _two;
                *;
};

FILES

$TMPDIR/lari.dbg.file: Binding output produced by ldd(1).

ATTRIBUTES

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWtoo
Interface Stability	See below.

Human readable output is Unstable. Options are Evolving.