![kueller](/assets/img/avatar_default.png)
git-svn-id: svn://svn.compuextreme.de/Viitor/V961/Viitor_cc65@4236 504e572c-2e33-0410-9681-be2bf7408885
75 lines
3.0 KiB
HTML
75 lines
3.0 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.20">
|
|
<TITLE>ld65 Users Guide: Detailed workings</TITLE>
|
|
<LINK HREF="ld65-5.html" REL=next>
|
|
<LINK HREF="ld65-3.html" REL=previous>
|
|
<LINK HREF="ld65.html#toc4" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="ld65-5.html">Next</A>
|
|
<A HREF="ld65-3.html">Previous</A>
|
|
<A HREF="ld65.html#toc4">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s4">4.</A> <A HREF="ld65.html#toc4">Detailed workings</A></H2>
|
|
|
|
|
|
<P>The linker does several things when combining object modules:</P>
|
|
<P>First, the command line is parsed from left to right. For each object file
|
|
encountered (object files are recognized by a magic word in the header, so
|
|
the linker does not care about the name), imported and exported
|
|
identifiers are read from the file and inserted in a table. If a library
|
|
name is given (libraries are also recognized by a magic word, there are no
|
|
special naming conventions), all modules in the library are checked if an
|
|
export from this module would satisfy an import from other modules. All
|
|
modules where this is the case are marked. If duplicate identifiers are
|
|
found, the linker issues a warning.</P>
|
|
<P>This procedure (parsing and reading from left to right) does mean, that a
|
|
library may only satisfy references for object modules (given directly or from
|
|
a library) named <EM>before</EM> that library. With the command line</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
ld65 crt0.o clib.lib test.o
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>the module test.o may not contain references to modules in the library
|
|
clib.lib. If this is the case, you have to change the order of the modules
|
|
on the command line:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
ld65 crt0.o test.o clib.lib
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Step two is, to read the configuration file, and assign start addresses
|
|
for the segments and define any linker symbols (see
|
|
<A HREF="ld65-5.html#config-files">Configuration files</A>).</P>
|
|
<P>After that, the linker is ready to produce an output file. Before doing that,
|
|
it checks it's data for consistency. That is, it checks for unresolved
|
|
externals (if the output format is not relocatable) and for symbol type
|
|
mismatches (for example a zero page symbol is imported by a module as absolute
|
|
symbol).</P>
|
|
<P>Step four is, to write the actual target files. In this step, the linker will
|
|
resolve any expressions contained in the segment data. Circular references are
|
|
also detected in this step (a symbol may have a circular reference that goes
|
|
unnoticed if the symbol is not used).</P>
|
|
<P>Step five is to output a map file with a detailed list of all modules,
|
|
segments and symbols encountered.</P>
|
|
<P>And, last step, if you give the <CODE>
|
|
<A HREF="ld65-2.html#option-v">-v</A></CODE> switch
|
|
twice, you get a dump of the segment data. However, this may be quite
|
|
unreadable if you're not a developer:-)</P>
|
|
|
|
|
|
|
|
<HR>
|
|
<A HREF="ld65-5.html">Next</A>
|
|
<A HREF="ld65-3.html">Previous</A>
|
|
<A HREF="ld65.html#toc4">Contents</A>
|
|
</BODY>
|
|
</HTML>
|