Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/gnu/dist/binutils/binutils.info-2

772 lines
28 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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.
Reference in New Issue View Git Blame Copy Permalink