diff options
Diffstat (limited to 'rdoff/rdf.doc')
| -rw-r--r-- | rdoff/rdf.doc | 99 |
1 files changed, 99 insertions, 0 deletions
diff --git a/rdoff/rdf.doc b/rdoff/rdf.doc new file mode 100644 index 00000000..300c2bc5 --- /dev/null +++ b/rdoff/rdf.doc @@ -0,0 +1,99 @@ +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. |