| This is as.info, produced by makeinfo version 4.3 from as.texinfo. |
| |
| START-INFO-DIR-ENTRY |
| * As: (as). The GNU assembler. |
| * Gas: (as). The GNU assembler. |
| END-INFO-DIR-ENTRY |
| |
| This file documents the GNU Assembler "as". |
| |
| Copyright (C) 1991, 92, 93, 94, 95, 96, 97, 98, 99, 2000, 2001, 2002 |
| Free Software Foundation, Inc. |
| |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.1 or |
| any later version published by the Free Software Foundation; with no |
| Invariant Sections, with no Front-Cover Texts, and with no Back-Cover |
| Texts. A copy of the license is included in the section entitled "GNU |
| Free Documentation License". |
| |
| |
| File: as.info, Node: VAX-Opts, Next: VAX-float, Up: Vax-Dependent |
| |
| VAX Command-Line Options |
| ------------------------ |
| |
| The Vax version of `as' accepts any of the following options, gives |
| a warning message that the option was ignored and proceeds. These |
| options are for compatibility with scripts designed for other people's |
| assemblers. |
| |
| ``-D' (Debug)' |
| ``-S' (Symbol Table)' |
| ``-T' (Token Trace)' |
| These are obsolete options used to debug old assemblers. |
| |
| ``-d' (Displacement size for JUMPs)' |
| This option expects a number following the `-d'. Like options |
| that expect filenames, the number may immediately follow the `-d' |
| (old standard) or constitute the whole of the command line |
| argument that follows `-d' (GNU standard). |
| |
| ``-V' (Virtualize Interpass Temporary File)' |
| Some other assemblers use a temporary file. This option commanded |
| them to keep the information in active memory rather than in a |
| disk file. `as' always does this, so this option is redundant. |
| |
| ``-J' (JUMPify Longer Branches)' |
| Many 32-bit computers permit a variety of branch instructions to |
| do the same job. Some of these instructions are short (and fast) |
| but have a limited range; others are long (and slow) but can |
| branch anywhere in virtual memory. Often there are 3 flavors of |
| branch: short, medium and long. Some other assemblers would emit |
| short and medium branches, unless told by this option to emit |
| short and long branches. |
| |
| ``-t' (Temporary File Directory)' |
| Some other assemblers may use a temporary file, and this option |
| takes a filename being the directory to site the temporary file. |
| Since `as' does not use a temporary disk file, this option makes |
| no difference. `-t' needs exactly one filename. |
| |
| The Vax version of the assembler accepts additional options when |
| compiled for VMS: |
| |
| `-h N' |
| External symbol or section (used for global variables) names are |
| not case sensitive on VAX/VMS and always mapped to upper case. |
| This is contrary to the C language definition which explicitly |
| distinguishes upper and lower case. To implement a standard |
| conforming C compiler, names must be changed (mapped) to preserve |
| the case information. The default mapping is to convert all lower |
| case characters to uppercase and adding an underscore followed by |
| a 6 digit hex value, representing a 24 digit binary value. The |
| one digits in the binary value represent which characters are |
| uppercase in the original symbol name. |
| |
| The `-h N' option determines how we map names. This takes several |
| values. No `-h' switch at all allows case hacking as described |
| above. A value of zero (`-h0') implies names should be upper |
| case, and inhibits the case hack. A value of 2 (`-h2') implies |
| names should be all lower case, with no case hack. A value of 3 |
| (`-h3') implies that case should be preserved. The value 1 is |
| unused. The `-H' option directs `as' to display every mapped |
| symbol during assembly. |
| |
| Symbols whose names include a dollar sign `$' are exceptions to the |
| general name mapping. These symbols are normally only used to |
| reference VMS library names. Such symbols are always mapped to |
| upper case. |
| |
| `-+' |
| The `-+' option causes `as' to truncate any symbol name larger |
| than 31 characters. The `-+' option also prevents some code |
| following the `_main' symbol normally added to make the object |
| file compatible with Vax-11 "C". |
| |
| `-1' |
| This option is ignored for backward compatibility with `as' |
| version 1.x. |
| |
| `-H' |
| The `-H' option causes `as' to print every symbol which was |
| changed by case mapping. |
| |
| |
| File: as.info, Node: VAX-float, Next: VAX-directives, Prev: VAX-Opts, Up: Vax-Dependent |
| |
| VAX Floating Point |
| ------------------ |
| |
| Conversion of flonums to floating point is correct, and compatible |
| with previous assemblers. Rounding is towards zero if the remainder is |
| exactly half the least significant bit. |
| |
| `D', `F', `G' and `H' floating point formats are understood. |
| |
| Immediate floating literals (_e.g._ `S`$6.9') are rendered |
| correctly. Again, rounding is towards zero in the boundary case. |
| |
| The `.float' directive produces `f' format numbers. The `.double' |
| directive produces `d' format numbers. |
| |
| |
| File: as.info, Node: VAX-directives, Next: VAX-opcodes, Prev: VAX-float, Up: Vax-Dependent |
| |
| Vax Machine Directives |
| ---------------------- |
| |
| The Vax version of the assembler supports four directives for |
| generating Vax floating point constants. They are described in the |
| table below. |
| |
| `.dfloat' |
| This expects zero or more flonums, separated by commas, and |
| assembles Vax `d' format 64-bit floating point constants. |
| |
| `.ffloat' |
| This expects zero or more flonums, separated by commas, and |
| assembles Vax `f' format 32-bit floating point constants. |
| |
| `.gfloat' |
| This expects zero or more flonums, separated by commas, and |
| assembles Vax `g' format 64-bit floating point constants. |
| |
| `.hfloat' |
| This expects zero or more flonums, separated by commas, and |
| assembles Vax `h' format 128-bit floating point constants. |
| |
| |
| File: as.info, Node: VAX-opcodes, Next: VAX-branch, Prev: VAX-directives, Up: Vax-Dependent |
| |
| VAX Opcodes |
| ----------- |
| |
| All DEC mnemonics are supported. Beware that `case...' instructions |
| have exactly 3 operands. The dispatch table that follows the `case...' |
| instruction should be made with `.word' statements. This is compatible |
| with all unix assemblers we know of. |
| |
| |
| File: as.info, Node: VAX-branch, Next: VAX-operands, Prev: VAX-opcodes, Up: Vax-Dependent |
| |
| VAX Branch Improvement |
| ---------------------- |
| |
| Certain pseudo opcodes are permitted. They are for branch |
| instructions. They expand to the shortest branch instruction that |
| reaches the target. Generally these mnemonics are made by substituting |
| `j' for `b' at the start of a DEC mnemonic. This feature is included |
| both for compatibility and to help compilers. If you do not need this |
| feature, avoid these opcodes. Here are the mnemonics, and the code |
| they can expand into. |
| |
| `jbsb' |
| `Jsb' is already an instruction mnemonic, so we chose `jbsb'. |
| (byte displacement) |
| `bsbb ...' |
| |
| (word displacement) |
| `bsbw ...' |
| |
| (long displacement) |
| `jsb ...' |
| |
| `jbr' |
| `jr' |
| Unconditional branch. |
| (byte displacement) |
| `brb ...' |
| |
| (word displacement) |
| `brw ...' |
| |
| (long displacement) |
| `jmp ...' |
| |
| `jCOND' |
| COND may be any one of the conditional branches `neq', `nequ', |
| `eql', `eqlu', `gtr', `geq', `lss', `gtru', `lequ', `vc', `vs', |
| `gequ', `cc', `lssu', `cs'. COND may also be one of the bit tests |
| `bs', `bc', `bss', `bcs', `bsc', `bcc', `bssi', `bcci', `lbs', |
| `lbc'. NOTCOND is the opposite condition to COND. |
| (byte displacement) |
| `bCOND ...' |
| |
| (word displacement) |
| `bNOTCOND foo ; brw ... ; foo:' |
| |
| (long displacement) |
| `bNOTCOND foo ; jmp ... ; foo:' |
| |
| `jacbX' |
| X may be one of `b d f g h l w'. |
| (word displacement) |
| `OPCODE ...' |
| |
| (long displacement) |
| OPCODE ..., foo ; |
| brb bar ; |
| foo: jmp ... ; |
| bar: |
| |
| `jaobYYY' |
| YYY may be one of `lss leq'. |
| |
| `jsobZZZ' |
| ZZZ may be one of `geq gtr'. |
| (byte displacement) |
| `OPCODE ...' |
| |
| (word displacement) |
| OPCODE ..., foo ; |
| brb bar ; |
| foo: brw DESTINATION ; |
| bar: |
| |
| (long displacement) |
| OPCODE ..., foo ; |
| brb bar ; |
| foo: jmp DESTINATION ; |
| bar: |
| |
| `aobleq' |
| `aoblss' |
| `sobgeq' |
| `sobgtr' |
| |
| (byte displacement) |
| `OPCODE ...' |
| |
| (word displacement) |
| OPCODE ..., foo ; |
| brb bar ; |
| foo: brw DESTINATION ; |
| bar: |
| |
| (long displacement) |
| OPCODE ..., foo ; |
| brb bar ; |
| foo: jmp DESTINATION ; |
| bar: |
| |
| |
| File: as.info, Node: VAX-operands, Next: VAX-no, Prev: VAX-branch, Up: Vax-Dependent |
| |
| VAX Operands |
| ------------ |
| |
| The immediate character is `$' for Unix compatibility, not `#' as |
| DEC writes it. |
| |
| The indirect character is `*' for Unix compatibility, not `@' as DEC |
| writes it. |
| |
| The displacement sizing character is ``' (an accent grave) for Unix |
| compatibility, not `^' as DEC writes it. The letter preceding ``' may |
| have either case. `G' is not understood, but all other letters (`b i l |
| s w') are understood. |
| |
| Register names understood are `r0 r1 r2 ... r15 ap fp sp pc'. Upper |
| and lower case letters are equivalent. |
| |
| For instance |
| tstb *w`$4(r5) |
| |
| Any expression is permitted in an operand. Operands are comma |
| separated. |
| |
| |
| File: as.info, Node: VAX-no, Prev: VAX-operands, Up: Vax-Dependent |
| |
| Not Supported on VAX |
| -------------------- |
| |
| Vax bit fields can not be assembled with `as'. Someone can add the |
| required code if they really need it. |
| |
| |
| File: as.info, Node: V850-Dependent, Next: Z8000-Dependent, Prev: Sparc-Dependent, Up: Machine Dependencies |
| |
| v850 Dependent Features |
| ======================= |
| |
| * Menu: |
| |
| * V850 Options:: Options |
| * V850 Syntax:: Syntax |
| * V850 Floating Point:: Floating Point |
| * V850 Directives:: V850 Machine Directives |
| * V850 Opcodes:: Opcodes |
| |
| |
| File: as.info, Node: V850 Options, Next: V850 Syntax, Up: V850-Dependent |
| |
| Options |
| ------- |
| |
| `as' supports the following additional command-line options for the |
| V850 processor family: |
| |
| `-wsigned_overflow' |
| Causes warnings to be produced when signed immediate values |
| overflow the space available for then within their opcodes. By |
| default this option is disabled as it is possible to receive |
| spurious warnings due to using exact bit patterns as immediate |
| constants. |
| |
| `-wunsigned_overflow' |
| Causes warnings to be produced when unsigned immediate values |
| overflow the space available for then within their opcodes. By |
| default this option is disabled as it is possible to receive |
| spurious warnings due to using exact bit patterns as immediate |
| constants. |
| |
| `-mv850' |
| Specifies that the assembled code should be marked as being |
| targeted at the V850 processor. This allows the linker to detect |
| attempts to link such code with code assembled for other |
| processors. |
| |
| `-mv850e' |
| Specifies that the assembled code should be marked as being |
| targeted at the V850E processor. This allows the linker to detect |
| attempts to link such code with code assembled for other |
| processors. |
| |
| `-mv850any' |
| Specifies that the assembled code should be marked as being |
| targeted at the V850 processor but support instructions that are |
| specific to the extended variants of the process. This allows the |
| production of binaries that contain target specific code, but |
| which are also intended to be used in a generic fashion. For |
| example libgcc.a contains generic routines used by the code |
| produced by GCC for all versions of the v850 architecture, |
| together with support routines only used by the V850E architecture. |
| |
| |
| File: as.info, Node: V850 Syntax, Next: V850 Floating Point, Prev: V850 Options, Up: V850-Dependent |
| |
| Syntax |
| ------ |
| |
| * Menu: |
| |
| * V850-Chars:: Special Characters |
| * V850-Regs:: Register Names |
| |
| |
| File: as.info, Node: V850-Chars, Next: V850-Regs, Up: V850 Syntax |
| |
| Special Characters |
| .................. |
| |
| `#' is the line comment character. |
| |
| |
| File: as.info, Node: V850-Regs, Prev: V850-Chars, Up: V850 Syntax |
| |
| Register Names |
| .............. |
| |
| `as' supports the following names for registers: |
| `general register 0' |
| r0, zero |
| |
| `general register 1' |
| r1 |
| |
| `general register 2' |
| r2, hp |
| |
| `general register 3' |
| r3, sp |
| |
| `general register 4' |
| r4, gp |
| |
| `general register 5' |
| r5, tp |
| |
| `general register 6' |
| r6 |
| |
| `general register 7' |
| r7 |
| |
| `general register 8' |
| r8 |
| |
| `general register 9' |
| r9 |
| |
| `general register 10' |
| r10 |
| |
| `general register 11' |
| r11 |
| |
| `general register 12' |
| r12 |
| |
| `general register 13' |
| r13 |
| |
| `general register 14' |
| r14 |
| |
| `general register 15' |
| r15 |
| |
| `general register 16' |
| r16 |
| |
| `general register 17' |
| r17 |
| |
| `general register 18' |
| r18 |
| |
| `general register 19' |
| r19 |
| |
| `general register 20' |
| r20 |
| |
| `general register 21' |
| r21 |
| |
| `general register 22' |
| r22 |
| |
| `general register 23' |
| r23 |
| |
| `general register 24' |
| r24 |
| |
| `general register 25' |
| r25 |
| |
| `general register 26' |
| r26 |
| |
| `general register 27' |
| r27 |
| |
| `general register 28' |
| r28 |
| |
| `general register 29' |
| r29 |
| |
| `general register 30' |
| r30, ep |
| |
| `general register 31' |
| r31, lp |
| |
| `system register 0' |
| eipc |
| |
| `system register 1' |
| eipsw |
| |
| `system register 2' |
| fepc |
| |
| `system register 3' |
| fepsw |
| |
| `system register 4' |
| ecr |
| |
| `system register 5' |
| psw |
| |
| `system register 16' |
| ctpc |
| |
| `system register 17' |
| ctpsw |
| |
| `system register 18' |
| dbpc |
| |
| `system register 19' |
| dbpsw |
| |
| `system register 20' |
| ctbp |
| |
| |
| File: as.info, Node: V850 Floating Point, Next: V850 Directives, Prev: V850 Syntax, Up: V850-Dependent |
| |
| Floating Point |
| -------------- |
| |
| The V850 family uses IEEE floating-point numbers. |
| |
| |
| File: as.info, Node: V850 Directives, Next: V850 Opcodes, Prev: V850 Floating Point, Up: V850-Dependent |
| |
| V850 Machine Directives |
| ----------------------- |
| |
| `.offset <EXPRESSION>' |
| Moves the offset into the current section to the specified amount. |
| |
| `.section "name", <type>' |
| This is an extension to the standard .section directive. It sets |
| the current section to be <type> and creates an alias for this |
| section called "name". |
| |
| `.v850' |
| Specifies that the assembled code should be marked as being |
| targeted at the V850 processor. This allows the linker to detect |
| attempts to link such code with code assembled for other |
| processors. |
| |
| `.v850e' |
| Specifies that the assembled code should be marked as being |
| targeted at the V850E processor. This allows the linker to detect |
| attempts to link such code with code assembled for other |
| processors. |
| |
| |
| File: as.info, Node: V850 Opcodes, Prev: V850 Directives, Up: V850-Dependent |
| |
| Opcodes |
| ------- |
| |
| `as' implements all the standard V850 opcodes. |
| |
| `as' also implements the following pseudo ops: |
| |
| `hi0()' |
| Computes the higher 16 bits of the given expression and stores it |
| into the immediate operand field of the given instruction. For |
| example: |
| |
| `mulhi hi0(here - there), r5, r6' |
| |
| computes the difference between the address of labels 'here' and |
| 'there', takes the upper 16 bits of this difference, shifts it |
| down 16 bits and then mutliplies it by the lower 16 bits in |
| register 5, putting the result into register 6. |
| |
| `lo()' |
| Computes the lower 16 bits of the given expression and stores it |
| into the immediate operand field of the given instruction. For |
| example: |
| |
| `addi lo(here - there), r5, r6' |
| |
| computes the difference between the address of labels 'here' and |
| 'there', takes the lower 16 bits of this difference and adds it to |
| register 5, putting the result into register 6. |
| |
| `hi()' |
| Computes the higher 16 bits of the given expression and then adds |
| the value of the most significant bit of the lower 16 bits of the |
| expression and stores the result into the immediate operand field |
| of the given instruction. For example the following code can be |
| used to compute the address of the label 'here' and store it into |
| register 6: |
| |
| `movhi hi(here), r0, r6' `movea lo(here), r6, r6' |
| |
| The reason for this special behaviour is that movea performs a sign |
| extention on its immediate operand. So for example if the address |
| of 'here' was 0xFFFFFFFF then without the special behaviour of the |
| hi() pseudo-op the movhi instruction would put 0xFFFF0000 into r6, |
| then the movea instruction would takes its immediate operand, |
| 0xFFFF, sign extend it to 32 bits, 0xFFFFFFFF, and then add it |
| into r6 giving 0xFFFEFFFF which is wrong (the fifth nibble is E). |
| With the hi() pseudo op adding in the top bit of the lo() pseudo |
| op, the movhi instruction actually stores 0 into r6 (0xFFFF + 1 = |
| 0x0000), so that the movea instruction stores 0xFFFFFFFF into r6 - |
| the right value. |
| |
| `hilo()' |
| Computes the 32 bit value of the given expression and stores it |
| into the immediate operand field of the given instruction (which |
| must be a mov instruction). For example: |
| |
| `mov hilo(here), r6' |
| |
| computes the absolute address of label 'here' and puts the result |
| into register 6. |
| |
| `sdaoff()' |
| Computes the offset of the named variable from the start of the |
| Small Data Area (whoes address is held in register 4, the GP |
| register) and stores the result as a 16 bit signed value in the |
| immediate operand field of the given instruction. For example: |
| |
| `ld.w sdaoff(_a_variable)[gp],r6' |
| |
| loads the contents of the location pointed to by the label |
| '_a_variable' into register 6, provided that the label is located |
| somewhere within +/- 32K of the address held in the GP register. |
| [Note the linker assumes that the GP register contains a fixed |
| address set to the address of the label called '__gp'. This can |
| either be set up automatically by the linker, or specifically set |
| by using the `--defsym __gp=<value>' command line option]. |
| |
| `tdaoff()' |
| Computes the offset of the named variable from the start of the |
| Tiny Data Area (whoes address is held in register 30, the EP |
| register) and stores the result as a 4,5, 7 or 8 bit unsigned |
| value in the immediate operand field of the given instruction. |
| For example: |
| |
| `sld.w tdaoff(_a_variable)[ep],r6' |
| |
| loads the contents of the location pointed to by the label |
| '_a_variable' into register 6, provided that the label is located |
| somewhere within +256 bytes of the address held in the EP |
| register. [Note the linker assumes that the EP register contains |
| a fixed address set to the address of the label called '__ep'. |
| This can either be set up automatically by the linker, or |
| specifically set by using the `--defsym __ep=<value>' command line |
| option]. |
| |
| `zdaoff()' |
| Computes the offset of the named variable from address 0 and |
| stores the result as a 16 bit signed value in the immediate |
| operand field of the given instruction. For example: |
| |
| `movea zdaoff(_a_variable),zero,r6' |
| |
| puts the address of the label '_a_variable' into register 6, |
| assuming that the label is somewhere within the first 32K of |
| memory. (Strictly speaking it also possible to access the last |
| 32K of memory as well, as the offsets are signed). |
| |
| `ctoff()' |
| Computes the offset of the named variable from the start of the |
| Call Table Area (whoes address is helg in system register 20, the |
| CTBP register) and stores the result a 6 or 16 bit unsigned value |
| in the immediate field of then given instruction or piece of data. |
| For example: |
| |
| `callt ctoff(table_func1)' |
| |
| will put the call the function whoes address is held in the call |
| table at the location labeled 'table_func1'. |
| |
| For information on the V850 instruction set, see `V850 Family |
| 32-/16-Bit single-Chip Microcontroller Architecture Manual' from NEC. |
| Ltd. |
| |
| |
| File: as.info, Node: Reporting Bugs, Next: Acknowledgements, Prev: Machine Dependencies, Up: Top |
| |
| Reporting Bugs |
| ************** |
| |
| Your bug reports play an essential role in making `as' reliable. |
| |
| Reporting a bug may help you by bringing a solution to your problem, |
| or it may not. But in any case the principal function of a bug report |
| is to help the entire community by making the next version of `as' work |
| better. Bug reports are your contribution to the maintenance of `as'. |
| |
| In order for a bug report to serve its purpose, you must include the |
| information that enables us to fix the bug. |
| |
| * Menu: |
| |
| * Bug Criteria:: Have you found a bug? |
| * Bug Reporting:: How to report bugs |
| |
| |
| File: as.info, Node: Bug Criteria, Next: Bug Reporting, Up: Reporting Bugs |
| |
| Have you found a bug? |
| ===================== |
| |
| If you are not sure whether you have found a bug, here are some |
| guidelines: |
| |
| * If the assembler gets a fatal signal, for any input whatever, that |
| is a `as' bug. Reliable assemblers never crash. |
| |
| * If `as' produces an error message for valid input, that is a bug. |
| |
| * If `as' does not produce an error message for invalid input, that |
| is a bug. However, you should note that your idea of "invalid |
| input" might be our idea of "an extension" or "support for |
| traditional practice". |
| |
| * If you are an experienced user of assemblers, your suggestions for |
| improvement of `as' are welcome in any case. |
| |
| |
| File: as.info, Node: Bug Reporting, Prev: Bug Criteria, Up: Reporting Bugs |
| |
| How to report bugs |
| ================== |
| |
| A number of companies and individuals offer support for GNU |
| products. If you obtained `as' from a support organization, we |
| recommend you contact that organization first. |
| |
| You can find contact information for many support companies and |
| individuals in the file `etc/SERVICE' in the GNU Emacs distribution. |
| |
| In any event, we also recommend that you send bug reports for `as' |
| to `bug-binutils@gnu.org'. |
| |
| The fundamental principle of reporting bugs usefully is this: |
| *report all the facts*. If you are not sure whether to state a fact or |
| leave it out, state it! |
| |
| Often people omit facts because they think they know what causes the |
| problem and assume that some details do not matter. Thus, you might |
| assume that the name of a symbol you use in an example does not matter. |
| Well, probably it does not, but one cannot be sure. Perhaps the bug |
| is a stray memory reference which happens to fetch from the location |
| where that name is stored in memory; perhaps, if the name were |
| different, the contents of that location would fool the assembler into |
| doing the right thing despite the bug. Play it safe and give a |
| specific, complete example. That is the easiest thing for you to do, |
| and the most helpful. |
| |
| Keep in mind that the purpose of a bug report is to enable us to fix |
| the bug if it is new to us. Therefore, always write your bug reports |
| on the assumption that the bug has not been reported previously. |
| |
| Sometimes people give a few sketchy facts and ask, "Does this ring a |
| bell?" Those bug reports are useless, and we urge everyone to _refuse |
| to respond to them_ except to chide the sender to report bugs properly. |
| |
| To enable us to fix the bug, you should include all these things: |
| |
| * The version of `as'. `as' announces it if you start it with the |
| `--version' argument. |
| |
| Without this, we will not know whether there is any point in |
| looking for the bug in the current version of `as'. |
| |
| * Any patches you may have applied to the `as' source. |
| |
| * The type of machine you are using, and the operating system name |
| and version number. |
| |
| * What compiler (and its version) was used to compile `as'--e.g. |
| "`gcc-2.7'". |
| |
| * The command arguments you gave the assembler to assemble your |
| example and observe the bug. To guarantee you will not omit |
| something important, list them all. A copy of the Makefile (or |
| the output from make) is sufficient. |
| |
| If we were to try to guess the arguments, we would probably guess |
| wrong and then we might not encounter the bug. |
| |
| * A complete input file that will reproduce the bug. If the bug is |
| observed when the assembler is invoked via a compiler, send the |
| assembler source, not the high level language source. Most |
| compilers will produce the assembler source when run with the `-S' |
| option. If you are using `gcc', use the options `-v |
| --save-temps'; this will save the assembler source in a file with |
| an extension of `.s', and also show you exactly how `as' is being |
| run. |
| |
| * A description of what behavior you observe that you believe is |
| incorrect. For example, "It gets a fatal signal." |
| |
| Of course, if the bug is that `as' gets a fatal signal, then we |
| will certainly notice it. But if the bug is incorrect output, we |
| might not notice unless it is glaringly wrong. You might as well |
| not give us a chance to make a mistake. |
| |
| Even if the problem you experience is a fatal signal, you should |
| still say so explicitly. Suppose something strange is going on, |
| such as, your copy of `as' is out of synch, or you have |
| encountered a bug in the C library on your system. (This has |
| happened!) Your copy might crash and ours would not. If you told |
| us to expect a crash, then when ours fails to crash, we would know |
| that the bug was not happening for us. If you had not told us to |
| expect a crash, then we would not be able to draw any conclusion |
| from our observations. |
| |
| * If you wish to suggest changes to the `as' source, send us context |
| diffs, as generated by `diff' with the `-u', `-c', or `-p' option. |
| Always send diffs from the old file to the new file. If you even |
| discuss something in the `as' source, refer to it by context, not |
| by line number. |
| |
| The line numbers in our development sources will not match those |
| in your sources. Your line numbers would convey no useful |
| information to us. |
| |
| Here are some things that are not necessary: |
| |
| * A description of the envelope of the bug. |
| |
| Often people who encounter a bug spend a lot of time investigating |
| which changes to the input file will make the bug go away and which |
| changes will not affect it. |
| |
| This is often time consuming and not very useful, because the way |
| we will find the bug is by running a single example under the |
| debugger with breakpoints, not by pure deduction from a series of |
| examples. We recommend that you save your time for something else. |
| |
| Of course, if you can find a simpler example to report _instead_ |
| of the original one, that is a convenience for us. Errors in the |
| output will be easier to spot, running under the debugger will take |
| less time, and so on. |
| |
| However, simplification is not vital; if you do not want to do |
| this, report the bug anyway and send us the entire test case you |
| used. |
| |
| * A patch for the bug. |
| |
| A patch for the bug does help us if it is a good one. But do not |
| omit the necessary information, such as the test case, on the |
| assumption that a patch is all we need. We might see problems |
| with your patch and decide to fix the problem another way, or we |
| might not understand it at all. |
| |
| Sometimes with a program as complicated as `as' it is very hard to |
| construct an example that will make the program follow a certain |
| path through the code. If you do not send us the example, we will |
| not be able to construct one, so we will not be able to verify |
| that the bug is fixed. |
| |
| And if we cannot understand what bug you are trying to fix, or why |
| your patch should be an improvement, we will not install it. A |
| test case will help us to understand. |
| |
| * A guess about what the bug is or what it depends on. |
| |
| Such guesses are usually wrong. Even we cannot guess right about |
| such things without first using the debugger to find the facts. |
| |
| |
| File: as.info, Node: Acknowledgements, Next: GNU Free Documentation License, Prev: Reporting Bugs, Up: Top |
| |
| Acknowledgements |
| **************** |
| |
| If you have contributed to `as' and your name isn't listed here, it |
| is not meant as a slight. We just don't know about it. Send mail to |
| the maintainer, and we'll correct the situation. Currently the |
| maintainer is Ken Raeburn (email address `raeburn@cygnus.com'). |
| |
| Dean Elsner wrote the original GNU assembler for the VAX.(1) |
| |
| Jay Fenlason maintained GAS for a while, adding support for |
| GDB-specific debug information and the 68k series machines, most of the |
| preprocessing pass, and extensive changes in `messages.c', |
| `input-file.c', `write.c'. |
| |
| K. Richard Pixley maintained GAS for a while, adding various |
| enhancements and many bug fixes, including merging support for several |
| processors, breaking GAS up to handle multiple object file format back |
| ends (including heavy rewrite, testing, an integration of the coff and |
| b.out back ends), adding configuration including heavy testing and |
| verification of cross assemblers and file splits and renaming, |
| converted GAS to strictly ANSI C including full prototypes, added |
| support for m680[34]0 and cpu32, did considerable work on i960 |
| including a COFF port (including considerable amounts of reverse |
| engineering), a SPARC opcode file rewrite, DECstation, rs6000, and |
| hp300hpux host ports, updated "know" assertions and made them work, |
| much other reorganization, cleanup, and lint. |
| |
| Ken Raeburn wrote the high-level BFD interface code to replace most |
| of the code in format-specific I/O modules. |
| |
| The original VMS support was contributed by David L. Kashtan. Eric |
| Youngdale has done much work with it since. |
| |
| The Intel 80386 machine description was written by Eliot Dresselhaus. |
| |
| Minh Tran-Le at IntelliCorp contributed some AIX 386 support. |
| |
| The Motorola 88k machine description was contributed by Devon Bowen |
| of Buffalo University and Torbjorn Granlund of the Swedish Institute of |
| Computer Science. |
| |
| Keith Knowles at the Open Software Foundation wrote the original |
| MIPS back end (`tc-mips.c', `tc-mips.h'), and contributed Rose format |
| support (which hasn't been merged in yet). Ralph Campbell worked with |
| the MIPS code to support a.out format. |
| |
| Support for the Zilog Z8k and Hitachi H8/300 and H8/500 processors |
| (tc-z8k, tc-h8300, tc-h8500), and IEEE 695 object file format |
| (obj-ieee), was written by Steve Chamberlain of Cygnus Support. Steve |
| also modified the COFF back end to use BFD for some low-level |
| operations, for use with the H8/300 and AMD 29k targets. |
| |
| John Gilmore built the AMD 29000 support, added `.include' support, |
| and simplified the configuration of which versions accept which |
| directives. He updated the 68k machine description so that Motorola's |
| opcodes always produced fixed-size instructions (e.g. `jsr'), while |
| synthetic instructions remained shrinkable (`jbsr'). John fixed many |
| bugs, including true tested cross-compilation support, and one bug in |
| relaxation that took a week and required the proverbial one-bit fix. |
| |
| Ian Lance Taylor of Cygnus Support merged the Motorola and MIT |
| syntax for the 68k, completed support for some COFF targets (68k, i386 |
| SVR3, and SCO Unix), added support for MIPS ECOFF and ELF targets, |
| wrote the initial RS/6000 and PowerPC assembler, and made a few other |
| minor patches. |
| |
| Steve Chamberlain made `as' able to generate listings. |
| |
| Hewlett-Packard contributed support for the HP9000/300. |
| |
| Jeff Law wrote GAS and BFD support for the native HPPA object format |
| (SOM) along with a fairly extensive HPPA testsuite (for both SOM and |
| ELF object formats). This work was supported by both the Center for |
| Software Science at the University of Utah and Cygnus Support. |
| |
| Support for ELF format files has been worked on by Mark Eichin of |
| Cygnus Support (original, incomplete implementation for SPARC), Pete |
| Hoogenboom and Jeff Law at the University of Utah (HPPA mainly), |
| Michael Meissner of the Open Software Foundation (i386 mainly), and Ken |
| Raeburn of Cygnus Support (sparc, and some initial 64-bit support). |
| |
| Linas Vepstas added GAS support for the ESA/390 "IBM 370" |
| architecture. |
| |
| Richard Henderson rewrote the Alpha assembler. Klaus Kaempf wrote |
| GAS and BFD support for openVMS/Alpha. |
| |
| Timothy Wall, Michael Hayes, and Greg Smart contributed to the |
| various tic* flavors. |
| |
| Several engineers at Cygnus Support have also provided many small |
| bug fixes and configuration enhancements. |
| |
| Many others have contributed large or small bugfixes and |
| enhancements. If you have contributed significant work and are not |
| mentioned on this list, and want to be, let us know. Some of the |
| history has been lost; we are not intentionally leaving anyone out. |
| |
| ---------- Footnotes ---------- |
| |
| (1) Any more details? |
| |