LD - link edit object files.

Syntax:

c_g8_ns/8cv1.3/mod/ld [file] [options]*

(+|-)Tables (-)        Deletesym=name,name,...
Entry=name             Format=keyword
Keepsym=name           Library=filename
Map=filename           Name=name
Output=filename        Use=name

Options:

file

can be the name of an LD object file or an LD library. If it is a library, the entire contents of the library will be used as input.

-Tables

tells LD to get rid of debugging information tables in the final output. At present, this has no effect on the final size of a program.

Deletesym=name,name,...

deletes the given symbol(s) from the object code. The named symbols should be global names. Deleting them prevents them from appearing in the output file as globals. Deleting a SYMDEF "hides" the symbol so that it is no longer visible; deleting a SYMREF just deletes the reference (but errors will occur if the symbol is used for relocation anywhere in the module).

Entry=name

specifies an entry name. This should be a name defined in the object code being linked. Execution will begin at this entry when the resulting program is loaded. This option is only meaningful if the output format is a run-unit or a B*. With other formats, the option is ignored.

Format=keyword

indicates the final output format for the object code. Possible "keyword" values are:

gcos_OM: a bound OM.
Ld: LD object code (e.g. for an LD library).
Bstar: a B* file.
Qstar: a Q* file.
gcos_RU: a NS mode run-unit.

Keepsym=name,name,name,...

deletes all symbol(s) from the object code EXCEPT for the ones named. The deletion process is the same as for Deletesym=.

Library=filename

specifies a (user) library containing object code that may need to be included in the link editing. There may be several Library= options on the command line. (When a library is specified in this way, LD only obtains modules that are needed to resolve references from other files; if a library file name is specified without Library=, LD will use the entire library as input.)

Map=filename

requests that a load map be written to the given file.

Name=name

assigns a name to the output module.

Output=filename

indicates that output should be written to the given file. The output file will contain link-edited object code.

Use=name

indicates that the libraries or standard library should be searched for a module containing the given "name" and that the module should be link-edited with the rest of the code, even though the "name" may not be referenced by the code.

Description:

LD link-edits one or more object modules into a single output file. The format of the output file is selected by the Format= option. The input can be a mix of LD files (produced by a Thinkage compiler), OM files, and/or B* files, or their associated library formats. (Note that some of these file formats may not be appropriate for the NS mode environment, e.g. B* and Q* formats.)

Below we list the possible output formats and the default files associated with each format.

gcos_OM      fc*o* (random)
Ld           fc*o* (random)
gcos_RU      fc*v* (random)
Bstar        b* (sequential)
Qstar        .h (random)

Name Files:

Name files may be used when a particular output format (e.g. Q* files) does not store data names in full length or loses case distinction in names.

A name file is a text file. Each line gives an abbreviated name, followed by a full data name, with case distinction, as in

getcha getchar
shortn ShortName

To create a name file, specify the Output= option in the form

Output=objfile,namefile

Linked object code (in the requested output format) will be written into "objfile" and an associated name file will be written into "namefile".

In a subsequent LD command, you can specify

c_g8_ns/8cv1.3/mod/ld file,namefile [options]*

LD will obtain full object names from the name file and work with these instead of the truncated names.

Notes:

At present, LD is a bare-bones tool, because it holds so little built-in information about its output file. For a run-unit, for example, it knows how to build the linkage segment and knows the reserved SEGIDs for special segments like the SLIS, but does not actually create these special segments.