772 lines
28 KiB
Plaintext
772 lines
28 KiB
Plaintext
|
This is Info file binutils.info, produced by Makeinfo-1.64 from the
|
|||
|
input file ./binutils.texi.
|
|||
|
|
|||
|
START-INFO-DIR-ENTRY
|
|||
|
* Binutils: (binutils). The GNU binary utilities "ar", "objcopy",
|
|||
|
"objdump", "nm", "nlmconv", "size",
|
|||
|
"strings", "strip", and "ranlib".
|
|||
|
END-INFO-DIR-ENTRY
|
|||
|
|
|||
|
Copyright (C) 1991, 92, 93, 94, 95, 96, 1997 Free Software
|
|||
|
Foundation, Inc.
|
|||
|
|
|||
|
Permission is granted to make and distribute verbatim copies of this
|
|||
|
manual provided the copyright notice and this permission notice are
|
|||
|
preserved on all copies.
|
|||
|
|
|||
|
Permission is granted to copy and distribute modified versions of
|
|||
|
this manual under the conditions for verbatim copying, provided also
|
|||
|
that the entire resulting derived work is distributed under the terms
|
|||
|
of a permission notice identical to this one.
|
|||
|
|
|||
|
Permission is granted to copy and distribute translations of this
|
|||
|
manual into another language, under the above conditions for modified
|
|||
|
versions.
|
|||
|
|
|||
|
|
|||
|
File: binutils.info, Node: c++filt, Next: addr2line, Prev: strip, Up: Top
|
|||
|
|
|||
|
c++filt
|
|||
|
*******
|
|||
|
|
|||
|
c++filt [ -_ | --strip-underscores ]
|
|||
|
[ -n | --no-strip-underscores ]
|
|||
|
[ -s FORMAT | --format=FORMAT ]
|
|||
|
[ --help ] [ --version ] [ SYMBOL... ]
|
|||
|
|
|||
|
The C++ language provides function overloading, which means that you
|
|||
|
can write many functions with the same name (providing each takes
|
|||
|
parameters of different types). All C++ function names are encoded
|
|||
|
into a low-level assembly label (this process is known as "mangling").
|
|||
|
The `c++filt' program does the inverse mapping: it decodes
|
|||
|
("demangles") low-level names into user-level names so that the linker
|
|||
|
can keep these overloaded functions from clashing.
|
|||
|
|
|||
|
Every alphanumeric word (consisting of letters, digits, underscores,
|
|||
|
dollars, or periods) seen in the input is a potential label. If the
|
|||
|
label decodes into a C++ name, the C++ name replaces the low-level name
|
|||
|
in the output.
|
|||
|
|
|||
|
You can use `c++filt' to decipher individual symbols:
|
|||
|
|
|||
|
c++filt SYMBOL
|
|||
|
|
|||
|
If no SYMBOL arguments are given, `c++filt' reads symbol names from
|
|||
|
the standard input and writes the demangled names to the standard
|
|||
|
output. All results are printed on the standard output.
|
|||
|
|
|||
|
`-_'
|
|||
|
`--strip-underscores'
|
|||
|
On some systems, both the C and C++ compilers put an underscore in
|
|||
|
front of every name. For example, the C name `foo' gets the
|
|||
|
low-level name `_foo'. This option removes the initial
|
|||
|
underscore. Whether `c++filt' removes the underscore by default
|
|||
|
is target dependent.
|
|||
|
|
|||
|
`-n'
|
|||
|
`--no-strip-underscores'
|
|||
|
Do not remove the initial underscore.
|
|||
|
|
|||
|
`-s FORMAT'
|
|||
|
`--format=FORMAT'
|
|||
|
GNU `nm' can decode three different methods of mangling, used by
|
|||
|
different C++ compilers. The argument to this option selects which
|
|||
|
method it uses:
|
|||
|
|
|||
|
`gnu'
|
|||
|
the one used by the GNU compiler (the default method)
|
|||
|
|
|||
|
`lucid'
|
|||
|
the one used by the Lucid compiler
|
|||
|
|
|||
|
`arm'
|
|||
|
the one specified by the C++ Annotated Reference Manual
|
|||
|
|
|||
|
`--help'
|
|||
|
Print a summary of the options to `c++filt' and exit.
|
|||
|
|
|||
|
`--version'
|
|||
|
Print the version number of `c++filt' and exit.
|
|||
|
|
|||
|
*Warning:* `c++filt' is a new utility, and the details of its user
|
|||
|
interface are subject to change in future releases. In particular,
|
|||
|
a command-line option may be required in the the future to decode
|
|||
|
a name passed as an argument on the command line; in other words,
|
|||
|
|
|||
|
c++filt SYMBOL
|
|||
|
|
|||
|
may in a future release become
|
|||
|
|
|||
|
c++filt OPTION SYMBOL
|
|||
|
|
|||
|
|
|||
|
File: binutils.info, Node: addr2line, Next: nlmconv, Prev: c++filt, Up: Top
|
|||
|
|
|||
|
addr2line
|
|||
|
*********
|
|||
|
|
|||
|
addr2line [ -b BFDNAME | --target=BFDNAME ]
|
|||
|
[ -C | --demangle ]
|
|||
|
[ -e FILENAME | --exe=FILENAME ]
|
|||
|
[ -f | --functions ] [ -s | --basename ]
|
|||
|
[ -H | --help ] [ -V | --version ]
|
|||
|
[ addr addr ... ]
|
|||
|
|
|||
|
`addr2line' translates program addresses into file names and line
|
|||
|
numbers. Given an address and an executable, it uses the debugging
|
|||
|
information in the executable to figure out which file name and line
|
|||
|
number are associated with a given address.
|
|||
|
|
|||
|
The executable to use is specified with the `-e' option. The
|
|||
|
default is `a.out'.
|
|||
|
|
|||
|
`addr2line' has two modes of operation.
|
|||
|
|
|||
|
In the first, hexadecimal addresses are specified on the command
|
|||
|
line, and `addr2line' displays the file name and line number for each
|
|||
|
address.
|
|||
|
|
|||
|
In the second, `addr2line' reads hexadecimal addresses from standard
|
|||
|
input, and prints the file name and line number for each address on
|
|||
|
standard output. In this mode, `addr2line' may be used in a pipe to
|
|||
|
convert dynamically chosen addresses.
|
|||
|
|
|||
|
The format of the output is `FILENAME:LINENO'. The file name and
|
|||
|
line number for each address is printed on a separate line. If the
|
|||
|
`-f' option is used, then each `FILENAME:LINENO' line is preceded by a
|
|||
|
`FUNCTIONNAME' line which is the name of the function containing the
|
|||
|
address.
|
|||
|
|
|||
|
If the file name or function name can not be determined, `addr2line'
|
|||
|
will print two question marks in their place. If the line number can
|
|||
|
not be determined, `addr2line' will print 0.
|
|||
|
|
|||
|
The long and short forms of options, shown here as alternatives, are
|
|||
|
equivalent.
|
|||
|
|
|||
|
`-b BFDNAME'
|
|||
|
`--target=BFDNAME'
|
|||
|
Specify that the object-code format for the object files is
|
|||
|
BFDNAME.
|
|||
|
|
|||
|
`-C'
|
|||
|
`--demangle'
|
|||
|
Decode ("demangle") low-level symbol names into user-level names.
|
|||
|
Besides removing any initial underscore prepended by the system,
|
|||
|
this makes C++ function names readable. *Note c++filt::, for more
|
|||
|
information on demangling.
|
|||
|
|
|||
|
`-e FILENAME'
|
|||
|
`--exe=FILENAME'
|
|||
|
Specify the name of the executable for which addresses should be
|
|||
|
translated. The default file is `a.out'.
|
|||
|
|
|||
|
`-f'
|
|||
|
`--functions'
|
|||
|
Display function names as well as file and line number information.
|
|||
|
|
|||
|
`-s'
|
|||
|
`--basenames'
|
|||
|
Display only the base of each file name.
|
|||
|
|
|||
|
|
|||
|
File: binutils.info, Node: nlmconv, Next: Selecting The Target System, Prev: addr2line, Up: Top
|
|||
|
|
|||
|
nlmconv
|
|||
|
*******
|
|||
|
|
|||
|
`nlmconv' converts a relocatable object file into a NetWare Loadable
|
|||
|
Module.
|
|||
|
|
|||
|
*Warning:* `nlmconv' is not always built as part of the binary
|
|||
|
utilities, since it is only useful for NLM targets.
|
|||
|
|
|||
|
nlmconv [ -I BFDNAME | --input-target=BFDNAME ]
|
|||
|
[ -O BFDNAME | --output-target=BFDNAME ]
|
|||
|
[ -T HEADERFILE | --header-file=HEADERFILE ]
|
|||
|
[ -d | --debug] [ -l LINKER | --linker=LINKER ]
|
|||
|
[ -h | --help ] [ -V | --version ]
|
|||
|
INFILE OUTFILE
|
|||
|
|
|||
|
`nlmconv' converts the relocatable `i386' object file INFILE into
|
|||
|
the NetWare Loadable Module OUTFILE, optionally reading HEADERFILE for
|
|||
|
NLM header information. For instructions on writing the NLM command
|
|||
|
file language used in header files, see the `linkers' section,
|
|||
|
`NLMLINK' in particular, of the `NLM Development and Tools Overview',
|
|||
|
which is part of the NLM Software Developer's Kit ("NLM SDK"),
|
|||
|
available from Novell, Inc. `nlmconv' uses the GNU Binary File
|
|||
|
Descriptor library to read INFILE; see *Note BFD: (ld.info)BFD, for
|
|||
|
more information.
|
|||
|
|
|||
|
`nlmconv' can perform a link step. In other words, you can list
|
|||
|
more than one object file for input if you list them in the definitions
|
|||
|
file (rather than simply specifying one input file on the command line).
|
|||
|
In this case, `nlmconv' calls the linker for you.
|
|||
|
|
|||
|
`-I BFDNAME'
|
|||
|
`--input-target=BFDNAME'
|
|||
|
Object format of the input file. `nlmconv' can usually determine
|
|||
|
the format of a given file (so no default is necessary). *Note
|
|||
|
Target Selection::, for more information.
|
|||
|
|
|||
|
`-O BFDNAME'
|
|||
|
`--output-target=BFDNAME'
|
|||
|
Object format of the output file. `nlmconv' infers the output
|
|||
|
format based on the input format, e.g. for a `i386' input file the
|
|||
|
output format is `nlm32-i386'. *Note Target Selection::, for more
|
|||
|
information.
|
|||
|
|
|||
|
`-T HEADERFILE'
|
|||
|
`--header-file=HEADERFILE'
|
|||
|
Reads HEADERFILE for NLM header information. For instructions on
|
|||
|
writing the NLM command file language used in header files, see
|
|||
|
see the `linkers' section, of the `NLM Development and Tools
|
|||
|
Overview', which is part of the NLM Software Developer's Kit,
|
|||
|
available from Novell, Inc.
|
|||
|
|
|||
|
`-d'
|
|||
|
`--debug'
|
|||
|
Displays (on standard error) the linker command line used by
|
|||
|
`nlmconv'.
|
|||
|
|
|||
|
`-l LINKER'
|
|||
|
`--linker=LINKER'
|
|||
|
Use LINKER for any linking. LINKER can be an abosolute or a
|
|||
|
relative pathname.
|
|||
|
|
|||
|
`-h'
|
|||
|
`--help'
|
|||
|
Prints a usage summary.
|
|||
|
|
|||
|
`-V'
|
|||
|
`--version'
|
|||
|
Prints the version number for `nlmconv'.
|
|||
|
|
|||
|
|
|||
|
File: binutils.info, Node: Selecting The Target System, Next: Reporting Bugs, Prev: nlmconv, Up: Top
|
|||
|
|
|||
|
Selecting the target system
|
|||
|
***************************
|
|||
|
|
|||
|
You can specify three aspects of the target system to the GNU binary
|
|||
|
file utilities, each in several ways:
|
|||
|
|
|||
|
* the target
|
|||
|
|
|||
|
* the architecture
|
|||
|
|
|||
|
* the linker emulation (which applies to the linker only)
|
|||
|
|
|||
|
In the following summaries, the lists of ways to specify values are
|
|||
|
in order of decreasing precedence. The ways listed first override those
|
|||
|
listed later.
|
|||
|
|
|||
|
The commands to list valid values only list the values for which the
|
|||
|
programs you are running were configured. If they were configured with
|
|||
|
`--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 configured "native" (on hosts with the
|
|||
|
same type as the target system).
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* Target Selection::
|
|||
|
* Architecture Selection::
|
|||
|
* Linker Emulation Selection::
|
|||
|
|
|||
|
|
|||
|
File: binutils.info, Node: Target Selection, Next: Architecture Selection, Up: Selecting The Target System
|
|||
|
|
|||
|
Target Selection
|
|||
|
================
|
|||
|
|
|||
|
A "target" is an object file format. A given target may be
|
|||
|
supported for multiple architectures (*note Architecture Selection::.).
|
|||
|
A target selection may also have variations for different operating
|
|||
|
systems or architectures.
|
|||
|
|
|||
|
The command to list valid target values is `objdump -i' (the first
|
|||
|
column of output contains the relevant information).
|
|||
|
|
|||
|
Some sample values are: `a.out-hp300bsd', `ecoff-littlemips',
|
|||
|
`a.out-sunos-big'.
|
|||
|
|
|||
|
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 `config.sub' which is included with the
|
|||
|
sources.
|
|||
|
|
|||
|
Some sample configuration triplets are: `m68k-hp-bsd',
|
|||
|
`mips-dec-ultrix', `sparc-sun-sunos'.
|
|||
|
|
|||
|
`objdump' Target
|
|||
|
----------------
|
|||
|
|
|||
|
Ways to specify:
|
|||
|
|
|||
|
1. command line option: `-b' or `--target'
|
|||
|
|
|||
|
2. environment variable `GNUTARGET'
|
|||
|
|
|||
|
3. deduced from the input file
|
|||
|
|
|||
|
`objcopy' and `strip' Input Target
|
|||
|
----------------------------------
|
|||
|
|
|||
|
Ways to specify:
|
|||
|
|
|||
|
1. command line options: `-I' or `--input-target', or `-F' or
|
|||
|
`--target'
|
|||
|
|
|||
|
2. environment variable `GNUTARGET'
|
|||
|
|
|||
|
3. deduced from the input file
|
|||
|
|
|||
|
`objcopy' and `strip' Output Target
|
|||
|
-----------------------------------
|
|||
|
|
|||
|
Ways to specify:
|
|||
|
|
|||
|
1. command line options: `-O' or `--output-target', or `-F' or
|
|||
|
`--target'
|
|||
|
|
|||
|
2. the input target (see "`objcopy' and `strip' Input Target" above)
|
|||
|
|
|||
|
3. environment variable `GNUTARGET'
|
|||
|
|
|||
|
4. deduced from the input file
|
|||
|
|
|||
|
`nm', `size', and `strings' Target
|
|||
|
----------------------------------
|
|||
|
|
|||
|
Ways to specify:
|
|||
|
|
|||
|
1. command line option: `--target'
|
|||
|
|
|||
|
2. environment variable `GNUTARGET'
|
|||
|
|
|||
|
3. deduced from the input file
|
|||
|
|
|||
|
Linker Input Target
|
|||
|
-------------------
|
|||
|
|
|||
|
Ways to specify:
|
|||
|
|
|||
|
1. command line option: `-b' or `--format' (*note Options:
|
|||
|
(ld.info)Options.)
|
|||
|
|
|||
|
2. script command `TARGET' (*note Option Commands: (ld.info)Option
|
|||
|
Commands.)
|
|||
|
|
|||
|
3. environment variable `GNUTARGET' (*note Environment:
|
|||
|
(ld.info)Environment.)
|
|||
|
|
|||
|
4. the default target of the selected linker emulation (*note Linker
|
|||
|
Emulation Selection::.)
|
|||
|
|
|||
|
Linker Output Target
|
|||
|
--------------------
|
|||
|
|
|||
|
Ways to specify:
|
|||
|
|
|||
|
1. command line option: `-oformat' (*note Options: (ld.info)Options.)
|
|||
|
|
|||
|
2. script command `OUTPUT_FORMAT' (*note Option Commands:
|
|||
|
(ld.info)Option Commands.)
|
|||
|
|
|||
|
3. the linker input target (see "Linker Input Target" above)
|
|||
|
|
|||
|
|
|||
|
File: binutils.info, Node: Architecture Selection, Next: Linker Emulation Selection, Prev: Target Selection, Up: Selecting The Target System
|
|||
|
|
|||
|
Architecture selection
|
|||
|
======================
|
|||
|
|
|||
|
An "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.
|
|||
|
|
|||
|
The command to list valid architecture values is `objdump -i' (the
|
|||
|
second column contains the relevant information).
|
|||
|
|
|||
|
Sample values: `m68k:68020', `mips:3000', `sparc'.
|
|||
|
|
|||
|
`objdump' Architecture
|
|||
|
----------------------
|
|||
|
|
|||
|
Ways to specify:
|
|||
|
|
|||
|
1. command line option: `-m' or `--architecture'
|
|||
|
|
|||
|
2. deduced from the input file
|
|||
|
|
|||
|
`objcopy', `nm', `size', `strings' Architecture
|
|||
|
-----------------------------------------------
|
|||
|
|
|||
|
Ways to specify:
|
|||
|
|
|||
|
1. deduced from the input file
|
|||
|
|
|||
|
Linker Input Architecture
|
|||
|
-------------------------
|
|||
|
|
|||
|
Ways to specify:
|
|||
|
|
|||
|
1. deduced from the input file
|
|||
|
|
|||
|
Linker Output Architecture
|
|||
|
--------------------------
|
|||
|
|
|||
|
Ways to specify:
|
|||
|
|
|||
|
1. script command `OUTPUT_ARCH' (*note Option Commands:
|
|||
|
(ld.info)Option Commands.)
|
|||
|
|
|||
|
2. the default architecture from the linker output target (*note
|
|||
|
Target Selection::.)
|
|||
|
|
|||
|
|
|||
|
File: binutils.info, Node: Linker Emulation Selection, Prev: Architecture Selection, Up: Selecting The Target System
|
|||
|
|
|||
|
Linker emulation selection
|
|||
|
==========================
|
|||
|
|
|||
|
A linker "emulation" is a "personality" of the linker, which gives
|
|||
|
the linker default values for the other aspects of the target system.
|
|||
|
In particular, it consists of
|
|||
|
|
|||
|
* the linker script
|
|||
|
|
|||
|
* the target
|
|||
|
|
|||
|
* several "hook" functions that are run at certain stages of the
|
|||
|
linking process to do special things that some targets require
|
|||
|
|
|||
|
The command to list valid linker emulation values is `ld -V'.
|
|||
|
|
|||
|
Sample values: `hp300bsd', `mipslit', `sun4'.
|
|||
|
|
|||
|
Ways to specify:
|
|||
|
|
|||
|
1. command line option: `-m' (*note Options: (ld.info)Options.)
|
|||
|
|
|||
|
2. environment variable `LDEMULATION'
|
|||
|
|
|||
|
3. compiled-in `DEFAULT_EMULATION' from `Makefile', which comes from
|
|||
|
`EMUL' in `config/TARGET.mt'
|
|||
|
|
|||
|
|
|||
|
File: binutils.info, Node: Reporting Bugs, Next: Index, Prev: Selecting The Target System, Up: Top
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
File: binutils.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 a binary utility gets a fatal signal, for any input whatever,
|
|||
|
that is a bug. Reliable utilities never crash.
|
|||
|
|
|||
|
* If a binary utility produces an error message for valid input,
|
|||
|
that is a bug.
|
|||
|
|
|||
|
* If you are an experienced user of binary utilities, your
|
|||
|
suggestions for improvement are welcome in any case.
|
|||
|
|
|||
|
|
|||
|
File: binutils.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 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 `etc/SERVICE' in the GNU Emacs distribution.
|
|||
|
|
|||
|
In any event, we also recommend that you send bug reports for the
|
|||
|
binary utilities to `bug-gnu-utils@prep.ai.mit.edu'.
|
|||
|
|
|||
|
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 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 *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 the utility. Each utility 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 the binary utilities.
|
|||
|
|
|||
|
* Any patches you may have applied to the source, including any
|
|||
|
patches made to the `BFD' library.
|
|||
|
|
|||
|
* The type of machine you are using, and the operating system name
|
|||
|
and version number.
|
|||
|
|
|||
|
* What compiler (and its version) was used to compile the
|
|||
|
utilities--e.g. "`gcc-2.7'".
|
|||
|
|
|||
|
* 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.
|
|||
|
|
|||
|
* 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 GNU programs
|
|||
|
(e.g., `gcc', `gas', and/or the GNU `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 `gcc', or whatever, was
|
|||
|
used to produce the object files. Also say how `gcc', or
|
|||
|
whatever, was configured.
|
|||
|
|
|||
|
* 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.
|
|||
|
|
|||
|
* If you wish to suggest changes to the 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 `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.
|
|||
|
|
|||
|
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 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.
|
|||
|
|
|||
|
* 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: binutils.info, Node: Index, Prev: Reporting Bugs, Up: Top
|
|||
|
|
|||
|
Index
|
|||
|
*****
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* .stab: objdump.
|
|||
|
* ar compatibility: ar.
|
|||
|
* nm compatibility: nm.
|
|||
|
* nm format: nm.
|
|||
|
* size display format: size.
|
|||
|
* size number format: size.
|
|||
|
* addr2line: addr2line.
|
|||
|
* address to file name and line number: addr2line.
|
|||
|
* all header information, object file: objdump.
|
|||
|
* ar: ar.
|
|||
|
* architecture: objdump.
|
|||
|
* architectures available: objdump.
|
|||
|
* archive contents: ranlib.
|
|||
|
* archive headers: objdump.
|
|||
|
* archives: ar.
|
|||
|
* bug criteria: Bug Criteria.
|
|||
|
* bug reports: Bug Reporting.
|
|||
|
* bugs: Reporting Bugs.
|
|||
|
* bugs, reporting: Bug Reporting.
|
|||
|
* c++filt: c++filt.
|
|||
|
* collections of files: ar.
|
|||
|
* compatibility, ar: ar.
|
|||
|
* contents of archive: ar cmdline.
|
|||
|
* crash: Bug Criteria.
|
|||
|
* creating archives: ar cmdline.
|
|||
|
* dates in archive: ar cmdline.
|
|||
|
* debug symbols: objdump.
|
|||
|
* debugging symbols: nm.
|
|||
|
* deleting from archive: ar cmdline.
|
|||
|
* demangling C++ symbols: c++filt.
|
|||
|
* demangling in nm: nm.
|
|||
|
* demangling in objdump <1>: objdump.
|
|||
|
* demangling in objdump: addr2line.
|
|||
|
* disassembling object code: objdump.
|
|||
|
* disassembly architecture: objdump.
|
|||
|
* disassembly endianness: objdump.
|
|||
|
* disassembly, with source: objdump.
|
|||
|
* discarding symbols: strip.
|
|||
|
* dynamic relocation entries, in object file: objdump.
|
|||
|
* dynamic symbol table entries, printing: objdump.
|
|||
|
* dynamic symbols: nm.
|
|||
|
* ELF object file format: objdump.
|
|||
|
* endianness: objdump.
|
|||
|
* error on valid input: Bug Criteria.
|
|||
|
* external symbols: nm.
|
|||
|
* extract from archive: ar cmdline.
|
|||
|
* fatal signal: Bug Criteria.
|
|||
|
* file name: nm.
|
|||
|
* header information, all: objdump.
|
|||
|
* input file name: nm.
|
|||
|
* libraries: ar.
|
|||
|
* listings strings: strings.
|
|||
|
* machine instructions: objdump.
|
|||
|
* moving in archive: ar cmdline.
|
|||
|
* MRI compatibility, ar: ar scripts.
|
|||
|
* name duplication in archive: ar cmdline.
|
|||
|
* name length: ar.
|
|||
|
* nm: nm.
|
|||
|
* objdump: objdump.
|
|||
|
* object code format <1>: objdump.
|
|||
|
* object code format <2>: strings.
|
|||
|
* object code format <3>: nm.
|
|||
|
* object code format <4>: size.
|
|||
|
* object code format: addr2line.
|
|||
|
* object file header: objdump.
|
|||
|
* object file information: objdump.
|
|||
|
* object file sections: objdump.
|
|||
|
* object formats available: objdump.
|
|||
|
* operations on archive: ar cmdline.
|
|||
|
* printing from archive: ar cmdline.
|
|||
|
* printing strings: strings.
|
|||
|
* quick append to archive: ar cmdline.
|
|||
|
* radix for section sizes: size.
|
|||
|
* ranlib: ranlib.
|
|||
|
* relative placement in archive: ar cmdline.
|
|||
|
* relocation entries, in object file: objdump.
|
|||
|
* removing symbols: strip.
|
|||
|
* repeated names in archive: ar cmdline.
|
|||
|
* replacement in archive: ar cmdline.
|
|||
|
* reporting bugs: Reporting Bugs.
|
|||
|
* scripts, ar: ar scripts.
|
|||
|
* section addresses in objdump: objdump.
|
|||
|
* section headers: objdump.
|
|||
|
* section information: objdump.
|
|||
|
* section sizes: size.
|
|||
|
* sections, full contents: objdump.
|
|||
|
* size: size.
|
|||
|
* sorting symbols: nm.
|
|||
|
* source disassembly: objdump.
|
|||
|
* source file name: nm.
|
|||
|
* source filenames for object files: objdump.
|
|||
|
* stab: objdump.
|
|||
|
* start-address: objdump.
|
|||
|
* stop-address: objdump.
|
|||
|
* strings: strings.
|
|||
|
* strings, printing: strings.
|
|||
|
* strip: strip.
|
|||
|
* symbol index <1>: ranlib.
|
|||
|
* symbol index: ar.
|
|||
|
* symbol index, listing: nm.
|
|||
|
* symbol line numbers: nm.
|
|||
|
* symbol table entries, printing: objdump.
|
|||
|
* symbols: nm.
|
|||
|
* symbols, discarding: strip.
|
|||
|
* undefined symbols: nm.
|
|||
|
* Unix compatibility, ar: ar cmdline.
|
|||
|
* updating an archive: ar cmdline.
|
|||
|
* version: Top.
|
|||
|
* VMA in objdump: objdump.
|
|||
|
* wide output, printing: objdump.
|
|||
|
* writing archive index: ar cmdline.
|
|||
|
|
|||
|
|