Commit | Line | Data |
---|---|---|
0e39a8bb RP |
1 | |
2 | ||
3 | The Code Pedigree of This Directory | |
4 | ||
5 | ||
6 | This directory contains a big merge of several development lines of | |
7 | gas as well as a few bug fixes and some configuration that I've added | |
8 | in order to retain my own sanity. | |
9 | ||
10 | A little history. | |
11 | ||
12 | The only common baseline of all versions was gas-1.31. | |
13 | ||
14 | From 1.31, Intel branched off and added: | |
15 | ||
16 | support for the Intel 80960 (i960) processor. | |
17 | support for b.out object files. | |
18 | some bug fixes. | |
19 | sloppy mac MPW support | |
20 | Intel gnu/960 makefiles and version numbering. | |
21 | ||
22 | Many of the bug fixes found their way into the main development line | |
23 | prior to 1.36. ALL intel changes were ifdef'd I80960. This was good | |
24 | as it isolated the changes, but bad in that it connected the b.out | |
25 | support to the i960 support, and bad in that the bug fixes were only | |
26 | active in the i960+b.out executables of gas, (although most of these | |
27 | were nicely marked with comments indicating that they were probably | |
28 | general bug fixes.) | |
29 | ||
30 | To pick up the main FSF development line again, along the way to 1.36, | |
31 | several new processors were added, many bugs fixed, and the world was | |
32 | a somewhat better place in general. | |
33 | ||
34 | From gas-1.36, Loic at Axis Design (france!) encapsulated object | |
35 | format specific actions, added coff versions of those encapsulations, | |
36 | and a config.gas style configuration and Makefile. This was a big | |
37 | change and a lot of work. | |
38 | ||
39 | Then along came the FIRST FSF release of gas-1.37. I say this because | |
40 | there have been at least two releases of gas-1.37. Only two of them | |
41 | do we care about for this story, so let's call them gas-1.37.1 and | |
42 | gas-1.37.2. | |
43 | ||
44 | Here starts the confusion. Firstly, gas-1.37.1 did not compile. | |
45 | ||
46 | In the meantime, John Gilmore at Cygnus Support had been hacking | |
47 | gas-1.37.1. He got it to compile. He added support for the AMD 29000 | |
48 | processor. AND he started encapsulating some of the a.out specific | |
49 | pieces of code mostly into functions. AND he rebuilt the relocation | |
50 | info to be generic. AND he restructured somewhat so that for a single | |
51 | host, cross assemblers could be built for all targets in the same | |
52 | directory. Useful work but a considerable nuisance because the a29k | |
53 | changes were not partitioned from the encapsulation changes, the | |
54 | encapsulation changes were incomplete, and the encapsulation required | |
55 | functions where alternate structuring might have used macros. Let's | |
56 | call this version gas-1.37.1+a29k. | |
57 | ||
58 | By the time gas-1.37.2 was "released", (remember that it TOO was | |
59 | labelled by FSF as gas-1.37), it compiled, but it also added i860 | |
60 | support and ansi style const declarations. | |
61 | ||
62 | At this point, Loic rolled his changes into gas-1.37.2. | |
63 | ||
64 | What I've done. | |
65 | ||
66 | I collected all the stray versions of gas that sounded relevant to my | |
67 | goals of cross assembly and alternate object file formats and the FSF | |
68 | releases from which the stray versions had branched. | |
69 | ||
70 | I rolled the Intel i960 changes from 1.31 into versions that I call | |
71 | 1.34+i960, 1.36+i960, and then 1.37.1+i960. | |
72 | ||
73 | Then I merged 1.37.1+i960 with 1.37.1+a29k to produce what I call | |
74 | 1.37.1+i960+a29k or 1.37.3. | |
75 | ||
76 | From 1.37.3, I pulled in Loic's stuff. This wasn't easy as Loic's | |
77 | stuff hit all the same points as John's encapsulations. Loic's goal | |
78 | was to split the a.out from coff dependancies for native assembly on | |
79 | coff, while John's was to split for multiple cross assembly from a | |
80 | single host. | |
81 | ||
82 | Loic's config arranged files much like emacs into m-*, etc. I've | |
83 | rearranged these somewhat. | |
84 | ||
85 | Theory: | |
86 | ||
87 | The goal of the new configuration scheme is to bury all object format, | |
88 | target processor, and host machine dependancies in object, target, and | |
89 | host specific files. That is, to move all #ifdef's out of the gas | |
90 | common code. | |
91 | ||
92 | Here's how it works. There is a .h and a .c file for each object file | |
93 | format, a .h and a .c file for each target processor, and a .h for | |
94 | each host. config.gas creates {sym}links in the current directory to | |
95 | the appropriate files in the config directory. config.gas also serves | |
96 | as a list of triplets {host, target, object-format} that have been | |
97 | tested at one time or another. I also recommend that config.gas be | |
98 | used to document triplet specific notes as to purpose of the triplet, | |
99 | etc. | |
100 | ||
101 | Implementation: | |
102 | ||
103 | host.h is a {sym}link to .../config/xm-yourhost.h. It is intended to | |
104 | be used to hide host compiler, system header file, and system library | |
105 | differences between host machines. If your host needs actual c source | |
106 | files, then either: these are generally useful functions, in which | |
107 | case you should probably build a local library outside of the gas | |
108 | source tree, or someone, perhaps me, is confused about what is needed | |
109 | by different hosts. | |
110 | ||
111 | obj-format.h is a {sym}link to .../config/obj-something.h. It is intended | |
112 | ||
113 | All gas .c files include as.h. | |
114 | ||
115 | as.h #define's "gas", includes host.h, defines a number of gas | |
116 | specific structures and types, and then includes tp.h, obj.h, and | |
117 | target-environment.h. | |
118 | ||
119 | target-environment.h defines a target environment specific | |
120 | preprocessor flag, eg, TE_SUN, and then includes obj-format.h. | |
121 | ||
122 | obj-format.h defines an object format specific preprocessor flag, eg, | |
123 | OBJ_AOUT, OBJ_BOUT, OBJ_COFF, includes "target-processor.h", and then | |
124 | defines the object specific macros, functions, types, and structures. | |
125 | ||
126 | target-processor.h | |
127 | ||
128 | target-processor. | |
129 | ||
130 | Porting: | |
131 | ||
132 | There appear to be four major types of ports; new hosts, new target | |
133 | processors, new object file formats, and new target environments. | |
134 | ||
135 | ||
136 | ----- | |
137 | ||
138 | reloc now stored internally as generic. (symbols too?) (segment types | |
139 | vs. names?) | |
140 | ||
141 | I don't mean to overlook anyone here. There have also been several | |
142 | other development lines here that I looked at and elected to bypass. | |
143 | Specifically, xxx's stabs in coff stuff was particularly tempting. |