home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Frozen Fish 1: Amiga
/
FrozenFish-Apr94.iso
/
bbs
/
alib
/
d3xx
/
d359
/
dice.lha
/
DICE
/
DICE.lzh
/
doc
/
dlink.doc
< prev
next >
Wrap
Text File
|
1990-05-19
|
6KB
|
148 lines
DLINK.DOC
DLINK <options> <files> <libraries>
Options may occur anywhere on the command lines. Any file ending in .o[bj]
is assumed to be an object file. Any file ending in .l[ib] is assumed to
be a library. Any file beginning with @ specifies a text file containing
a further list of files.
File ordering is maintained. Section ordering is maintained. All
sections of the same name are coagulated together with ordering
maintained. EXCEPTION: inter-section ordering is not maintained
within a library since library modules are random included. However,
ordering is maintained *between* libraries.
All object files specified are included in the final executable. All
libraries specified are searched at the point they are specified (that is,
specifying an object file that references a symbol defined in a library
specified BEFORE the object file will cause an undefined symbol error).
Normally an object file is specified after a library to terminate an
autoinit or autoexit section.
You do not have to order object files within a library, DLink will
automatically make as many passes as required to handle all internal
library references. However, ordering object files will make DLink go
faster.
Symbols defined in object files overide symbols defined in libraries.
Symbols defined in libraries specified before later libraries overide
symbols defined in later libraries. Symbols defined in a library and
also defined in a later specified object module causes an error.
CREATING A LIBRARY
DLink libraries are standard Amiga libraries... simply join one or more
object modules together and rename the result with a .lib extension.
LINKER SYMBOLS AND A4 RELATIVE ADDRESSING
__DATA_BAS Base of data space
__DATA_LEN Length of data space is LONGWORDS
__BSS_LEN Length of bss space in LONGWORDS
__RESIDENT Whether -r option was used or not
If -r is not used then the BSS space occurs just after the DATA
space ends and must be manually cleared by the program startup
code. __RESIDENT == 0
If -r is used (__RESIDENT != 0) then NO bss space is allocated. !!!!!!
The startup code is expected to AllocMem((__DATA_LEN+__BSS_LEN)*4)
bytes, copy the static data __DATA_BAS to the newly allocated
memory, and zero the BSS portion.
If A4 relative addressing is used the startup code is expected
to set A4 == BaseOfStaticData + 32766 (where BaseOfStaticData
is __DATA_BAS for non resident programs and the base of the
newly allocated memory for resident programs).
RESIDENT
If the -r options is given then NO BSS SPACE is allocated after the
data space... the startup code MUST allocate a data+bss space as shown
above. DLink will give error messages for any absolute data references
that occur (except the __DATA_BAS symbol which must be used to copy the
static data to the newly allocated data+bss memory on program startup).
DLink will give an error message if any data-data reloco32s exist when
you specify the -r option as such relocations would be incorrect when
copied to the newly allocated data+bss space. DC1 understands this and
will produce autoinit code to handle any such static data relocations
that occur in your C code when the -r option is given to compile a C
program.
PC-RELATIVE
Because the linker will insert a jump table for PC-RELATIVE references
to different hunks (after coagulation) or where the range is larger
than +/-32K, data should not be placed into a code segment and be
referenced via an external label(pc) unless you are positive the
reference is within +/-32K. This can only happen when referencing
between like-named code hunks. NOTE that the jump table is tagged
onto the end of the section the jump(s) occur in and thus you do
not want to have any autoinit/autoexit code that might possibly
generate a jump table (since the whole idea with autoinit is that
the code falls through to other autoinit code until the terminating
section in x.o's RTS).
Currently dlink cannot handle inter-module PC-RELATIVE references
beyond +/-32K (i.e. when one object file has more than 32K of code).
An error will occur.
Note that if -frag is used you cannot make PC-RELATIVE calls
between sections of differing names ever, or make a program resident.
The -frag option is almost never used on untested.
OVERLAYS (NOT SUPPORTED)
Overlays are not supported as yet.
OPTIONS
Options:
-o execname name of executable
-s include symbolic information. NOTE, if -r is used
symbolic info for the data sections will point to
the statically init'd stuff, NOT The actual data
space (in BSS) referenced by the code. This is a bug.
-f[rag] Fragment output file (default is to coagulate all
hunks of the same type regardless of name). If
frag is specified then only hunks of the same type
AND name are coagulated.
-r[es] Resident link.
-d[#] debug mode (spews lots of debugging junk out)
EXAMPLE
This is what DCC gives the linker to link the program 'foo.c' :
dlink dlib:c.o @tmp dlib:x.o -o ram:foo
--- tmp ---
foo.o
dlib:c.lib dlib:amiga.lib dlib:auto.lib
-----------
Basically it tells dlink to link the startup code, c.o, then the
program object module(s) (foo.o), then c.lib, amiga.lib, and auto.lib,
then finally x.o.
DCC handles all this for you
auto.lib contains autoinit code for certain selected libraries
including the dos.library. Autoinit code is brought in whenever a
given library base symbol has been referenced BUT NOT DEFINED. auto.lib
defines the symbol and generates autoinit code to open the library and
autoexit code to close the library.
x.o terminates the autoinit and autoexit sections with an RTS. The
autoinit and autoexit sections are called from the startup code c.o .