mirror of
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git
synced 2024-12-27 05:21:08 +01:00
850a26162a
of binutils. For all architectures and object file formats, ".p2align n" aligns to the next multiple of 2**n. Thus for FreeBSD, it does exactly the same thing as the traditional ".align". The old ".align" directive has different meanings in different object formats, and even in different variants of a.out. Sometimes is aligns to a multiple of n, and other times it aligns to a multiple of 2**n. ".p2align" is preferable for use in assembly language sources, since it makes them more portable to object formats other than a.out. |
||
---|---|---|
.. | ||
config | ||
doc | ||
opcode | ||
testscripts | ||
app.c | ||
as.1 | ||
as.1aout | ||
as.c | ||
as.h | ||
atof-generic.c | ||
bignum-copy.c | ||
bignum.h | ||
bit_fix.h | ||
ChangeLog | ||
cond.c | ||
config-gas.com | ||
configdos.bat | ||
configure.in | ||
CONTRIBUTORS | ||
COPYING | ||
debug.c | ||
expr.c | ||
expr.h | ||
flo-const.c | ||
flo-copy.c | ||
flonum-mult.c | ||
flonum.h | ||
frags.c | ||
frags.h | ||
gas-format.el | ||
hash.c | ||
hash.h | ||
hex-value.c | ||
input-file.c | ||
input-file.h | ||
input-scrub.c | ||
link.cmd | ||
listing.c | ||
listing.h | ||
make-gas.com | ||
Makefile | ||
makefile.dos | ||
Makefile.in | ||
messages.c | ||
NOTES | ||
NOTES.config | ||
obj.h | ||
obstack.c | ||
obstack.h | ||
output-file.c | ||
output-file.h | ||
read.c | ||
read.h | ||
README | ||
README-vms | ||
README.coff | ||
README.pic | ||
README.rich | ||
struc-symbol.h | ||
subsegs.c | ||
subsegs.h | ||
symbols.c | ||
symbols.h | ||
tc.h | ||
VERSION | ||
version.c | ||
write.c | ||
write.h | ||
xmalloc.c | ||
xrealloc.c |
This is a pre-alpha version of the GNU assembler, version 1.92.3. (this is a copy of the mail announcement. Real README follows below.) This session I merged the m88k support. It configures, builds, and assembles things, including some gcc2 output. I have no way of knowing if the output is right. I've merged the tahoe support. It configures and builds. I couldn't build the cygnus version of gcc2 for this machine, so I have no idea whether gas is assembling anything at all for it. I've walked through my bug and patch archives. Gas now makes a tolerable guess at a.out headers for hpux and sequent, although I have no way to know if these are right yet. Ming tran-le's changes for 386aix will probably drop out soon. He needs multiple segments and I don't plan to get that in before the real release. Eric youngdale's help with vms has been invaluable. According to him, this gas is doing vms. I didn't quite get a cross to vms working and don't plan to spend any more time on it. The gas manual is included in the distribution, configuration, and Makefiles. It should build, be printable, and readable through info. I have not yet verified that this gas has all of the unreleased changes that hack made after the last gas release. At this point I plan to ignore these until those bugs are re-reported in an alpha or full release I don't think it's worth my time. I have not yet verified any hosts other than sun4, although I have three-staged sun3 native. I have not updated the configuration doc. I do not plan to bring in any new backends for the upcoming release unless someone hands them to me on a platter as eric did for vms. I merged the m88k and tahoe ports because they were simple for me at this point, but would have been difficult for someone else. I may yet do this for the ncube support as well. I've looked at the osf stuff and discarded it for this release. I'm not sure I like what they've done for macho object format and without macho headers, I can't even build their version. I've looked at the utah stuff and discarded it for this release. They, too, have made some sweeping changes to support their object format that I'm not sure were necessary. In any case, merging this would be too much work for me right now. I've looked at the tron port. It's remarkably clean and it's a.out format. I don't plan to merge this for the full release for two reasons. First, it's so clean, they will be able to add their stuff on top and build a seperate distribution without much trouble. Second, I'm get responses from them, and hope that they will be able to do the merge. To do before alpha: * merge patches and address bugs as they arrive. * kill a remaining bug. The following input: .text a .word 3 b .word 4 c .half b-a kills most risc ports. I believe that this represents a failing of the internal representation of relocs (aka fixS's). The fix is relatively straightforward and I intend to make it. * add autoconf style configuration for hosts (not targets). * test via three-staging (preferably with gcc2) on all a.out based machines to which I have access. * update/clean out README's and build a brief porting guide. There is still a copyright issue on the coff back end, so it may need to be pulled for the full release. If this gets resolved, I hope to see coff run personally on at least one native machine before full release. Real README: This is a pre-alpha version of the GNU assembler, version 1.92.3. A number of things have changed and the wonderful world of gas looks very different. There's still a lot of irrelevant garbage lying around that will be cleaned up soon. The gas manual now builds and installs, but internal documentation is still scarce, as are logs of the changes made since the last gas release. My apologies, and I'll try to get something useful At this point I believe gas to be ansi only code for most target cpu's. That is, there should be relatively few, if any host system dependencies. Most of my recent effort has been spent testing and dusting off ports for which Cygnus hasn't had recent need. Hosting has recently been tested on only: sun4 sun3 I believe that gas can currently be targetted for: sun4 sun3 and "ports" for other cpu's and object file formats from the following set are probably trivial at this point: a.out a29k i386 i860 i960 m68k m88k ns32k tahoe sparc vax I have tested most of these in "generic" a.out configurations so I feel pretty confident in them. If anything else works, it's an accident. Some ports now generate object files that are somewhat differently shaped, but should be more correct. Specifically: * Most a.out ports now sort the relocation table in numerically ascending order. In previous versions of gas, the relocation table was sorted in descending order. To get the previous functionality, compile with -DREVERSE_SORT_RELOCS. * ns32k: The last gas I have from hack simply looks broken for ns32k. I think this one works, but don't have an assembler that I trust against which to compare. * i386: now uses ".align x" to mean x bytes rather than 2^x bytes. It also pads with the noop instruction rather than zeroes. In all cases, compiling with -DOLD_GAS will produce an assembler that should produce object files that are bitwise identical to the previous version of gas. NEW FEATURES! This isn't a complete catalog. I've forgotten what all has been done. * support for i960, a29k, m88k, and tahoe. * support for 68030 and 68040, including the ability to limit the instructions that gas will accept. ie, you can assemble for EXACTLY 68000 and no more. * object file formats have been broken out into separate backends. * a new "backend" has been created to represent the target environment. That is, gas now mimics various other assemblers rather than creating it's own requirements. A side effect of this is that this version of gas may not behave the same way as previous versions. * ansi. gas is now strictly ansi code so host ports should be trivial. REPORTING BUGS IN GAS Bugs in THIS RELEASE of gas should be reported directly to rich@cygnus.com. NOT to bug-gnu-utils@prep.ai.mit.edu. If you report a bug in GAS, please remember to include: A description of exactly what went wrong. How GAS was configured, The Operating System GAS was running under. The options given to GAS. The actual input file that caused the problem. It is silly to report a bug in GAS without including an input file for GAS. Don't ask us to generate the file just because you made it from files you think we have access to. 1. You might be mistaken. 2. It might take us a lot of time to install things to regenerate that file. 3. We might get a different file from the one you got, and might not see any bug. To save us these delays and uncertainties, always send the input file for the program that failed. If the input file is very large, and you are on the internet, you may want to make it avaliable for anonymous FTP instead of mailing it. If you do, include instructions for FTP'ing it in your bug report.