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