X-Git-Url: http://git.efficios.com/?a=blobdiff_plain;f=binutils%2Fbinutils.texi;h=535df3f6b8a0f0a16ec7119dd44e407e91e13631;hb=dd92f6397700e5478ae02b7dfad416181d04ef22;hp=c590e84fb06cacef0c3322e2d4f4d31c76d84c9c;hpb=10f2a7f6ac81c5e6af927c19773fc098bfed530e;p=deliverable%2Fbinutils-gdb.git diff --git a/binutils/binutils.texi b/binutils/binutils.texi index c590e84fb0..535df3f6b8 100644 --- a/binutils/binutils.texi +++ b/binutils/binutils.texi @@ -1,17 +1,19 @@ \input texinfo @c -*- Texinfo -*- @setfilename binutils.info +@include config.texi @ifinfo @format START-INFO-DIR-ENTRY -* Binutils:: The GNU binary utilities "ar", "ld", "objcopy", - "objdump", "nm", "size", "strings", "strip", and "ranlib". +* Binutils: (binutils). The GNU binary utilities "ar", "objcopy", + "objdump", "nm", "nlmconv", "size", "readelf" + "strings", "strip", "ranlib" and "dlltool". END-INFO-DIR-ENTRY @end format @end ifinfo @ifinfo -Copyright @copyright{} 1991, 1992, 1993 Free Software Foundation, Inc. +Copyright @copyright{} 1991, 92, 93, 94, 95, 96, 97, 98, 1999 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice @@ -37,22 +39,20 @@ into another language, under the above conditions for modified versions. @synindex ky cp @c @c This file documents the GNU binary utilities "ar", "ld", "objcopy", -@c "objdump", "nm", "size", "strings", "strip", and "ranlib". +@c "objdump", "nm", "size", "strings", "strip", "readelf" and "ranlib". @c -@c Copyright (C) 1991, 1992, 1993 Free Software Foundation, Inc. +@c Copyright (C) 1991, 92, 93, 94, 95, 96, 97, 98, 1999 Free Software Foundation, Inc. @c @c This text may be freely distributed under the terms of the GNU @c General Public License. @c @setchapternewpage odd -@settitle GNU Binary Utilities -@c @smallbook -@c @cropmarks +@settitle @sc{gnu} Binary Utilities @titlepage @finalout -@title The GNU Binary Utilities -@subtitle Version 2.2 +@title The @sc{gnu} Binary Utilities +@subtitle Version @value{VERSION} @sp 1 @subtitle May 1993 @author Roland H. Pesch @@ -66,7 +66,7 @@ into another language, under the above conditions for modified versions. @end tex @vskip 0pt plus 1filll -Copyright @copyright{} 1991, 1992, 1993 Free Software Foundation, Inc. +Copyright @copyright{} 1991, 92, 93, 94, 95, 96, 97, 1998 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice @@ -82,12 +82,11 @@ into another language, under the above conditions for modified versions. @end titlepage @node Top -@top -@chapter Introduction +@top Introduction @cindex version -This brief manual contains preliminary documentation for the GNU binary -utilities (collectively version 2.2): +This brief manual contains preliminary documentation for the @sc{gnu} binary +utilities (collectively version @value{VERSION}): @iftex @table @code @@ -106,6 +105,9 @@ Display information from object files @item ranlib Generate index to archive contents +@item readelf +Display the contents of ELF format files. + @item size List file section sizes and total size @@ -118,8 +120,17 @@ Discard symbols @item c++filt Demangle encoded C++ symbols +@item addr2line +Convert addresses into file names and line numbers + @item nlmconv Convert object code into a Netware Loadable Module + +@item windres +Manipulate Windows resources + +@item dlltool +Create the files needed to build and use Dynamic Link Libraries @end table @end iftex @@ -129,13 +140,18 @@ Convert object code into a Netware Loadable Module * objcopy:: Copy and translate object files * objdump:: Display information from object files * ranlib:: Generate index to archive contents +* readelf:: Display the contents of ELF format files. * size:: List section sizes and total size * strings:: List printable strings from files * strip:: Discard symbols * c++filt:: Filter to demangle encoded C++ symbols +* addr2line:: Convert addresses to file and line * nlmconv:: Converts object code into an NLM +* windres:: Manipulate Windows resources +* dlltool:: Create files needed to build and use DLLs * Selecting The Target System:: How these utilities determine the target. -* Index:: +* Reporting Bugs:: Reporting Bugs +* Index:: Index @end menu @node ar @@ -149,7 +165,7 @@ ar [-]@var{p}[@var{mod} [@var{relpos}]] @var{archive} [@var{member}@dots{}] ar -M [ } entry in the @samp{.drectve} +section of the object file. This can be done in C by using the +asm() operator: + +@smallexample + asm (".section .drectve"); + asm (".ascii \"-export:my_func\""); + + int my_func (void) @{ @dots{} @} +@end smallexample + +The second file needed for DLL creation is an exports file. This file +is linked with the object files that make up the body of the DLL and it +handles the interface between the DLL and the outside world. This is a +binary file and it can be created by giving the @samp{-e} option to +@code{dlltool} when it is creating or reading in a .def file. + +The third file needed for DLL creation is the library file that programs +will link with in order to access the functions in the DLL. This file +can be created by giving the @samp{-l} option to dlltool when it +is creating or reading in a .def file. + +@code{dlltool} builds the library file by hand, but it builds the +exports file by creating temporary files containing assembler statements +and then assembling these. The @samp{-S} command line option can be +used to specify the path to the assembler that dlltool will use, +and the @samp{-f} option can be used to pass specific flags to that +assembler. The @samp{-n} can be used to prevent dlltool from deleting +these temporary assembler files when it is done, and if @samp{-n} is +specified twice then this will prevent dlltool from deleting the +temporary object files it used to build the library. + +Here is an example of creating a DLL from a source file @samp{dll.c} and +also creating a program (from an object file called @samp{program.o}) +that uses that DLL: + +@smallexample + gcc -c dll.c + dlltool -e exports.o -l dll.lib dll.o + gcc dll.o exports.o -o dll.dll + gcc program.o dll.lib -o program +@end smallexample + +The command line options have the following meanings: + +@table @code + +@item -d @var{filename} +@itemx --input-def @var{filename} +@cindex input .def file +Specifies the name of a .def file to be read in and processed. + +@item -b @var{filename} +@itemx --base-file @var{filename} +@cindex base files +Specifies the name of a base file to be read in and processed. The +contents of this file will be added to the relocation section in the +exports file generated by dlltool. + +@item -e @var{filename} +@itemx --output-exp @var{filename} +Specifies the name of the export file to be created by dlltool. + +@item -z @var{filename} +@itemx --output-def @var{filename} +Specifies the name of the .def file to be created by dlltool. + +@item -l @var{filename} +@itemx --output-lib @var{filename} +Specifies the name of the library file to be created by dlltool. + +@item --export-all-symbols +Treat all global and weak defined symbols found in the input object +files as symbols to be exported. There is a small list of symbols which +are not exported by default; see the @code{--no-default-excludes} +option. You may add to the list of symbols to not export by using the +@code{--exclude-symbols} option. + +@item --no-export-all-symbols +Only export symbols explicitly listed in an input .def file or in +@samp{.drectve} sections in the input object files. This is the default +behaviour. The @samp{.drectve} sections are created by @samp{dllexport} +attributes in the source code. + +@item --exclude-symbols @var{list} +Do not export the symbols in @var{list}. This is a list of symbol names +separated by comma or colon characters. The symbol names should not +contain a leading underscore. This is only meaningful when +@code{--export-all-symbols} is used. + +@item --no-default-excludes +When @code{--export-all-symbols} is used, it will by default avoid +exporting certain special symbols. The current list of symbols to avoid +exporting is @samp{DllMain@@12}, @samp{DllEntryPoint@@0}, +@samp{impure_ptr}. You may use the @code{--no-default-excludes} option +to go ahead and export these special symbols. This is only meaningful +when @code{--export-all-symbols} is used. + +@item -S @var{path} +@itemx --as @var{path} +Specifies the path, including the filename, of the assembler to be used +to create the exports file. + +@item -f @var{switches} +@itemx --as-flags @var{switches} +Specifies any specific command line switches to be passed to the +assembler when building the exports file. This option will work even if +the @samp{-S} option is not used. This option only takes one argument, +and if it occurs more than once on the command line, then later +occurrences will override earlier occurrences. So if it is necessary to +pass multiple switches to the assembler they should be enclosed in +double quotes. + +@item -D @var{name} +@itemx --dll-name @var{name} +Specifies the name to be stored in the .def file as the name of the DLL +when the @samp{-e} option is used. If this option is not present, then +the filename given to the @samp{-e} option will be used as the name of +the DLL. + +@item -m @var{machine} +@itemx -machine @var{machine} +Specifies the type of machine for which the library file should be +built. @code{dlltool} has a built in default type, depending upon how +it was created, but this option can be used to override that. This is +normally only useful when creating DLLs for an ARM processor, when the +contents of the DLL are actually encode using THUMB instructions. + +@item -a +@itemx --add-indirect +Specifies that when @code{dlltool} is creating the exports file it +should add a section which allows the exported functions to be +referenced without using the import library. Whatever the hell that +means! + +@item -U +@itemx --add-underscore +Specifies that when @code{dlltool} is creating the exports file it +should prepend an underscore to the names of the exported functions. + +@item -k +@itemx --kill-at +Specifies that when @code{dlltool} is creating the exports file it +should not append the string @samp{@@ }. These numbers are +called ordinal numbers and they represent another way of accessing the +function in a DLL, other than by name. + +@item -A +@itemx --add-stdcall-alias +Specifies that when @code{dlltool} is creating the exports file it +should add aliases for stdcall symbols without @samp{@@ } +in addition to the symbols with @samp{@@ }. + +@item -x +@itemx --no-idata4 +Specifies that when @code{dlltool} is creating the exports and library +files it should omit the .idata4 section. This is for compatibility +with certain operating systems. + +@item -c +@itemx --no-idata5 +Specifies that when @code{dlltool} is creating the exports and library +files it should omit the .idata5 section. This is for compatibility +with certain operating systems. + +@item -i +@itemx --interwork +Specifies that @code{dlltool} should mark the objects in the library +file and exports file that it produces as supporting interworking +between ARM and THUMB code. + +@item -n +@itemx --nodelete +Makes @code{dlltool} preserve the temporary assembler files it used to +create the exports file. If this option is repeated then dlltool will +also preserve the temporary object files it uses to create the library +file. + +@item -v +@itemx --verbose +Make dlltool describe what it is doing. + +@item -h +@itemx --help +Displays a list of command line options and then exits. + +@item -V +@itemx --version +Displays dlltool's version number and then exits. + +@end table + +@node readelf +@chapter readelf + +@cindex ELF file information +@kindex readelf + +@smallexample +readelf [ -a | --all ] + [ -h | --file-header] + [ -l | --program-headers | --segments] + [ -S | --section-headers | --sections] + [ -e | --headers] + [ -s | --syms | --symbols] + [ -r | --relocs] + [ -d | --dynamic] + [ -V | --version-info] + [ -D | --use-dynamic] + [ -x | --hex-dump=] + [ -w[liapr] | --debug-dump[=info,=line,=abbrev,=pubnames,=ranges]] + [ --histogram] + [ -v | --version] + [ -H | --help] + @var{elffile}@dots{} +@end smallexample + +@code{readelf} displays information about one or more ELF format object +files. The options control what particular information to display. + +@var{elffile}@dots{} are the object files to be examined. At the +moment, @code{readelf} does not support examining archives, nor does it +support examing 64 bit ELF files. + +The long and short forms of options, shown here as alternatives, are +equivalent. At least one option besides @samp{-v} or @samp{-H} must be +given. + +@table @code +@item -a +@itemx --all +Equivalent to specifiying @samp{--file-header}, +@samp{--program-headers}, @samp{--sections}, @samp{--symbols}, +@samp{--relocs}, @samp{--dynamic} and @samp{--version-info}. + +@item -h +@itemx --file-header +@cindex ELF file header information +Displays the information contained in the ELF header at the start of the +file. + +@item -l +@itemx --program-headers +@itemx --segments +@cindex ELF program header information +@cindex ELF segment information +Displays the information contained in the file's segment headers, if it +has any. + +@item -S +@itemx --sections +@itemx --section-headers +@cindex ELF section information +Displays the information contained in the file's section headers, if it +has any. + +@item -s +@itemx --symbols +@itemx --syms +@cindex ELF symbol table information +Displays the entries in symbol table section of the file, if it has one. + +@item -e +@itemx --headers +Display all the headers in the file. Equivalent to @samp{-h -l -S}. + +@item -r +@itemx --relocs +@cindex ELF reloc information +Displays the contents of the file's relocation section, if it ha one. + +@item -d +@itemx --dynamic +@cindex ELF dynamic section information +Displays the contents of the file's dynamic section, if it has one. + +@item -V +@itemx --version-info +@cindex ELF version sections informations +Displays the contents of the version sections in the file, it they +exist. + +@item -D +@itemx --use-dynamic +When displaying symbols, this option makes @code{readelf} use the +symblol table in the file's dynamic section, rather than the one in the +symbols section. + +@item -x +@itemx --hex-dump= +Displays the contents of the indicated section as a hexadecimal dump. + +@item -w[liapr] +@itemx --debug-dump[=line,=info,=abbrev,=pubnames,=ranges] +Displays the contents of the debug sections in the file, if any are +present. If one of the optional letters or words follows the switch +then only data found in those specific sections will be dumped. + +@item --histogram +Display a histogram of bucket list lengths when displaying the contents +of the symbol tables. + +@item -v +@itemx --version +Display the version number of readelf. + +@item -H +@itemx --help +Display the command line options understood by @code{readelf}. + +@end table + + @node Selecting The Target System @chapter Selecting the target system -You can specify three aspects of the target system to the GNU binary -file utilities, each in several ways. The three aspects of the target -system that you can specify are +You can specify three aspects of the target system to the @sc{gnu} +binary file utilities, each in several ways: @itemize @bullet @item -the target, +the target @item -the architecture, and +the architecture @item -the linker emulation (which applies to the linker only). +the linker emulation (which applies to the linker only) @end itemize In the following summaries, the lists of ways to specify values are in -order of decreasing precedence. In other words, the ways listed earlier -override the ways listed later. +order of decreasing precedence. The ways listed first override those +listed later. -The commands to list valid values only list the values that the programs -you are running were configured for. If they were configured with -@samp{--with-targets=all}, the commands list most of the available +The commands to list valid values only list the values for which the +programs you are running were configured. If they were configured with +@samp{--enable-targets=all}, the commands list most of the available values, but a few are left out; not all targets can be configured in at -once because some of them can only be compiled ``native'' (on hosts with -the same type as the target system). +once because some of them can only be configured @dfn{native} (on hosts +with the same type as the target system). @menu * Target Selection:: @@ -1427,34 +2497,36 @@ the same type as the target system). @end menu @node Target Selection -@section Target selection +@section Target Selection A @dfn{target} is an object file format. A given target may be supported for multiple architectures (@pxref{Architecture Selection}). -It may also have variations for different operating systems or architectures. +A target selection may also have variations for different operating +systems or architectures. -Command to list valid values: @samp{objdump -i} (first column). +The command to list valid target values is @samp{objdump -i} +(the first column of output contains the relevant information). Some sample values are: @samp{a.out-hp300bsd}, @samp{ecoff-littlemips}, @samp{a.out-sunos-big}. -@menu -* objdump Target:: -* objcopy strip Input Target:: -* objcopy strip Output Target:: -* nm size strings Target:: -* Linker Input Target:: -* Linker Output Target:: -@end menu +You can also specify a target using a configuration triplet. This is +the same sort of name that is passed to configure to specify a target. +When you use a configuration triplet as an argument, it must be fully +canonicalized. You can see the canonical version of a triplet by +running the shell script @file{config.sub} which is included with the +sources. + +Some sample configuration triplets are: @samp{m68k-hp-bsd}, +@samp{mips-dec-ultrix}, @samp{sparc-sun-sunos}. -@node objdump Target -@subsection @code{objdump} target +@subheading @code{objdump} Target Ways to specify: @enumerate @item -command line option @samp{-b}, @samp{--target} +command line option: @samp{-b} or @samp{--target} @item environment variable @code{GNUTARGET} @@ -1463,14 +2535,13 @@ environment variable @code{GNUTARGET} deduced from the input file @end enumerate -@node objcopy strip Input Target -@subsection @code{objcopy} and @code{strip} input target +@subheading @code{objcopy} and @code{strip} Input Target Ways to specify: @enumerate @item -command line option @samp{-I}, @samp{--input-target}, @samp{-F}, @samp{--target} +command line options: @samp{-I} or @samp{--input-target}, or @samp{-F} or @samp{--target} @item environment variable @code{GNUTARGET} @@ -1479,17 +2550,16 @@ environment variable @code{GNUTARGET} deduced from the input file @end enumerate -@node objcopy strip Output Target -@subsection @code{objcopy} and @code{strip} output target +@subheading @code{objcopy} and @code{strip} Output Target Ways to specify: @enumerate @item -command line option @samp{-O}, @samp{-F}, @samp{--output-target}, @samp{--target} +command line options: @samp{-O} or @samp{--output-target}, or @samp{-F} or @samp{--target} @item -the input target (@pxref{objcopy strip Input Target}) +the input target (see ``@code{objcopy} and @code{strip} Input Target'' above) @item environment variable @code{GNUTARGET} @@ -1498,14 +2568,13 @@ environment variable @code{GNUTARGET} deduced from the input file @end enumerate -@node nm size strings Target -@subsection @code{nm}, @code{size}, and @code{strings} target +@subheading @code{nm}, @code{size}, and @code{strings} Target Ways to specify: @enumerate @item -command line option @samp{--target} +command line option: @samp{--target} @item environment variable @code{GNUTARGET} @@ -1514,14 +2583,13 @@ environment variable @code{GNUTARGET} deduced from the input file @end enumerate -@node Linker Input Target -@subsection Linker input target +@subheading Linker Input Target Ways to specify: @enumerate @item -command line option @samp{-b}, @samp{-format} +command line option: @samp{-b} or @samp{--format} (@pxref{Options,,Options,ld.info,Using LD}) @item @@ -1537,14 +2605,13 @@ the default target of the selected linker emulation (@pxref{Linker Emulation Selection}) @end enumerate -@node Linker Output Target -@subsection Linker output target +@subheading Linker Output Target Ways to specify: @enumerate @item -command line option @samp{-oformat} +command line option: @samp{-oformat} (@pxref{Options,,Options,ld.info,Using LD}) @item @@ -1552,42 +2619,34 @@ script command @code{OUTPUT_FORMAT} (@pxref{Option Commands,,Option Commands,ld.info,Using LD}) @item -the linker input target (@pxref{Linker Input Target}) +the linker input target (see ``Linker Input Target'' above) @end enumerate @node Architecture Selection @section Architecture selection -An @dfn{architecture} is a type of CPU on which an object file is to -run. Its name may contain a colon, separating the name of the -processor family from the name of the particular CPU. +An @dfn{architecture} is a type of @sc{cpu} on which an object file is +to run. Its name may contain a colon, separating the name of the +processor family from the name of the particular @sc{cpu}. -Command to list valid values: @samp{objdump -i} (second column). +The command to list valid architecture values is @samp{objdump -i} (the +second column contains the relevant information). Sample values: @samp{m68k:68020}, @samp{mips:3000}, @samp{sparc}. -@menu -* objdump Architecture:: -* objcopy nm size strings Architecture:: -* Linker Input Architecture:: -* Linker Output Architecture:: -@end menu - -@node objdump Architecture -@subsection @code{objdump} architecture +@subheading @code{objdump} Architecture Ways to specify: @enumerate @item -command line option @samp{-m}, @samp{--architecture} +command line option: @samp{-m} or @samp{--architecture} @item deduced from the input file @end enumerate -@node objcopy nm size strings Architecture -@subsection @code{objcopy}, @code{nm}, @code{size}, @code{strings} architecture +@subheading @code{objcopy}, @code{nm}, @code{size}, @code{strings} Architecture Ways to specify: @@ -1596,8 +2655,7 @@ Ways to specify: deduced from the input file @end enumerate -@node Linker Input Architecture -@subsection Linker input architecture +@subheading Linker Input Architecture Ways to specify: @@ -1606,8 +2664,7 @@ Ways to specify: deduced from the input file @end enumerate -@node Linker Output Architecture -@subsection Linker output architecture +@subheading Linker Output Architecture Ways to specify: @@ -1618,7 +2675,7 @@ script command @code{OUTPUT_ARCH} @item the default architecture from the linker output target -(@pxref{Linker Output Target}) +(@pxref{Target Selection}) @end enumerate @node Linker Emulation Selection @@ -1630,17 +2687,17 @@ In particular, it consists of @itemize @bullet @item -the linker script, +the linker script @item -the target, and +the target @item several ``hook'' functions that are run at certain stages of the linking -process to do special things that some targets require. +process to do special things that some targets require @end itemize -Command to list valid values: @samp{ld -V}. +The command to list valid linker emulation values is @samp{ld -V}. Sample values: @samp{hp300bsd}, @samp{mipslit}, @samp{sun4}. @@ -1648,7 +2705,7 @@ Ways to specify: @enumerate @item -command line option @samp{-m} +command line option: @samp{-m} (@pxref{Options,,Options,ld.info,Using LD}) @item @@ -1659,6 +2716,213 @@ compiled-in @code{DEFAULT_EMULATION} from @file{Makefile}, which comes from @code{EMUL} in @file{config/@var{target}.mt} @end enumerate +@node Reporting Bugs +@chapter Reporting Bugs +@cindex bugs +@cindex reporting bugs + +Your bug reports play an essential role in making the binary utilities +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 the binary +utilities work better. Bug reports are your contribution to their +maintenance. + +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 +@end menu + +@node Bug Criteria +@section Have you found a bug? +@cindex bug criteria + +If you are not sure whether you have found a bug, here are some guidelines: + +@itemize @bullet +@cindex fatal signal +@cindex crash +@item +If a binary utility gets a fatal signal, for any input whatever, that is +a bug. Reliable utilities never crash. + +@cindex error on valid input +@item +If a binary utility produces an error message for valid input, that is a +bug. + +@item +If you are an experienced user of binary utilities, your suggestions for +improvement are welcome in any case. +@end itemize + +@node Bug Reporting +@section How to report bugs +@cindex bug reports +@cindex bugs, reporting + +A number of companies and individuals offer support for @sc{gnu} +products. If you obtained the binary utilities 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 @file{etc/SERVICE} in the @sc{gnu} Emacs +distribution. + +In any event, we also recommend that you send bug reports for the binary +utilities to @samp{bug-gnu-utils@@gnu.org}. + +The fundamental principle of reporting bugs usefully is this: +@strong{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 file 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 pathname is stored in memory; perhaps, if the pathname were +different, the contents of that location would fool the utility 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 +@emph{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: + +@itemize @bullet +@item +The version of the utility. Each utility announces it if you start it +with the @samp{--version} argument. + +Without this, we will not know whether there is any point in looking for +the bug in the current version of the binary utilities. + +@item +Any patches you may have applied to the source, including any patches +made to the @code{BFD} library. + +@item +The type of machine you are using, and the operating system name and +version number. + +@item +What compiler (and its version) was used to compile the utilities---e.g. +``@code{gcc-2.7}''. + +@item +The command arguments you gave the utility to 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. + +@item +A complete input file, or set of input files, that will reproduce the +bug. If the utility is reading an object file or files, then it is +generally most helpful to send the actual object files, uuencoded if +necessary to get them through the mail system. Making them available +for anonymous FTP is not as good, but may be the only reasonable choice +for large object files. + +If the source files were produced exclusively using @sc{gnu} programs +(e.g., @code{gcc}, @code{gas}, and/or the @sc{gnu} @code{ld}), then it +may be OK to send the source files rather than the object files. In +this case, be sure to say exactly what version of @code{gcc}, or +whatever, was used to produce the object files. Also say how +@code{gcc}, or whatever, was configured. + +@item +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 the utility 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 the utility 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. + +@item +If you wish to suggest changes to the source, send us context diffs, as +generated by @code{diff} with the @samp{-u}, @samp{-c}, or @samp{-p} +option. Always send diffs from the old file to the new file. If you +even discuss something in the @code{ld} 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. +@end itemize + +Here are some things that are not necessary: + +@itemize @bullet +@item +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 @emph{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. + +@item +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 programs as complicated as the binary utilities 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. + +@item +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. +@end itemize + @node Index @unnumbered Index