1 The RDOFF version 1.1 Object File Format
2 ========================================
4 I seem to keep writing this document... I don't know what keeps
5 happening to it. Anyway, this one will hopefully stay around for a
8 RDOFF is a relocatable object file format whose design goals were
9 mainly to keep it simple, so that an RDOFF object can be loaded and
10 executed by a very small piece of code (primarily so that it can be
11 used by the microkernel of an operating system to store system
12 modules, which can then go on to load and execute more complex object
13 files, eg ELF, if so desired), yet still be able to be cope with
14 everything required by the operating system; linkage of multiple
15 modules together (possibly with automatic loading of new libraries
16 that are referred to by the object) at load time, allowing static or
17 dynamic linking as required by the application.
19 The overall format of the file is summarised in this table:
21 Length (bytes) Description
22 6 Contains the string 'RDOFF1' (little-endian targets),
23 or 'RDOFF' followed by the single byte 0x01
25 4 Length of the header section
26 ? Header section (see above for length)
27 4 Length of code section (.text)
29 4 Length of data section (.data)
32 Segments are referred to as numbers. Imported labels are implicitly
33 at offset zero from a segment; each is assigned a segment number when
34 it is imported. Segments in the object file itself are numbered:
39 The header consists of a sequence of records, each of which is
40 preceded by a byte to represent its type.
42 These records are one of the following types:
47 This record points to an address that will need either
48 relocation or linkage to an external segment when the object
52 1 Type identifier (must be 1)
53 1 Segment number (0 or 1) plus 64 if the reference is
54 relative (and thus does not require relocation with
55 the base of the code, only by the difference between
56 the start of this segment, and the segment referred to
58 4 Offset from start of segment of item requiring reloc.
59 1 Length of item (1, 2, or 4 bytes...)
60 2 Segment number to which reference is made.
62 2: Import Symbol Record
63 -----------------------
65 This record defines a segment to start at the location of a
66 named symbol; this symbol may need to be fetched from an
70 1 Type identifier (must be 2)
71 2 Segment number to allocate
72 ? String containing label (null terminated, max length =
75 3: Export Symbol Record
76 -----------------------
78 This record defines a symbol, to which external modules can
79 link using the above record type.
82 1 Type identifier (must be 3)
83 1 Segment containing symbol (0,1 or 2)
84 4 Offset of symbol within segment
85 ? String containing label (null terminated, max length =
88 4: Import Library Record
89 ------------------------
91 This record tells the loader that an extra library should be
92 loaded and linked to the module at either load- or run-time
93 (load time is easier, run-time is good, though...)
96 1 Type identifier (must be 4)
97 ? Name of library (null terminated string, max len = 128)
102 This record tells the loader how much memory to reserve after
103 the executable code loaded from the object file for the BSS
104 segment (referred to as segment number 2).
105 A loader can safely assume that there will only be one of
106 these records per module, but the linker probably cannot...
107 NASM will only output one, but other utilities may be written
108 that do, and future versions of NASM may output more than one.
111 1 Type identifier (must be 5)
112 4 Number of bytes to reserve