diff options
Diffstat (limited to 'rdoff/v1/rdf.doc')
| -rw-r--r-- | rdoff/v1/rdf.doc | 99 |
1 files changed, 0 insertions, 99 deletions
diff --git a/rdoff/v1/rdf.doc b/rdoff/v1/rdf.doc deleted file mode 100644 index 300c2bc..0000000 --- a/rdoff/v1/rdf.doc +++ /dev/null @@ -1,99 +0,0 @@ -RDOFF: Relocatable Dynamically-linked Object File Format -======================================================== - -RDOFF was designed initially to test the object-file production -interface to NASM. It soon became apparent that it could be enhanced -for use in serious applications due to its simplicity; code to load -and execute an RDOFF object module is very simple. It also contains -enhancements to allow it to be linked with a dynamic link library at -either run- or load- time, depending on how complex you wish to make -your loader. - -The RDOFF format (version 1.1, as produced by NASM v0.91) is defined -as follows: - -The first six bytes of the file contain the string 'RDOFF1'. Other -versions of the format may contain other last characters other than -'1' - all little endian versions of the file will always contain an -ASCII character with value greater than 32. If RDOFF is used on a -big-endian machine at some point in the future, the version will be -encoded in decimal rather than ASCII, so will be below 32. - -All multi-byte fields follwing this are encoded in either little- or -big-endian format depending on the system described by this version -information. Object files should be encoded in the endianness of -their target machine; files of incorrect endianness will be rejected -by the loader - this means that loaders do not need to convert -endianness, as RDOFF has been designed with simplicity of loading at -the forefront of the design requirements. - -The next 4 byte field is the length of the header in bytes. The -header consists of a sequence of variable length records. Each -record's type is identified by the first byte of the record. Record -types 1-4 are currently supported. Record type 5 will be added in -the near future, when I implement BSS segments. Record type 6 may be -to do with debugging, when I get debugging implemented. - -Type 1: Relocation -================== - -Offset Length Description -0 1 Type (contains 1) -1 1 Segment that contains reference (0 = text, 1 = data) - Add 64 to this number to indicate a relative linkage - to an external symbol (see notes) -2 4 Offset of reference -6 1 Length of reference (1,2 or 4 bytes) -7 2 Segment to which reference is made (0 = text, 1 = - data, 2 = BSS [when implemented]) others are external - symbols. - -Total length = 9 bytes - -Type 2: Symbol Import -===================== - -0 1 Type (2) -1 2 Segment number that will be used in references to this - symbol. -3 ? Null terminated string containing label (up to 32 - chars) to match against exports in linkage. - -Type 3: Symbol Export -===================== - -0 1 Type (3) -1 1 Segment containing object to be exported (0/1/2) -2 4 Offset within segment -6 ? Null terminate string containing label to export (32 - char maximum length) - -Type 4: Dynamic Link Library -============================ - -0 1 Type (4) -1 ? Library name (up to 128 chars) - -Type 5: Reserve BSS -=================== - -0 1 Type (5) -1 4 Amount of BSS space to reserve in bytes - -Total length: 5 bytes - ------------------------------------------------------------------------------ - -Following the header is the text (code) segment. This is preceded by -a 4-byte integer, which is its length in bytes. This is followed by -the length of the data segment (also 4 bytes), and finally the data -segment. - -Notes -===== - -Relative linking: The number stored at the address is offset -required from the imported symbol, with the address of the end of -the instruction subtracted from it. This means that the linker can -simply add the address of the label relative to the beginning of the -current segment to it. |