DLINK.DOC DLINK 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 .