Libraries and LWAR

LW Tool Chain
Prev		Next

LW Tool Chain
Prev		Next

LW Tool Chain
Prev

TERMTYPE	Meaning
00	end of expression
01	integer (16 bit in big endian order follows)
02	external symbol reference (NUL terminated symbol name follows)
03	local symbol reference (NUL terminated symbol name follows)
04	operator (1 byte operator number)
05	section base address reference
FF	This term will set flags for the expression. Each one of these terms will set a single flag. All of them should be specified first in an expression. If they are not, the behaviour is undefined. The byte following is the flag. Flag 01 indicates an 8 bit relocation. Flag 02 indicates a zero-width relocation (see the EXTDEP pseudo op in LWASM).

Number	Operator
01	addition (+)
02	subtraction (-)
03	multiplication (*)
04	division (/)
05	modulus (%)
06	integer division (\) (same as division)
07	bitwise and
08	bitwise or
09	bitwise xor
0A	boolean and
0B	boolean or
0C	unary negation, 2's complement (-)
0D	unary 1's complement (^)

LW Tool Chain
Prev

TERMTYPE	Meaning
00	end of expression
01	integer (16 bit in big endian order follows)
02	external symbol reference (NUL terminated symbol name follows)
03	local symbol reference (NUL terminated symbol name follows)
04	operator (1 byte operator number)
05	section base address reference
FF	This term will set flags for the expression. Each one of these terms will set a single flag. All of them should be specified first in an expression. If they are not, the behaviour is undefined. The byte following is the flag. Flag 01 indicates an 8 bit relocation. Flag 02 indicates a zero-width relocation (see the EXTDEP pseudo op in LWASM).

Number	Operator
01	addition (+)
02	subtraction (-)
03	multiplication (*)
04	division (/)
05	modulus (%)
06	integer division (\) (same as division)
07	bitwise and
08	bitwise or
09	bitwise xor
0A	boolean and
0B	boolean or
0C	unary negation, 2's complement (-)
0D	unary 1's complement (^)

LWASM supports generating a proprietary object file format which is described in Chapter 6. LWLINK is then used to link these object files into a final binary in any of LWLINK's supported binary diff -r 7887a48b74df -r d389adbcc4ab docs/manual/x795.html --- a/docs/manual/x795.html Thu Jul 19 13:17:30 2012 -0600 +++ b/docs/manual/x795.html Fri Aug 10 23:47:56 2012 -0600 @@ -17,7 +17,7 @@ HREF="x781.html">Next
define basesympat string
This causes the linker to define a symbol for the ultimate base address of +each section using the pattern specified by string. +In the string, %s can appear exactly once and will be replaced with the +section name. The base address is calculated after all instances of each +section have been collapsed together.
If the pattern resolves to the same string for multiple +sections, the results are undefined.
define lensympat string
This causes the linker to define a symbol for the ultimate length of each +section using the pattern specified by string. In +the string, %s can appear exactly once and will be replaced with the section +name. The length is calculated after all instances of a section have been +collapsed together.
If the pattern resolves to the same string for multiple +sections, the results are undefined.
section nameNext -Format Specific Linking Notes
LW Tool Chain
Prev Chapter 4. LWLINK Next
4.4. Format Specific Linking Notes
Some formats require special information to be able to generate actual -binaries. If the specific format you are interested in is not listed in -this section, then there is nothing special you need to know about to create -a final binary.
4.4.1. OS9 Modules
OS9 modules need to embed several items into the module header. These -items are the type of module, the langauge of the module, the module -attributes, the module revision number, the data size (bss), and the -execution offset. These are all either calculated or default to reasonable -values.
The data size is calcuated as the sum of all sections named "bss" or -".bss" in all object files that are linked together.
The execution offset is calculated from the address of the special -symbol "__start" which must be an exported (external) symbol in one of the -objects to be linked.
The type defaults to "Prgrm" or "Program module". The language -defaults to "Objct" or "6809 object code". Attributes default to enabling -the re-entrant flag. And finally, the revision defaults to zero.
The embedded module name is the output filename. If the output -filename includes more than just the filename, this will probably not be -what you want.
The type, language, attributes, revision, and module name can all be -overridden by providing a special section in exactly one of the object files -to be linked. This section is called "__os9" (note the two underscores). -To override the type, language, attributes, or revision values, define a -non-exported symbol in this section called "type", "lang", "attr", or "rev" -respectively. Any other symbols defined are ignored. To override the -module name, include as the only actual code in the section a NUL terminated -string (the FCN directive is useful for this). If there is no code in the -section or it beings with a NUL, the default name will be used. Any of the -preceeding that are not defined in the special section will retain their -default values.
The built-in link script for OS9 modules will place the following -sections, in order, in the module: "code", ".text", "data", ".data". It -will merge all sections with the name "bss" or ".bss" into the "data" -section. All other section names are ignored. What this means is that you -must define your data variables in the a section called "bss" or ".bss" even -though you will be refencing them all as offsets from U. This does have the -unpleasant side effect that all BSS references will end up being 16 bit -offsets because the assembler cannot know what the offset will be once the -linker is finished its work. Thus, if the tightest possible code is -required, having LWASM directly output the module is a better choice.
While the built-in link script is probably sufficient for most -purposes, you can provide your own script. If you provide a custom link -script, you must start your code and data sections at location 000D to -accommodate the module header. Otherwise, you will have an incorrect -location for the execution offset. You must use the ENTRY directive in the -script to define the entry point for the module.
It should also be obvious from the above that you cannot mix the bss -(rmb) definitions with the module code when linking separately. Those -familiar with typical module creation will probably find this an unpleasant -difference but it is unavoidable.
It should also be noted that direct page references should also be -avoided because you cannot know ahead of time whether the linker is going to -end up putting a particular variable in the first 256 bytes of the module's -data space. If, however, you know for certain you will have less than 256 -bytes of defined data space across all of the object files that will be -linked, you can instead use forced DP addressing for your data addresses -instead of the ,u notation. When linking with 3rd party libraries, this -practice should be avoided. Also, when creating libraries, always use the -offset from U technique.
Prev Home Next
Linking Scripts Up Libraries and LWAR
\ No newline at end of file diff -r 7887a48b74df -r d389adbcc4ab docs/manual/x843.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/manual/x843.html Fri Aug 10 23:47:56 2012 -0600 @@ -0,0 +1,224 @@ + +Format Specific Linking Notes
LW Tool Chain
Prev Chapter 4. LWLINK Next
4.4. Format Specific Linking Notes
Some formats require special information to be able to generate actual +binaries. If the specific format you are interested in is not listed in +this section, then there is nothing special you need to know about to create +a final binary.
4.4.1. OS9 Modules
OS9 modules need to embed several items into the module header. These +items are the type of module, the langauge of the module, the module +attributes, the module revision number, the data size (bss), and the +execution offset. These are all either calculated or default to reasonable +values.
The data size is calcuated as the sum of all sections named "bss" or +".bss" in all object files that are linked together.
The execution offset is calculated from the address of the special +symbol "__start" which must be an exported (external) symbol in one of the +objects to be linked.
The type defaults to "Prgrm" or "Program module". The language +defaults to "Objct" or "6809 object code". Attributes default to enabling +the re-entrant flag. And finally, the revision defaults to zero.
The embedded module name is the output filename. If the output +filename includes more than just the filename, this will probably not be +what you want.
The type, language, attributes, revision, and module name can all be +overridden by providing a special section in exactly one of the object files +to be linked. This section is called "__os9" (note the two underscores). +To override the type, language, attributes, or revision values, define a +non-exported symbol in this section called "type", "lang", "attr", or "rev" +respectively. Any other symbols defined are ignored. To override the +module name, include as the only actual code in the section a NUL terminated +string (the FCN directive is useful for this). If there is no code in the +section or it beings with a NUL, the default name will be used. Any of the +preceeding that are not defined in the special section will retain their +default values.
The built-in link script for OS9 modules will place the following +sections, in order, in the module: "code", ".text", "data", ".data". It +will merge all sections with the name "bss" or ".bss" into the "data" +section. All other section names are ignored. What this means is that you +must define your data variables in the a section called "bss" or ".bss" even +though you will be refencing them all as offsets from U. This does have the +unpleasant side effect that all BSS references will end up being 16 bit +offsets because the assembler cannot know what the offset will be once the +linker is finished its work. Thus, if the tightest possible code is +required, having LWASM directly output the module is a better choice.
While the built-in link script is probably sufficient for most +purposes, you can provide your own script. If you provide a custom link +script, you must start your code and data sections at location 000D to +accommodate the module header. Otherwise, you will have an incorrect +location for the execution offset. You must use the ENTRY directive in the +script to define the entry point for the module.
It should also be obvious from the above that you cannot mix the bss +(rmb) definitions with the module code when linking separately. Those +familiar with typical module creation will probably find this an unpleasant +difference but it is unavoidable.
It should also be noted that direct page references should also be +avoided because you cannot know ahead of time whether the linker is going to +end up putting a particular variable in the first 256 bytes of the module's +data space. If, however, you know for certain you will have less than 256 +bytes of defined data space across all of the object files that will be +linked, you can instead use forced DP addressing for your data addresses +instead of the ,u notation. When linking with 3rd party libraries, this +practice should be avoided. Also, when creating libraries, always use the +offset from U technique.
Prev Home Next
Linking Scripts Up Libraries and LWAR
\ No newline at end of file diff -r 7887a48b74df -r d389adbcc4ab lwlink/link.c --- a/lwlink/link.c Thu Jul 19 13:17:30 2012 -0600 +++ b/lwlink/link.c Fri Aug 10 23:47:56 2012 -0600 @@ -26,6 +26,7 @@ #include #include +#include #include "expr.h" #include "lwlink.h" @@ -37,6 +38,8 @@ static int nforced = 0; static int resolveonly = 0; +symlist_t *symlist = NULL; + void check_section_name(char *name, int *base, fileinfo_t *fn) { int sn; @@ -215,6 +218,58 @@ // theoretically, all the base addresses are set now } +/* run through all sections and generate any synthetic symbols */ +void generate_symbols(void) +{ + int sn; + char *lastsect = NULL; + char sym[256]; + int len; + symlist_t *se; +fprintf(stderr, "Generating symbols\n"); + for (sn = 0; sn < nsects; sn++) + { + fprintf(stderr, "Section %s (%s)\n", sectlist[sn].ptr -> name, lastsect); + if (!lastsect || strcmp(lastsect, (char *)(sectlist[sn].ptr -> name))) + { + if (lastsect && linkscript.lensympat) + { + /* handle length symbol */ + se = lw_alloc(sizeof(symlist_t)); + se -> val = len; + snprintf(sym, 255, linkscript.lensympat, lastsect); + se -> sym = lw_strdup(sym); + se -> next = symlist; + symlist = se; + } + lastsect = (char *)(sectlist[sn].ptr -> name); + len = 0; + /* handle base symbol */ + if (lastsect && linkscript.basesympat) + { + se = lw_alloc(sizeof(symlist_t)); + se -> val = sectlist[sn].ptr -> loadaddress; + snprintf(sym, 255, linkscript.basesympat, lastsect); + se -> sym = lw_strdup(sym); + se -> next = symlist; + symlist = se; + } + } + len += sectlist[sn].ptr -> codesize; + } + if (lastsect && linkscript.lensympat) + { + /* handle length symbol */ + se = lw_alloc(sizeof(symlist_t)); + se -> val = len; + snprintf(sym, 255, linkscript.lensympat, lastsect); + se -> sym = lw_strdup(sym); + se -> next = symlist; + symlist = se; + } + +} + lw_expr_stack_t *find_external_sym_recurse(char *sym, fileinfo_t *fn) { int sn; @@ -350,7 +405,19 @@ } else { + symlist_t *se; + // external symbol + // first look up synthesized symbols + for (se = symlist; se; se = se -> next) + { + if (!strcmp(se -> sym, sym)) + { + val = se -> val; + goto out; + } + } + // read all files in order until found (or not found) if (sect) { diff -r 7887a48b74df -r d389adbcc4ab lwlink/lwlink.h --- a/lwlink/lwlink.h Thu Jul 19 13:17:30 2012 -0600 +++ b/lwlink/lwlink.h Fri Aug 10 23:47:56 2012 -0600 @@ -157,10 +157,24 @@ int modattr; // module attributes int modrev; // module revision char *name; // module name + char *basesympat; // pattern for section base symbol (%s for section name) + char *lensympat; // pattern for section length symbol (%s for section name) } linkscript_t; #ifndef __script_c_seen__ extern linkscript_t linkscript; #endif +typedef struct symlist_s symlist_t; + +struct symlist_s +{ + char *sym; + int val; + symlist_t *next; + +}; + +extern symlist_t *symlist; + #endif //__lwlink_h_seen__ diff -r 7887a48b74df -r d389adbcc4ab lwlink/main.c --- a/lwlink/main.c Thu Jul 19 13:17:30 2012 -0600 +++ b/lwlink/main.c Fri Aug 10 23:47:56 2012 -0600 @@ -165,6 +165,7 @@ extern void setup_script(void); extern void resolve_files(void); extern void resolve_sections(void); +extern void generate_symbols(void); extern void resolve_references(void); extern void do_output(void); extern void display_map(void); @@ -196,6 +197,9 @@ // resolve section bases and section order resolve_sections(); + + // generate symbols + generate_symbols(); // resolve incomplete references resolve_references(); diff -r 7887a48b74df -r d389adbcc4ab lwlink/map.c --- a/lwlink/map.c Thu Jul 19 13:17:30 2012 -0600 +++ b/lwlink/map.c Fri Aug 10 23:47:56 2012 -0600 @@ -48,6 +48,7 @@ struct symliste *ce, *pe, *ne; symtab_t *sym; int i; + symlist_t *se; if (!strcmp(map_file, "-")) { @@ -77,6 +78,31 @@ } // generate a sorted list of symbols and display it + + for (se = symlist; se; se = se -> next) + { + for (pe = NULL, ce = slist; ce; ce = ce -> next) + { + i = strcmp(ce -> name, se -> sym); + if (i > 0) + { + break; + } + pe = ce; + } + + ne = lw_alloc(sizeof(struct symliste)); + ne -> ext = 1; + ne -> addr = se -> val; + ne -> next = ce; + ne -> name = se -> sym; + ne -> fn = ""; + if (pe) + pe -> next = ne; + else + slist = ne; + } + for (sn = 0; sn < nsects; sn++) { for (sym = sectlist[sn].ptr -> localsyms; sym; sym = sym -> next) diff -r 7887a48b74df -r d389adbcc4ab lwlink/script.c --- a/lwlink/script.c Thu Jul 19 13:17:30 2012 -0600 +++ b/lwlink/script.c Fri Aug 10 23:47:56 2012 -0600 @@ -35,6 +35,8 @@ // the built-in OS9 script // the 000D bit is to handle the module header! static char *os9_script = + "define basesympat s_%s\n" + "define lensympat l_%s\n" "section code load 000D\n" "section .text\n" "section data\n" @@ -46,6 +48,8 @@ // the built-in DECB target linker script static char *decb_script = + "define basesympat s_%s\n" + "define lensympat l_%s\n" "section init load 2000\n" "section code\n" "section *,!bss\n" @@ -55,6 +59,8 @@ // the built-in RAW target linker script static char *raw_script = + "define basesympat s_%s\n" + "define lensympat l_%s\n" "section init load 0000\n" "section code\n" "section *,!bss\n" @@ -62,6 +68,8 @@ ; static char *lwex0_script = + "define basesympat s_%s\n" + "define lensympat l_%s\n" "section init load 0100\n" "section .text\n" "section .data\n" @@ -79,6 +87,8 @@ // the "simple" script static char *simple_script = + "define basesympat s_%s\n" + "define lensympat l_%s\n" "section *,!bss\n" "section *,bss\n" ; @@ -216,7 +226,38 @@ for ( ; *ptr && isspace(*ptr); ptr++) /* do nothing */ ; - if (!strcmp(line, "pad")) + if (!strcmp(line, "define")) + { + // parse out the definition type + for (ptr2 = ptr; *ptr2 && !isspace(*ptr2); ptr2++) + /* do nothing */ ; + + if (*ptr2) + *ptr2++ = '\0'; + + while (*ptr2 && isspace(*ptr2)) + ptr2++; + + // now ptr points to the define type + if (!strcmp(ptr, "basesympat")) + { + /* section base symbol pattern */ + lw_free(linkscript.basesympat); + linkscript.basesympat = lw_strdup(ptr2); + } + else if (!strcmp(ptr, "lensympat")) + { + /* section length symbol pattern */ + lw_free(linkscript.lensympat); + linkscript.lensympat = lw_strdup(ptr2); + } + else + { + fprintf(stderr, "%s: bad script line: %s\n", scriptfile, line); + exit(1); + } + } + else if (!strcmp(line, "pad")) { // padding // parse the hex number and stow it

Chapter 5. Libraries and LWAR

5.1. Command Line Options

Chapter 5. Libraries and LWAR

5.1. Command Line Options

Chapter 6. Object Files

Chapter 6. Object Files

4.4. Format Specific Linking Notes

4.4.1. OS9 Modules

Chapter 5. Libraries and LWAR

5.1. Command Line Options

4.4. Format Specific Linking Notes

4.4.1. OS9 Modules

4.4. Format Specific Linking Notes

4.4.1. OS9 Modules