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.