7bca5fab5b
git-svn-id: svn://svn.compuextreme.de/Viitor/V962/Viitor_cc65@4352 504e572c-2e33-0410-9681-be2bf7408885
605 lines
25 KiB
HTML
605 lines
25 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: Configuration files</TITLE>
|
|
<LINK HREF="ld65-6.html" REL=next>
|
|
<LINK HREF="ld65-4.html" REL=previous>
|
|
<LINK HREF="ld65.html#toc5" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="ld65-6.html">Next</A>
|
|
<A HREF="ld65-4.html">Previous</A>
|
|
<A HREF="ld65.html#toc5">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="config-files"></A> <A NAME="s5">5.</A> <A HREF="ld65.html#toc5">Configuration files</A></H2>
|
|
|
|
|
|
<P>Configuration files are used to describe the layout of the output file(s). Two
|
|
major topics are covered in a config file: The memory layout of the target
|
|
architecture, and the assignment of segments to memory areas. In addition,
|
|
several other attributes may be specified.</P>
|
|
<P>Case is ignored for keywords, that is, section or attribute names, but it is
|
|
<EM>not</EM> ignored for names and strings.</P>
|
|
|
|
|
|
|
|
<H2><A NAME="ss5.1">5.1</A> <A HREF="ld65.html#toc5.1">Memory areas</A>
|
|
</H2>
|
|
|
|
|
|
<P>Memory areas are specified in a <CODE>MEMORY</CODE> section. Lets have a look at an
|
|
example (this one describes the usable memory layout of the C64):</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
MEMORY {
|
|
RAM1: start = $0800, size = $9800;
|
|
ROM1: start = $A000, size = $2000;
|
|
RAM2: start = $C000, size = $1000;
|
|
ROM2: start = $E000, size = $2000;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>As you can see, there are two ram areas and two rom areas. The names
|
|
(before the colon) are arbitrary names that must start with a letter, with
|
|
the remaining characters being letters or digits. The names of the memory
|
|
areas are used when assigning segments. As mentioned above, case is
|
|
significant for these names.</P>
|
|
<P>The syntax above is used in all sections of the config file. The name
|
|
(<CODE>ROM1</CODE> etc.) is said to be an identifier, the remaining tokens up to the
|
|
semicolon specify attributes for this identifier. You may use the equal sign
|
|
to assign values to attributes, and you may use a comma to separate
|
|
attributes, you may also leave both out. But you <EM>must</EM> use a semicolon to
|
|
mark the end of the attributes for one identifier. The section above may also
|
|
have looked like this:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# Start of memory section
|
|
MEMORY
|
|
{
|
|
RAM1:
|
|
start $0800
|
|
size $9800;
|
|
ROM1:
|
|
start $A000
|
|
size $2000;
|
|
RAM2:
|
|
start $C000
|
|
size $1000;
|
|
ROM2:
|
|
start $E000
|
|
size $2000;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>There are of course more attributes for a memory section than just start and
|
|
size. Start and size are mandatory attributes, that means, each memory area
|
|
defined <EM>must</EM> have these attributes given (the linker will check that). I
|
|
will cover other attributes later. As you may have noticed, I've used a
|
|
comment in the example above. Comments start with a hash mark (`#'), the
|
|
remainder of the line is ignored if this character is found.</P>
|
|
|
|
|
|
<H2><A NAME="ss5.2">5.2</A> <A HREF="ld65.html#toc5.2">Segments</A>
|
|
</H2>
|
|
|
|
|
|
<P>Let's assume you have written a program for your trusty old C64, and you would
|
|
like to run it. For testing purposes, it should run in the <CODE>RAM</CODE> area. So
|
|
we will start to assign segments to memory sections in the <CODE>SEGMENTS</CODE>
|
|
section:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
SEGMENTS {
|
|
CODE: load = RAM1, type = ro;
|
|
RODATA: load = RAM1, type = ro;
|
|
DATA: load = RAM1, type = rw;
|
|
BSS: load = RAM1, type = bss, define = yes;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>What we are doing here is telling the linker, that all segments go into the
|
|
<CODE>RAM1</CODE> memory area in the order specified in the <CODE>SEGMENTS</CODE> section. So
|
|
the linker will first write the <CODE>CODE</CODE> segment, then the <CODE>RODATA</CODE>
|
|
segment, then the <CODE>DATA</CODE> segment - but it will not write the <CODE>BSS</CODE>
|
|
segment. Why? Enter the segment type: For each segment specified, you may also
|
|
specify a segment attribute. There are five possible segment attributes:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
ro means readonly
|
|
wprot same as ro but will be marked as write protected in
|
|
the VICE label file if -Lp is given
|
|
rw means read/write
|
|
bss means that this is an uninitialized segment
|
|
zp a zeropage segment
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>So, because we specified that the segment with the name BSS is of type bss,
|
|
the linker knows that this is uninitialized data, and will not write it to an
|
|
output file. This is an important point: For the assembler, the <CODE>BSS</CODE>
|
|
segment has no special meaning. You specify, which segments have the bss
|
|
attribute when linking. This approach is much more flexible than having one
|
|
fixed bss segment, and is a result of the design decision to supporting an
|
|
arbitrary segment count.</P>
|
|
<P>If you specify "<CODE>type = bss</CODE>" for a segment, the linker will make sure that
|
|
this segment does only contain uninitialized data (that is, zeroes), and issue
|
|
a warning if this is not the case.</P>
|
|
<P>For a <CODE>bss</CODE> type segment to be useful, it must be cleared somehow by your
|
|
program (this happens usually in the startup code - for example the startup
|
|
code for cc65 generated programs takes care about that). But how does your
|
|
code know, where the segment starts, and how big it is? The linker is able to
|
|
give that information, but you must request it. This is, what we're doing with
|
|
the "<CODE>define = yes</CODE>" attribute in the <CODE>BSS</CODE> definitions. For each
|
|
segment, where this attribute is true, the linker will export three symbols.</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
__NAME_LOAD__ This is set to the address where the
|
|
segment is loaded.
|
|
__NAME_RUN__ This is set to the run address of the
|
|
segment. We will cover run addresses
|
|
later.
|
|
__NAME_SIZE__ This is set to the segment size.
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Replace <CODE>NAME</CODE> by the name of the segment, in the example above, this would
|
|
be <CODE>BSS</CODE>. These symbols may be accessed by your code.</P>
|
|
<P>Now, as we've configured the linker to write the first three segments and
|
|
create symbols for the last one, there's only one question left: Where does
|
|
the linker put the data? It would be very convenient to have the data in a
|
|
file, wouldn't it?</P>
|
|
|
|
<H2><A NAME="ss5.3">5.3</A> <A HREF="ld65.html#toc5.3">Output files</A>
|
|
</H2>
|
|
|
|
|
|
<P>We don't have any files specified above, and indeed, this is not needed in a
|
|
simple configuration like the one above. There is an additional attribute
|
|
"file" that may be specified for a memory area, that gives a file name to
|
|
write the area data into. If there is no file name given, the linker will
|
|
assign the default file name. This is "a.out" or the one given with the
|
|
<CODE>
|
|
<A HREF="ld65-2.html#option-o">-o</A></CODE> option on the command line. Since the
|
|
default behaviour is ok for our purposes, I did not use the attribute in the
|
|
example above. Let's have a look at it now.</P>
|
|
<P>The "file" attribute (the keyword may also be written as "FILE" if you like
|
|
that better) takes a string enclosed in double quotes (`"') that specifies the
|
|
file, where the data is written. You may specify the same file several times,
|
|
in that case the data for all memory areas having this file name is written
|
|
into this file, in the order of the memory areas defined in the <CODE>MEMORY</CODE>
|
|
section. Let's specify some file names in the <CODE>MEMORY</CODE> section used above:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
MEMORY {
|
|
RAM1: start = $0800, size = $9800, file = %O;
|
|
ROM1: start = $A000, size = $2000, file = "rom1.bin";
|
|
RAM2: start = $C000, size = $1000, file = %O;
|
|
ROM2: start = $E000, size = $2000, file = "rom2.bin";
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>The <CODE>%O</CODE> used here is a way to specify the default behaviour explicitly:
|
|
<CODE>%O</CODE> is replaced by a string (including the quotes) that contains the
|
|
default output name, that is, "a.out" or the name specified with the <CODE>
|
|
<A HREF="ld65-2.html#option-o">-o</A></CODE> option on the command line. Into this file, the
|
|
linker will first write any segments that go into <CODE>RAM1</CODE>, and will append
|
|
then the segments for <CODE>RAM2</CODE>, because the memory areas are given in this
|
|
order. So, for the RAM areas, nothing has really changed.</P>
|
|
<P>We've not used the ROM areas, but we will do that below, so we give the file
|
|
names here. Segments that go into <CODE>ROM1</CODE> will be written to a file named
|
|
"rom1.bin", and segments that go into <CODE>ROM2</CODE> will be written to a file
|
|
named "rom2.bin". The name given on the command line is ignored in both cases.</P>
|
|
<P>Assigning an empty file name for a memory area will discard the data written
|
|
to it. This is useful, if the a memory area has segments assigned that are
|
|
empty (for example because they are of type bss). In that case, the linker
|
|
will create an empty output file. This may be suppressed by assigning an empty
|
|
file name to that memory area.</P>
|
|
|
|
|
|
<H2><A NAME="ss5.4">5.4</A> <A HREF="ld65.html#toc5.4">LOAD and RUN addresses (ROMable code)</A>
|
|
</H2>
|
|
|
|
|
|
<P>Let us look now at a more complex example. Say, you've successfully tested
|
|
your new "Super Operating System" (SOS for short) for the C64, and you
|
|
will now go and replace the ROMs by your own code. When doing that, you
|
|
face a new problem: If the code runs in RAM, we need not to care about
|
|
read/write data. But now, if the code is in ROM, we must care about it.
|
|
Remember the default segments (you may of course specify your own):</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
CODE read only code
|
|
RODATA read only data
|
|
DATA read/write data
|
|
BSS uninitialized data, read/write
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Since <CODE>BSS</CODE> is not initialized, we must not care about it now, but what
|
|
about <CODE>DATA</CODE>? <CODE>DATA</CODE> contains initialized data, that is, data that was
|
|
explicitly assigned a value. And your program will rely on these values on
|
|
startup. Since there's no other way to remember the contents of the data
|
|
segment, than storing it into one of the ROMs, we have to put it there. But
|
|
unfortunately, ROM is not writable, so we have to copy it into RAM before
|
|
running the actual code.</P>
|
|
<P>The linker cannot help you copying the data from ROM into RAM (this must be
|
|
done by the startup code of your program), but it has some features that will
|
|
help you in this process.</P>
|
|
<P>First, you may not only specify a "<CODE>load</CODE>" attribute for a segment, but
|
|
also a "<CODE>run</CODE>" attribute. The "<CODE>load</CODE>" attribute is mandatory, and, if
|
|
you don't specify a "<CODE>run</CODE>" attribute, the linker assumes that load area
|
|
and run area are the same. We will use this feature for our data area:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
SEGMENTS {
|
|
CODE: load = ROM1, type = ro;
|
|
RODATA: load = ROM2, type = ro;
|
|
DATA: load = ROM2, run = RAM2, type = rw, define = yes;
|
|
BSS: load = RAM2, type = bss, define = yes;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Let's have a closer look at this <CODE>SEGMENTS</CODE> section. We specify that the
|
|
<CODE>CODE</CODE> segment goes into <CODE>ROM1</CODE> (the one at $A000). The readonly data
|
|
goes into <CODE>ROM2</CODE>. Read/write data will be loaded into <CODE>ROM2</CODE> but is run
|
|
in <CODE>RAM2</CODE>. That means that all references to labels in the <CODE>DATA</CODE>
|
|
segment are relocated to be in <CODE>RAM2</CODE>, but the segment is written to
|
|
<CODE>ROM2</CODE>. All your startup code has to do is, to copy the data from it's
|
|
location in <CODE>ROM2</CODE> to the final location in <CODE>RAM2</CODE>.</P>
|
|
<P>So, how do you know, where the data is located? This is the second point,
|
|
where you get help from the linker. Remember the "<CODE>define</CODE>" attribute?
|
|
Since we have set this attribute to true, the linker will define three
|
|
external symbols for the data segment that may be accessed from your code:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
__DATA_LOAD__ This is set to the address where the segment
|
|
is loaded, in this case, it is an address in
|
|
ROM2.
|
|
__DATA_RUN__ This is set to the run address of the segment,
|
|
in this case, it is an address in RAM2.
|
|
__DATA_SIZE__ This is set to the segment size.
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>So, what your startup code must do, is to copy <CODE>__DATA_SIZE__</CODE> bytes from
|
|
<CODE>__DATA_LOAD__</CODE> to <CODE>__DATA_RUN__</CODE> before any other routines are called.
|
|
All references to labels in the <CODE>DATA</CODE> segment are relocated to <CODE>RAM2</CODE>
|
|
by the linker, so things will work properly.</P>
|
|
|
|
|
|
<H2><A NAME="ss5.5">5.5</A> <A HREF="ld65.html#toc5.5">Other MEMORY area attributes</A>
|
|
</H2>
|
|
|
|
|
|
<P>There are some other attributes not covered above. Before starting the
|
|
reference section, I will discuss the remaining things here.</P>
|
|
<P>You may request symbols definitions also for memory areas. This may be
|
|
useful for things like a software stack, or an i/o area.</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
MEMORY {
|
|
STACK: start = $C000, size = $1000, define = yes;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>This will define three external symbols that may be used in your code:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
__STACK_START__ This is set to the start of the memory
|
|
area, $C000 in this example.
|
|
__STACK_SIZE__ The size of the area, here $1000.
|
|
__STACK_LAST__ This is NOT the same as START+SIZE.
|
|
Instead, it it defined as the first
|
|
address that is not used by data. If we
|
|
don't define any segments for this area,
|
|
the value will be the same as START.
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>A memory section may also have a type. Valid types are</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
ro for readonly memory
|
|
rw for read/write memory.
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>The linker will assure, that no segment marked as read/write or bss is put
|
|
into a memory area that is marked as readonly.</P>
|
|
<P>Unused memory in a memory area may be filled. Use the "<CODE>fill = yes</CODE>"
|
|
attribute to request this. The default value to fill unused space is zero. If
|
|
you don't like this, you may specify a byte value that is used to fill these
|
|
areas with the "<CODE>fillval</CODE>" attribute. This value is also used to fill unfilled
|
|
areas generated by the assemblers <CODE>.ALIGN</CODE> and <CODE>.RES</CODE> directives.</P>
|
|
<P>The symbol <CODE>%S</CODE> may be used to access the default start address (that is,
|
|
the one defined in the
|
|
<A HREF="#FEATURES">FEATURES</A> section, or the
|
|
value given on the command line with the <CODE>
|
|
<A HREF="ld65-2.html#option-S">-S</A></CODE>
|
|
option).</P>
|
|
|
|
|
|
<H2><A NAME="ss5.6">5.6</A> <A HREF="ld65.html#toc5.6">Other SEGMENT attributes</A>
|
|
</H2>
|
|
|
|
|
|
<P>Segments may be aligned to some memory boundary. Specify "<CODE>align = num</CODE>" to
|
|
request this feature. Num must be a power of two. To align all segments on a
|
|
page boundary, use</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
SEGMENTS {
|
|
CODE: load = ROM1, type = ro, align = $100;
|
|
RODATA: load = ROM2, type = ro, align = $100;
|
|
DATA: load = ROM2, run = RAM2, type = rw, define = yes,
|
|
align = $100;
|
|
BSS: load = RAM2, type = bss, define = yes, align = $100;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>If an alignment is requested, the linker will add enough space to the output
|
|
file, so that the new segment starts at an address that is divideable by the
|
|
given number without a remainder. All addresses are adjusted accordingly. To
|
|
fill the unused space, bytes of zero are used, or, if the memory area has a
|
|
"<CODE>fillval</CODE>" attribute, that value. Alignment is always needed, if you have
|
|
the used the <CODE>.ALIGN</CODE> command in the assembler. The alignment of a segment
|
|
must be equal or greater than the alignment used in the <CODE>.ALIGN</CODE> command.
|
|
The linker will check that, and issue a warning, if the alignment of a segment
|
|
is lower than the alignment requested in a <CODE>.ALIGN</CODE> command of one of the
|
|
modules making up this segment.</P>
|
|
<P>For a given segment you may also specify a fixed offset into a memory area or
|
|
a fixed start address. Use this if you want the code to run at a specific
|
|
address (a prominent case is the interrupt vector table which must go at
|
|
address $FFFA). Only one of <CODE>ALIGN</CODE> or <CODE>OFFSET</CODE> or <CODE>START</CODE> may be
|
|
specified. If the directive creates empty space, it will be filled with zero,
|
|
of with the value specified with the "<CODE>fillval</CODE>" attribute if one is given.
|
|
The linker will warn you if it is not possible to put the code at the
|
|
specified offset (this may happen if other segments in this area are too
|
|
large). Here's an example:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
SEGMENTS {
|
|
VECTORS: load = ROM2, type = ro, start = $FFFA;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>or (for the segment definitions from above)</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
SEGMENTS {
|
|
VECTORS: load = ROM2, type = ro, offset = $1FFA;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>The "<CODE>align</CODE>", "<CODE>start</CODE>" and "<CODE>offset</CODE>" attributes change placement
|
|
of the segment in the run memory area, because this is what is usually
|
|
desired. If load and run memory areas are equal (which is the case if only the
|
|
load memory area has been specified), the attributes will also work. There is
|
|
also a "<CODE>align_load</CODE>" attribute that may be used to align the start of the
|
|
segment in the load memory area, in case different load and run areas have
|
|
been specified. There are no special attributes to set start or offset for
|
|
just the load memory area.</P>
|
|
<P>To suppress the warning, the linker issues if it encounters a segment that is
|
|
not found in any of the input files, use "<CODE>optional=yes</CODE>" as additional
|
|
segment attribute. Be careful when using this attribute, because a missing
|
|
segment may be a sign of a problem, and if you're suppressing the warning,
|
|
there is no one left to tell you about it.</P>
|
|
|
|
<H2><A NAME="ss5.7">5.7</A> <A HREF="ld65.html#toc5.7">The FILES section</A>
|
|
</H2>
|
|
|
|
|
|
<P>The <CODE>FILES</CODE> section is used to support other formats than straight binary
|
|
(which is the default, so binary output files do not need an explicit entry
|
|
in the <CODE>FILES</CODE> section).</P>
|
|
<P>The <CODE>FILES</CODE> section lists output files and as only attribute the format of
|
|
each output file. Assigning binary format to the default output file would
|
|
look like this:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
FILES {
|
|
%O: format = bin;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>The only other available output format is the o65 format specified by Andre
|
|
Fachat. It is defined like this:</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
FILES {
|
|
%O: format = o65;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>The necessary o65 attributes are defined in a special section labeled
|
|
<CODE>FORMAT</CODE>.</P>
|
|
|
|
|
|
|
|
<H2><A NAME="ss5.8">5.8</A> <A HREF="ld65.html#toc5.8">The FORMAT section</A>
|
|
</H2>
|
|
|
|
|
|
<P>The <CODE>FORMAT</CODE> section is used to describe file formats. The default (binary)
|
|
format has currently no attributes, so, while it may be listed in this
|
|
section, the attribute list is empty. The second supported format, o65, has
|
|
several attributes that may be defined here.</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
FORMATS {
|
|
o65: os = lunix, version = 0, type = small,
|
|
import = LUNIXKERNEL,
|
|
export = _main;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="FEATURES"></A> <A NAME="ss5.9">5.9</A> <A HREF="ld65.html#toc5.9">The FEATURES section</A>
|
|
</H2>
|
|
|
|
|
|
<P>In addition to the <CODE>MEMORY</CODE> and <CODE>SEGMENTS</CODE> sections described above, the
|
|
linker has features that may be enabled by an additional section labeled
|
|
<CODE>FEATURES</CODE>.</P>
|
|
|
|
|
|
<H3>The CONDES feature</H3>
|
|
|
|
|
|
<P><CODE>CONDES</CODE> is used to tell the linker to emit module constructor/destructor
|
|
tables.</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
FEATURES {
|
|
CONDES: segment = RODATA,
|
|
type = constructor,
|
|
label = __CONSTRUCTOR_TABLE__,
|
|
count = __CONSTRUCTOR_COUNT__;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>The <CODE>CONDES</CODE> feature has several attributes:</P>
|
|
<P>
|
|
<DL>
|
|
|
|
<DT><B><CODE>segment</CODE></B><DD><P>This attribute tells the linker into which segment the table should be
|
|
placed. If the segment does not exist, it is created.</P>
|
|
|
|
|
|
<DT><B><CODE>type</CODE></B><DD><P>Describes the type of the routines to place in the table. Type may be one of
|
|
the predefined types <CODE>constructor</CODE>, <CODE>destructor</CODE>, <CODE>interruptor</CODE>, or
|
|
a numeric value between 0 and 6.</P>
|
|
|
|
|
|
<DT><B><CODE>label</CODE></B><DD><P>This specifies the label to use for the table. The label points to the start
|
|
of the table in memory and may be used from within user written code.</P>
|
|
|
|
|
|
<DT><B><CODE>count</CODE></B><DD><P>This is an optional attribute. If specified, an additional symbol is defined
|
|
by the linker using the given name. The value of this symbol is the number
|
|
of entries (<EM>not</EM> bytes) in the table. While this attribute is optional,
|
|
it is often useful to define it.</P>
|
|
|
|
|
|
<DT><B><CODE>order</CODE></B><DD><P>Optional attribute that takes one of the keywords <CODE>increasing</CODE> or
|
|
<CODE>decreasing</CODE> as an argument. Specifies the sorting order of the entries
|
|
within the table. The default is <CODE>increasing</CODE>, which means that the
|
|
entries are sorted with increasing priority (the first entry has the lowest
|
|
priority). "Priority" is the priority specified when declaring a symbol as
|
|
<CODE>.CONDES</CODE> with the assembler, higher values mean higher priority. You may
|
|
change this behaviour by specifying <CODE>decreasing</CODE> as the argument, the
|
|
order of entries is reversed in this case.</P>
|
|
<P>Please note that the order of entries with equal priority is undefined.</P>
|
|
|
|
</DL>
|
|
</P>
|
|
<P>Without specifying the <CODE>CONDES</CODE> feature, the linker will not create any
|
|
tables, even if there are <CODE>condes</CODE> entries in the object files.</P>
|
|
<P>For more information see the <CODE>.CONDES</CODE> command in the
|
|
<A HREF="ca65.html">ca65 manual</A>.</P>
|
|
|
|
|
|
<H3>The STARTADDRESS feature</H3>
|
|
|
|
|
|
<P><CODE>STARTADDRESS</CODE> is used to set the default value for the start address,
|
|
which can be referenced by the <CODE>%S</CODE> symbol. The builtin default for the
|
|
linker is $200.</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
FEATURES {
|
|
# Default start address is $1000
|
|
STARTADDRESS: default = $1000;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
<P>Please note that order is important: The default start address must be defined
|
|
<EM>before</EM> the <CODE>%S</CODE> symbol is used in the config file. This does usually
|
|
mean, that the <CODE>FEATURES</CODE> section has to go to the top of the config file.</P>
|
|
|
|
|
|
|
|
<H2><A NAME="SYMBOLS"></A> <A NAME="ss5.10">5.10</A> <A HREF="ld65.html#toc5.10">The SYMBOLS section</A>
|
|
</H2>
|
|
|
|
|
|
<P>The configuration file may also be used to define symbols used in the link
|
|
stage. The mandatory attribute for a symbol is its value. A second, boolean
|
|
attribute named <CODE>weak</CODE> is available. If a symbol is marked as weak, it may
|
|
be overridden by defining a symbol of the same name from the command line. The
|
|
default for symbols is that they're strong, which means that an attempt to
|
|
define a symbol with the same name from the command line will lead to an
|
|
error.</P>
|
|
<P>The following example defines the stack size for an application, but allows
|
|
the programmer to override the value by specifying <CODE>--define
|
|
__STACKSIZE__=xxx</CODE> on the command line.</P>
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
SYMBOLS {
|
|
# Define the stack size for the application
|
|
__STACKSIZE__: value = $800, weak = yes;
|
|
}
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
</P>
|
|
|
|
|
|
|
|
<H2><A NAME="ss5.11">5.11</A> <A HREF="ld65.html#toc5.11">Builtin configurations</A>
|
|
</H2>
|
|
|
|
|
|
<P>The builtin configurations are part of the linker source. They are also
|
|
distributed together with the machine specific binary packages (usually in the
|
|
doc directory) and don't have a special format. So if you need a special
|
|
configuration, it's a good idea to start with the builtin configuration for
|
|
your system. In a first step, just replace <CODE>-t target</CODE> by <CODE>-C
|
|
configfile</CODE>. The go on and modify the config file to suit your needs.</P>
|
|
|
|
|
|
|
|
<HR>
|
|
<A HREF="ld65-6.html">Next</A>
|
|
<A HREF="ld65-4.html">Previous</A>
|
|
<A HREF="ld65.html#toc5">Contents</A>
|
|
</BODY>
|
|
</HTML>
|