1999-10-08 Ben Elliston <bje@cygnus.com>

* binutils.texi: Some rewording and clarifications.
This commit is contained in:
Ian Lance Taylor 1999-10-08 13:56:33 +00:00
parent 0af9979518
commit f20a759a4d
2 changed files with 19 additions and 14 deletions

View file

@ -1,3 +1,7 @@
1999-10-08 Ben Elliston <bje@cygnus.com>
* binutils.texi: Some rewording and clarifications.
1999-09-15 Ulrich Drepper <drepper@cygnus.com>
* readelf.c (dynamic_segment_parisc_val): Print 0 for DLD_FLAGS if

View file

@ -641,7 +641,7 @@ nm [ -a | --debug-syms ] [ -g | --extern-only ]
@end smallexample
@sc{gnu} @code{nm} lists the symbols from object files @var{objfile}@dots{}.
If no object files are listed as arguments, @code{nm} assumes
If no object files are listed as arguments, @code{nm} assumes the file
@file{a.out}.
For each symbol, @code{nm} shows:
@ -731,7 +731,7 @@ equivalent.
@cindex input file name
@cindex file name
@cindex source file name
Precede each symbol by the name of the input file (or archive element)
Precede each symbol by the name of the input file (or archive member)
in which it was found, rather than identifying the input file once only,
before all of its symbols.
@ -908,12 +908,12 @@ the load address of the lowest section copied into the output file.
When generating an S-record or a raw binary file, it may be helpful to
use @samp{-S} to remove sections containing debugging information. In
some cases @samp{-R} will be useful to remove sections which contain
information which is not needed by the binary file.
information that is not needed by the binary file.
@table @code
@item @var{infile}
@itemx @var{outfile}
The source and output files, respectively.
The input and output files, respectively.
If you do not specify @var{outfile}, @code{objcopy} creates a
temporary file and destructively renames the result with
the name of @var{infile}.
@ -1024,7 +1024,7 @@ done by increasing the size of the last section. The extra space is
filled in with the value specified by @samp{--gap-fill} (default zero).
@item --set-start @var{val}
Set the address of the new file to @var{val}. Not all object file
Set the start address of the new file to @var{val}. Not all object file
formats support setting the start address.
@item --change-start @var{incr}
@ -1465,6 +1465,7 @@ The @sc{gnu} @code{ranlib} program is another form of @sc{gnu} @code{ar}; runnin
@table @code
@item -v
@itemx -V
@itemx --version
Show the version number of @code{ranlib}.
@end table
@ -1508,7 +1509,7 @@ Berkeley's.
Here is an example of the Berkeley (default) format of output from
@code{size}:
@smallexample
size --format=Berkeley ranlib size
$ size --format=Berkeley ranlib size
text data bss dec hex filename
294880 81920 11592 388392 5ed28 ranlib
294880 81920 11888 388688 5ee50 size
@ -1518,7 +1519,7 @@ text data bss dec hex filename
This is the same data, but displayed closer to System V conventions:
@smallexample
size --format=SysV ranlib size
$ size --format=SysV ranlib size
ranlib :
section size addr
.text 294880 8192
@ -1859,7 +1860,7 @@ 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 @code{-e} option. The
default is @file{a.out}.
default is the file @file{a.out}.
@code{addr2line} has two modes of operation.
@ -2551,9 +2552,9 @@ Some sample values are: @samp{a.out-hp300bsd}, @samp{ecoff-littlemips},
@samp{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
the same sort of name that is passed to @file{configure} to specify a
target. When you use a configuration triplet as an argument, it must be
fully canonicalized. You can see the canonical version of a triplet by
running the shell script @file{config.sub} which is included with the
sources.
@ -2897,7 +2898,7 @@ 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
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
@ -2909,8 +2910,8 @@ to draw any conclusion from our observations.
If you wish to suggest changes to the source, send us context diffs, as
generated by @code{diff} with the @samp{-u}, @samp{-c}, or @samp{-p}
option. Always send diffs from the old file to the new file. If you
even discuss something in the @code{ld} source, refer to it by context,
not by line number.
wish to discuss something in the @code{ld} source, refer to it by
context, not by line number.
The line numbers in our development sources will not match those in your
sources. Your line numbers would convey no useful information to us.