HP 3000 Manuals HP 3000 Manuals
Building a Shared Global Data XL An XL can have shared global data modules and non-shared global data modules. You can determine if a module in an XL contains shared global data by using the LISTXL command. If the SHARED DATA header field is set to YES, the module is a shared global data module. If the SHARED DATA header field is set to NO, the module does not contain shared global data. As before, the BUILDXL command builds an empty XL. The ADDXL command is used to add shared global data modules to an XL. RLs or object files can still be specified as input to the ADDXL command.
NOTE XLs can have duplicate data exports. Duplicate Storage Universals in an XL is acceptable. However, duplicate Storage Universals are ignored by all XL commands except the LISTXL command. It is not recommended that XLs contain duplicate Data Universal exports. Most XL commands process Data Universal exports and, like entry points, it assumes Data Universal exports in the XL are unique. XLs with duplicate module names containing duplicate Data Universal exports are not acceptable because there is no unique way for the XL commands to correctly identify which module to process.
Adding an Object File to an XL To add object files to an XL and have it share global data, the SHARE option must be specified or the LKSHAREDATA variable must be set to TRUE. The default behavior remains linking for non-shared data. When adding modules to an XL and sharing is turned on, all non-hidden Data Universals and Storage Universals are exported and all Data Unsats, Data Universals, and Storage Universals are imported. The Universals are exported and imported to give the loader the chance to decide which export will be used as the single overriding definition that will resolve all outstanding references to the export for the life of the load. This is slightly different than when linking an object file to form a program file and sharing data. In that type of link, Data Universals are not importable because Data Universals in program files always take precedence over Data Universal exports in an XL. For more information on the loader binding rules, refer to "Loader Binding Rules" . The Link Editor now allows modules in an XL to contain unresolved data symbols when linking for shared code and data. At load time, the loader attempts to resolve these symbols. If the symbols are not resolved, the loader emits an error message and aborts the load. To reduce the number of data exports, you are encouraged to use the HIDERL command to hide data symbols. Refer to "Hiding Data Symbols" .
NOTE XLs can now contain duplicate data symbols, as long as the duplicates occur in different modules. When adding modules to an XL, if another module has a data item with the same name, the second module is also added to the XL. For Data Universal exports, when replacing modules, only the first module found exporting that symbol is replaced.
When adding modules from a RL, a new parameter can be used to instruct the Link Editor to add only the module that exports the specified data symbol: DATA=data_name An indirect file can be specified for this parameter. Note that data_name is case-sensitive and must be a Data Universal. If data_name is a Data Unsat or Storage Universal, the ADDXL command ignores it. If DATA= is used without the SHARE option, the ADDXL command ignores the DATA= parameter. Example ADDXL FROM=TESTRL2;TO=MYXL3 ADDXL FROM=DKRL;DATA=MYTIME,index,link_time;TO=MYXL4;SHARE In the first line, modules from TESTRL2 are added to MYXL3. Data is not shared, so the linking behavior is the same as for non-shared global data environments. Data will not be exported nor imported in MYXL3. In the second line, modules from the RL DKRL are added to MYXL4. Only modules that export MYTIME, index, and link_time (Data Universal exports) are added to the XL. MYXL4 contains data exports (and imports if there are any) that other XLs and program files can access. Manipulating XLs The COPYXL Link Editor command now allows modules to be copied based on data exports (Data Universals only). This implies that the XL was built for shared data and, therefore, has data exports. The COPYXL command accepts a new parameter: DATA=data_name, data_name... Note that data_name is case-sensitive. The first module found that exports the specified data symbol is copied from the XL. If the module is not a shared global or module, the DATA= option is ignored. Example COPYXL FROM=MYXL4;DATA=myindex;TO=NEWXL The first module found in MYXL4 that exports myindex (Data Universal) is copied to NEWXL. If there are duplicate Data Universal exports, it is recommended that you use the MODULE= or ENTRY= parameters to specify a specific module or a module that exports the entry point to be copied. The PURGEXL Link Editor command allows modules to be purged, based on exports (Data Universals only). This implies that the XL was built for shared data and, therefore, has data exports. The PURGEXL command accepts a new parameter: DATA=data_name Note that data_name is case-sensitive. The first module found that exports the specified data symbol is purged from the XL. If the module is not a shared global data module, the DATA= option is ignored. Example PURGEXL XL=MYXL;DATA=bar In this example, the first module found that exports bar is purged. If there are duplicate Data Universal exports, it is recommended that you use the MODULE= or ENTRY= parameter to specify a specific module or a module that exports the entry point to be purged. Listing Program Files and XLs The LISTPROG and LISTXL Link Editor commands now list Data Unsats, Storage Universals, and Data Universals. The LISTPROG command uses the ;DATA option to print data symbols. The LISTXL command accepts a new parameter to allow the printing of modules that export a particular data symbol: DATA_ITEM=data_name Note that data_name is case-sensitive and can be either a Data Universal or Storage Universal. Example LISTXL MYXL;DATA_ITEM=foo In this example, only the modules that export foo are listed. There are new field values for shared global data modules in the LISTPROG and LISTXL output. The field values are: * Under Sym Type, there is a new symbol type, s_req, which denotes a storage request. * Under Sym Scope, there is an unsatisfied scope, unsat, which is now valid with symbol type data. * Under Sym Value, the DP-relative DXRT offset is printed for Data Unsats: dp = data pointer. For Data Universals in program files, the address of the literal or the offset from DP is printed. For Data Universals in XLs, the best-guess offset from DP is printed. This is a best-guess because the loader can override the definition at run time unless the symbol is hidden or the module is linked for non-shared data. For Storage Universals, the best-guess offset from DP is printed (best-guess because the loader can override it at run time) unless the symbol is hidden or the module is linked for non-shared data. A new field, SHARED DATA, is printed in the output listing to indicate if a module is a shared global data module. If SHARED DATA is set to YES, the module contains shared global data; if SHARED DATA is set to NO, the module does not contain shared global data. All Data Universals and Storage Universals are listed before the Data Unsats. If the ;VALUE option is specified, the symbols are sorted in each class by value. If the ;VALUE option is not specified, the symbols are sorted in each class by name. See "Sample Listings" for examples.