diff options
Diffstat (limited to 'rdoff/Changes')
| -rw-r--r-- | rdoff/Changes | 63 |
1 files changed, 0 insertions, 63 deletions
diff --git a/rdoff/Changes b/rdoff/Changes deleted file mode 100644 index 34163a9..0000000 --- a/rdoff/Changes +++ /dev/null @@ -1,63 +0,0 @@ -Differences between RDOFF versions 1 & 2 -======================================== - -This document is designed primarily for people maintaining code which -uses RDOFF version 1, and would like to upgrade that code to work -with version 2. - -The main changes are summarised here: - -Overall format -============== - -The overall format has changed somewhat since version 1, in order -to make RDOFF more flexible. After the file type identifier (which -has been changed to 'RDOFF2', obviously), there is now a 4 byte -integer describing the length of the object module. This allows -multiple objects to be concatenated, while the loader can easily -build an index of the locations of each object. This isn't as -pointless as it sounds; I'm using RDOFF in a microkernel operating -system, and this is the ideal way of loading multiple driver modules -at boot time. - -There are also no longer a fixed number of segments; instead there -is a list of segments, immediately following the header. -Each segment is preceded by a 10 byte header giving information about -that segment. This header has the following format: - -Length Description -2 Type -2 Number -2 Reserved -4 Length - -'Type' is a number describing what sort of segment it is (eg text, data, -comment, debug info). See 'rdoff2.txt' for a list of the segment types. -'Number' is the number used to refer to the segment in the header records. -Not all segments will be loaded; it is only intended that one code -and one data segment will be loaded into memory. It is possible, however, -for a loaded segment to contain a reference to an unloaded segment. -This is an error, and should be flagged at load time. Or maybe you should -load the segment... its up to you, really. - -The segment's data immediately follows the end of the segment header. - -HEADER RECORDS -============== - -All of the header records have changed in this version, but not -substantially. Each record type has had a content-length code added, -a single byte immediately following the type byte. This contains the -length of the rest of the record (excluding the type and length bytes, -but including the terminating nulls on any strings in the record). - -There are two new record types, Segment Relocation (6), and FAR import (7). -The record formats are identical to Relocation (1) and import (2). They are -only of real use on systems using segmented architectures. Systems using -a flat model should treat FAR import (7) exactly the same as an import (2), -and should either flag segment relocation as an error, or attempt to figure -out whether it is a reference to a code or data symbol, and set the value -referenced to the according selector value. I am opting for the former -approach, and would recommend that others working on 32 bit flat systems -do the same. - |