HP 3000 Manuals HP 3000 Manuals
Advanced Topics
This section describes additional information on shared global data in
XLs.
External Data References
An external data reference, also known as an import, is a reference to a
data symbol that is not defined in the module. External data references
are now allowed in program files and XLs if they are linked for shared
data. These references are not resolved at link time because the Link
Editor builds one load module at a time, using LINK or ADDXL. Therefore,
the Link Editor does not know where the corresponding data definition, or
export, is located. The data item could be located in a module in the
same XL or in another XL.
Because the Link Editor cannot resolve external data references, it turns
the reference into an LST data import request. It also allocates an
entry in the Data Cross Reference Table (DXRT) for the unresolved data
reference. The instruction used to reference the external data is
changed from a direct reference to an indirect reference through the
DXRT. This indirection enables the loader to locate data definitions for
each data reference and initialize the DXRT with the appropriate values
at run time.
External data references can be created by the Link Editor for Storage
and Data symbols. When linking to form a program file, the Link Editor
creates a corresponding Data Unsat record for each Storage Universal.
The Link Editor creates the Data Unsat to allow other definitions or
Storage symbols to override the original definition or symbol at run
time. The Link Editor also creates an LST data import record and
allocates an entry in the DXRT for the import. At run time, the loader
locates data definitions for each data reference, including those that
the Link Editor created. For Storage Universals, if a larger Storage
Universal or a corresponding Data Universal is found, the loader ignores
the original Storage Universal and binds all references to the symbol
found.
When adding modules to an XL, the Link Editor creates a corresponding
Data Unsat record for each Data Universal and goes through the same
process used for creating imports for Storage Universals, outlined above.
This allows other definitions to override the original at run time. Data
Universals in program files do not have Link Editor-created Data Unsats
because Data Universals in program files always take precedence over
symbols in an XL. Therefore, Data Universals in the program can never be
overridden at run time.
Duplicate Data
Duplicate data exports are allowed in an XL, as long as the duplicates
occur in separate modules. Duplicate Data Universal exports are not
allowed in program files and are not recommended in XLs. Duplicate Data
Universals are not recommended in XLs because duplicate data exports are
not allowed in HP-UX Shared Libraries. Also, the loader uses the first
Data Universal it finds as the defining definition. The loader picks one
of the duplicate symbols and uses it as the single overriding definition
for all references to it.
There is a distinction between Data Universal and Storage Universal data
exports because there is apt to be more duplicate Storage Universals than
Data Universals. For example, Data Universal exports do not exist in
Pascal object files. All declarations are considered Storage Unsats.
The XL commands that support the DATA= parameter (ADDXL, COPYXL, PURGEXL)
work on Data Universals and ignore Storage Universals. The LISTXL
command is an exception. LISTXL DATA_ITEM= lists all modules that export
the specified Data Universal or Storage Universal, it does not change the
XL in any way. Therefore, it is less of a risk to list every module that
exports a data item than to only list one.
The DATA= parameter works on the first module it finds that exports the
Data Universal symbol. Because duplicate data is legal, the Link Editor
cannot predict if you want to process only one module that exports the
data item or all modules that export the data item. To ensure that you
are processing a specific module and not just the first one the Link
Editor finds that exports a specific data symbol, use the ENTRY= or
MODULE= options of the ADDXL, COPYXL, or PURGEXL commands. The exception
is the LISTXL command as noted above.
The XL commands that support the ENTRY= parameter (ADDXL, COPYXL,
PURGEXL) work on only one module that exports the symbol, because entry
points must be unique in an XL and in program files.
Example
The following example demonstrates how the PURGEXL and LISTXL commands
process an XL that contains duplicate data exports. Assume that after
each PURGEXL command is executed, the process starts over with the same
MYXL XL.
MYXL
Module DKTEST
i data univ /* i, foo, fee are exports */
foo data univ
fee s_req univ
fum data unsat /* fum, foo, fee, i are imports */
foo data unsat
fee data unsat
i data unsat
Module DKOPEN
fee s_req univ /* fee is an export */
fum data unsat /* fum, fee are imports */
fee data unsat
Module DKCLOSE
foo data univ /* foo, bar are exports */
bar entry univ
foo data unsat /* foo is an import */
Module DKGET
bar data univ /* bar is an export */
bar data unsat /* bar is an import */
PURGEXL XL=MYXL;DATA=foo Deletes module DKTEST from MYXL because
DKTEST is the first module found that
exports foo.
PURGEXL XL=MYXL;DATA=fee Does not delete any module from MYXL
because no module was found that exports
a data universal symbol named fee.
PURGEXL XL=MYXL;DATA=fum Does not delete any module from MYXL
because no module was found that exports
a data universal symbol named fum.
PURGEXL XL=MYXL;DATA=bar Deletes module DKGET from MYXL because
DKGET exports a data universal symbol
named bar.
PURGEXL XL=MYXL;ENTRY=bar Deletes module DKCLOSE from MYXL because
DKCLOSE exports an entry symbol named
bar.
LISTXL XL=MYXL;DATA_ITEM=fee Lists modules DKTEST and DKOPEN from MYXL
because both modules export a data symbol
named fee.