Symbol Name Resolution

As explained in Syntax, a symbol identifier present
in an expression context evaluates to the value of this symbol. The value
typically denotes the virtual address of the storage associated with the symbol
in the target's virtual address space. A target can support multiple symbol
tables including, but not limited to,

Primary executable symbol table

Primary dynamic symbol table

Runtime link-editor symbol table

Standard and dynamic symbol tables for each of a number of
load objects (such as shared libraries in a user process, or kernel modules
in the Solaris kernel)

The target typically searches the primary executable's symbol tables
first, then one or more of the other symbol tables. Notice that ELF symbol tables contain only entries for external, global, and
static symbols; automatic symbols do not appear in the symbol tables processed
by MDB.

Additionally, MDB provides a private user-defined symbol table that
is searched prior to any of the target symbol tables. The private symbol table
is initially empty, and can be manipulated using the ::nmadd
and ::nmdel dcmds.

The ::nm-P option can be used to
display the contents of the private symbol table. The private symbol table
allows the user to create symbol definitions for program functions or data
that were either missing from the original program or stripped out. These
definitions are then used whenever MDB converts a symbolic name to an address,
or an address to the nearest symbol.

Because targets contain multiple symbol tables, and each symbol table
can include symbols from multiple object files, different symbols with the
same name can exist. MDB uses the backquote “ ` “
character as a symbol-name scoping operator to allow the programmer to obtain
the value of the desired symbol in this situation.

You can specify the scope used to resolve a symbol name as either: object`name, or file`name, or object`file`name. The object identifier refers to
the name of a load object. The file identifier refers to the basename of a
source file that has a symbol of type STT_FILE in the specified
object's symbol table. The object identifier's interpretation depends on the
target type.

The MDB kernel target expects object to specify
the base name of a loaded kernel module. For example, the symbol name:

specfs`_init

evaluates to the value of the _init symbol in the specfs kernel module.

The mdb process target expects object to specify the name of the executable or of a loaded shared
library. It can take any of the following forms:

Exact match (that is, a full pathname): /usr/lib/libc.so.1

Exact basename match: libc.so.1

Initial basename match up to a ``.'' suffix: libc.so or libc

Literal string a.out which is accepted
as an alias for the executable

The process target will also accept any of the four forms described
above preceded by an optional link-map id (lmid). The lmid prefix is specified by an initial LM followed
by the link-map id in hexadecimal followed by an additional backquote. For
example, the symbol name:

LM0`libc.so.1`_init

will evaluate to the value of the _init symbol in
the libc.so.1 library that is loaded on link-map 0 (LM_ID_BASE). The link-map specifier may be necessary to resolve
symbol naming conflicts in the event that the same library is loaded on more
than one link map. For more information on link maps, refer to the Linker
and Libraries Guide and the dlopen(3DL) man page. Link-map identifiers will
be displayed when symbols are printed according to the setting of the showlmid option, as described under Summary of Command-line Options.

In the case of a naming conflict between symbols and hexadecimal integer
values, MDB attempts to evaluate an ambiguous token as a symbol first, before
evaluating it as an integer value. For example, the token f
can refer either to the decimal integer value 15 specified
in hexadecimal (the default base), or to a global variable named f in the target's symbol table. If a symbol with an ambiguous name
is present, the integer value can be specified by using an explicit 0x or 0X prefix.