编译器/解释器

开发平台：
C/C++

rdoff.txt：源码内容
							The RDOFF version 1.1 Object File Format
========================================
I seem to keep writing this document... I don't know what keeps
happening to it. Anyway, this one will hopefully stay around for a
while.
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

						