1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
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.
|
