Fixed minor typos.

This commit is contained in:
Roland Pesch 1991-08-19 23:03:12 +00:00
parent 2791be2f81
commit 188d6d224e
9 changed files with 42 additions and 38 deletions

View File

@ -1,8 +1,11 @@
Mon Aug 19 13:48:22 1991 Roland H. Pesch (pesch at cygint.cygnus.com)
* bfd.texinfo: use @setchapternewpage on instead of lots of
@page's; minor rephrasing in Introduction.
* aoutx.h, archive.c, archures.c, bfd.c, bfd.texinfo, cache.c,
coffcode.h, core.c, format.c, libbfd.c, libbfd.h, libcoff.h,
opncls.c, reloc.c, section.c, syms.c, targets.c (documentation
coffcode.h, core.c, format.c, ieee.c, libbfd.c, libbfd.h, libcoff.h,
oasys.c, opncls.c, reloc.c, section.c, syms.c, targets.c (documentation
segments): used BFD (caps) more consistently as a name in
discourse, fixed a few other minor typos and uses of fonts

View File

@ -22,7 +22,7 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */
@section Architectures
BFD's idea of an architecture is implimented in @code{archures.c}. BFD
keeps two atoms in a BFD describing the architecture of the data
attatched to the BFD, the @code{enum bfd_architecture arch} field and
attached to the BFD, the @code{enum bfd_architecture arch} field and
the @code{unsigned long machine} field.
*/

View File

@ -24,10 +24,10 @@ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */
@section typedef bfd
Pointers to bfd structs are the cornerstone of any application using
libbfd. References though the BFD and to data in the BFD give the
@code{libbfd}. References though the BFD and to data in the BFD give the
entire BFD functionality.
Finally! The BFD struct itself. This contains the major data about
Here is the BFD struct itself. This contains the major data about
the file, and contains pointers to the rest of the data.
*+++
@ -62,12 +62,13 @@ the back end.
$ boolean target_defaulted;
The caching routines use these to maintain an LRU list of BFDs.
The caching routines use these to maintain a least-recently-used list of
BFDs (@pxref{File Caching}).
$ struct _bfd *lru_prev, *lru_next;
When a file is closed by the caching routines, it retains the state
here:
When a file is closed by the caching routines, BFD retains state
information on the file here:
$ file_ptr where;
@ -117,14 +118,14 @@ The number of sections
$ unsigned int section_count;
Stuff only usefull for object files:
Stuff only useful for object files:
The start address.
$ bfd_vma start_address;
Used for input and output
$ unsigned int symcount;
Symtab for output BFD
Symbol table for output BFD
$ struct symbol_cache_entry **outsymbols;
@ -136,7 +137,7 @@ Particular machine within arch, e.g. 68010
$ unsigned long obj_machine;
Stuff only usefull for archives:
Stuff only useful for archives:
$ PTR arelt_data;
$ struct _bfd *my_archive;
@ -152,7 +153,7 @@ Used by the application to hold private data
$ PTR usrdata;
Where all the allocated stuff under this BFD goes
Where all the allocated stuff under this BFD goes (@pxref{Memory Usage}).
$ struct obstack memory;
$};

View File

@ -29,6 +29,7 @@ into another language, under the above conditions for modified versions.
@end ifinfo
@iftex
@c@finalout
@setchapternewpage on
@c@setchapternewpage odd
@settitle LIB BFD, the Binary File Descriptor Library
@titlepage
@ -324,13 +325,13 @@ which can simply derive this information can pass it successfully
between formats (COFF, IEEE and Oasys).
@end table
What is a backend
@c FIXME: what is this line about? Do we want introductory remarks
@c FIXME... on back ends? commented out for now.
@c What is a backend
@node BFD front end, BFD back end, Mechanism, Top
@page
@chapter BFD front end
@include bfd.texi
@page
@node Memory Usage, Sections, bfd, Top
@section Memory Usage
BFD keeps all its internal structures in obstacks. There is one obstack
@ -355,37 +356,37 @@ operation and reopen the BFD again, to get a fresh copy of the data structures.
@node Sections,Symbols ,Memory Usage, Top
@include section.texi
@page
@node Symbols, Archives ,Sections, To
@include syms.texi
@page
@node Archives, Formats, Symbols, Top
@include archive.texi
@page
@node Formats, Relocations, Archives, Top
@include format.texi
@page
@node Relocations, Core Files,Formats, Top
@include reloc.texi
@page
@node Core Files, Targets, Relocations, Top
@include core.texi
@page
@node Targets, Architectures, Core Files, Top
@include targets.texi
@page
@node Architectures, Opening and Closing, Targets, Top
@include archures.texi
@page
@node Opening and Closing, Internal, Architectures, Top
@include opncls.texi
@page
@node Internal, File Caching, Opening and Closing, Top
@include libbfd.texi
@page
@node File Caching, Top, Internal, Top
@include cache.texi
@page
@chapter BFD back end
@node BFD back end, ,BFD front end, Top
@menu
@ -398,17 +399,16 @@ operation and reopen the BFD again, to get a fresh copy of the data structures.
@end menu
@node What to Put Where, aout backends, BFD back end, BFD back end
All of BFD lives in one directory.
@page
@node aout backends, coff backends, What to Put Where, BFD back end
@include aoutx.texi
@page
@node coff backends, oasys backends, aout backends, BFD back end
@include coffcode.texi
@page
@node Index, , BFD, Top
@unnumbered Function Index
@printindex fn
@setchapternewpage on
@unnumbered Index
@printindex cp

View File

@ -49,7 +49,7 @@ DEFUN(bfd_core_file_failing_command,(abfd),
/*proto* bfd_core_file_failing_signal
Returns the signal number which caused the core dump which generated
the file the BFD is attatched to.
the file the BFD is attached to.
*; PROTO(int, bfd_core_file_failing_signal, (bfd *));
*/
@ -66,8 +66,8 @@ bfd_core_file_failing_signal (abfd)
/*proto* core_file_matches_executable_p
Returns @code{true} if the core file attatched to @var{core_bfd} was
generated by a run of the executable file attatched to @var{exec_bfd},
Returns @code{true} if the core file attached to @var{core_bfd} was
generated by a run of the executable file attached to @var{exec_bfd},
or else @code{false}.
*; PROTO(boolean, core_file_matches_executable_p,
(bfd *core_bfd, bfd *exec_bfd));

View File

@ -232,7 +232,7 @@ Initialize a BFD by putting it on the cache LRU.
/*
*i bfd_cache_close
Remove the BFD from the cache. If the attatched file is open, then close it too.
Remove the BFD from the cache. If the attached file is open, then close it too.
*/
PROTO(void, bfd_cache_close, (bfd *));

View File

@ -282,7 +282,7 @@ pending operations are completed and the file written out and closed.
If the created file is executable, then @code{chmod} is called to mark
it as such.
All memory attatched to the BFD's obstacks is released.
All memory attached to the BFD's obstacks is released.
@code{true} is returned if all is ok, otherwise @code{false}.
*; PROTO(boolean, bfd_close,(bfd *));

View File

@ -136,7 +136,7 @@ returned by the back end's get_symtab action. @xref{Symbols}. The
symbol is referenced through a pointer to a pointer so that tools like
the linker can fixup all the symbols of the same name by modifying
only one pointer. The relocation routine looks in the symbol and uses
the base of the section the symbol is attatched to and the value of
the base of the section the symbol is attached to and the value of
the symbol as the initial relocation offset. If the symbol pointer is
zero, then the section provided is looked up.
@item address

View File

@ -85,7 +85,7 @@ the BFD, and is freed when the BFD is closed.
@node Writing Symbols, typedef asymbol, Reading Symbols, Symbols
@subsection Writing Symbols
Writing of a symbol table is automatic when a BFD open for writing
is closed. The application attatches a vector of pointers to pointers to symbols
is closed. The application attaches a vector of pointers to pointers to symbols
to the BFD being written, and fills in the symbol count. The close and
cleanup code reads through the table provided and performs all the
necessary operations. The outputing code must always be provided with