mirror of
https://frontier.innolan.net/github/amigaos-binutils.git
synced 2026-09-13 09:33:07 +00:00
1026 lines
44 KiB
Plaintext
1026 lines
44 KiB
Plaintext
This is binutils.info, produced by makeinfo version 4.3 from
|
|
binutils.texi.
|
|
|
|
START-INFO-DIR-ENTRY
|
|
* Binutils: (binutils). The GNU binary utilities.
|
|
* ar: (binutils)ar. Create, modify, and extract from archives
|
|
* nm: (binutils)nm. List symbols from object files
|
|
* objcopy: (binutils)objcopy. Copy and translate object files
|
|
* objdump: (binutils)objdump. Display information from object files
|
|
* ranlib: (binutils)ranlib. Generate index to archive contents
|
|
* readelf: (binutils)readelf. Display the contents of ELF format files.
|
|
* size: (binutils)size. List section sizes and total size
|
|
* strings: (binutils)strings. List printable strings from files
|
|
* strip: (binutils)strip. Discard symbols
|
|
* c++filt: (binutils)c++filt. Filter to demangle encoded C++ symbols
|
|
* cxxfilt: (binutils)c++filt. MS-DOS name for c++filt
|
|
* addr2line: (binutils)addr2line. Convert addresses to file and line
|
|
* nlmconv: (binutils)nlmconv. Converts object code into an NLM
|
|
* windres: (binutils)windres. Manipulate Windows resources
|
|
* dlltool: (binutils)dlltool. Create files needed to build and use DLLs
|
|
END-INFO-DIR-ENTRY
|
|
|
|
Copyright (C) 1991, 92, 93, 94, 95, 96, 97, 98, 99, 2000, 2001,
|
|
2002, 2003 Free Software Foundation, Inc.
|
|
|
|
Permission is granted to copy, distribute and/or modify this document
|
|
under the terms of the GNU Free Documentation License, Version 1.1 or
|
|
any later version published by the Free Software Foundation; with no
|
|
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
|
Texts. A copy of the license is included in the section entitled "GNU
|
|
Free Documentation License".
|
|
|
|
|
|
File: binutils.info, Node: readelf, Next: size, Prev: ranlib, Up: Top
|
|
|
|
readelf
|
|
*******
|
|
|
|
readelf [`-a'|`--all']
|
|
[`-h'|`--file-header']
|
|
[`-l'|`--program-headers'|`--segments']
|
|
[`-S'|`--section-headers'|`--sections']
|
|
[`-e'|`--headers']
|
|
[`-s'|`--syms'|`--symbols']
|
|
[`-n'|`--notes']
|
|
[`-r'|`--relocs']
|
|
[`-u'|`--unwind']
|
|
[`-d'|`--dynamic']
|
|
[`-V'|`--version-info']
|
|
[`-A'|`--arch-specific']
|
|
[`-D'|`--use-dynamic']
|
|
[`-x' <number>|`--hex-dump='<number>]
|
|
[`-w[liaprmfFso]'|
|
|
`--debug-dump'[=line,=info,=abbrev,=pubnames,=ranges,=macro,=frames,=frames-interp,=str,=loc]]
|
|
[`-I'|`-histogram']
|
|
[`-v'|`--version']
|
|
[`-W'|`--wide']
|
|
[`-H'|`--help']
|
|
ELFFILE...
|
|
|
|
`readelf' displays information about one or more ELF format object
|
|
files. The options control what particular information to display.
|
|
|
|
ELFFILE... are the object files to be examined. At the moment,
|
|
`readelf' does not support examining archives, nor does it support
|
|
examining 64 bit ELF files.
|
|
|
|
The long and short forms of options, shown here as alternatives, are
|
|
equivalent. At least one option besides `-v' or `-H' must be given.
|
|
|
|
`-a'
|
|
`--all'
|
|
Equivalent to specifiying `--file-header', `--program-headers',
|
|
`--sections', `--symbols', `--relocs', `--dynamic', `--notes' and
|
|
`--version-info'.
|
|
|
|
`-h'
|
|
`--file-header'
|
|
Displays the information contained in the ELF header at the start
|
|
of the file.
|
|
|
|
`-l'
|
|
`--program-headers'
|
|
`--segments'
|
|
Displays the information contained in the file's segment headers,
|
|
if it has any.
|
|
|
|
`-S'
|
|
`--sections'
|
|
`--section-headers'
|
|
Displays the information contained in the file's section headers,
|
|
if it has any.
|
|
|
|
`-s'
|
|
`--symbols'
|
|
`--syms'
|
|
Displays the entries in symbol table section of the file, if it
|
|
has one.
|
|
|
|
`-e'
|
|
`--headers'
|
|
Display all the headers in the file. Equivalent to `-h -l -S'.
|
|
|
|
`-n'
|
|
`--notes'
|
|
Displays the contents of the NOTE segment, if it exists.
|
|
|
|
`-r'
|
|
`--relocs'
|
|
Displays the contents of the file's relocation section, if it has
|
|
one.
|
|
|
|
`-u'
|
|
`--unwind'
|
|
Displays the contents of the file's unwind section, if it has one.
|
|
Only the unwind sections for IA64 ELF files are currently
|
|
supported.
|
|
|
|
`-u'
|
|
`--unwind'
|
|
Displays the contents of the file's unwind section, if it has one.
|
|
Only the unwind sections for IA64 ELF files are currently
|
|
supported.
|
|
|
|
`-d'
|
|
`--dynamic'
|
|
Displays the contents of the file's dynamic section, if it has one.
|
|
|
|
`-V'
|
|
`--version-info'
|
|
Displays the contents of the version sections in the file, it they
|
|
exist.
|
|
|
|
`-A'
|
|
`--arch-specific'
|
|
Displays architecture-specific information in the file, if there
|
|
is any.
|
|
|
|
`-D'
|
|
`--use-dynamic'
|
|
When displaying symbols, this option makes `readelf' use the
|
|
symbol table in the file's dynamic section, rather than the one in
|
|
the symbols section.
|
|
|
|
`-x <number>'
|
|
`--hex-dump=<number>'
|
|
Displays the contents of the indicated section as a hexadecimal
|
|
dump.
|
|
|
|
`-w[liaprmfFso]'
|
|
`--debug-dump[=line,=info,=abbrev,=pubnames,=ranges,=macro,=frames,=frames-interp,=str,=loc]'
|
|
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.
|
|
|
|
`-I'
|
|
`--histogram'
|
|
Display a histogram of bucket list lengths when displaying the
|
|
contents of the symbol tables.
|
|
|
|
`-v'
|
|
`--version'
|
|
Display the version number of readelf.
|
|
|
|
`-W'
|
|
`--wide'
|
|
Don't break output lines to fit into 80 columns. By default
|
|
`readelf' breaks section header and segment listing lines for
|
|
64-bit ELF files, so that they fit into 80 columns. This option
|
|
causes `readelf' to print each section header resp. each segment
|
|
one a single line, which is far more readable on terminals wider
|
|
than 80 columns.
|
|
|
|
`-H'
|
|
`--help'
|
|
Display the command line options understood by `readelf'.
|
|
|
|
|
|
File: binutils.info, Node: Selecting The Target System, Next: Reporting Bugs, Prev: dlltool, Up: Top
|
|
|
|
Selecting the Target System
|
|
***************************
|
|
|
|
You can specify two aspects of the target system to the GNU binary
|
|
file utilities, each in several ways:
|
|
|
|
* the target
|
|
|
|
* the architecture
|
|
|
|
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::
|
|
|
|
|
|
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
|
|
|
|
|
|
File: binutils.info, Node: Architecture 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
|
|
|
|
|
|
File: binutils.info, Node: Reporting Bugs, Next: GNU Free Documentation License, 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-binutils@gnu.org'.
|
|
|
|
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?" This cannot help us fix a bug, so it is basically useless. We
|
|
respond by asking for enough details to enable us to investigate. You
|
|
might as well expedite matters by sending them to begin with.
|
|
|
|
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. Note
|
|
that `bug-binutils@gnu.org' is a mailing list, so you should avoid
|
|
sending very large files to it. Making the files available for
|
|
anonymous FTP is OK.
|
|
|
|
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 wish
|
|
to 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: GNU Free Documentation License, Next: Index, Prev: Reporting Bugs, Up: Top
|
|
|
|
GNU Free Documentation License
|
|
******************************
|
|
|
|
Version 1.1, March 2000
|
|
Copyright (C) 2000 Free Software Foundation, Inc.
|
|
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
Everyone is permitted to copy and distribute verbatim copies
|
|
of this license document, but changing it is not allowed.
|
|
|
|
|
|
0. PREAMBLE
|
|
|
|
The purpose of this License is to make a manual, textbook, or other
|
|
written document "free" in the sense of freedom: to assure everyone
|
|
the effective freedom to copy and redistribute it, with or without
|
|
modifying it, either commercially or noncommercially. Secondarily,
|
|
this License preserves for the author and publisher a way to get
|
|
credit for their work, while not being considered responsible for
|
|
modifications made by others.
|
|
|
|
This License is a kind of "copyleft", which means that derivative
|
|
works of the document must themselves be free in the same sense.
|
|
It complements the GNU General Public License, which is a copyleft
|
|
license designed for free software.
|
|
|
|
We have designed this License in order to use it for manuals for
|
|
free software, because free software needs free documentation: a
|
|
free program should come with manuals providing the same freedoms
|
|
that the software does. But this License is not limited to
|
|
software manuals; it can be used for any textual work, regardless
|
|
of subject matter or whether it is published as a printed book.
|
|
We recommend this License principally for works whose purpose is
|
|
instruction or reference.
|
|
|
|
|
|
1. APPLICABILITY AND DEFINITIONS
|
|
|
|
This License applies to any manual or other work that contains a
|
|
notice placed by the copyright holder saying it can be distributed
|
|
under the terms of this License. The "Document", below, refers to
|
|
any such manual or work. Any member of the public is a licensee,
|
|
and is addressed as "you."
|
|
|
|
A "Modified Version" of the Document means any work containing the
|
|
Document or a portion of it, either copied verbatim, or with
|
|
modifications and/or translated into another language.
|
|
|
|
A "Secondary Section" is a named appendix or a front-matter
|
|
section of the Document that deals exclusively with the
|
|
relationship of the publishers or authors of the Document to the
|
|
Document's overall subject (or to related matters) and contains
|
|
nothing that could fall directly within that overall subject.
|
|
(For example, if the Document is in part a textbook of
|
|
mathematics, a Secondary Section may not explain any mathematics.)
|
|
The relationship could be a matter of historical connection with
|
|
the subject or with related matters, or of legal, commercial,
|
|
philosophical, ethical or political position regarding them.
|
|
|
|
The "Invariant Sections" are certain Secondary Sections whose
|
|
titles are designated, as being those of Invariant Sections, in
|
|
the notice that says that the Document is released under this
|
|
License.
|
|
|
|
The "Cover Texts" are certain short passages of text that are
|
|
listed, as Front-Cover Texts or Back-Cover Texts, in the notice
|
|
that says that the Document is released under this License.
|
|
|
|
A "Transparent" copy of the Document means a machine-readable copy,
|
|
represented in a format whose specification is available to the
|
|
general public, whose contents can be viewed and edited directly
|
|
and straightforwardly with generic text editors or (for images
|
|
composed of pixels) generic paint programs or (for drawings) some
|
|
widely available drawing editor, and that is suitable for input to
|
|
text formatters or for automatic translation to a variety of
|
|
formats suitable for input to text formatters. A copy made in an
|
|
otherwise Transparent file format whose markup has been designed
|
|
to thwart or discourage subsequent modification by readers is not
|
|
Transparent. A copy that is not "Transparent" is called "Opaque."
|
|
|
|
Examples of suitable formats for Transparent copies include plain
|
|
ASCII without markup, Texinfo input format, LaTeX input format,
|
|
SGML or XML using a publicly available DTD, and
|
|
standard-conforming simple HTML designed for human modification.
|
|
Opaque formats include PostScript, PDF, proprietary formats that
|
|
can be read and edited only by proprietary word processors, SGML
|
|
or XML for which the DTD and/or processing tools are not generally
|
|
available, and the machine-generated HTML produced by some word
|
|
processors for output purposes only.
|
|
|
|
The "Title Page" means, for a printed book, the title page itself,
|
|
plus such following pages as are needed to hold, legibly, the
|
|
material this License requires to appear in the title page. For
|
|
works in formats which do not have any title page as such, "Title
|
|
Page" means the text near the most prominent appearance of the
|
|
work's title, preceding the beginning of the body of the text.
|
|
|
|
2. VERBATIM COPYING
|
|
|
|
You may copy and distribute the Document in any medium, either
|
|
commercially or noncommercially, provided that this License, the
|
|
copyright notices, and the license notice saying this License
|
|
applies to the Document are reproduced in all copies, and that you
|
|
add no other conditions whatsoever to those of this License. You
|
|
may not use technical measures to obstruct or control the reading
|
|
or further copying of the copies you make or distribute. However,
|
|
you may accept compensation in exchange for copies. If you
|
|
distribute a large enough number of copies you must also follow
|
|
the conditions in section 3.
|
|
|
|
You may also lend copies, under the same conditions stated above,
|
|
and you may publicly display copies.
|
|
|
|
3. COPYING IN QUANTITY
|
|
|
|
If you publish printed copies of the Document numbering more than
|
|
100, and the Document's license notice requires Cover Texts, you
|
|
must enclose the copies in covers that carry, clearly and legibly,
|
|
all these Cover Texts: Front-Cover Texts on the front cover, and
|
|
Back-Cover Texts on the back cover. Both covers must also clearly
|
|
and legibly identify you as the publisher of these copies. The
|
|
front cover must present the full title with all words of the
|
|
title equally prominent and visible. You may add other material
|
|
on the covers in addition. Copying with changes limited to the
|
|
covers, as long as they preserve the title of the Document and
|
|
satisfy these conditions, can be treated as verbatim copying in
|
|
other respects.
|
|
|
|
If the required texts for either cover are too voluminous to fit
|
|
legibly, you should put the first ones listed (as many as fit
|
|
reasonably) on the actual cover, and continue the rest onto
|
|
adjacent pages.
|
|
|
|
If you publish or distribute Opaque copies of the Document
|
|
numbering more than 100, you must either include a
|
|
machine-readable Transparent copy along with each Opaque copy, or
|
|
state in or with each Opaque copy a publicly-accessible
|
|
computer-network location containing a complete Transparent copy
|
|
of the Document, free of added material, which the general
|
|
network-using public has access to download anonymously at no
|
|
charge using public-standard network protocols. If you use the
|
|
latter option, you must take reasonably prudent steps, when you
|
|
begin distribution of Opaque copies in quantity, to ensure that
|
|
this Transparent copy will remain thus accessible at the stated
|
|
location until at least one year after the last time you
|
|
distribute an Opaque copy (directly or through your agents or
|
|
retailers) of that edition to the public.
|
|
|
|
It is requested, but not required, that you contact the authors of
|
|
the Document well before redistributing any large number of
|
|
copies, to give them a chance to provide you with an updated
|
|
version of the Document.
|
|
|
|
4. MODIFICATIONS
|
|
|
|
You may copy and distribute a Modified Version of the Document
|
|
under the conditions of sections 2 and 3 above, provided that you
|
|
release the Modified Version under precisely this License, with
|
|
the Modified Version filling the role of the Document, thus
|
|
licensing distribution and modification of the Modified Version to
|
|
whoever possesses a copy of it. In addition, you must do these
|
|
things in the Modified Version:
|
|
|
|
A. Use in the Title Page (and on the covers, if any) a title
|
|
distinct from that of the Document, and from those of previous
|
|
versions (which should, if there were any, be listed in the
|
|
History section of the Document). You may use the same title
|
|
as a previous version if the original publisher of that version
|
|
gives permission.
|
|
B. List on the Title Page, as authors, one or more persons or
|
|
entities responsible for authorship of the modifications in the
|
|
Modified Version, together with at least five of the principal
|
|
authors of the Document (all of its principal authors, if it
|
|
has less than five).
|
|
C. State on the Title page the name of the publisher of the
|
|
Modified Version, as the publisher.
|
|
D. Preserve all the copyright notices of the Document.
|
|
E. Add an appropriate copyright notice for your modifications
|
|
adjacent to the other copyright notices.
|
|
F. Include, immediately after the copyright notices, a license
|
|
notice giving the public permission to use the Modified Version
|
|
under the terms of this License, in the form shown in the
|
|
Addendum below.
|
|
G. Preserve in that license notice the full lists of Invariant
|
|
Sections and required Cover Texts given in the Document's
|
|
license notice.
|
|
H. Include an unaltered copy of this License.
|
|
I. Preserve the section entitled "History", and its title, and add
|
|
to it an item stating at least the title, year, new authors, and
|
|
publisher of the Modified Version as given on the Title Page.
|
|
If there is no section entitled "History" in the Document,
|
|
create one stating the title, year, authors, and publisher of
|
|
the Document as given on its Title Page, then add an item
|
|
describing the Modified Version as stated in the previous
|
|
sentence.
|
|
J. Preserve the network location, if any, given in the Document for
|
|
public access to a Transparent copy of the Document, and
|
|
likewise the network locations given in the Document for
|
|
previous versions it was based on. These may be placed in the
|
|
"History" section. You may omit a network location for a work
|
|
that was published at least four years before the Document
|
|
itself, or if the original publisher of the version it refers
|
|
to gives permission.
|
|
K. In any section entitled "Acknowledgements" or "Dedications",
|
|
preserve the section's title, and preserve in the section all the
|
|
substance and tone of each of the contributor acknowledgements
|
|
and/or dedications given therein.
|
|
L. Preserve all the Invariant Sections of the Document,
|
|
unaltered in their text and in their titles. Section numbers
|
|
or the equivalent are not considered part of the section titles.
|
|
M. Delete any section entitled "Endorsements." Such a section
|
|
may not be included in the Modified Version.
|
|
N. Do not retitle any existing section as "Endorsements" or to
|
|
conflict in title with any Invariant Section.
|
|
|
|
If the Modified Version includes new front-matter sections or
|
|
appendices that qualify as Secondary Sections and contain no
|
|
material copied from the Document, you may at your option
|
|
designate some or all of these sections as invariant. To do this,
|
|
add their titles to the list of Invariant Sections in the Modified
|
|
Version's license notice. These titles must be distinct from any
|
|
other section titles.
|
|
|
|
You may add a section entitled "Endorsements", provided it contains
|
|
nothing but endorsements of your Modified Version by various
|
|
parties-for example, statements of peer review or that the text has
|
|
been approved by an organization as the authoritative definition
|
|
of a standard.
|
|
|
|
You may add a passage of up to five words as a Front-Cover Text,
|
|
and a passage of up to 25 words as a Back-Cover Text, to the end
|
|
of the list of Cover Texts in the Modified Version. Only one
|
|
passage of Front-Cover Text and one of Back-Cover Text may be
|
|
added by (or through arrangements made by) any one entity. If the
|
|
Document already includes a cover text for the same cover,
|
|
previously added by you or by arrangement made by the same entity
|
|
you are acting on behalf of, you may not add another; but you may
|
|
replace the old one, on explicit permission from the previous
|
|
publisher that added the old one.
|
|
|
|
The author(s) and publisher(s) of the Document do not by this
|
|
License give permission to use their names for publicity for or to
|
|
assert or imply endorsement of any Modified Version.
|
|
|
|
5. COMBINING DOCUMENTS
|
|
|
|
You may combine the Document with other documents released under
|
|
this License, under the terms defined in section 4 above for
|
|
modified versions, provided that you include in the combination
|
|
all of the Invariant Sections of all of the original documents,
|
|
unmodified, and list them all as Invariant Sections of your
|
|
combined work in its license notice.
|
|
|
|
The combined work need only contain one copy of this License, and
|
|
multiple identical Invariant Sections may be replaced with a single
|
|
copy. If there are multiple Invariant Sections with the same name
|
|
but different contents, make the title of each such section unique
|
|
by adding at the end of it, in parentheses, the name of the
|
|
original author or publisher of that section if known, or else a
|
|
unique number. Make the same adjustment to the section titles in
|
|
the list of Invariant Sections in the license notice of the
|
|
combined work.
|
|
|
|
In the combination, you must combine any sections entitled
|
|
"History" in the various original documents, forming one section
|
|
entitled "History"; likewise combine any sections entitled
|
|
"Acknowledgements", and any sections entitled "Dedications." You
|
|
must delete all sections entitled "Endorsements."
|
|
|
|
6. COLLECTIONS OF DOCUMENTS
|
|
|
|
You may make a collection consisting of the Document and other
|
|
documents released under this License, and replace the individual
|
|
copies of this License in the various documents with a single copy
|
|
that is included in the collection, provided that you follow the
|
|
rules of this License for verbatim copying of each of the
|
|
documents in all other respects.
|
|
|
|
You may extract a single document from such a collection, and
|
|
distribute it individually under this License, provided you insert
|
|
a copy of this License into the extracted document, and follow
|
|
this License in all other respects regarding verbatim copying of
|
|
that document.
|
|
|
|
7. AGGREGATION WITH INDEPENDENT WORKS
|
|
|
|
A compilation of the Document or its derivatives with other
|
|
separate and independent documents or works, in or on a volume of
|
|
a storage or distribution medium, does not as a whole count as a
|
|
Modified Version of the Document, provided no compilation
|
|
copyright is claimed for the compilation. Such a compilation is
|
|
called an "aggregate", and this License does not apply to the
|
|
other self-contained works thus compiled with the Document, on
|
|
account of their being thus compiled, if they are not themselves
|
|
derivative works of the Document.
|
|
|
|
If the Cover Text requirement of section 3 is applicable to these
|
|
copies of the Document, then if the Document is less than one
|
|
quarter of the entire aggregate, the Document's Cover Texts may be
|
|
placed on covers that surround only the Document within the
|
|
aggregate. Otherwise they must appear on covers around the whole
|
|
aggregate.
|
|
|
|
8. TRANSLATION
|
|
|
|
Translation is considered a kind of modification, so you may
|
|
distribute translations of the Document under the terms of section
|
|
4. Replacing Invariant Sections with translations requires special
|
|
permission from their copyright holders, but you may include
|
|
translations of some or all Invariant Sections in addition to the
|
|
original versions of these Invariant Sections. You may include a
|
|
translation of this License provided that you also include the
|
|
original English version of this License. In case of a
|
|
disagreement between the translation and the original English
|
|
version of this License, the original English version will prevail.
|
|
|
|
9. TERMINATION
|
|
|
|
You may not copy, modify, sublicense, or distribute the Document
|
|
except as expressly provided for under this License. Any other
|
|
attempt to copy, modify, sublicense or distribute the Document is
|
|
void, and will automatically terminate your rights under this
|
|
License. However, parties who have received copies, or rights,
|
|
from you under this License will not have their licenses
|
|
terminated so long as such parties remain in full compliance.
|
|
|
|
10. FUTURE REVISIONS OF THIS LICENSE
|
|
|
|
The Free Software Foundation may publish new, revised versions of
|
|
the GNU Free Documentation License from time to time. Such new
|
|
versions will be similar in spirit to the present version, but may
|
|
differ in detail to address new problems or concerns. See
|
|
http://www.gnu.org/copyleft/.
|
|
|
|
Each version of the License is given a distinguishing version
|
|
number. If the Document specifies that a particular numbered
|
|
version of this License "or any later version" applies to it, you
|
|
have the option of following the terms and conditions either of
|
|
that specified version or of any later version that has been
|
|
published (not as a draft) by the Free Software Foundation. If
|
|
the Document does not specify a version number of this License,
|
|
you may choose any version ever published (not as a draft) by the
|
|
Free Software Foundation.
|
|
|
|
|
|
ADDENDUM: How to use this License for your documents
|
|
====================================================
|
|
|
|
To use this License in a document you have written, include a copy of
|
|
the License in the document and put the following copyright and license
|
|
notices just after the title page:
|
|
|
|
Copyright (C) YEAR YOUR NAME.
|
|
Permission is granted to copy, distribute and/or modify this document
|
|
under the terms of the GNU Free Documentation License, Version 1.1
|
|
or any later version published by the Free Software Foundation;
|
|
with the Invariant Sections being LIST THEIR TITLES, with the
|
|
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
|
|
A copy of the license is included in the section entitled "GNU
|
|
Free Documentation License."
|
|
|
|
If you have no Invariant Sections, write "with no Invariant Sections"
|
|
instead of saying which ones are invariant. If you have no Front-Cover
|
|
Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being
|
|
LIST"; likewise for Back-Cover Texts.
|
|
|
|
If your document contains nontrivial examples of program code, we
|
|
recommend releasing these examples in parallel under your choice of
|
|
free software license, such as the GNU General Public License, to
|
|
permit their use in free software.
|
|
|
|
|
|
File: binutils.info, Node: Index, Prev: GNU Free Documentation License, Up: Top
|
|
|
|
Index
|
|
*****
|
|
|
|
* Menu:
|
|
|
|
* .stab: objdump.
|
|
* addr2line: addr2line.
|
|
* address to file name and line number: addr2line.
|
|
* all header information, object file: objdump.
|
|
* ar: ar.
|
|
* ar compatibility: ar.
|
|
* architecture: objdump.
|
|
* architectures available: objdump.
|
|
* archive contents: ranlib.
|
|
* archive headers: objdump.
|
|
* archives: ar.
|
|
* base files: dlltool.
|
|
* bug criteria: Bug Criteria.
|
|
* bug reports: Bug Reporting.
|
|
* bugs: Reporting Bugs.
|
|
* bugs, reporting: Bug Reporting.
|
|
* c++filt: c++filt.
|
|
* changing object addresses: objcopy.
|
|
* changing section address: objcopy.
|
|
* changing section LMA: objcopy.
|
|
* changing section VMA: objcopy.
|
|
* changing start address: objcopy.
|
|
* collections of files: ar.
|
|
* compatibility, ar: ar.
|
|
* contents of archive: ar cmdline.
|
|
* crash: Bug Criteria.
|
|
* creating archives: ar cmdline.
|
|
* cxxfilt: c++filt.
|
|
* 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>: addr2line.
|
|
* demangling in objdump: objdump.
|
|
* disassembling object code: objdump.
|
|
* disassembly architecture: objdump.
|
|
* disassembly endianness: objdump.
|
|
* disassembly, with source: objdump.
|
|
* discarding symbols: strip.
|
|
* DLL: dlltool.
|
|
* dlltool: dlltool.
|
|
* dynamic relocation entries, in object file: objdump.
|
|
* dynamic symbol table entries, printing: objdump.
|
|
* dynamic symbols: nm.
|
|
* ELF core notes: readelf.
|
|
* ELF dynamic section information: readelf.
|
|
* ELF file header information: readelf.
|
|
* ELF file information: readelf.
|
|
* ELF object file format: objdump.
|
|
* ELF program header information: readelf.
|
|
* ELF reloc information: readelf.
|
|
* ELF section information: readelf.
|
|
* ELF segment information: readelf.
|
|
* ELF symbol table information: readelf.
|
|
* ELF version sections informations: readelf.
|
|
* 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 .def file: dlltool.
|
|
* 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.
|
|
* nm compatibility: nm.
|
|
* nm format: nm.
|
|
* not writing archive index: ar cmdline.
|
|
* objdump: objdump.
|
|
* object code format <1>: addr2line.
|
|
* object code format <2>: strings.
|
|
* object code format <3>: size.
|
|
* object code format <4>: objdump.
|
|
* object code format: nm.
|
|
* 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.
|
|
* readelf: readelf.
|
|
* 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.
|
|
* size display format: size.
|
|
* size number format: size.
|
|
* sorting symbols: nm.
|
|
* source code context: objdump.
|
|
* 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.
|
|
* unwind information: readelf.
|
|
* updating an archive: ar cmdline.
|
|
* version: Top.
|
|
* VMA in objdump: objdump.
|
|
* wide output, printing: objdump.
|
|
* writing archive index: ar cmdline.
|
|
|
|
|