The RDOFF version 1.1 Object File Format ======================================== RDOFF is a relocatable object file format whose design goals were mainly to keep it simple, so that an RDOFF object can be loaded and executed by a very small piece of code (primarily so that it can be used by the microkernel of an operating system to store system modules, which can then go on to load and execute more complex object files, eg ELF, if so desired), yet still be able to be cope with everything required by the operating system; linkage of multiple modules together (possibly with automatic loading of new libraries that are referred to by the object) at load time, allowing static or dynamic linking as required by the application. The overall format of the file is summarised in this table: Length (bytes) Description 6 Contains the string 'RDOFF1' (little-endian targets), or 'RDOFF' followed by the single byte 0x01 (big-endian targets). 4 Length of the header section ? Header section (see above for length) 4 Length of code section (.text) ? Code section 4 Length of data section (.data) ? Data section Segments are referred to as numbers. Imported labels are implicitly at offset zero from a segment; each is assigned a segment number when it is imported. Segments in the object file itself are numbered: 0 - text segemnt 1 - data segment 2 - bss segment The header consists of a sequence of records, each of which is preceded by a byte to represent its type. These records are one of the following types: 1: Relocation Record -------------------- This record points to an address that will need either relocation or linkage to an external segment when the object is loaded or linked. Length Description 1 Type identifier (must be 1) 1 Segment number (0 or 1) plus 64 if the reference is relative (and thus does not require relocation with the base of the code, only by the difference between the start of this segment, and the segment referred to (see below) 4 Offset from start of segment of item requiring reloc. 1 Length of item (1, 2, or 4 bytes...) 2 Segment number to which reference is made. 2: Import Symbol Record ----------------------- This record defines a segment to start at the location of a named symbol; this symbol may need to be fetched from an external library. Length Description 1 Type identifier (must be 2) 2 Segment number to allocate ? String containing label (null terminated, max length = 32 chars) 3: Export Symbol Record ----------------------- This record defines a symbol, to which external modules can link using the above record type. Length Description 1 Type identifier (must be 3) 1 Segment containing symbol (0,1 or 2) 4 Offset of symbol within segment ? String containing label (null terminated, max length = 32 chars) 4: Import Library Record ------------------------ This record tells the loader that an extra library should be loaded and linked to the module at either load- or run-time (load time is easier, run-time is good, though...) Length Description 1 Type identifier (must be 4) ? Name of library (null terminated string, max len = 128) 5: Reserve BSS Bytes -------------------- This record tells the loader how much memory to reserve after the executable code loaded from the object file for the BSS segment (referred to as segment number 2). A loader can safely assume that there will only be one of these records per module, but the linker probably cannot... NASM will only output one, but other utilities may be written that do, and future versions of NASM may output more than one. Length Description 1 Type identifier (must be 5) 4 Number of bytes to reserve