250

Chapter 43. Reporting Bugs

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 com 

pilers 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 conve 

nience 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.