Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!munnari.oz.au!comp.vuw.ac.nz!kaukau.comp.vuw.ac.nz!waikato!ldo
From: ldo@waikato.ac.nz (Lawrence D'Oliveiro)
Newsgroups: comp.lang.postscript
Subject: Regarding eexec, cexec and other mysteries
Message-ID: <1990Jan8.062339.8718@waikato.ac.nz>
Date: 8 Jan 90 06:23:39 GMT
Distribution: comp.lang.postscript
Organization: University of Waikato
Lines: 27

In article <17491@rpp386.cactus.org>, woody@rpp386.cactus.org (Woodrow Baker)
says

	"The only 2 things that I haven't got down about cexec are how to
	set the  relocation tables up, what they refer to, and some more
	of the system calls."

The relocation table format is very simple. Offset 12 in the header
of the cexec block contains the offset to the relocation table, and offset
14 contains its length in bytes. The table itself is just a sequence
of 16-bit integers, being the offsets from the beginning of the cexec
block of longwords needing relocation. Each longword will have the
base address of the cexec block added to it.

I haven't actually tested this out, as the development system I use
generates position-independent code, so I've never bothered setting
up any relocation tables. But it's an interpretation consistent with
the examples I've examined.

Lawrence D'Oliveiro
Hacker-in-residence
Computer Services Department
University of Waikato
Hamilton, New Zealand
ph:  +64-71-562-889
fax: +64-71-384-066
"I'd rather be hacking than cracking."