Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.sys.next
Subject: portable a.out formats [was ABI a.out format used with NeXT]
Message-ID: <23314@amdcad.AMD.COM>
Date: 20 Oct 88 16:51:40 GMT
References: <7558@bloom-beacon.MIT.EDU> <909@goofy.megatest.UUCP>
Sender: news@amdcad.AMD.COM
Reply-To: tim@crackle.amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 32
Summary:
Expires:
Sender:
Followup-To:

In article <909@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
| Even *Sun* binaries are not the same as Sun binaries, or so I heard
| today.  A fellow told me that the RISC a.out format for sun-4 is
| incompatible with Unix (bsd) a.out format, which is what sun-3 uses.
| He was steamed because a linker I had written and put in the public
| domain would not work on his new machine.  Wanted to know if I had
| Sun-4 version.

It is very hard to create a truly portable object file format that can
work on all machines.  The problem is the relocation info.  Most of the
"standard" object file formats (like the BSD a.out or COFF) only define
relocation types that were needed on architectures like VAX or 680x0
(i.e. direct or PC-relative 8, 16, and 32-bit references).  However, new
architectures require different relocation types.

For example, most RISC processors load a full 32-bit constant with a
sequence of two instructions, like

	const	lr0, extern_value	; load low 16 bits
	consth	lr0, extern_value	; load hi 16 bits

Now we need a relocation type that can take a 32-bit absolute address
and stuff the upper half into an instruction.

Because of this, most vendors extend a.out or COFF to fit their
requirements.  A fully portable object file format would require a
general-purpose linker "evaluation language" which allows not only +/-,
but also <<, >>, &, |, etc.


	-- Tim Olson
	Advanced Micro Devices
	(tim@crackle.amd.com)