145 lines
5.5 KiB
Plaintext
145 lines
5.5 KiB
Plaintext
|
(This file is under construction.)
|
||
|
|
||
|
|
||
|
The Code Pedigree of This Directory
|
||
|
|
||
|
|
||
|
This directory contains a big merge of several development lines of
|
||
|
gas as well as a few bug fixes and some configuration that I've added
|
||
|
in order to retain my own sanity.
|
||
|
|
||
|
A little history.
|
||
|
|
||
|
The only common baseline of all versions was gas-1.31.
|
||
|
|
||
|
From 1.31, Intel branched off and added:
|
||
|
|
||
|
support for the Intel 80960 (i960) processor.
|
||
|
support for b.out object files.
|
||
|
some bug fixes.
|
||
|
sloppy mac MPW support
|
||
|
Intel gnu/960 makefiles and version numbering.
|
||
|
|
||
|
Many of the bug fixes found their way into the main development line
|
||
|
prior to 1.36. ALL intel changes were ifdef'd I80960. This was good
|
||
|
as it isolated the changes, but bad in that it connected the b.out
|
||
|
support to the i960 support, and bad in that the bug fixes were only
|
||
|
active in the i960+b.out executables of gas, (although most of these
|
||
|
were nicely marked with comments indicating that they were probably
|
||
|
general bug fixes.)
|
||
|
|
||
|
To pick up the main FSF development line again, along the way to 1.36,
|
||
|
several new processors were added, many bugs fixed, and the world was
|
||
|
a somewhat better place in general.
|
||
|
|
||
|
From gas-1.36, Loic at Axis Design (france!) encapsulated object
|
||
|
format specific actions, added coff versions of those encapsulations,
|
||
|
and a config.gas style configuration and Makefile. This was a big
|
||
|
change and a lot of work.
|
||
|
|
||
|
Then along came the FIRST FSF release of gas-1.37. I say this because
|
||
|
there have been at least two releases of gas-1.37. Only two of them
|
||
|
do we care about for this story, so let's call them gas-1.37.1 and
|
||
|
gas-1.37.2.
|
||
|
|
||
|
Here starts the confusion. Firstly, gas-1.37.1 did not compile.
|
||
|
|
||
|
In the meantime, John Gilmore at Cygnus Support had been hacking
|
||
|
gas-1.37.1. He got it to compile. He added support for the AMD 29000
|
||
|
processor. AND he started encapsulating some of the a.out specific
|
||
|
pieces of code mostly into functions. AND he rebuilt the relocation
|
||
|
info to be generic. AND he restructured somewhat so that for a single
|
||
|
host, cross assemblers could be built for all targets in the same
|
||
|
directory. Useful work but a considerable nuisance because the a29k
|
||
|
changes were not partitioned from the encapsulation changes, the
|
||
|
encapsulation changes were incomplete, and the encapsulation required
|
||
|
functions where alternate structuring might have used macros. Let's
|
||
|
call this version gas-1.37.1+a29k.
|
||
|
|
||
|
By the time gas-1.37.2 was "released", (remember that it TOO was
|
||
|
labelled by FSF as gas-1.37), it compiled, but it also added i860
|
||
|
support and ansi style const declarations.
|
||
|
|
||
|
At this point, Loic rolled his changes into gas-1.37.2.
|
||
|
|
||
|
What I've done.
|
||
|
|
||
|
I collected all the stray versions of gas that sounded relevant to my
|
||
|
goals of cross assembly and alternate object file formats and the FSF
|
||
|
releases from which the stray versions had branched.
|
||
|
|
||
|
I rolled the Intel i960 changes from 1.31 into versions that I call
|
||
|
1.34+i960, 1.36+i960, and then 1.37.1+i960.
|
||
|
|
||
|
Then I merged 1.37.1+i960 with 1.37.1+a29k to produce what I call
|
||
|
1.37.1+i960+a29k or 1.37.3.
|
||
|
|
||
|
From 1.37.3, I pulled in Loic's stuff. This wasn't easy as Loic's
|
||
|
stuff hit all the same points as John's encapsulations. Loic's goal
|
||
|
was to split the a.out from coff dependancies for native assembly on
|
||
|
coff, while John's was to split for multiple cross assembly from a
|
||
|
single host.
|
||
|
|
||
|
Loic's config arranged files much like emacs into m-*, etc. I've
|
||
|
rearranged these somewhat.
|
||
|
|
||
|
Theory:
|
||
|
|
||
|
The goal of the new configuration scheme is to bury all object format,
|
||
|
target processor, and host machine dependancies in object, target, and
|
||
|
host specific files. That is, to move all #ifdef's out of the gas
|
||
|
common code.
|
||
|
|
||
|
Here's how it works. There is a .h and a .c file for each object file
|
||
|
format, a .h and a .c file for each target processor, and a .h for
|
||
|
each host. config.gas creates {sym}links in the current directory to
|
||
|
the appropriate files in the config directory. config.gas also serves
|
||
|
as a list of triplets {host, target, object-format} that have been
|
||
|
tested at one time or another. I also recommend that config.gas be
|
||
|
used to document triplet specific notes as to purpose of the triplet,
|
||
|
etc.
|
||
|
|
||
|
Implementation:
|
||
|
|
||
|
host.h is a {sym}link to .../config/xm-yourhost.h. It is intended to
|
||
|
be used to hide host compiler, system header file, and system library
|
||
|
differences between host machines. If your host needs actual c source
|
||
|
files, then either: these are generally useful functions, in which
|
||
|
case you should probably build a local library outside of the gas
|
||
|
source tree, or someone, perhaps me, is confused about what is needed
|
||
|
by different hosts.
|
||
|
|
||
|
obj-format.h is a {sym}link to .../config/obj-something.h. It is intended
|
||
|
|
||
|
All gas .c files include as.h.
|
||
|
|
||
|
as.h #define's "gas", includes host.h, defines a number of gas
|
||
|
specific structures and types, and then includes tp.h, obj.h, and
|
||
|
target-environment.h.
|
||
|
|
||
|
target-environment.h defines a target environment specific
|
||
|
preprocessor flag, eg, TE_SUN, and then includes obj-format.h.
|
||
|
|
||
|
obj-format.h defines an object format specific preprocessor flag, eg,
|
||
|
OBJ_AOUT, OBJ_BOUT, OBJ_COFF, includes "target-processor.h", and then
|
||
|
defines the object specific macros, functions, types, and structures.
|
||
|
|
||
|
target-processor.h
|
||
|
|
||
|
target-processor.
|
||
|
|
||
|
Porting:
|
||
|
|
||
|
There appear to be four major types of ports; new hosts, new target
|
||
|
processors, new object file formats, and new target environments.
|
||
|
|
||
|
|
||
|
-----
|
||
|
|
||
|
reloc now stored internally as generic. (symbols too?) (segment types
|
||
|
vs. names?)
|
||
|
|
||
|
I don't mean to overlook anyone here. There have also been several
|
||
|
other development lines here that I looked at and elected to bypass.
|
||
|
Specifically, xxx's stabs in coff stuff was particularly tempting.
|