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, the
following symbol tables:
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 symbol tables of the primary executable first, then
one or more of the other symbol tables. Note 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.
Use the ::nmadd and ::nmdel dcmds to manipulate the private symbol table.
Use the ::nm -P dcmd to display the contents of the private symbol
table. The private symbol table enables you 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 converts 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 enable you
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 symbol table
of the specified object. The object identifier's interpretation depends on the target type.
The MDB kernel target expects object to specify the basename 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. The value of object can take any
of the following forms:
Exact match (that is, a full path name): /usr/lib/libc.so.1
Exact basename match: libc.so.1
Initial basename match up to a period or dot character (.) 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 these four forms 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 character (`). For example, the symbol name LM0`libc.so.1`_init evaluates 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 might be necessary to resolve symbol naming
conflicts if 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(3C) man page. Link-map identifiers are displayed when symbols are printed according
to the setting of the showlmid option, as described in 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 can have an ambiguous name, use an explicit 0x or 0X prefix
to specify the integer value.
