--- a/doc/lwlink.txt	Thu Jan 22 02:05:08 2009 +0000
+++ b/doc/lwlink.txt	Thu Jan 22 02:05:30 2009 +0000
@@ -38,10 +38,10 @@
 
 Raw: this is a raw binary with no header information, etc. Suitable for ROM
 images, etc. By default, the raw target starts the binary at address 0, puts
-any section named "init" first, then "code" and/or "text", then all other
-non-bss sections, then all bss sections. Note that any "bss" type section
-that exists anywhere but at the end of the binary (i.e. is between or before
-one or more non-bss sections) will be included as a series of NUL bytes.
+any section named "init" first, then "code", then all other non-bss
+sections, then all bss sections. Note that any "bss" type section that
+exists anywhere but at the end of the binary (i.e. is between or before one
+or more non-bss sections) will be included as a series of NUL bytes.
 
 DECB: this creates a LOADM style binary according to the linker script. By
 default, this target places the sections in the same order as the raw target

--- a/doc/scripts.txt	Thu Jan 22 02:05:08 2009 +0000
+++ b/doc/scripts.txt	Thu Jan 22 02:05:30 2009 +0000
@@ -6,10 +6,18 @@
 section not referenced by a directive is assumed to be loaded after the
 final section explicitly referenced.
 
+The sections will appear in the resulting binary in the order they are
+specified in the script file.
+
+If a referenced section is not found, the linker will behave as though the
+section did exist but had a zero size, no relocations, and no exports.
+
 A section may only be referenced once. Any subsequent references will have
 no effect.
 
-section <name> load at <addr>
+All numbers are hexadecimal.
+
+section <name> load <addr>
 
 This causes the section <name> to load at <addr>. For raw target, only one
 "load at" entry is allowed for non-bss sections and it must be the first
@@ -18,19 +26,28 @@
 load addresses but since they will not appear in the binary anyway, this is
 okay.
 
-For the DECB target, each "load at" entry will cause a new "block" to be
+For the DECB target, each "load" entry will cause a new "block" to be
 output to the binary which will contain the load address. It is legal for
 sections to overlap in this manner - the linker assumes the loader will sort
 everything out.
 
-section <name> load after <name2>
+section <name>
+
+This will cause the section <name> to load after the previously listed
+section.
+
+exec <addr or sym>
 
-This will cause the section <name> to load after <name2>. This has the
-effect of essentially gluing <name> onto the end of <name2>. If multiple
-sections are specified to load after a particular section, they will load in
-the order specified.
+This will cause the execution address (entry point) to be the address
+specified (in hex) *or* the specified symbol name. The symbol name must
+match a symbol that is exported by one of the object files being linked.
+This has no effect for targets that do not encode the entry point into the
+resulting file. If not specified, the entry point is assumed to be address 0
+which is probably not what you want. The default link scripts for targets
+that support this directive automatically starts at the beginning of the
+first section (usually "init" or "code") that is emitted in the binary.
 
-pad to <size>
+pad <size>
 
 This will cause the output file to be padded with NUL bytes to be exactly
 <size> bytes in length. This only makes sense for a raw target.