mirror of
https://github.com/netwide-assembler/nasm.git
synced 2024-11-27 08:10:07 +08:00
63 lines
2.7 KiB
Plaintext
63 lines
2.7 KiB
Plaintext
Differences between RDOFF versions 1 & 2
|
|
========================================
|
|
|
|
This document is designed primarily for people maintaining code which
|
|
uses RDOFF version 1, and would like to upgrade that code to work
|
|
with version 2.
|
|
|
|
The main changes are summarised here:
|
|
|
|
Overall format
|
|
==============
|
|
|
|
The overall format has changed somewhat since version 1, in order
|
|
to make RDOFF more flexible. After the file type identifier (which
|
|
has been changed to 'RDOFF2', obviously), there is now a 4 byte
|
|
integer describing the length of the object module. This allows
|
|
multiple objects to be concatenated, while the loader can easily
|
|
build an index of the locations of each object. This isn't as
|
|
pointless as it sounds; I'm using RDOFF in a microkernel operating
|
|
system, and this is the ideal way of loading multiple driver modules
|
|
at boot time.
|
|
|
|
There are also no longer a fixed number of segments; instead there
|
|
is a list of segments, immediately following the header.
|
|
Each segment is preceded by a 10 byte header giving information about
|
|
that segment. This header has the following format:
|
|
|
|
Length Description
|
|
2 Type
|
|
2 Number
|
|
2 Reserved
|
|
4 Length
|
|
|
|
'Type' is a number describing what sort of segment it is (eg text, data,
|
|
comment, debug info). See 'rdoff2.txt' for a list of the segment types.
|
|
'Number' is the number used to refer to the segment in the header records.
|
|
Not all segments will be loaded; it is only intended that one code
|
|
and one data segment will be loaded into memory. It is possible, however,
|
|
for a loaded segment to contain a reference to an unloaded segment.
|
|
This is an error, and should be flagged at load time. Or maybe you should
|
|
load the segment... its up to you, really.
|
|
|
|
The segment's data immediately follows the end of the segment header.
|
|
|
|
HEADER RECORDS
|
|
==============
|
|
|
|
All of the header records have changed in this version, but not
|
|
substantially. Each record type has had a content-length code added,
|
|
a single byte immediately following the type byte. This contains the
|
|
length of the rest of the record (excluding the type and length bytes,
|
|
but including the terminating nulls on any strings in the record).
|
|
|
|
There are two new record types, Segment Relocation (6), and FAR import (7).
|
|
The record formats are identical to Relocation (1) and import (2). They are
|
|
only of real use on systems using segmented architectures. Systems using
|
|
a flat model should treat FAR import (7) exactly the same as an import (2),
|
|
and should either flag segment relocation as an error, or attempt to figure
|
|
out whether it is a reference to a code or data symbol, and set the value
|
|
referenced to the according selector value. I am opting for the former
|
|
approach, and would recommend that others working on 32 bit flat systems
|
|
do the same.
|