mirror of
https://github.com/darlinghq/darling-gdb.git
synced 2025-01-31 14:04:12 +00:00
Fixed minor typos.
This commit is contained in:
parent
2791be2f81
commit
188d6d224e
@ -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
|
||||
|
||||
|
@ -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.
|
||||
*/
|
||||
|
||||
|
19
bfd/bfd.c
19
bfd/bfd.c
@ -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;
|
||||
$};
|
||||
|
@ -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
|
||||
|
||||
|
@ -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));
|
||||
|
@ -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 *));
|
||||
|
||||
|
@ -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 *));
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
Loading…
x
Reference in New Issue
Block a user