OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

Compare Revisions

  • This comparison shows the changes necessary to convert path 
    /or1k/tags/start/gdb-5.0/bfd/doc
    from Rev 579 to Rev 1765
    ↔ Reverse comparison
  •

Rev 579 → Rev 1765

/coffcode.texi
0,0 → 1,666
@section coff backends
BFD supports a number of different flavours of coff format.
The major differences between formats are the sizes and
alignments of fields in structures on disk, and the occasional
extra field.
 
Coff in all its varieties is implemented with a few common
files and a number of implementation specific files. For
example, The 88k bcs coff format is implemented in the file
@file{coff-m88k.c}. This file @code{#include}s
@file{coff/m88k.h} which defines the external structure of the
coff format for the 88k, and @file{coff/internal.h} which
defines the internal structure. @file{coff-m88k.c} also
defines the relocations used by the 88k format
@xref{Relocations}.
 
The Intel i960 processor version of coff is implemented in
@file{coff-i960.c}. This file has the same structure as
@file{coff-m88k.c}, except that it includes @file{coff/i960.h}
rather than @file{coff-m88k.h}.
 
@subsection Porting to a new version of coff
The recommended method is to select from the existing
implementations the version of coff which is most like the one
you want to use. For example, we'll say that i386 coff is
the one you select, and that your coff flavour is called foo.
Copy @file{i386coff.c} to @file{foocoff.c}, copy
@file{../include/coff/i386.h} to @file{../include/coff/foo.h},
and add the lines to @file{targets.c} and @file{Makefile.in}
so that your new back end is used. Alter the shapes of the
structures in @file{../include/coff/foo.h} so that they match
what you need. You will probably also have to add
@code{#ifdef}s to the code in @file{coff/internal.h} and
@file{coffcode.h} if your version of coff is too wild.
 
You can verify that your new BFD backend works quite simply by
building @file{objdump} from the @file{binutils} directory,
and making sure that its version of what's going on and your
host system's idea (assuming it has the pretty standard coff
dump utility, usually called @code{att-dump} or just
@code{dump}) are the same. Then clean up your code, and send
what you've done to Cygnus. Then your stuff will be in the
next release, and you won't have to keep integrating it.
 
@subsection How the coff backend works
 
 
@subsubsection File layout
The Coff backend is split into generic routines that are
applicable to any Coff target and routines that are specific
to a particular target. The target-specific routines are
further split into ones which are basically the same for all
Coff targets except that they use the external symbol format
or use different values for certain constants.
 
The generic routines are in @file{coffgen.c}. These routines
work for any Coff target. They use some hooks into the target
specific code; the hooks are in a @code{bfd_coff_backend_data}
structure, one of which exists for each target.
 
The essentially similar target-specific routines are in
@file{coffcode.h}. This header file includes executable C code.
The various Coff targets first include the appropriate Coff
header file, make any special defines that are needed, and
then include @file{coffcode.h}.
 
Some of the Coff targets then also have additional routines in
the target source file itself.
 
For example, @file{coff-i960.c} includes
@file{coff/internal.h} and @file{coff/i960.h}. It then
defines a few constants, such as @code{I960}, and includes
@file{coffcode.h}. Since the i960 has complex relocation
types, @file{coff-i960.c} also includes some code to
manipulate the i960 relocs. This code is not in
@file{coffcode.h} because it would not be used by any other
target.
 
@subsubsection Bit twiddling
Each flavour of coff supported in BFD has its own header file
describing the external layout of the structures. There is also
an internal description of the coff layout, in
@file{coff/internal.h}. A major function of the
coff backend is swapping the bytes and twiddling the bits to
translate the external form of the structures into the normal
internal form. This is all performed in the
@code{bfd_swap}_@i{thing}_@i{direction} routines. Some
elements are different sizes between different versions of
coff; it is the duty of the coff version specific include file
to override the definitions of various packing routines in
@file{coffcode.h}. E.g., the size of line number entry in coff is
sometimes 16 bits, and sometimes 32 bits. @code{#define}ing
@code{PUT_LNSZ_LNNO} and @code{GET_LNSZ_LNNO} will select the
correct one. No doubt, some day someone will find a version of
coff which has a varying field size not catered to at the
moment. To port BFD, that person will have to add more @code{#defines}.
Three of the bit twiddling routines are exported to
@code{gdb}; @code{coff_swap_aux_in}, @code{coff_swap_sym_in}
and @code{coff_swap_lineno_in}. @code{GDB} reads the symbol
table on its own, but uses BFD to fix things up. More of the
bit twiddlers are exported for @code{gas};
@code{coff_swap_aux_out}, @code{coff_swap_sym_out},
@code{coff_swap_lineno_out}, @code{coff_swap_reloc_out},
@code{coff_swap_filehdr_out}, @code{coff_swap_aouthdr_out},
@code{coff_swap_scnhdr_out}. @code{Gas} currently keeps track
of all the symbol table and reloc drudgery itself, thereby
saving the internal BFD overhead, but uses BFD to swap things
on the way out, making cross ports much safer. Doing so also
allows BFD (and thus the linker) to use the same header files
as @code{gas}, which makes one avenue to disaster disappear.
 
@subsubsection Symbol reading
The simple canonical form for symbols used by BFD is not rich
enough to keep all the information available in a coff symbol
table. The back end gets around this problem by keeping the original
symbol table around, "behind the scenes".
 
When a symbol table is requested (through a call to
@code{bfd_canonicalize_symtab}), a request gets through to
@code{coff_get_normalized_symtab}. This reads the symbol table from
the coff file and swaps all the structures inside into the
internal form. It also fixes up all the pointers in the table
(represented in the file by offsets from the first symbol in
the table) into physical pointers to elements in the new
internal table. This involves some work since the meanings of
fields change depending upon context: a field that is a
pointer to another structure in the symbol table at one moment
may be the size in bytes of a structure at the next. Another
pass is made over the table. All symbols which mark file names
(@code{C_FILE} symbols) are modified so that the internal
string points to the value in the auxent (the real filename)
rather than the normal text associated with the symbol
(@code{".file"}).
 
At this time the symbol names are moved around. Coff stores
all symbols less than nine characters long physically
within the symbol table; longer strings are kept at the end of
the file in the string table. This pass moves all strings
into memory and replaces them with pointers to the strings.
 
The symbol table is massaged once again, this time to create
the canonical table used by the BFD application. Each symbol
is inspected in turn, and a decision made (using the
@code{sclass} field) about the various flags to set in the
@code{asymbol}. @xref{Symbols}. The generated canonical table
shares strings with the hidden internal symbol table.
 
Any linenumbers are read from the coff file too, and attached
to the symbols which own the functions the linenumbers belong to.
 
@subsubsection Symbol writing
Writing a symbol to a coff file which didn't come from a coff
file will lose any debugging information. The @code{asymbol}
structure remembers the BFD from which the symbol was taken, and on
output the back end makes sure that the same destination target as
source target is present.
 
When the symbols have come from a coff file then all the
debugging information is preserved.
 
Symbol tables are provided for writing to the back end in a
vector of pointers to pointers. This allows applications like
the linker to accumulate and output large symbol tables
without having to do too much byte copying.
 
This function runs through the provided symbol table and
patches each symbol marked as a file place holder
(@code{C_FILE}) to point to the next file place holder in the
list. It also marks each @code{offset} field in the list with
the offset from the first symbol of the current symbol.
 
Another function of this procedure is to turn the canonical
value form of BFD into the form used by coff. Internally, BFD
expects symbol values to be offsets from a section base; so a
symbol physically at 0x120, but in a section starting at
0x100, would have the value 0x20. Coff expects symbols to
contain their final value, so symbols have their values
changed at this point to reflect their sum with their owning
section. This transformation uses the
@code{output_section} field of the @code{asymbol}'s
@code{asection} @xref{Sections}.
 
@itemize @bullet
 
@item
@code{coff_mangle_symbols}
@end itemize
This routine runs though the provided symbol table and uses
the offsets generated by the previous pass and the pointers
generated when the symbol table was read in to create the
structured hierachy required by coff. It changes each pointer
to a symbol into the index into the symbol table of the asymbol.
 
@itemize @bullet
 
@item
@code{coff_write_symbols}
@end itemize
This routine runs through the symbol table and patches up the
symbols from their internal form into the coff way, calls the
bit twiddlers, and writes out the table to the file.
 
@findex coff_symbol_type
@subsubsection @code{coff_symbol_type}
@strong{Description}@*
The hidden information for an @code{asymbol} is described in a
@code{combined_entry_type}:
 
 
@example
 
typedef struct coff_ptr_struct
@{
 
/* Remembers the offset from the first symbol in the file for
this symbol. Generated by coff_renumber_symbols. */
unsigned int offset;
 
/* Should the value of this symbol be renumbered. Used for
XCOFF C_BSTAT symbols. Set by coff_slurp_symbol_table. */
unsigned int fix_value : 1;
 
/* Should the tag field of this symbol be renumbered.
Created by coff_pointerize_aux. */
unsigned int fix_tag : 1;
 
/* Should the endidx field of this symbol be renumbered.
Created by coff_pointerize_aux. */
unsigned int fix_end : 1;
 
/* Should the x_csect.x_scnlen field be renumbered.
Created by coff_pointerize_aux. */
unsigned int fix_scnlen : 1;
 
/* Fix up an XCOFF C_BINCL/C_EINCL symbol. The value is the
index into the line number entries. Set by
coff_slurp_symbol_table. */
unsigned int fix_line : 1;
 
/* The container for the symbol structure as read and translated
from the file. */
 
union @{
union internal_auxent auxent;
struct internal_syment syment;
@} u;
@} combined_entry_type;
 
 
/* Each canonical asymbol really looks like this: */
 
typedef struct coff_symbol_struct
@{
/* The actual symbol which the rest of BFD works with */
asymbol symbol;
 
/* A pointer to the hidden information for this symbol */
combined_entry_type *native;
 
/* A pointer to the linenumber information for this symbol */
struct lineno_cache_entry *lineno;
 
/* Have the line numbers been relocated yet ? */
boolean done_lineno;
@} coff_symbol_type;
@end example
@findex bfd_coff_backend_data
@subsubsection @code{bfd_coff_backend_data}
 
@example
/* COFF symbol classifications. */
 
enum coff_symbol_classification
@{
/* Global symbol. */
COFF_SYMBOL_GLOBAL,
/* Common symbol. */
COFF_SYMBOL_COMMON,
/* Undefined symbol. */
COFF_SYMBOL_UNDEFINED,
/* Local symbol. */
COFF_SYMBOL_LOCAL,
/* PE section symbol. */
COFF_SYMBOL_PE_SECTION
@};
 
@end example
Special entry points for gdb to swap in coff symbol table parts:
@example
typedef struct
@{
void (*_bfd_coff_swap_aux_in) PARAMS ((
bfd *abfd,
PTR ext,
int type,
int class,
int indaux,
int numaux,
PTR in));
 
void (*_bfd_coff_swap_sym_in) PARAMS ((
bfd *abfd ,
PTR ext,
PTR in));
 
void (*_bfd_coff_swap_lineno_in) PARAMS ((
bfd *abfd,
PTR ext,
PTR in));
 
@end example
Special entry points for gas to swap out coff parts:
@example
unsigned int (*_bfd_coff_swap_aux_out) PARAMS ((
bfd *abfd,
PTR in,
int type,
int class,
int indaux,
int numaux,
PTR ext));
 
unsigned int (*_bfd_coff_swap_sym_out) PARAMS ((
bfd *abfd,
PTR in,
PTR ext));
 
unsigned int (*_bfd_coff_swap_lineno_out) PARAMS ((
bfd *abfd,
PTR in,
PTR ext));
 
unsigned int (*_bfd_coff_swap_reloc_out) PARAMS ((
bfd *abfd,
PTR src,
PTR dst));
 
unsigned int (*_bfd_coff_swap_filehdr_out) PARAMS ((
bfd *abfd,
PTR in,
PTR out));
 
unsigned int (*_bfd_coff_swap_aouthdr_out) PARAMS ((
bfd *abfd,
PTR in,
PTR out));
 
unsigned int (*_bfd_coff_swap_scnhdr_out) PARAMS ((
bfd *abfd,
PTR in,
PTR out));
 
@end example
Special entry points for generic COFF routines to call target
dependent COFF routines:
@example
unsigned int _bfd_filhsz;
unsigned int _bfd_aoutsz;
unsigned int _bfd_scnhsz;
unsigned int _bfd_symesz;
unsigned int _bfd_auxesz;
unsigned int _bfd_relsz;
unsigned int _bfd_linesz;
unsigned int _bfd_filnmlen;
boolean _bfd_coff_long_filenames;
boolean _bfd_coff_long_section_names;
unsigned int _bfd_coff_default_section_alignment_power;
void (*_bfd_coff_swap_filehdr_in) PARAMS ((
bfd *abfd,
PTR ext,
PTR in));
void (*_bfd_coff_swap_aouthdr_in) PARAMS ((
bfd *abfd,
PTR ext,
PTR in));
void (*_bfd_coff_swap_scnhdr_in) PARAMS ((
bfd *abfd,
PTR ext,
PTR in));
void (*_bfd_coff_swap_reloc_in) PARAMS ((
bfd *abfd,
PTR ext,
PTR in));
boolean (*_bfd_coff_bad_format_hook) PARAMS ((
bfd *abfd,
PTR internal_filehdr));
boolean (*_bfd_coff_set_arch_mach_hook) PARAMS ((
bfd *abfd,
PTR internal_filehdr));
PTR (*_bfd_coff_mkobject_hook) PARAMS ((
bfd *abfd,
PTR internal_filehdr,
PTR internal_aouthdr));
flagword (*_bfd_styp_to_sec_flags_hook) PARAMS ((
bfd *abfd,
PTR internal_scnhdr,
const char *name,
asection *section));
void (*_bfd_set_alignment_hook) PARAMS ((
bfd *abfd,
asection *sec,
PTR internal_scnhdr));
boolean (*_bfd_coff_slurp_symbol_table) PARAMS ((
bfd *abfd));
boolean (*_bfd_coff_symname_in_debug) PARAMS ((
bfd *abfd,
struct internal_syment *sym));
boolean (*_bfd_coff_pointerize_aux_hook) PARAMS ((
bfd *abfd,
combined_entry_type *table_base,
combined_entry_type *symbol,
unsigned int indaux,
combined_entry_type *aux));
boolean (*_bfd_coff_print_aux) PARAMS ((
bfd *abfd,
FILE *file,
combined_entry_type *table_base,
combined_entry_type *symbol,
combined_entry_type *aux,
unsigned int indaux));
void (*_bfd_coff_reloc16_extra_cases) PARAMS ((
bfd *abfd,
struct bfd_link_info *link_info,
struct bfd_link_order *link_order,
arelent *reloc,
bfd_byte *data,
unsigned int *src_ptr,
unsigned int *dst_ptr));
int (*_bfd_coff_reloc16_estimate) PARAMS ((
bfd *abfd,
asection *input_section,
arelent *r,
unsigned int shrink,
struct bfd_link_info *link_info));
enum coff_symbol_classification (*_bfd_coff_classify_symbol) PARAMS ((
bfd *abfd,
struct internal_syment *));
boolean (*_bfd_coff_compute_section_file_positions) PARAMS ((
bfd *abfd));
boolean (*_bfd_coff_start_final_link) PARAMS ((
bfd *output_bfd,
struct bfd_link_info *info));
boolean (*_bfd_coff_relocate_section) PARAMS ((
bfd *output_bfd,
struct bfd_link_info *info,
bfd *input_bfd,
asection *input_section,
bfd_byte *contents,
struct internal_reloc *relocs,
struct internal_syment *syms,
asection **sections));
reloc_howto_type *(*_bfd_coff_rtype_to_howto) PARAMS ((
bfd *abfd,
asection *sec,
struct internal_reloc *rel,
struct coff_link_hash_entry *h,
struct internal_syment *sym,
bfd_vma *addendp));
boolean (*_bfd_coff_adjust_symndx) PARAMS ((
bfd *obfd,
struct bfd_link_info *info,
bfd *ibfd,
asection *sec,
struct internal_reloc *reloc,
boolean *adjustedp));
boolean (*_bfd_coff_link_add_one_symbol) PARAMS ((
struct bfd_link_info *info,
bfd *abfd,
const char *name,
flagword flags,
asection *section,
bfd_vma value,
const char *string,
boolean copy,
boolean collect,
struct bfd_link_hash_entry **hashp));
 
boolean (*_bfd_coff_link_output_has_begun) PARAMS ((
bfd * abfd,
struct coff_final_link_info * pfinfo));
boolean (*_bfd_coff_final_link_postscript) PARAMS ((
bfd * abfd,
struct coff_final_link_info * pfinfo));
 
@} bfd_coff_backend_data;
 
#define coff_backend_info(abfd) ((bfd_coff_backend_data *) (abfd)->xvec->backend_data)
 
#define bfd_coff_swap_aux_in(a,e,t,c,ind,num,i) \
((coff_backend_info (a)->_bfd_coff_swap_aux_in) (a,e,t,c,ind,num,i))
 
#define bfd_coff_swap_sym_in(a,e,i) \
((coff_backend_info (a)->_bfd_coff_swap_sym_in) (a,e,i))
 
#define bfd_coff_swap_lineno_in(a,e,i) \
((coff_backend_info ( a)->_bfd_coff_swap_lineno_in) (a,e,i))
 
#define bfd_coff_swap_reloc_out(abfd, i, o) \
((coff_backend_info (abfd)->_bfd_coff_swap_reloc_out) (abfd, i, o))
 
#define bfd_coff_swap_lineno_out(abfd, i, o) \
((coff_backend_info (abfd)->_bfd_coff_swap_lineno_out) (abfd, i, o))
 
#define bfd_coff_swap_aux_out(a,i,t,c,ind,num,o) \
((coff_backend_info (a)->_bfd_coff_swap_aux_out) (a,i,t,c,ind,num,o))
 
#define bfd_coff_swap_sym_out(abfd, i,o) \
((coff_backend_info (abfd)->_bfd_coff_swap_sym_out) (abfd, i, o))
 
#define bfd_coff_swap_scnhdr_out(abfd, i,o) \
((coff_backend_info (abfd)->_bfd_coff_swap_scnhdr_out) (abfd, i, o))
 
#define bfd_coff_swap_filehdr_out(abfd, i,o) \
((coff_backend_info (abfd)->_bfd_coff_swap_filehdr_out) (abfd, i, o))
 
#define bfd_coff_swap_aouthdr_out(abfd, i,o) \
((coff_backend_info (abfd)->_bfd_coff_swap_aouthdr_out) (abfd, i, o))
 
#define bfd_coff_filhsz(abfd) (coff_backend_info (abfd)->_bfd_filhsz)
#define bfd_coff_aoutsz(abfd) (coff_backend_info (abfd)->_bfd_aoutsz)
#define bfd_coff_scnhsz(abfd) (coff_backend_info (abfd)->_bfd_scnhsz)
#define bfd_coff_symesz(abfd) (coff_backend_info (abfd)->_bfd_symesz)
#define bfd_coff_auxesz(abfd) (coff_backend_info (abfd)->_bfd_auxesz)
#define bfd_coff_relsz(abfd) (coff_backend_info (abfd)->_bfd_relsz)
#define bfd_coff_linesz(abfd) (coff_backend_info (abfd)->_bfd_linesz)
#define bfd_coff_filnmlen(abfd) (coff_backend_info (abfd)->_bfd_filnmlen)
#define bfd_coff_long_filenames(abfd) (coff_backend_info (abfd)->_bfd_coff_long_filenames)
#define bfd_coff_long_section_names(abfd) \
(coff_backend_info (abfd)->_bfd_coff_long_section_names)
#define bfd_coff_default_section_alignment_power(abfd) \
(coff_backend_info (abfd)->_bfd_coff_default_section_alignment_power)
#define bfd_coff_swap_filehdr_in(abfd, i,o) \
((coff_backend_info (abfd)->_bfd_coff_swap_filehdr_in) (abfd, i, o))
 
#define bfd_coff_swap_aouthdr_in(abfd, i,o) \
((coff_backend_info (abfd)->_bfd_coff_swap_aouthdr_in) (abfd, i, o))
 
#define bfd_coff_swap_scnhdr_in(abfd, i,o) \
((coff_backend_info (abfd)->_bfd_coff_swap_scnhdr_in) (abfd, i, o))
 
#define bfd_coff_swap_reloc_in(abfd, i, o) \
((coff_backend_info (abfd)->_bfd_coff_swap_reloc_in) (abfd, i, o))
 
#define bfd_coff_bad_format_hook(abfd, filehdr) \
((coff_backend_info (abfd)->_bfd_coff_bad_format_hook) (abfd, filehdr))
 
#define bfd_coff_set_arch_mach_hook(abfd, filehdr)\
((coff_backend_info (abfd)->_bfd_coff_set_arch_mach_hook) (abfd, filehdr))
#define bfd_coff_mkobject_hook(abfd, filehdr, aouthdr)\
((coff_backend_info (abfd)->_bfd_coff_mkobject_hook) (abfd, filehdr, aouthdr))
 
#define bfd_coff_styp_to_sec_flags_hook(abfd, scnhdr, name, section)\
((coff_backend_info (abfd)->_bfd_styp_to_sec_flags_hook)\
(abfd, scnhdr, name, section))
 
#define bfd_coff_set_alignment_hook(abfd, sec, scnhdr)\
((coff_backend_info (abfd)->_bfd_set_alignment_hook) (abfd, sec, scnhdr))
 
#define bfd_coff_slurp_symbol_table(abfd)\
((coff_backend_info (abfd)->_bfd_coff_slurp_symbol_table) (abfd))
 
#define bfd_coff_symname_in_debug(abfd, sym)\
((coff_backend_info (abfd)->_bfd_coff_symname_in_debug) (abfd, sym))
 
#define bfd_coff_print_aux(abfd, file, base, symbol, aux, indaux)\
((coff_backend_info (abfd)->_bfd_coff_print_aux)\
(abfd, file, base, symbol, aux, indaux))
 
#define bfd_coff_reloc16_extra_cases(abfd, link_info, link_order, reloc, data, src_ptr, dst_ptr)\
((coff_backend_info (abfd)->_bfd_coff_reloc16_extra_cases)\
(abfd, link_info, link_order, reloc, data, src_ptr, dst_ptr))
 
#define bfd_coff_reloc16_estimate(abfd, section, reloc, shrink, link_info)\
((coff_backend_info (abfd)->_bfd_coff_reloc16_estimate)\
(abfd, section, reloc, shrink, link_info))
 
#define bfd_coff_classify_symbol(abfd, sym)\
((coff_backend_info (abfd)->_bfd_coff_classify_symbol)\
(abfd, sym))
 
#define bfd_coff_compute_section_file_positions(abfd)\
((coff_backend_info (abfd)->_bfd_coff_compute_section_file_positions)\
(abfd))
 
#define bfd_coff_start_final_link(obfd, info)\
((coff_backend_info (obfd)->_bfd_coff_start_final_link)\
(obfd, info))
#define bfd_coff_relocate_section(obfd,info,ibfd,o,con,rel,isyms,secs)\
((coff_backend_info (ibfd)->_bfd_coff_relocate_section)\
(obfd, info, ibfd, o, con, rel, isyms, secs))
#define bfd_coff_rtype_to_howto(abfd, sec, rel, h, sym, addendp)\
((coff_backend_info (abfd)->_bfd_coff_rtype_to_howto)\
(abfd, sec, rel, h, sym, addendp))
#define bfd_coff_adjust_symndx(obfd, info, ibfd, sec, rel, adjustedp)\
((coff_backend_info (abfd)->_bfd_coff_adjust_symndx)\
(obfd, info, ibfd, sec, rel, adjustedp))
#define bfd_coff_link_add_one_symbol(info,abfd,name,flags,section,value,string,cp,coll,hashp)\
((coff_backend_info (abfd)->_bfd_coff_link_add_one_symbol)\
(info, abfd, name, flags, section, value, string, cp, coll, hashp))
 
#define bfd_coff_link_output_has_begun(a,p) \
((coff_backend_info (a)->_bfd_coff_link_output_has_begun) (a,p))
#define bfd_coff_final_link_postscript(a,p) \
((coff_backend_info (a)->_bfd_coff_final_link_postscript) (a,p))
 
@end example
@subsubsection Writing relocations
To write relocations, the back end steps though the
canonical relocation table and create an
@code{internal_reloc}. The symbol index to use is removed from
the @code{offset} field in the symbol table supplied. The
address comes directly from the sum of the section base
address and the relocation offset; the type is dug directly
from the howto field. Then the @code{internal_reloc} is
swapped into the shape of an @code{external_reloc} and written
out to disk.
 
@subsubsection Reading linenumbers
Creating the linenumber table is done by reading in the entire
coff linenumber table, and creating another table for internal use.
 
A coff linenumber table is structured so that each function
is marked as having a line number of 0. Each line within the
function is an offset from the first line in the function. The
base of the line number information for the table is stored in
the symbol associated with the function.
 
Note: The PE format uses line number 0 for a flag indicating a
new source file.
 
The information is copied from the external to the internal
table, and each symbol which marks a function is marked by
pointing its...
 
How does this work ?
 
@subsubsection Reading relocations
Coff relocations are easily transformed into the internal BFD form
(@code{arelent}).
 
Reading a coff relocation table is done in the following stages:
 
@itemize @bullet
 
@item
Read the entire coff relocation table into memory.
 
@item
Process each relocation in turn; first swap it from the
external to the internal form.
 
@item
Turn the symbol referenced in the relocation's symbol index
into a pointer into the canonical symbol table.
This table is the same as the one returned by a call to
@code{bfd_canonicalize_symtab}. The back end will call that
routine and save the result if a canonicalization hasn't been done.
 
@item
The reloc index is turned into a pointer to a howto
structure, in a back end specific way. For instance, the 386
and 960 use the @code{r_type} to directly produce an index
into a howto table vector; the 88k subtracts a number from the
@code{r_type} field and creates an addend field.
@end itemize
 
/Makefile.in
0,0 → 1,599
# Makefile.in generated automatically by automake 1.4 from Makefile.am
 
# Copyright (C) 1994, 1995-8, 1999 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
 
 
SHELL = @SHELL@
 
srcdir = @srcdir@
top_srcdir = @top_srcdir@
VPATH = @srcdir@
prefix = @prefix@
exec_prefix = @exec_prefix@
 
bindir = @bindir@
sbindir = @sbindir@
libexecdir = @libexecdir@
datadir = @datadir@
sysconfdir = @sysconfdir@
sharedstatedir = @sharedstatedir@
localstatedir = @localstatedir@
libdir = @libdir@
infodir = @infodir@
mandir = @mandir@
includedir = @includedir@
oldincludedir = /usr/include
 
DESTDIR =
 
pkgdatadir = $(datadir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
 
top_builddir = ..
 
ACLOCAL = @ACLOCAL@
AUTOCONF = @AUTOCONF@
AUTOMAKE = @AUTOMAKE@
AUTOHEADER = @AUTOHEADER@
 
INSTALL = @INSTALL@
INSTALL_PROGRAM = @INSTALL_PROGRAM@ $(AM_INSTALL_PROGRAM_FLAGS)
INSTALL_DATA = @INSTALL_DATA@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
transform = @program_transform_name@
 
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_alias = @build_alias@
build_triplet = @build@
host_alias = @host_alias@
host_triplet = @host@
target_alias = @target_alias@
target_triplet = @target@
AR = @AR@
AS = @AS@
BFD_HOST_64BIT_LONG = @BFD_HOST_64BIT_LONG@
BFD_HOST_64_BIT = @BFD_HOST_64_BIT@
BFD_HOST_64_BIT_DEFINED = @BFD_HOST_64_BIT_DEFINED@
BFD_HOST_U_64_BIT = @BFD_HOST_U_64_BIT@
CATALOGS = @CATALOGS@
CATOBJEXT = @CATOBJEXT@
CC = @CC@
CC_FOR_BUILD = @CC_FOR_BUILD@
COREFILE = @COREFILE@
COREFLAG = @COREFLAG@
DATADIRNAME = @DATADIRNAME@
DLLTOOL = @DLLTOOL@
EXEEXT = @EXEEXT@
EXEEXT_FOR_BUILD = @EXEEXT_FOR_BUILD@
GMOFILES = @GMOFILES@
GMSGFMT = @GMSGFMT@
GT_NO = @GT_NO@
GT_YES = @GT_YES@
HDEFINES = @HDEFINES@
INCLUDE_LOCALE_H = @INCLUDE_LOCALE_H@
INSTOBJEXT = @INSTOBJEXT@
INTLDEPS = @INTLDEPS@
INTLLIBS = @INTLLIBS@
INTLOBJS = @INTLOBJS@
LIBTOOL = @LIBTOOL@
LN_S = @LN_S@
MAINT = @MAINT@
MAKEINFO = @MAKEINFO@
MKINSTALLDIRS = @MKINSTALLDIRS@
MSGFMT = @MSGFMT@
OBJDUMP = @OBJDUMP@
PACKAGE = @PACKAGE@
POFILES = @POFILES@
POSUB = @POSUB@
RANLIB = @RANLIB@
TDEFINES = @TDEFINES@
USE_INCLUDED_LIBINTL = @USE_INCLUDED_LIBINTL@
USE_NLS = @USE_NLS@
VERSION = @VERSION@
WARN_CFLAGS = @WARN_CFLAGS@
WIN32LDFLAGS = @WIN32LDFLAGS@
WIN32LIBADD = @WIN32LIBADD@
all_backends = @all_backends@
bfd_backends = @bfd_backends@
bfd_machines = @bfd_machines@
l = @l@
tdefaults = @tdefaults@
wordsize = @wordsize@
 
AUTOMAKE_OPTIONS = cygnus
 
DOCFILES = aoutx.texi archive.texi archures.texi \
bfdt.texi cache.texi coffcode.texi \
core.texi elf.texi elfcode.texi format.texi libbfd.texi \
opncls.texi reloc.texi section.texi \
syms.texi targets.texi init.texi hash.texi linker.texi
 
 
PROTOS = archive.p archures.p bfd.p \
core.p format.p \
libbfd.p opncls.p reloc.p \
section.p syms.p targets.p \
format.p core.p init.p
 
 
IPROTOS = cache.ip libbfd.ip reloc.ip init.ip archures.ip coffcode.ip
 
# SRCDOC, SRCPROT, SRCIPROT only used to sidestep Sun Make bug in interaction
# between VPATH and suffix rules. If you use GNU Make, perhaps other Makes,
# you don't need these three:
SRCDOC = $(srcdir)/../aoutx.h $(srcdir)/../archive.c \
$(srcdir)/../archures.c $(srcdir)/../bfd.c \
$(srcdir)/../cache.c $(srcdir)/../coffcode.h \
$(srcdir)/../corefile.c $(srcdir)/../elf.c \
$(srcdir)/../elfcode.h $(srcdir)/../format.c \
$(srcdir)/../libbfd.c $(srcdir)/../opncls.c \
$(srcdir)/../reloc.c $(srcdir)/../section.c \
$(srcdir)/../syms.c $(srcdir)/../targets.c \
$(srcdir)/../hash.c $(srcdir)/../linker.c
 
 
SRCPROT = $(srcdir)/../archive.c $(srcdir)/../archures.c \
$(srcdir)/../bfd.c $(srcdir)/../coffcode.h $(srcdir)/../corefile.c \
$(srcdir)/../format.c $(srcdir)/../libbfd.c \
$(srcdir)/../opncls.c $(srcdir)/../reloc.c \
$(srcdir)/../section.c $(srcdir)/../syms.c \
$(srcdir)/../targets.c $(srcdir)/../init.c
 
 
SRCIPROT = $(srcdir)/../cache.c $(srcdir)/../libbfd.c \
$(srcdir)/../reloc.c $(srcdir)/../cpu-h8300.c \
$(srcdir)/../cpu-i960.c $(srcdir)/../archures.c \
$(srcdir)/../init.c
 
 
TEXIDIR = $(srcdir)/../../texinfo/fsf
 
info_TEXINFOS = bfd.texinfo
 
MKDOC = chew$(EXEEXT_FOR_BUILD)
 
noinst_TEXINFOS = bfdint.texi
 
MOSTLYCLEANFILES = $(MKDOC) *.o
 
CLEANFILES = s-* *.p *.ip
 
DISTCLEANFILES = bfd.?? bfd.??? bfd.h libbfd.h libcoff.h texput.log
 
MAINTAINERCLEANFILES = $(DOCFILES)
mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
CONFIG_HEADER = ../config.h
CONFIG_CLEAN_FILES =
TEXI2DVI = `if test -f $(top_srcdir)/../texinfo/util/texi2dvi; then echo $(top_srcdir)/../texinfo/util/texi2dvi; else echo texi2dvi; fi`
TEXINFO_TEX = $(top_srcdir)/../texinfo/texinfo.tex
INFO_DEPS = bfd.info
DVIS = bfd.dvi
TEXINFOS = bfd.texinfo
DIST_COMMON = ChangeLog Makefile.am Makefile.in
 
 
DISTFILES = $(DIST_COMMON) $(SOURCES) $(HEADERS) $(TEXINFOS) $(EXTRA_DIST)
 
TAR = tar
GZIP_ENV = --best
all: all-redirect
.SUFFIXES:
.SUFFIXES: .dvi .info .ps .texi .texinfo .txi
$(srcdir)/Makefile.in: @MAINTAINER_MODE_TRUE@ Makefile.am $(top_srcdir)/configure.in $(ACLOCAL_M4)
cd $(top_srcdir) && $(AUTOMAKE) --cygnus doc/Makefile
 
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
cd $(top_builddir) \
&& CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status
 
 
bfd.info: bfd.texinfo
bfd.dvi: bfd.texinfo
 
 
DVIPS = dvips
 
.texi.info:
@rm -f $@ $@-[0-9] $@-[0-9][0-9]
$(MAKEINFO) -I $(srcdir) $<
 
.texi.dvi:
TEXINPUTS=$(top_srcdir)/../texinfo:$$TEXINPUTS \
MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $<
 
.texi:
@rm -f $@ $@-[0-9] $@-[0-9][0-9]
$(MAKEINFO) -I $(srcdir) $<
 
.texinfo.info:
@rm -f $@ $@-[0-9] $@-[0-9][0-9]
$(MAKEINFO) -I $(srcdir) $<
 
.texinfo:
@rm -f $@ $@-[0-9] $@-[0-9][0-9]
$(MAKEINFO) -I $(srcdir) $<
 
.texinfo.dvi:
TEXINPUTS=$(top_srcdir)/../texinfo:$$TEXINPUTS \
MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $<
 
.txi.info:
@rm -f $@ $@-[0-9] $@-[0-9][0-9]
$(MAKEINFO) -I $(srcdir) $<
 
.txi.dvi:
TEXINPUTS=$(top_srcdir)/../texinfo:$$TEXINPUTS \
MAKEINFO='$(MAKEINFO) -I $(srcdir)' $(TEXI2DVI) $<
 
.txi:
@rm -f $@ $@-[0-9] $@-[0-9][0-9]
$(MAKEINFO) -I $(srcdir) $<
.dvi.ps:
$(DVIPS) $< -o $@
 
install-info-am: $(INFO_DEPS)
@$(NORMAL_INSTALL)
$(mkinstalldirs) $(DESTDIR)$(infodir)
@list='$(INFO_DEPS)'; \
for file in $$list; do \
if test -f $$file; then d=.; else d=$(srcdir); fi; \
for ifile in `cd $$d && echo $$file $$file-[0-9] $$file-[0-9][0-9]`; do \
if test -f $$d/$$ifile; then \
echo " $(INSTALL_DATA) $$d/$$ifile $(DESTDIR)$(infodir)/$$ifile"; \
$(INSTALL_DATA) $$d/$$ifile $(DESTDIR)$(infodir)/$$ifile; \
else : ; fi; \
done; \
done
@$(POST_INSTALL)
@if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \
list='$(INFO_DEPS)'; \
for file in $$list; do \
echo " install-info --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/$$file";\
install-info --info-dir=$(DESTDIR)$(infodir) $(DESTDIR)$(infodir)/$$file || :;\
done; \
else : ; fi
 
uninstall-info:
$(PRE_UNINSTALL)
@if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian' >/dev/null 2>&1; then \
ii=yes; \
else ii=; fi; \
list='$(INFO_DEPS)'; \
for file in $$list; do \
test -z "$ii" \
|| install-info --info-dir=$(DESTDIR)$(infodir) --remove $$file; \
done
@$(NORMAL_UNINSTALL)
list='$(INFO_DEPS)'; \
for file in $$list; do \
(cd $(DESTDIR)$(infodir) && rm -f $$file $$file-[0-9] $$file-[0-9][0-9]); \
done
 
dist-info: $(INFO_DEPS)
list='$(INFO_DEPS)'; \
for base in $$list; do \
if test -f $$base; then d=.; else d=$(srcdir); fi; \
for file in `cd $$d && eval echo $$base*`; do \
test -f $(distdir)/$$file \
|| ln $$d/$$file $(distdir)/$$file 2> /dev/null \
|| cp -p $$d/$$file $(distdir)/$$file; \
done; \
done
 
mostlyclean-aminfo:
-rm -f bfd.aux bfd.cp bfd.cps bfd.dvi bfd.fn bfd.fns bfd.ky bfd.kys \
bfd.ps bfd.log bfd.pg bfd.toc bfd.tp bfd.tps bfd.vr bfd.vrs \
bfd.op bfd.tr bfd.cv bfd.cn
 
clean-aminfo:
 
distclean-aminfo:
 
maintainer-clean-aminfo:
for i in $(INFO_DEPS); do \
rm -f $$i; \
if test "`echo $$i-[0-9]*`" != "$$i-[0-9]*"; then \
rm -f $$i-[0-9]*; \
fi; \
done
clean-info: mostlyclean-aminfo
tags: TAGS
TAGS:
 
 
distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)
 
subdir = doc
 
distdir: $(DISTFILES)
@for file in $(DISTFILES); do \
if test -f $$file; then d=.; else d=$(srcdir); fi; \
if test -d $$d/$$file; then \
cp -pr $$d/$$file $(distdir)/$$file; \
else \
test -f $(distdir)/$$file \
|| ln $$d/$$file $(distdir)/$$file 2> /dev/null \
|| cp -p $$d/$$file $(distdir)/$$file || :; \
fi; \
done
$(MAKE) $(AM_MAKEFLAGS) top_distdir="$(top_distdir)" distdir="$(distdir)" dist-info
info-am: $(INFO_DEPS)
info: info-am
dvi-am: $(DVIS)
dvi: dvi-am
check-am:
check: check-am
installcheck-am:
installcheck: installcheck-am
install-info-am:
install-info: install-info-am
install-exec-am:
install-exec: install-exec-am
 
install-data-am:
install-data: install-data-am
 
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
install: install-am
uninstall-am:
uninstall: uninstall-am
all-am: Makefile
all-redirect: all-am
install-strip:
$(MAKE) $(AM_MAKEFLAGS) AM_INSTALL_PROGRAM_FLAGS=-s install
installdirs:
 
 
mostlyclean-generic:
-test -z "$(MOSTLYCLEANFILES)" || rm -f $(MOSTLYCLEANFILES)
 
clean-generic:
-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
 
distclean-generic:
-rm -f Makefile $(CONFIG_CLEAN_FILES)
-rm -f config.cache config.log stamp-h stamp-h[0-9]*
-test -z "$(DISTCLEANFILES)" || rm -f $(DISTCLEANFILES)
 
maintainer-clean-generic:
-test -z "$(MAINTAINERCLEANFILES)" || rm -f $(MAINTAINERCLEANFILES)
mostlyclean-am: mostlyclean-aminfo mostlyclean-generic
 
mostlyclean: mostlyclean-am
 
clean-am: clean-aminfo clean-generic mostlyclean-am
 
clean: clean-am
 
distclean-am: distclean-aminfo distclean-generic clean-am
-rm -f libtool
 
distclean: distclean-am
 
maintainer-clean-am: maintainer-clean-aminfo maintainer-clean-generic \
distclean-am
@echo "This command is intended for maintainers to use;"
@echo "it deletes files that may require special tools to rebuild."
 
maintainer-clean: maintainer-clean-am
 
.PHONY: install-info-am uninstall-info mostlyclean-aminfo \
distclean-aminfo clean-aminfo maintainer-clean-aminfo tags distdir \
info-am info dvi-am dvi check check-am installcheck-am installcheck \
install-info-am install-info install-exec-am install-exec \
install-data-am install-data install-am install uninstall-am uninstall \
all-redirect all-am all installdirs mostlyclean-generic \
distclean-generic clean-generic maintainer-clean-generic clean \
mostlyclean distclean maintainer-clean
 
 
$(MKDOC): chew.o
$(CC_FOR_BUILD) -o $(MKDOC) chew.o $(LOADLIBES) $(LDFLAGS)
 
chew.o: chew.c
$(CC_FOR_BUILD) -c -I.. -I$(srcdir)/.. -I$(srcdir)/../../include -I$(srcdir)/../../intl -I../../intl $(H_CFLAGS) $(CFLAGS) $(srcdir)/chew.c
 
protos: libbfd.h libcoff.h bfd.h
 
bfd.info bfd.dvi: $(DOCFILES) bfdsumm.texi bfd.texinfo
 
# We can't replace these rules with an implicit rule, because
# makes without VPATH support couldn't find the .h files in `..'.
 
# We use s-XXX targets so that we can distribute the info files,
# and permit people to rebuild them, without requiring the makeinfo
# program. If somebody tries to rebuild info, but none of the .texi
# files have changed, then this Makefile will build chew, and will
# build all of the stamp files, but will not actually have to rebuild
# bfd.info.
 
s-aoutx: $(MKDOC) $(srcdir)/../aoutx.h $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../aoutx.h >aoutx.tmp
$(srcdir)/../../move-if-change aoutx.tmp aoutx.texi
touch s-aoutx
aoutx.texi: s-aoutx
 
s-archive: $(MKDOC) $(srcdir)/../archive.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../archive.c >archive.tmp
$(srcdir)/../../move-if-change archive.tmp archive.texi
touch s-archive
archive.texi: s-archive
 
s-archures: $(MKDOC) $(srcdir)/../archures.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str < $(srcdir)/../archures.c >archures.tmp
$(srcdir)/../../move-if-change archures.tmp archures.texi
touch s-archures
archures.texi: s-archures
 
# We use bfdt.texi, rather than bfd.texi, to avoid conflicting with
# bfd.texinfo on an 8.3 filesystem.
s-bfd: $(MKDOC) $(srcdir)/../bfd.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str < $(srcdir)/../bfd.c >bfd.tmp
$(srcdir)/../../move-if-change bfd.tmp bfdt.texi
touch s-bfd
bfdt.texi: s-bfd
 
s-cache: $(MKDOC) $(srcdir)/../cache.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str < $(srcdir)/../cache.c >cache.tmp
$(srcdir)/../../move-if-change cache.tmp cache.texi
touch s-cache
cache.texi: s-cache
 
s-coffcode: $(MKDOC) $(srcdir)/../coffcode.h $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../coffcode.h >coffcode.tmp
$(srcdir)/../../move-if-change coffcode.tmp coffcode.texi
touch s-coffcode
coffcode.texi: s-coffcode
 
s-core: $(MKDOC) $(srcdir)/../corefile.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../corefile.c >core.tmp
$(srcdir)/../../move-if-change core.tmp core.texi
touch s-core
core.texi: s-core
 
s-elf: $(MKDOC) $(srcdir)/../elf.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../elf.c >elf.tmp
$(srcdir)/../../move-if-change elf.tmp elf.texi
touch s-elf
elf.texi: s-elf
 
s-elfcode: $(MKDOC) $(srcdir)/../elfcode.h $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../elfcode.h >elfcode.tmp
$(srcdir)/../../move-if-change elfcode.tmp elfcode.texi
touch s-elfcode
elfcode.texi: s-elfcode
 
s-format: $(MKDOC) $(srcdir)/../format.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../format.c >format.tmp
$(srcdir)/../../move-if-change format.tmp format.texi
touch s-format
format.texi: s-format
 
s-libbfd: $(MKDOC) $(srcdir)/../libbfd.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str < $(srcdir)/../libbfd.c >libbfd.tmp
$(srcdir)/../../move-if-change libbfd.tmp libbfd.texi
touch s-libbfd
libbfd.texi: s-libbfd
 
s-opncls: $(MKDOC) $(srcdir)/../opncls.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../opncls.c >opncls.tmp
$(srcdir)/../../move-if-change opncls.tmp opncls.texi
touch s-opncls
opncls.texi: s-opncls
 
s-reloc: $(MKDOC) $(srcdir)/../reloc.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../reloc.c >reloc.tmp
$(srcdir)/../../move-if-change reloc.tmp reloc.texi
touch s-reloc
reloc.texi: s-reloc
 
s-section: $(MKDOC) $(srcdir)/../section.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../section.c >section.tmp
$(srcdir)/../../move-if-change section.tmp section.texi
touch s-section
section.texi: s-section
 
s-syms: $(MKDOC) $(srcdir)/../syms.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../syms.c >syms.tmp
$(srcdir)/../../move-if-change syms.tmp syms.texi
touch s-syms
syms.texi: s-syms
 
s-targets: $(MKDOC) $(srcdir)/../targets.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../targets.c >targets.tmp
$(srcdir)/../../move-if-change targets.tmp targets.texi
touch s-targets
targets.texi: s-targets
 
s-init: $(MKDOC) $(srcdir)/../init.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../init.c >init.tmp
$(srcdir)/../../move-if-change init.tmp init.texi
touch s-init
init.texi: s-init
 
s-hash: $(MKDOC) $(srcdir)/../hash.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../hash.c >hash.tmp
$(srcdir)/../../move-if-change hash.tmp hash.texi
touch s-hash
hash.texi: s-hash
 
s-linker: $(MKDOC) $(srcdir)/../linker.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../linker.c >linker.tmp
$(srcdir)/../../move-if-change linker.tmp linker.texi
touch s-linker
linker.texi: s-linker
 
libbfd.h: $(srcdir)/../libbfd-in.h \
$(srcdir)/../init.c \
$(srcdir)/../libbfd.c \
$(srcdir)/../cache.c \
$(srcdir)/../reloc.c \
$(srcdir)/../archures.c \
$(srcdir)/proto.str \
$(MKDOC)
cat $(srcdir)/../libbfd-in.h >libbfd.h
./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../init.c >>libbfd.h
./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../libbfd.c >>libbfd.h
./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../cache.c >>libbfd.h
./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../reloc.c >>libbfd.h
./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../archures.c >>libbfd.h
./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../elf.c >>libbfd.h
 
libcoff.h: $(srcdir)/../libcoff-in.h \
$(srcdir)/../coffcode.h \
$(srcdir)/proto.str \
$(MKDOC)
cat $(srcdir)/../libcoff-in.h >libcoff.h
./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../coffcode.h >>libcoff.h
 
bfd.h: $(srcdir)/../bfd-in.h \
$(srcdir)/../init.c \
$(srcdir)/../opncls.c \
$(srcdir)/../libbfd.c \
$(srcdir)/../section.c \
$(srcdir)/../archures.c \
$(srcdir)/../reloc.c \
$(srcdir)/../syms.c \
$(srcdir)/../bfd.c \
$(srcdir)/../archive.c \
$(srcdir)/../corefile.c \
$(srcdir)/../targets.c \
$(srcdir)/../format.c \
$(srcdir)/proto.str \
$(MKDOC)
cat $(srcdir)/../bfd-in.h >bfd.h
./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../init.c >>bfd.h
./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../opncls.c >>bfd.h
./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../libbfd.c >>bfd.h
./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../section.c >>bfd.h
./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../archures.c >>bfd.h
./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../reloc.c >>bfd.h
./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../syms.c >>bfd.h
./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../bfd.c >>bfd.h
./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../archive.c >>bfd.h
./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../corefile.c >>bfd.h
./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../targets.c >>bfd.h
./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../format.c >>bfd.h
echo "#ifdef __cplusplus" >>bfd.h
echo "}" >>bfd.h
echo "#endif" >>bfd.h
echo "#endif" >>bfd.h
 
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
/bfdt.texi
0,0 → 1,601
@section @code{typedef bfd}
A BFD has type @code{bfd}; objects of this type are the
cornerstone of any application using BFD. Using BFD
consists of making references though the BFD and to data in the BFD.
 
Here is the structure that defines the type @code{bfd}. It
contains the major data about the file and pointers
to the rest of the data.
 
 
@example
 
struct _bfd
@{
/* The filename the application opened the BFD with. */
CONST char *filename;
 
/* A pointer to the target jump table. */
const struct bfd_target *xvec;
 
/* To avoid dragging too many header files into every file that
includes `@code{bfd.h}', IOSTREAM has been declared as a "char
*", and MTIME as a "long". Their correct types, to which they
are cast when used, are "FILE *" and "time_t". The iostream
is the result of an fopen on the filename. However, if the
BFD_IN_MEMORY flag is set, then iostream is actually a pointer
to a bfd_in_memory struct. */
PTR iostream;
 
/* Is the file descriptor being cached? That is, can it be closed as
needed, and re-opened when accessed later? */
 
boolean cacheable;
 
/* Marks whether there was a default target specified when the
BFD was opened. This is used to select which matching algorithm
to use to choose the back end. */
 
boolean target_defaulted;
 
/* The caching routines use these to maintain a
least-recently-used list of BFDs */
 
struct _bfd *lru_prev, *lru_next;
 
/* When a file is closed by the caching routines, BFD retains
state information on the file here: */
 
file_ptr where;
 
/* and here: (``once'' means at least once) */
 
boolean opened_once;
 
/* Set if we have a locally maintained mtime value, rather than
getting it from the file each time: */
 
boolean mtime_set;
 
/* File modified time, if mtime_set is true: */
 
long mtime;
 
/* Reserved for an unimplemented file locking extension.*/
 
int ifd;
 
/* The format which belongs to the BFD. (object, core, etc.) */
 
bfd_format format;
 
/* The direction the BFD was opened with*/
 
enum bfd_direction @{no_direction = 0,
read_direction = 1,
write_direction = 2,
both_direction = 3@} direction;
 
/* Format_specific flags*/
 
flagword flags;
 
/* Currently my_archive is tested before adding origin to
anything. I believe that this can become always an add of
origin, with origin set to 0 for non archive files. */
 
file_ptr origin;
 
/* Remember when output has begun, to stop strange things
from happening. */
boolean output_has_begun;
 
/* Pointer to linked list of sections*/
struct sec *sections;
 
/* The number of sections */
unsigned int section_count;
 
/* Stuff only useful for object files:
The start address. */
bfd_vma start_address;
 
/* Used for input and output*/
unsigned int symcount;
 
/* Symbol table for output BFD (with symcount entries) */
struct symbol_cache_entry **outsymbols;
 
/* Pointer to structure which contains architecture information*/
const struct bfd_arch_info *arch_info;
 
/* Stuff only useful for archives:*/
PTR arelt_data;
struct _bfd *my_archive; /* The containing archive BFD. */
struct _bfd *next; /* The next BFD in the archive. */
struct _bfd *archive_head; /* The first BFD in the archive. */
boolean has_armap;
 
/* A chain of BFD structures involved in a link. */
struct _bfd *link_next;
 
/* A field used by _bfd_generic_link_add_archive_symbols. This will
be used only for archive elements. */
int archive_pass;
 
/* Used by the back end to hold private data. */
 
union
@{
struct aout_data_struct *aout_data;
struct artdata *aout_ar_data;
struct _oasys_data *oasys_obj_data;
struct _oasys_ar_data *oasys_ar_data;
struct coff_tdata *coff_obj_data;
struct pe_tdata *pe_obj_data;
struct xcoff_tdata *xcoff_obj_data;
struct ecoff_tdata *ecoff_obj_data;
struct ieee_data_struct *ieee_data;
struct ieee_ar_data_struct *ieee_ar_data;
struct srec_data_struct *srec_data;
struct ihex_data_struct *ihex_data;
struct tekhex_data_struct *tekhex_data;
struct elf_obj_tdata *elf_obj_data;
struct nlm_obj_tdata *nlm_obj_data;
struct bout_data_struct *bout_data;
struct sun_core_struct *sun_core_data;
struct sco5_core_struct *sco5_core_data;
struct trad_core_struct *trad_core_data;
struct som_data_struct *som_data;
struct hpux_core_struct *hpux_core_data;
struct hppabsd_core_struct *hppabsd_core_data;
struct sgi_core_struct *sgi_core_data;
struct lynx_core_struct *lynx_core_data;
struct osf_core_struct *osf_core_data;
struct cisco_core_struct *cisco_core_data;
struct versados_data_struct *versados_data;
struct netbsd_core_struct *netbsd_core_data;
PTR any;
@} tdata;
/* Used by the application to hold private data*/
PTR usrdata;
 
/* Where all the allocated stuff under this BFD goes. This is a
struct objalloc *, but we use PTR to avoid requiring the inclusion of
objalloc.h. */
PTR memory;
@};
 
@end example
@section Error reporting
Most BFD functions return nonzero on success (check their
individual documentation for precise semantics). On an error,
they call @code{bfd_set_error} to set an error condition that callers
can check by calling @code{bfd_get_error}.
If that returns @code{bfd_error_system_call}, then check
@code{errno}.
 
The easiest way to report a BFD error to the user is to
use @code{bfd_perror}.
 
@subsection Type @code{bfd_error_type}
The values returned by @code{bfd_get_error} are defined by the
enumerated type @code{bfd_error_type}.
 
 
@example
 
typedef enum bfd_error
@{
bfd_error_no_error = 0,
bfd_error_system_call,
bfd_error_invalid_target,
bfd_error_wrong_format,
bfd_error_invalid_operation,
bfd_error_no_memory,
bfd_error_no_symbols,
bfd_error_no_armap,
bfd_error_no_more_archived_files,
bfd_error_malformed_archive,
bfd_error_file_not_recognized,
bfd_error_file_ambiguously_recognized,
bfd_error_no_contents,
bfd_error_nonrepresentable_section,
bfd_error_no_debug_section,
bfd_error_bad_value,
bfd_error_file_truncated,
bfd_error_file_too_big,
bfd_error_invalid_error_code
@} bfd_error_type;
 
@end example
@findex bfd_get_error
@subsubsection @code{bfd_get_error}
@strong{Synopsis}
@example
bfd_error_type bfd_get_error (void);
@end example
@strong{Description}@*
Return the current BFD error condition.
 
@findex bfd_set_error
@subsubsection @code{bfd_set_error}
@strong{Synopsis}
@example
void bfd_set_error (bfd_error_type error_tag);
@end example
@strong{Description}@*
Set the BFD error condition to be @var{error_tag}.
 
@findex bfd_errmsg
@subsubsection @code{bfd_errmsg}
@strong{Synopsis}
@example
CONST char *bfd_errmsg (bfd_error_type error_tag);
@end example
@strong{Description}@*
Return a string describing the error @var{error_tag}, or
the system error if @var{error_tag} is @code{bfd_error_system_call}.
 
@findex bfd_perror
@subsubsection @code{bfd_perror}
@strong{Synopsis}
@example
void bfd_perror (CONST char *message);
@end example
@strong{Description}@*
Print to the standard error stream a string describing the
last BFD error that occurred, or the last system error if
the last BFD error was a system call failure. If @var{message}
is non-NULL and non-empty, the error string printed is preceded
by @var{message}, a colon, and a space. It is followed by a newline.
 
@subsection BFD error handler
Some BFD functions want to print messages describing the
problem. They call a BFD error handler function. This
function may be overriden by the program.
 
The BFD error handler acts like printf.
 
 
@example
 
typedef void (*bfd_error_handler_type) PARAMS ((const char *, ...));
 
@end example
@findex bfd_set_error_handler
@subsubsection @code{bfd_set_error_handler}
@strong{Synopsis}
@example
bfd_error_handler_type bfd_set_error_handler (bfd_error_handler_type);
@end example
@strong{Description}@*
Set the BFD error handler function. Returns the previous
function.
 
@findex bfd_set_error_program_name
@subsubsection @code{bfd_set_error_program_name}
@strong{Synopsis}
@example
void bfd_set_error_program_name (const char *);
@end example
@strong{Description}@*
Set the program name to use when printing a BFD error. This
is printed before the error message followed by a colon and
space. The string must not be changed after it is passed to
this function.
 
@findex bfd_get_error_handler
@subsubsection @code{bfd_get_error_handler}
@strong{Synopsis}
@example
bfd_error_handler_type bfd_get_error_handler (void);
@end example
@strong{Description}@*
Return the BFD error handler function.
 
@section Symbols
 
 
@findex bfd_get_reloc_upper_bound
@subsubsection @code{bfd_get_reloc_upper_bound}
@strong{Synopsis}
@example
long bfd_get_reloc_upper_bound(bfd *abfd, asection *sect);
@end example
@strong{Description}@*
Return the number of bytes required to store the
relocation information associated with section @var{sect}
attached to bfd @var{abfd}. If an error occurs, return -1.
 
@findex bfd_canonicalize_reloc
@subsubsection @code{bfd_canonicalize_reloc}
@strong{Synopsis}
@example
long bfd_canonicalize_reloc
(bfd *abfd,
asection *sec,
arelent **loc,
asymbol **syms);
@end example
@strong{Description}@*
Call the back end associated with the open BFD
@var{abfd} and translate the external form of the relocation
information attached to @var{sec} into the internal canonical
form. Place the table into memory at @var{loc}, which has
been preallocated, usually by a call to
@code{bfd_get_reloc_upper_bound}. Returns the number of relocs, or
-1 on error.
 
The @var{syms} table is also needed for horrible internal magic
reasons.
 
@findex bfd_set_reloc
@subsubsection @code{bfd_set_reloc}
@strong{Synopsis}
@example
void bfd_set_reloc
(bfd *abfd, asection *sec, arelent **rel, unsigned int count)
@end example
@strong{Description}@*
Set the relocation pointer and count within
section @var{sec} to the values @var{rel} and @var{count}.
The argument @var{abfd} is ignored.
 
@findex bfd_set_file_flags
@subsubsection @code{bfd_set_file_flags}
@strong{Synopsis}
@example
boolean bfd_set_file_flags(bfd *abfd, flagword flags);
@end example
@strong{Description}@*
Set the flag word in the BFD @var{abfd} to the value @var{flags}.
 
Possible errors are:
@itemize @bullet
 
@item
@code{bfd_error_wrong_format} - The target bfd was not of object format.
@item
@code{bfd_error_invalid_operation} - The target bfd was open for reading.
@item
@code{bfd_error_invalid_operation} -
The flag word contained a bit which was not applicable to the
type of file. E.g., an attempt was made to set the @code{D_PAGED} bit
on a BFD format which does not support demand paging.
@end itemize
 
@findex bfd_set_start_address
@subsubsection @code{bfd_set_start_address}
@strong{Synopsis}
@example
boolean bfd_set_start_address(bfd *abfd, bfd_vma vma);
@end example
@strong{Description}@*
Make @var{vma} the entry point of output BFD @var{abfd}.
 
@strong{Returns}@*
Returns @code{true} on success, @code{false} otherwise.
 
@findex bfd_get_mtime
@subsubsection @code{bfd_get_mtime}
@strong{Synopsis}
@example
long bfd_get_mtime(bfd *abfd);
@end example
@strong{Description}@*
Return the file modification time (as read from the file system, or
from the archive header for archive members).
 
@findex bfd_get_size
@subsubsection @code{bfd_get_size}
@strong{Synopsis}
@example
long bfd_get_size(bfd *abfd);
@end example
@strong{Description}@*
Return the file size (as read from file system) for the file
associated with BFD @var{abfd}.
 
The initial motivation for, and use of, this routine is not
so we can get the exact size of the object the BFD applies to, since
that might not be generally possible (archive members for example).
It would be ideal if someone could eventually modify
it so that such results were guaranteed.
 
Instead, we want to ask questions like "is this NNN byte sized
object I'm about to try read from file offset YYY reasonable?"
As as example of where we might do this, some object formats
use string tables for which the first @code{sizeof(long)} bytes of the
table contain the size of the table itself, including the size bytes.
If an application tries to read what it thinks is one of these
string tables, without some way to validate the size, and for
some reason the size is wrong (byte swapping error, wrong location
for the string table, etc.), the only clue is likely to be a read
error when it tries to read the table, or a "virtual memory
exhausted" error when it tries to allocate 15 bazillon bytes
of space for the 15 bazillon byte table it is about to read.
This function at least allows us to answer the quesion, "is the
size reasonable?".
 
@findex bfd_get_gp_size
@subsubsection @code{bfd_get_gp_size}
@strong{Synopsis}
@example
int bfd_get_gp_size(bfd *abfd);
@end example
@strong{Description}@*
Return the maximum size of objects to be optimized using the GP
register under MIPS ECOFF. This is typically set by the @code{-G}
argument to the compiler, assembler or linker.
 
@findex bfd_set_gp_size
@subsubsection @code{bfd_set_gp_size}
@strong{Synopsis}
@example
void bfd_set_gp_size(bfd *abfd, int i);
@end example
@strong{Description}@*
Set the maximum size of objects to be optimized using the GP
register under ECOFF or MIPS ELF. This is typically set by
the @code{-G} argument to the compiler, assembler or linker.
 
@findex bfd_scan_vma
@subsubsection @code{bfd_scan_vma}
@strong{Synopsis}
@example
bfd_vma bfd_scan_vma(CONST char *string, CONST char **end, int base);
@end example
@strong{Description}@*
Convert, like @code{strtoul}, a numerical expression
@var{string} into a @code{bfd_vma} integer, and return that integer.
(Though without as many bells and whistles as @code{strtoul}.)
The expression is assumed to be unsigned (i.e., positive).
If given a @var{base}, it is used as the base for conversion.
A base of 0 causes the function to interpret the string
in hex if a leading "0x" or "0X" is found, otherwise
in octal if a leading zero is found, otherwise in decimal.
 
Overflow is not detected.
 
@findex bfd_copy_private_bfd_data
@subsubsection @code{bfd_copy_private_bfd_data}
@strong{Synopsis}
@example
boolean bfd_copy_private_bfd_data(bfd *ibfd, bfd *obfd);
@end example
@strong{Description}@*
Copy private BFD information from the BFD @var{ibfd} to the
the BFD @var{obfd}. Return @code{true} on success, @code{false} on error.
Possible error returns are:
 
@itemize @bullet
 
@item
@code{bfd_error_no_memory} -
Not enough memory exists to create private data for @var{obfd}.
@end itemize
@example
#define bfd_copy_private_bfd_data(ibfd, obfd) \
BFD_SEND (obfd, _bfd_copy_private_bfd_data, \
(ibfd, obfd))
@end example
 
@findex bfd_merge_private_bfd_data
@subsubsection @code{bfd_merge_private_bfd_data}
@strong{Synopsis}
@example
boolean bfd_merge_private_bfd_data(bfd *ibfd, bfd *obfd);
@end example
@strong{Description}@*
Merge private BFD information from the BFD @var{ibfd} to the
the output file BFD @var{obfd} when linking. Return @code{true}
on success, @code{false} on error. Possible error returns are:
 
@itemize @bullet
 
@item
@code{bfd_error_no_memory} -
Not enough memory exists to create private data for @var{obfd}.
@end itemize
@example
#define bfd_merge_private_bfd_data(ibfd, obfd) \
BFD_SEND (obfd, _bfd_merge_private_bfd_data, \
(ibfd, obfd))
@end example
 
@findex bfd_set_private_flags
@subsubsection @code{bfd_set_private_flags}
@strong{Synopsis}
@example
boolean bfd_set_private_flags(bfd *abfd, flagword flags);
@end example
@strong{Description}@*
Set private BFD flag information in the BFD @var{abfd}.
Return @code{true} on success, @code{false} on error. Possible error
returns are:
 
@itemize @bullet
 
@item
@code{bfd_error_no_memory} -
Not enough memory exists to create private data for @var{obfd}.
@end itemize
@example
#define bfd_set_private_flags(abfd, flags) \
BFD_SEND (abfd, _bfd_set_private_flags, \
(abfd, flags))
@end example
 
@findex stuff
@subsubsection @code{stuff}
@strong{Description}@*
Stuff which should be documented:
@example
#define bfd_sizeof_headers(abfd, reloc) \
BFD_SEND (abfd, _bfd_sizeof_headers, (abfd, reloc))
 
#define bfd_find_nearest_line(abfd, sec, syms, off, file, func, line) \
BFD_SEND (abfd, _bfd_find_nearest_line, (abfd, sec, syms, off, file, func, line))
 
/* Do these three do anything useful at all, for any back end? */
#define bfd_debug_info_start(abfd) \
BFD_SEND (abfd, _bfd_debug_info_start, (abfd))
 
#define bfd_debug_info_end(abfd) \
BFD_SEND (abfd, _bfd_debug_info_end, (abfd))
 
#define bfd_debug_info_accumulate(abfd, section) \
BFD_SEND (abfd, _bfd_debug_info_accumulate, (abfd, section))
 
 
#define bfd_stat_arch_elt(abfd, stat) \
BFD_SEND (abfd, _bfd_stat_arch_elt,(abfd, stat))
 
#define bfd_update_armap_timestamp(abfd) \
BFD_SEND (abfd, _bfd_update_armap_timestamp, (abfd))
 
#define bfd_set_arch_mach(abfd, arch, mach)\
BFD_SEND ( abfd, _bfd_set_arch_mach, (abfd, arch, mach))
 
#define bfd_relax_section(abfd, section, link_info, again) \
BFD_SEND (abfd, _bfd_relax_section, (abfd, section, link_info, again))
 
#define bfd_gc_sections(abfd, link_info) \
BFD_SEND (abfd, _bfd_gc_sections, (abfd, link_info))
 
#define bfd_link_hash_table_create(abfd) \
BFD_SEND (abfd, _bfd_link_hash_table_create, (abfd))
 
#define bfd_link_add_symbols(abfd, info) \
BFD_SEND (abfd, _bfd_link_add_symbols, (abfd, info))
 
#define bfd_final_link(abfd, info) \
BFD_SEND (abfd, _bfd_final_link, (abfd, info))
 
#define bfd_free_cached_info(abfd) \
BFD_SEND (abfd, _bfd_free_cached_info, (abfd))
 
#define bfd_get_dynamic_symtab_upper_bound(abfd) \
BFD_SEND (abfd, _bfd_get_dynamic_symtab_upper_bound, (abfd))
 
#define bfd_print_private_bfd_data(abfd, file)\
BFD_SEND (abfd, _bfd_print_private_bfd_data, (abfd, file))
 
#define bfd_canonicalize_dynamic_symtab(abfd, asymbols) \
BFD_SEND (abfd, _bfd_canonicalize_dynamic_symtab, (abfd, asymbols))
 
#define bfd_get_dynamic_reloc_upper_bound(abfd) \
BFD_SEND (abfd, _bfd_get_dynamic_reloc_upper_bound, (abfd))
 
#define bfd_canonicalize_dynamic_reloc(abfd, arels, asyms) \
BFD_SEND (abfd, _bfd_canonicalize_dynamic_reloc, (abfd, arels, asyms))
 
extern bfd_byte *bfd_get_relocated_section_contents
PARAMS ((bfd *, struct bfd_link_info *,
struct bfd_link_order *, bfd_byte *,
boolean, asymbol **));
 
@end example
 
/archive.texi
0,0 → 1,95
@section Archives
 
 
@strong{Description}@*
An archive (or library) is just another BFD. It has a symbol
table, although there's not much a user program will do with it.
 
The big difference between an archive BFD and an ordinary BFD
is that the archive doesn't have sections. Instead it has a
chain of BFDs that are considered its contents. These BFDs can
be manipulated like any other. The BFDs contained in an
archive opened for reading will all be opened for reading. You
may put either input or output BFDs into an archive opened for
output; they will be handled correctly when the archive is closed.
 
Use @code{bfd_openr_next_archived_file} to step through
the contents of an archive opened for input. You don't
have to read the entire archive if you don't want
to! Read it until you find what you want.
 
Archive contents of output BFDs are chained through the
@code{next} pointer in a BFD. The first one is findable through
the @code{archive_head} slot of the archive. Set it with
@code{bfd_set_archive_head} (q.v.). A given BFD may be in only one
open output archive at a time.
 
As expected, the BFD archive code is more general than the
archive code of any given environment. BFD archives may
contain files of different formats (e.g., a.out and coff) and
even different architectures. You may even place archives
recursively into archives!
 
This can cause unexpected confusion, since some archive
formats are more expressive than others. For instance, Intel
COFF archives can preserve long filenames; SunOS a.out archives
cannot. If you move a file from the first to the second
format and back again, the filename may be truncated.
Likewise, different a.out environments have different
conventions as to how they truncate filenames, whether they
preserve directory names in filenames, etc. When
interoperating with native tools, be sure your files are
homogeneous.
 
Beware: most of these formats do not react well to the
presence of spaces in filenames. We do the best we can, but
can't always handle this case due to restrictions in the format of
archives. Many Unix utilities are braindead in regards to
spaces and such in filenames anyway, so this shouldn't be much
of a restriction.
 
Archives are supported in BFD in @code{archive.c}.
 
@findex bfd_get_next_mapent
@subsubsection @code{bfd_get_next_mapent}
@strong{Synopsis}
@example
symindex bfd_get_next_mapent(bfd *abfd, symindex previous, carsym **sym);
@end example
@strong{Description}@*
Step through archive @var{abfd}'s symbol table (if it
has one). Successively update @var{sym} with the next symbol's
information, returning that symbol's (internal) index into the
symbol table.
 
Supply @code{BFD_NO_MORE_SYMBOLS} as the @var{previous} entry to get
the first one; returns @code{BFD_NO_MORE_SYMBOLS} when you've already
got the last one.
 
A @code{carsym} is a canonical archive symbol. The only
user-visible element is its name, a null-terminated string.
 
@findex bfd_set_archive_head
@subsubsection @code{bfd_set_archive_head}
@strong{Synopsis}
@example
boolean bfd_set_archive_head(bfd *output, bfd *new_head);
@end example
@strong{Description}@*
Set the head of the chain of
BFDs contained in the archive @var{output} to @var{new_head}.
 
@findex bfd_openr_next_archived_file
@subsubsection @code{bfd_openr_next_archived_file}
@strong{Synopsis}
@example
bfd *bfd_openr_next_archived_file(bfd *archive, bfd *previous);
@end example
@strong{Description}@*
Provided a BFD, @var{archive}, containing an archive and NULL, open
an input BFD on the first contained element and returns that.
Subsequent calls should pass
the archive and the previous return value to return a created
BFD to the next contained element. NULL is returned when there
are no more.
 
/targets.log
0,0 → 1,2430
This is pdfTeX, Version 3.14159-13d (Web2C 7.3.1) (format=pdftex 2000.7.19) 15 MAY 2001 10:39
**/home/markom/gdb/gdb-5.0/bfd/doc/targets.texi
(/home/markom/gdb/gdb-5.0/bfd/doc/targets.texi[/usr/share/texmf/pdftex/config/p
dftex.cfg]
Babel <v3.6Z> and hyphenation patterns for american, french, german, ngerman, i
talian, nohyphenation, loaded.
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.12 When a file is opened with @code{bfd_
openr}, its format and
? q
OK, entering \batchmode...
! Extra }, or forgotten $.
l.12 When a file is opened with @code{bfd_openr}
, its format and
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.15
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (306.20938pt too wide) in paragraph at lines 12--15
[]\tenrm When a file is opened with @codebfd$[]\teni penr; itsformatandtargetar
eunknown:BFDusesvariousmechanismstodeterminehowtointerpretthefile:Theoperations
performedare \tenrm :$ |
 
\hbox(6.94444+1.94444)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm W
.\tenrm h
.\tenrm e
.\tenrm n
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.20 @code{_
bfd_new_bfd}, then call @code{bfd_find_target} with the
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Extra }, or forgotten $.
l.20 @code{_bfd_new_bfd}
, then call @code{bfd_find_target} with the
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.22
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (284.22328pt too wide) in paragraph at lines 18--22
[]\tenrm @item Cre-ate a BFD by call-ing the in-ter-nal rou-tine @code$[]\teni
fd[]ew[]fd; thencall\tenrm @\teni code[]withthetargetstringsuppliedto\tenrm @\t
eni code[]andthenewBFDpointer:$ |
 
\hbox(6.94444+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm @
.\tenrm i
.\tenrm t
.\tenrm e
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.24 ...l target string was provided to @code{bfd_
find_target},
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Extra }, or forgotten $.
l.24 ...ing was provided to @code{bfd_find_target}
,
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.27
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (198.12112pt too wide) in paragraph at lines 23--27
[]\tenrm @item If a null tar-get string was pro-vided to @codebfd$[]\teni ind[]
arget; lookuptheenvironmentvariable\tenrm @\teni code[]andusethatasthetargetstr
ing:$ |
 
\hbox(6.94444+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm @
.\tenrm i
.\tenrm t
.\tenrm e
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.31 as the target type, and set @code{target_
defaulted} in the BFD to
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Extra }, or forgotten $.
l.31 ...rget type, and set @code{target_defaulted}
in the BFD to
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.34
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (271.4008pt too wide) in paragraph at lines 28--34
\tenrm in the tar-get vec-tor as the tar-get type, and set @codetarget$[]\teni
efaultedintheBFDtocause\tenrm @\teni code[]toloopthroughallthetargets:\tenrm @\
teni xref[]:\tenrm @\teni xref[]:$ |
 
\hbox(6.94444+2.86108)x469.75499, glue set - 1.0
.\tenrm i
.\tenrm n
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm t
.\tenrm h
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.41 Otherwise return the error @code{bfd_
error_invalid_target} to
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Extra }, or forgotten $.
l.41 ... the error @code{bfd_error_invalid_target}
to
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.43
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.45 @code{bfd_
openr} attempts to open the file using
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Extra }, or forgotten $.
l.45 @code{bfd_openr}
attempts to open the file using
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.57
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (1523.06082pt too wide) in paragraph at lines 44--57
[]\tenrm @item @codebfd$[]\teni penrattemptstoopenthefileusing\tenrm @\teni cod
e[]; andreturnstheBFD:\tenrm @\teni enditemizeOncetheBFDhasbeenopenedandthetarg
etselected; thefileformatmaybedetermined:Thisisdonebycalling\tenrm @\teni code[
]ontheBFDwithasuggestedformat:If\tenrm @\teni code[]hasbeenset; eachpossibletar
gettypeistriedtoseeifitrecognizesthespecifiedformat:\tenrm @\teni code[]returns
\tenrm @\teni code[]whenthecallerguessesright:\tenrm @\teni menu \tensy ^^C|
 
\hbox(6.94444+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm @
.\tenrm i
.\tenrm t
.\tenrm e
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.58 @node bfd_
target, , Targets, Targets
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.59
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.60 @subsection bfd_
target
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.61
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.72 @code{bfd_
target} vector. They are used in a number of macros further
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Extra }, or forgotten $.
l.72 @code{bfd_target}
vector. They are used in a number of macros further
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.77
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (983.60736pt too wide) in paragraph at lines 71--77
[]\tenrm The macros be-low are used to dis-patch to func-tions through the @cod
ebfd$[]\teni argetvector:Theyareusedinanumberofmacrosfurtherdownin\tenrm @\teni
file[]; andarealsousedwhencallingvariousroutinesbyhandinsidetheBFDimplementati
on:The\tenrm @\teni var[]argumentmustbeparenthesized\tenrm ; \teni itcontainsal
ltheargumentstothecalledfunction:$ |
 
\hbox(6.94444+1.94444)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm T
.\tenrm h
.\tenrm e
.\glue 3.33333 plus 1.66666 minus 1.11111
.etc.
 
! You can't use `macro parameter character #' in horizontal mode.
l.81 #
define BFD_SEND(bfd, message, arglist) \
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.81 #define BFD_
SEND(bfd, message, arglist) \
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.83
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! You can't use `macro parameter character #' in vertical mode.
l.84 #
ifdef DEBUG_BFD_SEND
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.84 #ifdef DEBUG_
BFD_SEND
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! You can't use `macro parameter character #' in math mode.
l.85 #
undef BFD_SEND
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! You can't use `macro parameter character #' in math mode.
l.86 #
define BFD_SEND(bfd, message, arglist) \
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Misplaced alignment tab character &.
l.87 (((bfd) &
& (bfd)->xvec && (bfd)->xvec->message) ? \
I can't figure out why you would want to use a tab mark
here. If you just want an ampersand, the remedy is
simple: Just type `I\&' now. But if some right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.
 
! Misplaced alignment tab character &.
l.87 (((bfd) &&
(bfd)->xvec && (bfd)->xvec->message) ? \
I can't figure out why you would want to use a tab mark
here. If you just want an ampersand, the remedy is
simple: Just type `I\&' now. But if some right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.
 
! Misplaced alignment tab character &.
l.87 (((bfd) && (bfd)->xvec &
& (bfd)->xvec->message) ? \
I can't figure out why you would want to use a tab mark
here. If you just want an ampersand, the remedy is
simple: Just type `I\&' now. But if some right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.
 
! Misplaced alignment tab character &.
l.87 (((bfd) && (bfd)->xvec &&
(bfd)->xvec->message) ? \
I can't figure out why you would want to use a tab mark
here. If you just want an ampersand, the remedy is
simple: Just type `I\&' now. But if some right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.
 
! Missing { inserted.
<to be read again>
_
l.89 (bfd_assert (__
FILE__,__LINE__), NULL))
A left brace was mandatory here, so I've put one in.
You might want to delete and/or insert some corrections
so that I will find a matching right brace soon.
(If you're confused by all this, try typing `I}' now.)
 
! Missing { inserted.
<to be read again>
_
l.89 (bfd_assert (__FILE__
,__LINE__), NULL))
A left brace was mandatory here, so I've put one in.
You might want to delete and/or insert some corrections
so that I will find a matching right brace soon.
(If you're confused by all this, try typing `I}' now.)
 
! Double subscript.
l.89 (bfd_assert (__FILE__,_
_LINE__), NULL))
I treat `x_1_2' essentially like `x_1{}_2'.
 
! Missing { inserted.
<to be read again>
_
l.89 (bfd_assert (__FILE__,__
LINE__), NULL))
A left brace was mandatory here, so I've put one in.
You might want to delete and/or insert some corrections
so that I will find a matching right brace soon.
(If you're confused by all this, try typing `I}' now.)
 
! Missing { inserted.
<to be read again>
_
l.89 (bfd_assert (__FILE__,__LINE__
), NULL))
A left brace was mandatory here, so I've put one in.
You might want to delete and/or insert some corrections
so that I will find a matching right brace soon.
(If you're confused by all this, try typing `I}' now.)
 
! You can't use `macro parameter character #' in math mode.
l.90 #
endif
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! You can't use `macro parameter character #' in math mode.
l.94 #
define BFD_SEND_FMT(bfd, message, arglist) \
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.96
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing } inserted.
<inserted text>
}
<to be read again>
$
<to be read again>
\par
l.96
I've inserted something that you may have forgotten.
(See the <inserted text> above.)
With luck, this will get me unwedged. But if you
really didn't forget anything, try typing `2' now; then
my insertion and my current dilemma will both disappear.
 
! Missing } inserted.
<inserted text>
}
<to be read again>
$
<to be read again>
\par
l.96
I've inserted something that you may have forgotten.
(See the <inserted text> above.)
With luck, this will get me unwedged. But if you
really didn't forget anything, try typing `2' now; then
my insertion and my current dilemma will both disappear.
 
! Missing } inserted.
<inserted text>
}
<to be read again>
$
<to be read again>
\par
l.96
I've inserted something that you may have forgotten.
(See the <inserted text> above.)
With luck, this will get me unwedged. But if you
really didn't forget anything, try typing `2' now; then
my insertion and my current dilemma will both disappear.
 
! Missing } inserted.
<inserted text>
}
<to be read again>
$
<to be read again>
\par
l.96
I've inserted something that you may have forgotten.
(See the <inserted text> above.)
With luck, this will get me unwedged. But if you
really didn't forget anything, try typing `2' now; then
my insertion and my current dilemma will both disappear.
 
 
Overfull \hbox (6.35303pt too wide) in paragraph at lines 84--96
[]\tenrm ifdef DEBUG$[]\teni FD[]ENDundefBFD[]ENDdefineBFD[]END\tenrm (\teni bf
d; message; arglist\tenrm ) (((\teni bfd\tenrm )(\teni bfd\tenrm )\tensy ^^@ \t
eni >|
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm i
.\tenrm f
.\tenrm d
.\tenrm e
.etc.
 
 
Overfull \hbox (582.33636pt too wide) in paragraph at lines 84--96
\teni xvec\tenrm (\teni bfd\tenrm )\tensy ^^@ \teni > xvec\tensy ^^@ \teni > me
ssage\tenrm )? ((\tensy ^^C\tenrm ((\teni bfd\tenrm )\tensy ^^@ \teni > xvec\te
nsy ^^@ \teni > message\tenrm ))\teni arglist\tenrm ) : (\teni bfd[]ssert\tenr
m ([]$ |
 
\hbox(7.5+9.50002)x469.75499, glue set - 1.0
.\teni x
.\teni v
.\kern0.35878
.\teni e
.\teni c
.etc.
 
! You can't use `macro parameter character #' in vertical mode.
l.97 #
ifdef DEBUG_BFD_SEND
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.97 #ifdef DEBUG_
BFD_SEND
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! You can't use `macro parameter character #' in math mode.
l.98 #
undef BFD_SEND_FMT
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! You can't use `macro parameter character #' in math mode.
l.99 #
define BFD_SEND_FMT(bfd, message, arglist) \
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Misplaced alignment tab character &.
l.100 (((bfd) &
& (bfd)->xvec && (bfd)->xvec->message) ? \
I can't figure out why you would want to use a tab mark
here. If you just want an ampersand, the remedy is
simple: Just type `I\&' now. But if some right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.
 
! Misplaced alignment tab character &.
l.100 (((bfd) &&
(bfd)->xvec && (bfd)->xvec->message) ? \
I can't figure out why you would want to use a tab mark
here. If you just want an ampersand, the remedy is
simple: Just type `I\&' now. But if some right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.
 
! Misplaced alignment tab character &.
l.100 (((bfd) && (bfd)->xvec &
& (bfd)->xvec->message) ? \
I can't figure out why you would want to use a tab mark
here. If you just want an ampersand, the remedy is
simple: Just type `I\&' now. But if some right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.
 
! Misplaced alignment tab character &.
l.100 (((bfd) && (bfd)->xvec &&
(bfd)->xvec->message) ? \
I can't figure out why you would want to use a tab mark
here. If you just want an ampersand, the remedy is
simple: Just type `I\&' now. But if some right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.
 
! Missing { inserted.
<to be read again>
_
l.102 (bfd_assert (__
FILE__,__LINE__), NULL))
A left brace was mandatory here, so I've put one in.
You might want to delete and/or insert some corrections
so that I will find a matching right brace soon.
(If you're confused by all this, try typing `I}' now.)
 
! Missing { inserted.
<to be read again>
_
l.102 (bfd_assert (__FILE__
,__LINE__), NULL))
A left brace was mandatory here, so I've put one in.
You might want to delete and/or insert some corrections
so that I will find a matching right brace soon.
(If you're confused by all this, try typing `I}' now.)
 
! Double subscript.
l.102 (bfd_assert (__FILE__,_
_LINE__), NULL))
I treat `x_1_2' essentially like `x_1{}_2'.
 
! Missing { inserted.
<to be read again>
_
l.102 (bfd_assert (__FILE__,__
LINE__), NULL))
A left brace was mandatory here, so I've put one in.
You might want to delete and/or insert some corrections
so that I will find a matching right brace soon.
(If you're confused by all this, try typing `I}' now.)
 
! Missing { inserted.
<to be read again>
_
l.102 (bfd_assert (__FILE__,__LINE__
), NULL))
A left brace was mandatory here, so I've put one in.
You might want to delete and/or insert some corrections
so that I will find a matching right brace soon.
(If you're confused by all this, try typing `I}' now.)
 
! You can't use `macro parameter character #' in math mode.
l.103 #
endif
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.109
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing } inserted.
<inserted text>
}
<to be read again>
$
<to be read again>
\par
l.109
I've inserted something that you may have forgotten.
(See the <inserted text> above.)
With luck, this will get me unwedged. But if you
really didn't forget anything, try typing `2' now; then
my insertion and my current dilemma will both disappear.
 
! Missing } inserted.
<inserted text>
}
<to be read again>
$
<to be read again>
\par
l.109
I've inserted something that you may have forgotten.
(See the <inserted text> above.)
With luck, this will get me unwedged. But if you
really didn't forget anything, try typing `2' now; then
my insertion and my current dilemma will both disappear.
 
! Missing } inserted.
<inserted text>
}
<to be read again>
$
<to be read again>
\par
l.109
I've inserted something that you may have forgotten.
(See the <inserted text> above.)
With luck, this will get me unwedged. But if you
really didn't forget anything, try typing `2' now; then
my insertion and my current dilemma will both disappear.
 
! Missing } inserted.
<inserted text>
}
<to be read again>
$
<to be read again>
\par
l.109
I've inserted something that you may have forgotten.
(See the <inserted text> above.)
With luck, this will get me unwedged. But if you
really didn't forget anything, try typing `2' now; then
my insertion and my current dilemma will both disappear.
 
 
Overfull \hbox (55.14197pt too wide) in paragraph at lines 97--109
[]\tenrm ifdef DEBUG$[]\teni FD[]ENDundefBFD[]END[]MTdefineBFD[]END[]MT\tenrm (
\teni bfd; message; arglist\tenrm ) (((\teni bfd\tenrm )(\teni bfd\tenrm )\tens
y ^^@ \teni >|
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm i
.\tenrm f
.\tenrm d
.\tenrm e
.etc.
 
 
Overfull \hbox (366.75514pt too wide) in paragraph at lines 97--109
\tenrm (\teni bfd[]ssert\tenrm ([]$ |
 
\hbox(7.5+9.50002)x469.75499
.\tenrm (
.\teni b
.\teni f
.\kern1.0764
.\teni d
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.114 enum bfd_
flavour @{
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.133
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (1617.72424pt too wide) in paragraph at lines 110--133
\tenrm we can't have one macro to de-fine them both! @ex-am-ple enum bfd$[]\ten
i lavour\tenrm @[];$ |
 
\hbox(6.94444+2.86108)x469.75499, glue set - 1.0
.\tenrm w
.\kern-0.27779
.\tenrm e
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm c
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.134 enum bfd_
endian @{ BFD_ENDIAN_BIG, BFD_ENDIAN_LITTLE, BFD_ENDIAN_UNKNO...
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.135
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.137 typedef struct bfd_
link_info _bfd_link_info;
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.138
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.139 typedef struct bfd_
target
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing { inserted.
<to be read again>
^
'->^
\bgroup \prim@s
l.170 (if any), perhaps `_'
.
A left brace was mandatory here, so I've put one in.
You might want to delete and/or insert some corrections
so that I will find a matching right brace soon.
(If you're confused by all this, try typing `I}' now.)
 
! Double subscript.
l.198 bfd_vma (*bfd_h_
getx64) PARAMS ((const bfd_byte *));
I treat `x_1_2' essentially like `x_1{}_2'.
 
! Double subscript.
l.199 bfd_signed_vma (*bfd_h_
getx_signed_64) PARAMS ((const bfd_byte *));
I treat `x_1_2' essentially like `x_1{}_2'.
 
! Double subscript.
l.200 void (*bfd_h_
putx64) PARAMS ((bfd_vma, bfd_byte *));
I treat `x_1_2' essentially like `x_1{}_2'.
 
! Double subscript.
l.201 bfd_vma (*bfd_h_
getx32) PARAMS ((const bfd_byte *));
I treat `x_1_2' essentially like `x_1{}_2'.
 
! Double subscript.
l.202 bfd_signed_vma (*bfd_h_
getx_signed_32) PARAMS ((const bfd_byte *));
I treat `x_1_2' essentially like `x_1{}_2'.
 
! Double subscript.
l.203 void (*bfd_h_
putx32) PARAMS ((bfd_vma, bfd_byte *));
I treat `x_1_2' essentially like `x_1{}_2'.
 
! Double subscript.
l.204 bfd_vma (*bfd_h_
getx16) PARAMS ((const bfd_byte *));
I treat `x_1_2' essentially like `x_1{}_2'.
 
! Double subscript.
l.205 bfd_signed_vma (*bfd_h_
getx_signed_16) PARAMS ((const bfd_byte *));
I treat `x_1_2' essentially like `x_1{}_2'.
 
! Double subscript.
l.206 void (*bfd_h_
putx16) PARAMS ((bfd_vma, bfd_byte *));
I treat `x_1_2' essentially like `x_1{}_2'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.210
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing } inserted.
<inserted text>
}
<to be read again>
$
<to be read again>
\par
l.210
I've inserted something that you may have forgotten.
(See the <inserted text> above.)
With luck, this will get me unwedged. But if you
really didn't forget anything, try typing `2' now; then
my insertion and my current dilemma will both disappear.
 
! Missing } inserted.
<inserted text>
}
<to be read again>
$
<to be read again>
\par
l.210
I've inserted something that you may have forgotten.
(See the <inserted text> above.)
With luck, this will get me unwedged. But if you
really didn't forget anything, try typing `2' now; then
my insertion and my current dilemma will both disappear.
 
 
Overfull \hbox (9145.03305pt too wide) in paragraph at lines 139--210
[]\tenrm typedef struct bfd$[]\teni arget\tenrm @[]$ |
 
\hbox(7.5+3.77779)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm t
.\kern-0.27779
.\tenrm y
.\tenrm p
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.211 ...f a file being read. Return a @code{bfd_
target *} or zero.
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Extra }, or forgotten $.
l.211 ...being read. Return a @code{bfd_target *}
or zero.
I've deleted a group-closing symbol because it seems to be
spurious, as in `$x}$'. But perhaps the } is legitimate and
you forgot something else, as in `\hbox{$x}'. In such cases
the way to recover is to insert both the forgotten and the
deleted material, e.g., by typing `I$}'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.226
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (1432.4339pt too wide) in paragraph at lines 211--226
\tenrm (\tensy ^^C[]\teni fd[]heck[]ormat\tenrm [\teni bfd[]ype[]nd\tenrm ])\te
ni PARAMS\tenrm ((\teni bfd\tensy ^^C\tenrm )); @\teni endexampleSettheformatof
afilebeingwritten:\tenrm @\teni exampleboolean\tenrm (\tensy ^^C[]\teni fd[]et[
]ormat\tenrm [\teni bfd[]ype[]nd\tenrm ])\teni PARAMS\tenrm ((\teni bfd\tensy ^
^C\tenrm )); @\teni endexampleWritecachedinformationintoafilebeingwritten; at\t
enrm @\teni code[]:\tenrm @\teni exampleboolean\tenrm (\tensy ^^C[]\teni fd[]ri
te[]ontents\tenrm [\teni bfd[]ype[]nd\tenrm ])\teni PARAMS\tenrm ((\teni bfd\te
nsy ^^C\tenrm )); @\teni endexampleThegeneraltargetvector:Thesevectorsareinitia
lizedusingtheBFD[]UMP[]ABLEmacros:\tenrm @\teni example$ |
 
\hbox(7.5+2.86108)x469.75499
.\tenrm (
.\tensy ^^C
.\hbox(4.8611+0.0)x4.01666, shifted 1.49998
..\seveni b
.\teni f
.\kern1.0764
.etc.
 
! You can't use `macro parameter character #' in horizontal mode.
l.228 #
define BFD_JUMP_TABLE_GENERIC(NAME)\
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.228 #define BFD_
JUMP_TABLE_GENERIC(NAME)\
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.234
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (690.33372pt too wide) in paragraph at lines 227--234
[]\tenrm /* Generic en-try points. */ de-fine BFD$[]\teni UMP[]ABLE[]ENERIC\ten
rm (\teni NAME\tenrm ) \teni CAT\tenrm (\teni NAME;[] lose[]nd[]leanup\tenrm )\
teni ; CAT\tenrm (\teni NAME;[] fd[]ree[]ached[]nfo\tenrm )\teni ; CAT\tenrm
(\teni NAME;[] ew[]ection[]ook\tenrm )\teni ; CAT\tenrm (\teni NAME;[] et[]ect
ion[]ontents\tenrm )\teni ; CAT\tenrm (\teni NAME;[] et[]ection[]ontents[]n[]i
ndow\tenrm )$ |
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm G
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.236 boolean (*_
close_and_cleanup) PARAMS ((bfd *));
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.247
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (75.98923pt too wide) in paragraph at lines 235--247
[]\tenrm /* Called when the BFD is be-ing closed to do any nec-es-sary cleanup.
*/ boolean (*$[]\teni lose[]nd[]leanup\tenrm )\teni PARAMS\tenrm ((\teni bfd\t
ensy ^^C\tenrm )); \teni = \tensy ^^C|
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm C
.etc.
 
 
Overfull \hbox (110.88339pt too wide) in paragraph at lines 235--247
\teni AsktheBFDtofreeallcachedinformation: \tensy ^^C \teni =boolean\tenrm (\te
nsy ^^C[]\teni fd[]ree[]ached[]nfo\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy
^^C\tenrm )); \teni = \tensy ^^C \teni Calledwhenanewsectioniscreated: \tensy ^
^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\teni A
.\teni s
.\teni k
.\kern0.3148
.\teni t
.etc.
 
 
Overfull \hbox (744.53798pt too wide) in paragraph at lines 235--247
\teni =boolean\tenrm (\tensy ^^C[]\teni ew[]ection[]ook\tenrm )\teni PARAMS\ten
rm ((\teni bfd\tensy ^^C\teni ; sec[]tr\tenrm )); \teni = \tensy ^^C \teni Read
thecontentsofasection: \tensy ^^C \teni =boolean\tenrm (\tensy ^^C[]\teni fd[]e
t[]ection[]ontents\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\teni ; sec[]
tr; PTR; file[]tr; bfd[]ize[]ype\tenrm )); \teni boolean\tenrm (\tensy ^^C[]\te
ni fd[]et[]ection[]ontents[]n[]indow\tenrm )\teni PARAMS\tenrm ((\teni bfd\tens
y ^^C\teni ; sec[]tr; bfd[]indow\tensy ^^C\teni ; file[]tr; bfd[]ize[]ype\tenrm
));$ |
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\teni =
.\teni b
.\teni o
.\teni o
.\teni l
.etc.
 
! You can't use `macro parameter character #' in horizontal mode.
l.249 #
define BFD_JUMP_TABLE_COPY(NAME)\
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.249 #define BFD_
JUMP_TABLE_COPY(NAME)\
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.272
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (1005.69203pt too wide) in paragraph at lines 248--272
[]\tenrm /* En-try points to copy pri-vate data. */ de-fine BFD$[]\teni UMP[]AB
LE[]OPY\tenrm (\teni NAME\tenrm ) \teni CAT\tenrm (\teni NAME;[] fd[]opy[]rivat
e[]fd[]ata\tenrm )\teni ; CAT\tenrm (\teni NAME;[] fd[]erge[]rivate[]fd[]ata\t
enrm )\teni ; CAT\tenrm (\teni NAME;[] fd[]opy[]rivate[]ection[]ata\tenrm )\te
ni ; CAT\tenrm (\teni NAME;[] fd[]opy[]rivate[]ymbol[]ata\tenrm )\teni ; CAT\
tenrm (\teni NAME;[] fd[]et[]rivate[]lags\tenrm )\teni ; CAT\tenrm (\teni NAME
;[] fd[]rint[]rivate[]fd[]ata\tenrm ) \teni = \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm E
.etc.
 
 
Overfull \hbox (105.27933pt too wide) in paragraph at lines 248--272
\teni CalledtocopyBFDgeneralprivatedatafromoneobjectfiletoanother: \tensy ^^C \
teni =boolean\tenrm (\tensy ^^C[]\teni fd[]opy[]rivate[]fd[]ata\tenrm )\teni PA
RAMS\tenrm ((\teni bfd\tensy ^^C\teni ; bfd\tensy ^^C\tenrm )); \teni = \tensy
^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\teni C
.\kern0.71527
.\teni a
.\teni l
.\kern0.19678
.etc.
 
 
Overfull \hbox (232.6433pt too wide) in paragraph at lines 248--272
\teni CalledtomergeBFDgeneralprivatedatafromoneobjectfiletoacommonoutputfilewhe
nlinking: \tensy ^^C \teni =boolean\tenrm (\tensy ^^C[]\teni fd[]erge[]rivate[]
fd[]ata\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\teni ; bfd\tensy ^^C\te
nrm )); \teni = \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\teni C
.\kern0.71527
.\teni a
.\teni l
.\kern0.19678
.etc.
 
 
Overfull \hbox (180.84906pt too wide) in paragraph at lines 248--272
\teni CalledtocopyBFDprivatesectiondatafromoneobjectfiletoanother: \tensy ^^C \
teni =boolean\tenrm (\tensy ^^C[]\teni fd[]opy[]rivate[]ection[]ata\tenrm )\ten
i PARAMS\tenrm ((\teni bfd\tensy ^^C\teni ; sec[]tr; bfd\tensy ^^C\teni ; sec[]
tr\tenrm )); \teni = \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\teni C
.\kern0.71527
.\teni a
.\teni l
.\kern0.19678
.etc.
 
 
Overfull \hbox (196.80196pt too wide) in paragraph at lines 248--272
\teni CalledtocopyBFDprivatesymboldatafromonesymboltoanother: \tensy ^^C \teni
=boolean\tenrm (\tensy ^^C[]\teni fd[]opy[]rivate[]ymbol[]ata\tenrm )\teni PARA
MS\tenrm ((\teni bfd\tensy ^^C\teni ; asymbol\tensy ^^C\teni ; bfd\tensy ^^C\te
ni ; asymbol\tensy ^^C\tenrm )); \teni = \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\teni C
.\kern0.71527
.\teni a
.\teni l
.\kern0.19678
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.274 boolean (*_
bfd_print_private_bfd_data) PARAMS ((bfd *, PTR));
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.275
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! You can't use `macro parameter character #' in horizontal mode.
l.277 #
define BFD_JUMP_TABLE_CORE(NAME)\
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.277 #define BFD_
JUMP_TABLE_CORE(NAME)\
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.284
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (435.32944pt too wide) in paragraph at lines 276--284
[]\tenrm /* Core file en-try points. */ de-fine BFD$[]\teni UMP[]ABLE[]ORE\tenr
m (\teni NAME\tenrm ) \teni CAT\tenrm (\teni NAME;[] ore[]ile[]ailing[]ommand\t
enrm )\teni ; CAT\tenrm (\teni NAME;[] ore[]ile[]ailing[]ignal\tenrm )\teni ;
CAT\tenrm (\teni NAME;[] ore[]ile[]atches[]xecutable[]\tenrm )\teni char \tens
y ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm C
.etc.
 
 
Overfull \hbox (227.0452pt too wide) in paragraph at lines 276--284
\tenrm (\tensy ^^C[]\teni ore[]ile[]ailing[]ommand\tenrm )\teni PARAMS\tenrm ((
\teni bfd\tensy ^^C\tenrm )); \teni int\tenrm (\tensy ^^C[]\teni ore[]ile[]aili
ng[]ignal\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\tenrm )); \teni boole
an\tenrm (\tensy ^^C[]\teni ore[]ile[]atches[]xecutable[]\tenrm )\teni PARAMS\t
enrm ((\teni bfd\tensy ^^C\teni ; bfd\tensy ^^C\tenrm ));$ |
 
\hbox(7.5+2.86108)x469.75499
.\tenrm (
.\tensy ^^C
.\hbox(3.01389+0.0)x4.07375, shifted 1.49998
..\seveni c
.\teni o
.\teni r
.etc.
 
! You can't use `macro parameter character #' in horizontal mode.
l.286 #
define BFD_JUMP_TABLE_ARCHIVE(NAME)\
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.286 #define BFD_
JUMP_TABLE_ARCHIVE(NAME)\
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! You can't use `macro parameter character #' in math mode.
l.309 #
define bfd_get_elt_at_index(b,i) BFD_SEND(b, _bfd_get_elt_at_index, (...
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.313
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (2190.77087pt too wide) in paragraph at lines 285--313
[]\tenrm /* Archive en-try points. */ de-fine BFD$[]\teni UMP[]ABLE[]RCHIVE\ten
rm (\teni NAME\tenrm ) \teni CAT\tenrm (\teni NAME;[] lurp[]rmap\tenrm )\teni ;
CAT\tenrm (\teni NAME;[] lurp[]xtended[]ame[]able\tenrm )\teni ; CAT\tenrm (
\teni NAME;[] onstruct[]xtended[]ame[]able\tenrm )\teni ; CAT\tenrm (\teni NAM
E;[] runcate[]rname\tenrm )\teni ; CAT\tenrm (\teni NAME;[] rite[]rmap\tenrm )
\teni ; CAT\tenrm (\teni NAME;[] ead[]r[]dr\tenrm )\teni ; CAT\tenrm (\teni N
AME;[] penr[]ext[]rchived[]ile\tenrm )\teni ; CAT\tenrm (\teni NAME;[] et[]lt[
]t[]ndex\tenrm )\teni ; CAT\tenrm (\teni NAME;[] eneric[]tat[]rch[]lt\tenrm )\
teni ; CAT\tenrm (\teni NAME;[] pdate[]rmap[]imestamp\tenrm )\teni boolean\ten
rm (\tensy ^^C[]\teni fd[]lurp[]rmap\tenrm )\teni PARAMS\tenrm ((\teni bfd\tens
y ^^C\tenrm )); \teni boolean\tenrm (\tensy ^^C[]\teni fd[]lurp[]xtended[]ame[]
able\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\tenrm )); \teni boolean\te
nrm (\tensy ^^C[]\teni fd[]onstruct[]xtended[]ame[]able\tenrm )\teni PARAMS\ten
rm ((\teni bfd\tensy ^^C\teni ; char \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm A
.etc.
 
 
Overfull \hbox (146.6143pt too wide) in paragraph at lines 285--313
\tensy ^^C\teni ; bfd[]ize[]ype\tensy ^^C\teni ; constchar \tensy ^^C ^^C\tenrm
)); \teni void\tenrm (\tensy ^^C[]\teni fd[]runcate[]rname\tenrm )\teni PARAMS
\tenrm ((\teni bfd\tensy ^^C\teni ; CONSTchar\tensy ^^C\teni ; char\tensy ^^C\t
enrm )); \teni boolean\tenrm (\tensy ^^C\teni write[]rmap\tenrm )\teni PARAMS\t
enrm ((\teni bfd \tensy ^^C|
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\tensy ^^C
.\teni ;
.\glue(\thinmuskip) 1.66663
.\teni b
.\teni f
.etc.
 
 
Overfull \hbox (76.89238pt too wide) in paragraph at lines 285--313
\teni arch; unsignedintelength; structorl \tensy ^^C \teni map; unsignedintorl[
]ount; intstridx\tenrm )); \teni PTR\tenrm (\tensy ^^C[]\teni fd[]ead[]r[]dr[]n
\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\tenrm )); \teni bfd \tensy ^^C
|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\teni a
.\teni r
.\kern0.27779
.\teni c
.\teni h
.etc.
 
 
Overfull \hbox (107.68881pt too wide) in paragraph at lines 285--313
\tenrm (\tensy ^^C\teni openr[]ext[]rchived[]ile\tenrm )\teni PARAMS\tenrm ((\t
eni bfd \tensy ^^C \teni arch; bfd \tensy ^^C \teni prev\tenrm )); \teni define
bfd[]et[]lt[]t[]ndex\tenrm (\teni b; i\tenrm )\teni BFD[]END\tenrm (\teni b;[]
fd[]et[]lt[]t[]ndex; \tenrm (\teni b; i\tenrm ))\teni bfd \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\tenrm (
.\tensy ^^C
.\teni o
.\teni p
.\teni e
.etc.
 
 
Overfull \hbox (236.0826pt too wide) in paragraph at lines 285--313
\tenrm (\tensy ^^C[]\teni fd[]et[]lt[]t[]ndex\tenrm )\teni PARAMS\tenrm ((\teni
bfd\tensy ^^C\teni ; symindex\tenrm )); \teni int\tenrm (\tensy ^^C[]\teni fd[
]tat[]rch[]lt\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\teni ; structstat
\tensy ^^C\tenrm )); \teni boolean\tenrm (\tensy ^^C[]\teni fd[]pdate[]rmap[]im
estamp\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\tenrm ));$ |
 
\hbox(7.5+2.86108)x469.75499
.\tenrm (
.\tensy ^^C
.\hbox(4.8611+0.0)x4.01666, shifted 1.49998
..\seveni b
.\teni f
.\kern1.0764
.etc.
 
[1[/usr/share/texmf/dvips/config/pdftex.map]]
! You can't use `macro parameter character #' in horizontal mode.
l.315 #
define BFD_JUMP_TABLE_SYMBOLS(NAME)\
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.315 #define BFD_
JUMP_TABLE_SYMBOLS(NAME)\
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! You can't use `macro parameter character #' in math mode.
l.335 #
define bfd_print_symbol(b,p,s,e) BFD_SEND(b, _bfd_print_symbol, (b,p,...
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! You can't use `macro parameter character #' in math mode.
l.339 #
define bfd_get_symbol_info(b,p,e) BFD_SEND(b, _bfd_get_symbol_info, (...
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.341
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (2113.0178pt too wide) in paragraph at lines 314--341
[]\tenrm /* En-try points used for sym-bols. */ de-fine BFD$[]\teni UMP[]ABLE[]
YMBOLS\tenrm (\teni NAME\tenrm ) \teni CAT\tenrm (\teni NAME;[] et[]ymtab[]pper
[]ound\tenrm )\teni ; CAT\tenrm (\teni NAME;[] et[]ymtab\tenrm )\teni ; CAT\t
enrm (\teni NAME;[] ake[]mpty[]ymbol\tenrm )\teni ; CAT\tenrm (\teni NAME;[] r
int[]ymbol\tenrm )\teni ; CAT\tenrm (\teni NAME;[] et[]ymbol[]nfo\tenrm )\teni
; CAT\tenrm (\teni NAME;[] fd[]s[]ocal[]abel[]ame\tenrm )\teni ; CAT\tenrm (
\teni NAME;[] et[]ineno\tenrm )\teni ; CAT\tenrm (\teni NAME;[] ind[]earest[]i
ne\tenrm )\teni ; CAT\tenrm (\teni NAME;[] fd[]ake[]ebug[]ymbol\tenrm )\teni ;
CAT\tenrm (\teni NAME;[] ead[]inisymbols\tenrm )\teni ; CAT\tenrm (\teni NAM
E;[] inisymbol[]o[]ymbol\tenrm )\teni long\tenrm (\tensy ^^C[]\teni fd[]et[]ymt
ab[]pper[]ound\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\tenrm )); \teni
long\tenrm (\tensy ^^C[]\teni fd[]anonicalize[]ymtab\tenrm )\teni PARAMS\tenrm
((\teni bfd\tensy ^^C\teni ; structsymbol[]ache[]ntry \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm E
.etc.
 
 
Overfull \hbox (1573.21065pt too wide) in paragraph at lines 314--341
\tensy ^^C\tenrm )); \teni structsymbol[]ache[]ntry \tensy ^^C \tenrm (\tensy ^
^C[]\teni fd[]ake[]mpty[]ymbol\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\
tenrm )); \teni void\tenrm (\tensy ^^C[]\teni fd[]rint[]ymbol\tenrm )\teni PARA
MS\tenrm ((\teni bfd\tensy ^^C\teni ; PTR; structsymbol[]ache[]ntry\tensy ^^C\t
eni ; bfd[]rint[]ymbol[]ype\tenrm )); \teni definebfd[]rint[]ymbol\tenrm (\teni
b; p; s; e\tenrm )\teni BFD[]END\tenrm (\teni b;[] fd[]rint[]ymbol; \tenrm (\t
eni b; p; s; e\tenrm ))\teni void\tenrm (\tensy ^^C[]\teni fd[]et[]ymbol[]nfo\t
enrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\teni ; structsymbol[]ache[]ntry\
tensy ^^C\teni ; symbol[]nfo\tensy ^^C\tenrm )); \teni definebfd[]et[]ymbol[]nf
o\tenrm (\teni b; p; e\tenrm )\teni BFD[]END\tenrm (\teni b;[] fd[]et[]ymbol[]n
fo; \tenrm (\teni b; p; e\tenrm ))\teni boolean\tenrm (\tensy ^^C[]\teni fd[]s[
]ocal[]abel[]ame\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\teni ; constch
ar\tensy ^^C\tenrm ));$ |
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\tensy ^^C
.\tenrm )
.\tenrm )
.\tenrm ;
.\glue(\thinmuskip) 1.66663
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.342 alent * (*_
get_lineno) PARAMS ((bfd *, struct symbol_cache_entry ...
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! You can't use `macro parameter character #' in math mode.
l.354 #
define bfd_read_minisymbols(b, d, m, s) \
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! You can't use `macro parameter character #' in math mode.
l.358 #
define bfd_minisymbol_to_symbol(b, d, m, f) \
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.362
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (45.80591pt too wide) in paragraph at lines 342--362
[]\tenrm alent * (*$[]\teni et[]ineno\tenrm )\teni PARAMS\tenrm ((\teni bfd\ten
sy ^^C\teni ; structsymbol[]ache[]ntry\tensy ^^C\tenrm )); \teni boolean\tenrm
(\tensy ^^C[]\teni fd[]ind[]earest[]ine\tenrm )\teni PARAMS\tenrm ((\teni bfd \
tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm a
.\tenrm l
.\tenrm e
.\tenrm n
.etc.
 
 
Overfull \hbox (15.90805pt too wide) in paragraph at lines 342--362
\teni abfd; structsec \tensy ^^C \teni section; structsymbol[]ache[]ntry \tensy
^^C ^^C\teni symbols; bfd[]maoffset; CONSTchar \tensy ^^C ^^C\teni file; CONST
char \tensy ^^C|
 
\hbox(6.94444+1.94444)x469.75499, glue set - 1.0
.\teni a
.\teni b
.\teni f
.\kern1.0764
.\teni d
.etc.
 
 
Overfull \hbox (377.39622pt too wide) in paragraph at lines 342--362
\tensy ^^C\teni func; unsignedint \tensy ^^C \teni line\tenrm )); \teni = \tens
y ^^C \teni Back \tensy ^^@ \teni doortoallowformat \tensy ^^@ \teni awareappli
cationstocreatedebugsymbolswhileusingBFDforeverythingelse:Currentlyusedbytheass
emblerwhencreatingCOFFfiles: \tensy ^^C|
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\tensy ^^C
.\teni f
.\kern1.0764
.\teni u
.\teni n
.etc.
 
 
Overfull \hbox (1045.06613pt too wide) in paragraph at lines 342--362
\teni =asymbol \tensy ^^C \tenrm (\tensy ^^C[]\teni fd[]ake[]ebug[]ymbol\tenrm
)\teni PARAMS\tenrm ((\teni bfd \tensy ^^C \teni abfd; void \tensy ^^C \teni pt
r; unsignedlongsize\tenrm )); \teni definebfd[]ead[]inisymbols\tenrm (\teni b;
d; m; s\tenrm ) \teni BFD[]END\tenrm (\teni b;[] ead[]inisymbols; \tenrm (\teni
b; d; m; s\tenrm ))\teni long\tenrm (\tensy ^^C[]\teni ead[]inisymbols\tenrm )
\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\teni ; boolean; PTR\tensy ^^C\teni ; u
nsignedint\tensy ^^C\tenrm )); \teni definebfd[]inisymbol[]o[]ymbol\tenrm (\ten
i b; d; m; f\tenrm ) \teni BFD[]END\tenrm (\teni b;[] inisymbol[]o[]ymbol; \ten
rm (\teni b; d; m; f\tenrm ))\teni asymbol \tensy ^^C|
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\teni =
.\teni a
.\teni s
.\teni y
.\kern0.35878
.etc.
 
! You can't use `macro parameter character #' in horizontal mode.
l.364 #
define BFD_JUMP_TABLE_RELOCS(NAME)\
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.364 #define BFD_
JUMP_TABLE_RELOCS(NAME)\
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.375
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (844.81805pt too wide) in paragraph at lines 363--375
[]\tenrm /* Rou-tines for re-locs. */ de-fine BFD$[]\teni UMP[]ABLE[]ELOCS\tenr
m (\teni NAME\tenrm ) \teni CAT\tenrm (\teni NAME;[] et[]eloc[]pper[]ound\tenrm
)\teni ; CAT\tenrm (\teni NAME;[] anonicalize[]eloc\tenrm )\teni ; CAT\tenrm
(\teni NAME;[] fd[]eloc[]ype[]ookup\tenrm )\teni long\tenrm (\tensy ^^C[]\teni
et[]eloc[]pper[]ound\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\teni ; se
c[]tr\tenrm )); \teni long\tenrm (\tensy ^^C[]\teni fd[]anonicalize[]eloc\tenrm
)\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\teni ; sec[]tr; arelent \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm R
.etc.
 
 
Overfull \hbox (58.1229pt too wide) in paragraph at lines 363--375
\tensy ^^C\teni ; structsymbol[]ache[]ntry \tensy ^^C ^^C\tenrm )); \teni = \te
nsy ^^C \teni Seedocumentationonreloctypes: \tensy ^^C \teni =reloc[]owto[]ype
\tensy ^^C \tenrm (\tensy ^^C\teni reloc[]ype[]ookup\tenrm )\teni PARAMS\tenrm
((\teni bfd \tensy ^^C|
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\tensy ^^C
.\teni ;
.\glue(\thinmuskip) 1.66663
.\teni s
.\teni t
.etc.
 
! You can't use `macro parameter character #' in horizontal mode.
l.377 #
define BFD_JUMP_TABLE_WRITE(NAME)\
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.377 #define BFD_
JUMP_TABLE_WRITE(NAME)\
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.384
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (984.54932pt too wide) in paragraph at lines 376--384
[]\tenrm /* Rou-tines used when writ-ing an ob-ject file. */ de-fine BFD$[]\ten
i UMP[]ABLE[]RITE\tenrm (\teni NAME\tenrm ) \teni CAT\tenrm (\teni NAME;[] et[]
rch[]ach\tenrm )\teni ; CAT\tenrm (\teni NAME;[] et[]ection[]ontents\tenrm )\t
eni boolean\tenrm (\tensy ^^C[]\teni fd[]et[]rch[]ach\tenrm )\teni PARAMS\tenrm
((\teni bfd\tensy ^^C\teni ; enumbfd[]rchitecture; unsignedlong\tenrm )); \ten
i boolean\tenrm (\tensy ^^C[]\teni fd[]et[]ection[]ontents\tenrm )\teni PARAMS\
tenrm ((\teni bfd\tensy ^^C\teni ; sec[]tr; PTR; file[]tr; bfd[]ize[]ype\tenrm
));$ |
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm R
.etc.
 
! You can't use `macro parameter character #' in horizontal mode.
l.386 #
define BFD_JUMP_TABLE_LINK(NAME)\
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.386 #define BFD_
JUMP_TABLE_LINK(NAME)\
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.400
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (1416.36243pt too wide) in paragraph at lines 385--400
[]\tenrm /* Rou-tines used by the linker. */ de-fine BFD$[]\teni UMP[]ABLE[]INK
\tenrm (\teni NAME\tenrm ) \teni CAT\tenrm (\teni NAME;[] izeof[]eaders\tenrm )
\teni ; CAT\tenrm (\teni NAME;[] fd[]et[]elocated[]ection[]ontents\tenrm )\ten
i ; CAT\tenrm (\teni NAME;[] fd[]elax[]ection\tenrm )\teni ; CAT\tenrm (\teni
NAME;[] fd[]ink[]ash[]able[]reate\tenrm )\teni ; CAT\tenrm (\teni NAME;[] fd[
]ink[]dd[]ymbols\tenrm )\teni ; CAT\tenrm (\teni NAME;[] fd[]inal[]ink\tenrm )
\teni ; CAT\tenrm (\teni NAME;[] fd[]ink[]plit[]ection\tenrm )\teni ; CAT\ten
rm (\teni NAME;[] fd[]c[]ections\tenrm )\teni int\tenrm (\tensy ^^C[]\teni fd[]
izeof[]eaders\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\teni ; boolean\te
nrm )); \teni bfd[]yte \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm R
.etc.
 
 
Overfull \hbox (206.31094pt too wide) in paragraph at lines 385--400
\tenrm (\tensy ^^C[]\teni fd[]et[]elocated[]ection[]ontents\tenrm )\teni PARAMS
\tenrm ((\teni bfd\tensy ^^C\teni ; structbfd[]ink[]nfo\tensy ^^C\teni ; struct
bfd[]ink[]rder\tensy ^^C\teni ; bfd[]yte \tensy ^^C \teni data; booleanrelocate
able; structsymbol[]ache[]ntry \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\tenrm (
.\tensy ^^C
.\hbox(4.8611+0.0)x4.01666, shifted 1.49998
..\seveni b
.\teni f
.\kern1.0764
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.401 boolean (*_
bfd_relax_section) PARAMS ((bfd *, struct sec *,
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.403
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.406 struct bfd_
link_hash_table *(*_bfd_link_hash_table_create) PARAMS ((...
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.407
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.409 boolean (*_
bfd_link_add_symbols) PARAMS ((bfd *, struct bfd_link_inf...
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.410
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (112.4323pt too wide) in paragraph at lines 408--410
[]\tenrm /* Add sym-bols from this ob-ject file into the hash ta-ble. */ boolea
n (*$[]\teni fd[]ink[]dd[]ymbols\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^
C\teni ; structbfd[]ink[]nfo\tensy ^^C\tenrm ));$ |
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm A
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.411 /* Do a link based on the link_
order structures attached to each
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.414
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (183.90022pt too wide) in paragraph at lines 411--414
[]\tenrm /* Do a link based on the link$[]\teni rderstructuresattachedtoeachsec
tionoftheBFD: \tensy ^^C \teni =boolean\tenrm (\tensy ^^C[]\teni fd[]inal[]ink\
tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\teni ; structbfd[]ink[]nfo\tens
y ^^C\tenrm ));$ |
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm D
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.416 boolean (*_
bfd_link_split_section) PARAMS ((bfd *, struct sec *));
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.417
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (121.31348pt too wide) in paragraph at lines 415--417
[]\tenrm /* Should this sec-tion be split up into smaller pieces dur-ing link-i
ng. */ boolean (*$[]\teni fd[]ink[]plit[]ection\tenrm )\teni PARAMS\tenrm ((\te
ni bfd\tensy ^^C\teni ; structsec\tensy ^^C\tenrm ));$ |
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm S
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.419 boolean (*_
bfd_gc_sections) PARAMS ((bfd *, struct bfd_link_info *));
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.420
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (106.85928pt too wide) in paragraph at lines 418--420
[]\tenrm /* Re-move sec-tions that are not ref-er-enced from the out-put. */ bo
olean (*$[]\teni fd[]c[]ections\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C
\teni ; structbfd[]ink[]nfo\tensy ^^C\tenrm ));$ |
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm R
.etc.
 
! You can't use `macro parameter character #' in horizontal mode.
l.422 #
define BFD_JUMP_TABLE_DYNAMIC(NAME)\
Sorry, but I'm not programmed to handle this case;
I'll just pretend that you didn't ask for it.
If you're in the wrong mode, you might be able to
return to the right one by typing `I}' or `I$' or `I\par'.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.422 #define BFD_
JUMP_TABLE_DYNAMIC(NAME)\
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.437
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (806.16087pt too wide) in paragraph at lines 421--437
[]\tenrm /* Rou-tines to han-dle dy-namic sym-bols and re-locs. */ de-fine BFD$
[]\teni UMP[]ABLE[]YNAMIC\tenrm (\teni NAME\tenrm ) \teni CAT\tenrm (\teni NAME
;[] et[]ynamic[]ymtab[]pper[]ound\tenrm )\teni ; CAT\tenrm (\teni NAME;[] anon
icalize[]ynamic[]ymtab\tenrm )\teni ; CAT\tenrm (\teni NAME;[] et[]ynamic[]elo
c[]pper[]ound\tenrm )\teni ; CAT\tenrm (\teni NAME;[] anonicalize[]ynamic[]elo
c\tenrm )\teni = \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm /
.\tenrm *
.\glue 3.33333 plus 1.66666 minus 1.11111
.\tenrm R
.etc.
 
 
Overfull \hbox (87.0036pt too wide) in paragraph at lines 421--437
\teni Gettheamountofmemoryrequiredtoholdthedynamicsymbols: \tensy ^^C \teni =lo
ng\tenrm (\tensy ^^C[]\teni fd[]et[]ynamic[]ymtab[]pper[]ound\tenrm )\teni PARA
MS\tenrm ((\teni bfd\tensy ^^C\tenrm )); \teni = \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\teni G
.\teni e
.\teni t
.\teni t
.\teni h
.etc.
 
 
Overfull \hbox (26.73997pt too wide) in paragraph at lines 421--437
\teni Readinthedynamicsymbols: \tensy ^^C \teni =long\tenrm (\tensy ^^C[]\teni
fd[]anonicalize[]ynamic[]ymtab\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\
teni ; structsymbol[]ache[]ntry \tensy ^^C|
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\teni R
.\kern0.07726
.\teni e
.\teni a
.\teni d
.etc.
 
 
Overfull \hbox (94.91333pt too wide) in paragraph at lines 421--437
\tensy ^^C\tenrm )); \teni = \tensy ^^C \teni Gettheamountofmemoryrequiredtohol
dthedynamicrelocs: \tensy ^^C \teni =long\tenrm (\tensy ^^C[]\teni fd[]et[]ynam
ic[]eloc[]pper[]ound\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\tenrm ));
\teni = \tensy ^^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\tensy ^^C
.\tenrm )
.\tenrm )
.\tenrm ;
.\glue(\thinmuskip) 1.66663
.etc.
 
 
Overfull \hbox (54.05371pt too wide) in paragraph at lines 421--437
\teni Readinthedynamicrelocs: \tensy ^^C \teni =long\tenrm (\tensy ^^C[]\teni f
d[]anonicalize[]ynamic[]eloc\tenrm )\teni PARAMS\tenrm ((\teni bfd\tensy ^^C\te
ni ; arelent \tensy ^^C ^^C\teni ; structsymbol[]ache[]ntry \tensy ^^C|
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\teni R
.\kern0.07726
.\teni e
.\teni a
.\teni d
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.439 A pointer to an alternative bfd_
target in case the current one is not
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.447
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (993.69698pt too wide) in paragraph at lines 438--447
[]\tenrm @end ex-am-ple A pointer to an al-ter-na-tive bfd$[]\teni argetincaset
hecurrentoneisnotsatisfactory:Thiscanhappenwhenthetargetcpusupportsbothbigandli
ttleendiancode; andtargetchosenbythelinkerhasthewrongendianness:Thefunctionopen
[]utput\tenrm ()\teni inld=ldlang:cusesthisfieldtofindanalternativeoutputformat
thatissuitable:\tenrm @\teni example= \tensy ^^C|
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm @
.\tenrm e
.\tenrm n
.\tenrm d
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.452 PTR backend_
data;
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.453
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.454 @} bfd_
target;
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.456
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.457 @findex bfd_
set_default_target
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.467
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (153.4344pt too wide) in paragraph at lines 457--467
[]\tenrm @findex bfd$[]\teni et[]efault[]arget\tenrm @\teni subsubsection\tenrm
@\teni code[]\tenrm @\teni strong[]\tenrm @\teni examplebooleanbfd[]et[]efault
[]arget\tenrm (\teni constchar \tensy ^^C|
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm @
.\tenrm ^^L (ligature fi)
.\tenrm n
.\tenrm d
.etc.
 
 
Overfull \hbox (363.22246pt too wide) in paragraph at lines 457--467
\teni name\tenrm ); @\teni endexample\tenrm @\teni strong[]\tenrm @ \tensy ^^C
\teni SetthedefaulttargetvectortousewhenrecognizingaBFD:Thistakesthenameoftheta
rget; whichmaybeaBFDtargetnameoraconfigurationtriplet:$ |
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\teni n
.\teni a
.\teni m
.\teni e
.\tenrm )
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.468 @findex bfd_
find_target
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.484
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (2201.83133pt too wide) in paragraph at lines 468--484
\teni bfd[]ind[]arget\tenrm (\teni CONSTchar \tensy ^^C \teni target[]ame; bfd
\tensy ^^C \teni abfd\tenrm ); @\teni endexample\tenrm @\teni strong[]\tenrm @
\tensy ^^C \teni Returnapointertothetransfervectorfortheobjecttargetnamed\tenrm
@\teni var[]:If\tenrm @\teni var[]is\tenrm @\teni code[]; choosetheoneintheenv
ironmentvariable\tenrm @\teni code[]\tenrm ; \teni ifthatisnullornotdefined; th
enchoosethefirstentryinthetargetlist:Passinginthestring\tenrm "\teni default\te
nrm "\teni orsettingtheenvironmentvariableto\tenrm "\teni default\tenrm "\teni
willcausethefirstentryinthetargetlisttobereturned; and\tenrm "\teni target[]efa
ulted\tenrm "\teni willbesetintheBFD:Thiscauses\tenrm @\teni code[]toloopoveral
lthetargetstofindtheonethatmatchesthefilebeingread:$ |
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\teni b
.\teni f
.\kern1.0764
.\teni d
.\hbox(4.8611+1.3611)x5.18408, shifted 1.49998
..\seveni f
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.485 @findex bfd_
target_list
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.495
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (223.86203pt too wide) in paragraph at lines 485--495
[]\tenrm @findex bfd$[]\teni arget[]ist\tenrm @\teni subsubsection\tenrm @\teni
code[]\tenrm @\teni strong[]\tenrm @\teni exampleconstchar \tensy ^^C ^^C\teni
bfd[]arget[]ist\tenrm (\teni void\tenrm ); @\teni endexample\tenrm @\teni stro
ng[]\tenrm @ \tensy ^^C|
 
\hbox(7.5+2.5)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm @
.\tenrm ^^L (ligature fi)
.\tenrm n
.\tenrm d
.etc.
 
 
Overfull \hbox (37.35316pt too wide) in paragraph at lines 485--495
\teni ReturnafreshlymallocedNULL \tensy ^^@ \teni terminatedvectorofthenamesofa
llthevalidBFDtargets:Donotmodifythenames:$ |
 
\hbox(6.94444+1.94444)x469.75499, glue set - 1.0
.\teni R
.\kern0.07726
.\teni e
.\teni t
.\teni u
.etc.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
_
l.496 @findex bfd_
seach_for_target
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
! Missing $ inserted.
<inserted text>
$
<to be read again>
\par
l.508
I've inserted a begin-math/end-math symbol since I think
you left one out. Proceed, with fingers crossed.
 
 
Overfull \hbox (37.06117pt too wide) in paragraph at lines 496--508
[]\tenrm @findex bfd$[]\teni each[]or[]arget\tenrm @\teni subsubsection\tenrm @
\teni code[]\tenrm @\teni strong[]\tenrm @\teni exampleconstbfd[]arget \tensy ^
^C|
 
\hbox(6.94444+2.86108)x469.75499, glue set - 1.0
.\hbox(0.0+0.0)x20.0
.\tenrm @
.\tenrm ^^L (ligature fi)
.\tenrm n
.\tenrm d
.etc.
 
 
Overfull \hbox (4.127pt too wide) in paragraph at lines 496--508
\teni bfd[]earch[]or[]arget\tenrm (\teni int\tenrm (\tensy ^^C\teni search[]unc
\tenrm )(\teni constbfd[]arget\tensy ^^C\teni ; void\tensy ^^C\tenrm )\teni ; v
oid\tensy ^^C\tenrm ); @\teni endexample\tenrm @\teni strong[]\tenrm @ \tensy ^
^C|
 
\hbox(7.5+2.86108)x469.75499, glue set - 1.0
.\teni b
.\teni f
.\kern1.0764
.\teni d
.\hbox(3.01389+0.0)x4.27432, shifted 1.49998
..\seveni s
.etc.
 
 
Overfull \hbox (6.92068pt too wide) in paragraph at lines 496--508
\teni Returnapointertothefirsttransfervectorinthelistoftransfervectorsmaintaine
dbyBFDthatproducesanon \tensy ^^@|
 
\hbox(6.94444+1.94444)x469.75499, glue set - 1.0
.\teni R
.\kern0.07726
.\teni e
.\teni t
.\teni u
.etc.
 
 
Overfull \hbox (72.41927pt too wide) in paragraph at lines 496--508
\teni zeroresultwhenpassedtothefunction\tenrm @\teni var[]:Theparameter\tenrm @
\teni var[]ispassed; unexamined; tothesearchfunction:$ |
 
\hbox(6.94444+2.86108)x469.75499
.\teni z
.\kern0.4398
.\teni e
.\teni r
.\kern0.27779
.etc.
 
)
! Emergency stop.
<*> /home/markom/gdb/gdb-5.0/bfd/doc/targets.texi
*** (job aborted, no legal \end found)
 
! ==> Fatal error occurred, the output PDF file not finished!
/core.texi
0,0 → 1,38
@section Core files
 
 
@strong{Description}@*
These are functions pertaining to core files.
 
@findex bfd_core_file_failing_command
@subsubsection @code{bfd_core_file_failing_command}
@strong{Synopsis}
@example
CONST char *bfd_core_file_failing_command(bfd *abfd);
@end example
@strong{Description}@*
Return a read-only string explaining which program was running
when it failed and produced the core file @var{abfd}.
 
@findex bfd_core_file_failing_signal
@subsubsection @code{bfd_core_file_failing_signal}
@strong{Synopsis}
@example
int bfd_core_file_failing_signal(bfd *abfd);
@end example
@strong{Description}@*
Returns the signal number which caused the core dump which
generated the file the BFD @var{abfd} is attached to.
 
@findex core_file_matches_executable_p
@subsubsection @code{core_file_matches_executable_p}
@strong{Synopsis}
@example
boolean core_file_matches_executable_p
(bfd *core_bfd, bfd *exec_bfd);
@end example
@strong{Description}@*
Return @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}, @code{false} otherwise.
 
/bfdsumm.texi
0,0 → 1,148
@c This summary of BFD is shared by the BFD and LD docs.
When an object file is opened, BFD subroutines automatically determine
the format of the input object file. They then build a descriptor in
memory with pointers to routines that will be used to access elements of
the object file's data structures.
 
As different information from the the object files is required,
BFD reads from different sections of the file and processes them.
For example, a very common operation for the linker is processing symbol
tables. Each BFD back end provides a routine for converting
between the object file's representation of symbols and an internal
canonical format. When the linker asks for the symbol table of an object
file, it calls through a memory pointer to the routine from the
relevant BFD back end which reads and converts the table into a canonical
form. The linker then operates upon the canonical form. When the link is
finished and the linker writes the output file's symbol table,
another BFD back end routine is called to take the newly
created symbol table and convert it into the chosen output format.
 
@menu
* BFD information loss:: Information Loss
* Canonical format:: The BFD canonical object-file format
@end menu
 
@node BFD information loss
@subsection Information Loss
 
@emph{Information can be lost during output.} The output formats
supported by BFD do not provide identical facilities, and
information which can be described in one form has nowhere to go in
another format. One example of this is alignment information in
@code{b.out}. There is nowhere in an @code{a.out} format file to store
alignment information on the contained data, so when a file is linked
from @code{b.out} and an @code{a.out} image is produced, alignment
information will not propagate to the output file. (The linker will
still use the alignment information internally, so the link is performed
correctly).
 
Another example is COFF section names. COFF files may contain an
unlimited number of sections, each one with a textual section name. If
the target of the link is a format which does not have many sections (e.g.,
@code{a.out}) or has sections without names (e.g., the Oasys format), the
link cannot be done simply. You can circumvent this problem by
describing the desired input-to-output section mapping with the linker command
language.
 
@emph{Information can be lost during canonicalization.} The BFD
internal canonical form of the external formats is not exhaustive; there
are structures in input formats for which there is no direct
representation internally. This means that the BFD back ends
cannot maintain all possible data richness through the transformation
between external to internal and back to external formats.
 
This limitation is only a problem when an application reads one
format and writes another. Each BFD back end is responsible for
maintaining as much data as possible, and the internal BFD
canonical form has structures which are opaque to the BFD core,
and exported only to the back ends. When a file is read in one format,
the canonical form is generated for BFD and the application. At the
same time, the back end saves away any information which may otherwise
be lost. If the data is then written back in the same format, the back
end routine will be able to use the canonical form provided by the
BFD core as well as the information it prepared earlier. Since
there is a great deal of commonality between back ends,
there is no information lost when
linking or copying big endian COFF to little endian COFF, or @code{a.out} to
@code{b.out}. When a mixture of formats is linked, the information is
only lost from the files whose format differs from the destination.
 
@node Canonical format
@subsection The BFD canonical object-file format
 
The greatest potential for loss of information occurs when there is the least
overlap between the information provided by the source format, that
stored by the canonical format, and that needed by the
destination format. A brief description of the canonical form may help
you understand which kinds of data you can count on preserving across
conversions.
@cindex BFD canonical format
@cindex internal object-file format
 
@table @emph
@item files
Information stored on a per-file basis includes target machine
architecture, particular implementation format type, a demand pageable
bit, and a write protected bit. Information like Unix magic numbers is
not stored here---only the magic numbers' meaning, so a @code{ZMAGIC}
file would have both the demand pageable bit and the write protected
text bit set. The byte order of the target is stored on a per-file
basis, so that big- and little-endian object files may be used with one
another.
 
@item sections
Each section in the input file contains the name of the section, the
section's original address in the object file, size and alignment
information, various flags, and pointers into other BFD data
structures.
 
@item symbols
Each symbol contains a pointer to the information for the object file
which originally defined it, its name, its value, and various flag
bits. When a BFD back end reads in a symbol table, it relocates all
symbols to make them relative to the base of the section where they were
defined. Doing this ensures that each symbol points to its containing
section. Each symbol also has a varying amount of hidden private data
for the BFD back end. Since the symbol points to the original file, the
private data format for that symbol is accessible. @code{ld} can
operate on a collection of symbols of wildly different formats without
problems.
 
Normal global and simple local symbols are maintained on output, so an
output file (no matter its format) will retain symbols pointing to
functions and to global, static, and common variables. Some symbol
information is not worth retaining; in @code{a.out}, type information is
stored in the symbol table as long symbol names. This information would
be useless to most COFF debuggers; the linker has command line switches
to allow users to throw it away.
 
There is one word of type information within the symbol, so if the
format supports symbol type information within symbols (for example, COFF,
IEEE, Oasys) and the type is simple enough to fit within one word
(nearly everything but aggregates), the information will be preserved.
 
@item relocation level
Each canonical BFD relocation record contains a pointer to the symbol to
relocate to, the offset of the data to relocate, the section the data
is in, and a pointer to a relocation type descriptor. Relocation is
performed by passing messages through the relocation type
descriptor and the symbol pointer. Therefore, relocations can be performed
on output data using a relocation method that is only available in one of the
input formats. For instance, Oasys provides a byte relocation format.
A relocation record requesting this relocation type would point
indirectly to a routine to perform this, so the relocation may be
performed on a byte being written to a 68k COFF file, even though 68k COFF
has no such relocation type.
 
@item line numbers
Object formats can contain, for debugging purposes, some form of mapping
between symbols, source line numbers, and addresses in the output file.
These addresses have to be relocated along with the symbol information.
Each symbol with an associated list of line number records points to the
first record of the list. The head of a line number list consists of a
pointer to the symbol, which allows finding out the address of the
function whose line number is being described. The rest of the list is
made up of pairs: offsets into the section and line numbers. Any format
which can simply derive this information can pass it successfully
between formats (COFF, IEEE and Oasys).
@end table
/bfd.texinfo
0,0 → 1,348
\input texinfo.tex
@setfilename bfd.info
@c $Id: bfd.texinfo,v 1.1.1.1 2001-05-18 11:00:55 markom Exp $
@tex
% NOTE LOCAL KLUGE TO AVOID TOO MUCH WHITESPACE
\global\long\def\example{%
\begingroup
\let\aboveenvbreak=\par
\let\afterenvbreak=\par
\parskip=0pt
\lisp}
\global\long\def\Eexample{%
\Elisp
\endgroup
\vskip -\parskip% to cancel out effect of following \par
}
@end tex
@synindex fn cp
 
@ifinfo
@format
START-INFO-DIR-ENTRY
* Bfd: (bfd). The Binary File Descriptor library.
END-INFO-DIR-ENTRY
@end format
@end ifinfo
 
@ifinfo
This file documents the BFD library.
 
Copyright (C) 1991 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.
 
@ignore
Permission is granted to process this file through Tex and print the
results, provided the printed document carries copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).
 
@end ignore
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, subject to the terms
of the GNU General Public License, which includes the provision 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.
@end ifinfo
@iftex
@c@finalout
@setchapternewpage on
@c@setchapternewpage odd
@settitle LIB BFD, the Binary File Descriptor Library
@titlepage
@title{libbfd}
@subtitle{The Binary File Descriptor Library}
@sp 1
@subtitle First Edition---BFD version < 3.0
@subtitle April 1991
@author {Steve Chamberlain}
@author {Cygnus Support}
@page
 
@tex
\def\$#1${{#1}} % Kluge: collect RCS revision info without $...$
\xdef\manvers{\$Revision: 1.1.1.1 $} % For use in headers, footers too
{\parskip=0pt
\hfill Cygnus Support\par
\hfill sac\@cygnus.com\par
\hfill {\it BFD}, \manvers\par
\hfill \TeX{}info \texinfoversion\par
}
\global\parindent=0pt % Steve likes it this way
@end tex
 
@vskip 0pt plus 1filll
Copyright @copyright{} 1991 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, subject to the terms
of the GNU General Public License, which includes the provision 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.
@end titlepage
@end iftex
 
@node Top, Overview, (dir), (dir)
@ifinfo
This file documents the binary file descriptor library libbfd.
@end ifinfo
 
@menu
* Overview:: Overview of BFD
* BFD front end:: BFD front end
* BFD back ends:: BFD back ends
* Index:: Index
@end menu
 
@node Overview, BFD front end, Top, Top
@chapter Introduction
@cindex BFD
@cindex what is it?
BFD is a package which allows applications to use the
same routines to operate on object files whatever the object file
format. A new object file format can be supported simply by
creating a new BFD back end and adding it to the library.
 
BFD is split into two parts: the front end, and the back ends (one for
each object file format).
@itemize @bullet
@item The front end of BFD provides the interface to the user. It manages
memory and various canonical data structures. The front end also
decides which back end to use and when to call back end routines.
@item The back ends provide BFD its view of the real world. Each back
end provides a set of calls which the BFD front end can use to maintain
its canonical form. The back ends also may keep around information for
their own use, for greater efficiency.
@end itemize
@menu
* History:: History
* How It Works:: How It Works
* What BFD Version 2 Can Do:: What BFD Version 2 Can Do
@end menu
 
@node History, How It Works, Overview, Overview
@section History
 
One spur behind BFD was the desire, on the part of the GNU 960 team at
Intel Oregon, for interoperability of applications on their COFF and
b.out file formats. Cygnus was providing GNU support for the team, and
was contracted to provide the required functionality.
 
The name came from a conversation David Wallace was having with Richard
Stallman about the library: RMS said that it would be quite hard---David
said ``BFD''. Stallman was right, but the name stuck.
 
At the same time, Ready Systems wanted much the same thing, but for
different object file formats: IEEE-695, Oasys, Srecords, a.out and 68k
coff.
 
BFD was first implemented by members of Cygnus Support; Steve
Chamberlain (@code{sac@@cygnus.com}), John Gilmore
(@code{gnu@@cygnus.com}), K. Richard Pixley (@code{rich@@cygnus.com})
and David Henkel-Wallace (@code{gumby@@cygnus.com}).
 
 
 
@node How It Works, What BFD Version 2 Can Do, History, Overview
@section How To Use BFD
 
To use the library, include @file{bfd.h} and link with @file{libbfd.a}.
 
BFD provides a common interface to the parts of an object file
for a calling application.
 
When an application sucessfully opens a target file (object, archive, or
whatever), a pointer to an internal structure is returned. This pointer
points to a structure called @code{bfd}, described in
@file{bfd.h}. Our convention is to call this pointer a BFD, and
instances of it within code @code{abfd}. All operations on
the target object file are applied as methods to the BFD. The mapping is
defined within @code{bfd.h} in a set of macros, all beginning
with @samp{bfd_} to reduce namespace pollution.
 
For example, this sequence does what you would probably expect:
return the number of sections in an object file attached to a BFD
@code{abfd}.
 
@lisp
@c @cartouche
#include "bfd.h"
 
unsigned int number_of_sections(abfd)
bfd *abfd;
@{
return bfd_count_sections(abfd);
@}
@c @end cartouche
@end lisp
 
The abstraction used within BFD is that an object file has:
 
@itemize @bullet
@item
a header,
@item
a number of sections containing raw data (@pxref{Sections}),
@item
a set of relocations (@pxref{Relocations}), and
@item
some symbol information (@pxref{Symbols}).
@end itemize
@noindent
Also, BFDs opened for archives have the additional attribute of an index
and contain subordinate BFDs. This approach is fine for a.out and coff,
but loses efficiency when applied to formats such as S-records and
IEEE-695.
 
@node What BFD Version 2 Can Do, , How It Works, Overview
@section What BFD Version 2 Can Do
@include bfdsumm.texi
 
@node BFD front end, BFD back ends, Overview, Top
@chapter BFD front end
@include bfdt.texi
 
@menu
* Memory Usage::
* Initialization::
* Sections::
* Symbols::
* Archives::
* Formats::
* Relocations::
* Core Files::
* Targets::
* Architectures::
* Opening and Closing::
* Internal::
* File Caching::
* Linker Functions::
* Hash Tables::
@end menu
 
@node Memory Usage, Initialization, BFD front end, BFD front end
@section Memory usage
BFD keeps all of its internal structures in obstacks. There is one obstack
per open BFD file, into which the current state is stored. When a BFD is
closed, the obstack is deleted, and so everything which has been
allocated by BFD for the closing file is thrown away.
 
BFD does not free anything created by an application, but pointers into
@code{bfd} structures become invalid on a @code{bfd_close}; for example,
after a @code{bfd_close} the vector passed to
@code{bfd_canonicalize_symtab} is still around, since it has been
allocated by the application, but the data that it pointed to are
lost.
 
The general rule is to not close a BFD until all operations dependent
upon data from the BFD have been completed, or all the data from within
the file has been copied. To help with the management of memory, there
is a function (@code{bfd_alloc_size}) which returns the number of bytes
in obstacks associated with the supplied BFD. This could be used to
select the greediest open BFD, close it to reclaim the memory, perform
some operation and reopen the BFD again, to get a fresh copy of the data
structures.
 
@node Initialization, Sections, Memory Usage, BFD front end
@include init.texi
 
@node Sections, Symbols, Initialization, BFD front end
@include section.texi
 
@node Symbols, Archives, Sections, BFD front end
@include syms.texi
 
@node Archives, Formats, Symbols, BFD front end
@include archive.texi
 
@node Formats, Relocations, Archives, BFD front end
@include format.texi
 
@node Relocations, Core Files, Formats, BFD front end
@include reloc.texi
 
@node Core Files, Targets, Relocations, BFD front end
@include core.texi
 
@node Targets, Architectures, Core Files, BFD front end
@include targets.texi
 
@node Architectures, Opening and Closing, Targets, BFD front end
@include archures.texi
 
@node Opening and Closing, Internal, Architectures, BFD front end
@include opncls.texi
 
@node Internal, File Caching, Opening and Closing, BFD front end
@include libbfd.texi
 
@node File Caching, Linker Functions, Internal, BFD front end
@include cache.texi
 
@node Linker Functions, Hash Tables, File Caching, BFD front end
@include linker.texi
 
@node Hash Tables, , Linker Functions, BFD front end
@include hash.texi
 
@node BFD back ends, Index, BFD front end, Top
@chapter BFD back ends
@menu
* What to Put Where::
* aout :: a.out backends
* coff :: coff backends
* elf :: elf backends
@ignore
* oasys :: oasys backends
* ieee :: ieee backend
* srecord :: s-record backend
@end ignore
@end menu
@node What to Put Where, aout, BFD back ends, BFD back ends
All of BFD lives in one directory.
 
@node aout, coff, What to Put Where, BFD back ends
@include aoutx.texi
 
@node coff, elf, aout, BFD back ends
@include coffcode.texi
 
@node elf, , coff, BFD back ends
@include elf.texi
@c Leave this out until the file has some actual contents...
@c @include elfcode.texi
 
@node Index, , BFD back ends , Top
@unnumbered Index
@printindex cp
 
@tex
% I think something like @colophon should be in texinfo. In the
% meantime:
\long\def\colophon{\hbox to0pt{}\vfill
\centerline{The body of this manual is set in}
\centerline{\fontname\tenrm,}
\centerline{with headings in {\bf\fontname\tenbf}}
\centerline{and examples in {\tt\fontname\tentt}.}
\centerline{{\it\fontname\tenit\/} and}
\centerline{{\sl\fontname\tensl\/}}
\centerline{are used for emphasis.}\vfill}
\page\colophon
% Blame: doc@cygnus.com, 28mar91.
@end tex
 
@contents
@bye
/aoutx.texi
0,0 → 1,211
@section a.out backends
 
 
@strong{Description}@*
BFD supports a number of different flavours of a.out format,
though the major differences are only the sizes of the
structures on disk, and the shape of the relocation
information.
 
The support is split into a basic support file @file{aoutx.h}
and other files which derive functions from the base. One
derivation file is @file{aoutf1.h} (for a.out flavour 1), and
adds to the basic a.out functions support for sun3, sun4, 386
and 29k a.out files, to create a target jump vector for a
specific target.
 
This information is further split out into more specific files
for each machine, including @file{sunos.c} for sun3 and sun4,
@file{newsos3.c} for the Sony NEWS, and @file{demo64.c} for a
demonstration of a 64 bit a.out format.
 
The base file @file{aoutx.h} defines general mechanisms for
reading and writing records to and from disk and various
other methods which BFD requires. It is included by
@file{aout32.c} and @file{aout64.c} to form the names
@code{aout_32_swap_exec_header_in}, @code{aout_64_swap_exec_header_in}, etc.
 
As an example, this is what goes on to make the back end for a
sun4, from @file{aout32.c}:
 
@example
#define ARCH_SIZE 32
#include "aoutx.h"
@end example
 
Which exports names:
 
@example
...
aout_32_canonicalize_reloc
aout_32_find_nearest_line
aout_32_get_lineno
aout_32_get_reloc_upper_bound
...
@end example
 
from @file{sunos.c}:
 
@example
#define TARGET_NAME "a.out-sunos-big"
#define VECNAME sunos_big_vec
#include "aoutf1.h"
@end example
 
requires all the names from @file{aout32.c}, and produces the jump vector
 
@example
sunos_big_vec
@end example
 
The file @file{host-aout.c} is a special case. It is for a large set
of hosts that use ``more or less standard'' a.out files, and
for which cross-debugging is not interesting. It uses the
standard 32-bit a.out support routines, but determines the
file offsets and addresses of the text, data, and BSS
sections, the machine architecture and machine type, and the
entry point address, in a host-dependent manner. Once these
values have been determined, generic code is used to handle
the object file.
 
When porting it to run on a new system, you must supply:
 
@example
HOST_PAGE_SIZE
HOST_SEGMENT_SIZE
HOST_MACHINE_ARCH (optional)
HOST_MACHINE_MACHINE (optional)
HOST_TEXT_START_ADDR
HOST_STACK_END_ADDR
@end example
 
in the file @file{../include/sys/h-@var{XXX}.h} (for your host). These
values, plus the structures and macros defined in @file{a.out.h} on
your host system, will produce a BFD target that will access
ordinary a.out files on your host. To configure a new machine
to use @file{host-aout.c}, specify:
 
@example
TDEFAULTS = -DDEFAULT_VECTOR=host_aout_big_vec
TDEPFILES= host-aout.o trad-core.o
@end example
 
in the @file{config/@var{XXX}.mt} file, and modify @file{configure.in}
to use the
@file{@var{XXX}.mt} file (by setting "@code{bfd_target=XXX}") when your
configuration is selected.
 
@subsection Relocations
 
 
@strong{Description}@*
The file @file{aoutx.h} provides for both the @emph{standard}
and @emph{extended} forms of a.out relocation records.
 
The standard records contain only an
address, a symbol index, and a type field. The extended records
(used on 29ks and sparcs) also have a full integer for an
addend.
 
@subsection Internal entry points
 
 
@strong{Description}@*
@file{aoutx.h} exports several routines for accessing the
contents of an a.out file, which are gathered and exported in
turn by various format specific files (eg sunos.c).
 
@findex aout_@var{size}_swap_exec_header_in
@subsubsection @code{aout_@var{size}_swap_exec_header_in}
@strong{Synopsis}
@example
void aout_@var{size}_swap_exec_header_in,
(bfd *abfd,
struct external_exec *raw_bytes,
struct internal_exec *execp);
@end example
@strong{Description}@*
Swap the information in an executable header @var{raw_bytes} taken
from a raw byte stream memory image into the internal exec header
structure @var{execp}.
 
@findex aout_@var{size}_swap_exec_header_out
@subsubsection @code{aout_@var{size}_swap_exec_header_out}
@strong{Synopsis}
@example
void aout_@var{size}_swap_exec_header_out
(bfd *abfd,
struct internal_exec *execp,
struct external_exec *raw_bytes);
@end example
@strong{Description}@*
Swap the information in an internal exec header structure
@var{execp} into the buffer @var{raw_bytes} ready for writing to disk.
 
@findex aout_@var{size}_some_aout_object_p
@subsubsection @code{aout_@var{size}_some_aout_object_p}
@strong{Synopsis}
@example
const bfd_target *aout_@var{size}_some_aout_object_p
(bfd *abfd,
const bfd_target *(*callback_to_real_object_p)());
@end example
@strong{Description}@*
Some a.out variant thinks that the file open in @var{abfd}
checking is an a.out file. Do some more checking, and set up
for access if it really is. Call back to the calling
environment's "finish up" function just before returning, to
handle any last-minute setup.
 
@findex aout_@var{size}_mkobject
@subsubsection @code{aout_@var{size}_mkobject}
@strong{Synopsis}
@example
boolean aout_@var{size}_mkobject, (bfd *abfd);
@end example
@strong{Description}@*
Initialize BFD @var{abfd} for use with a.out files.
 
@findex aout_@var{size}_machine_type
@subsubsection @code{aout_@var{size}_machine_type}
@strong{Synopsis}
@example
enum machine_type aout_@var{size}_machine_type
(enum bfd_architecture arch,
unsigned long machine));
@end example
@strong{Description}@*
Keep track of machine architecture and machine type for
a.out's. Return the @code{machine_type} for a particular
architecture and machine, or @code{M_UNKNOWN} if that exact architecture
and machine can't be represented in a.out format.
 
If the architecture is understood, machine type 0 (default)
is always understood.
 
@findex aout_@var{size}_set_arch_mach
@subsubsection @code{aout_@var{size}_set_arch_mach}
@strong{Synopsis}
@example
boolean aout_@var{size}_set_arch_mach,
(bfd *,
enum bfd_architecture arch,
unsigned long machine));
@end example
@strong{Description}@*
Set the architecture and the machine of the BFD @var{abfd} to the
values @var{arch} and @var{machine}. Verify that @var{abfd}'s format
can support the architecture required.
 
@findex aout_@var{size}_new_section_hook
@subsubsection @code{aout_@var{size}_new_section_hook}
@strong{Synopsis}
@example
boolean aout_@var{size}_new_section_hook,
(bfd *abfd,
asection *newsect));
@end example
@strong{Description}@*
Called by the BFD in response to a @code{bfd_make_section}
request.
 
/elfcode.texi --- init.texi (nonexistent) +++ init.texi (revision 1765) @@ -0,0 +1,13 @@ +@section Initialization +These are the functions that handle initializing a BFD. + +@findex bfd_init +@subsubsection @code{bfd_init} +@strong{Synopsis} +@example +void bfd_init(void); +@end example +@strong{Description}@* +This routine must be called before any other BFD function to +initialize magical internal data structures. +
/reloc.texi
0,0 → 1,1302
@section Relocations
BFD maintains relocations in much the same way it maintains
symbols: they are left alone until required, then read in
en-mass and translated into an internal form. A common
routine @code{bfd_perform_relocation} acts upon the
canonical form to do the fixup.
 
Relocations are maintained on a per section basis,
while symbols are maintained on a per BFD basis.
 
All that a back end has to do to fit the BFD interface is to create
a @code{struct reloc_cache_entry} for each relocation
in a particular section, and fill in the right bits of the structures.
 
@menu
* typedef arelent::
* howto manager::
@end menu
 
 
@node typedef arelent, howto manager, Relocations, Relocations
@subsection typedef arelent
This is the structure of a relocation entry:
 
 
@example
 
typedef enum bfd_reloc_status
@{
/* No errors detected */
bfd_reloc_ok,
 
/* The relocation was performed, but there was an overflow. */
bfd_reloc_overflow,
 
/* The address to relocate was not within the section supplied. */
bfd_reloc_outofrange,
 
/* Used by special functions */
bfd_reloc_continue,
 
/* Unsupported relocation size requested. */
bfd_reloc_notsupported,
 
/* Unused */
bfd_reloc_other,
 
/* The symbol to relocate against was undefined. */
bfd_reloc_undefined,
 
/* The relocation was performed, but may not be ok - presently
generated only when linking i960 coff files with i960 b.out
symbols. If this type is returned, the error_message argument
to bfd_perform_relocation will be set. */
bfd_reloc_dangerous
@}
bfd_reloc_status_type;
 
 
typedef struct reloc_cache_entry
@{
/* A pointer into the canonical table of pointers */
struct symbol_cache_entry **sym_ptr_ptr;
 
/* offset in section */
bfd_size_type address;
 
/* addend for relocation value */
bfd_vma addend;
 
/* Pointer to how to perform the required relocation */
reloc_howto_type *howto;
 
@} arelent;
@end example
@strong{Description}@*
Here is a description of each of the fields within an @code{arelent}:
 
@itemize @bullet
 
@item
@code{sym_ptr_ptr}
@end itemize
The symbol table pointer points to a pointer to the symbol
associated with the relocation request. It is
the pointer into the table returned by the back end's
@code{get_symtab} action. @xref{Symbols}. The symbol is referenced
through a pointer to a pointer so that tools like the linker
can fix up 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 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.
 
@itemize @bullet
 
@item
@code{address}
@end itemize
The @code{address} field gives the offset in bytes from the base of
the section data which owns the relocation record to the first
byte of relocatable information. The actual data relocated
will be relative to this point; for example, a relocation
type which modifies the bottom two bytes of a four byte word
would not touch the first byte pointed to in a big endian
world.
 
@itemize @bullet
 
@item
@code{addend}
@end itemize
The @code{addend} is a value provided by the back end to be added (!)
to the relocation offset. Its interpretation is dependent upon
the howto. For example, on the 68k the code:
 
@example
char foo[];
main()
@{
return foo[0x12345678];
@}
@end example
 
Could be compiled into:
 
@example
linkw fp,#-4
moveb @@#12345678,d0
extbl d0
unlk fp
rts
@end example
 
This could create a reloc pointing to @code{foo}, but leave the
offset in the data, something like:
 
@example
RELOCATION RECORDS FOR [.text]:
offset type value
00000006 32 _foo
 
00000000 4e56 fffc ; linkw fp,#-4
00000004 1039 1234 5678 ; moveb @@#12345678,d0
0000000a 49c0 ; extbl d0
0000000c 4e5e ; unlk fp
0000000e 4e75 ; rts
@end example
 
Using coff and an 88k, some instructions don't have enough
space in them to represent the full address range, and
pointers have to be loaded in two parts. So you'd get something like:
 
@example
or.u r13,r0,hi16(_foo+0x12345678)
ld.b r2,r13,lo16(_foo+0x12345678)
jmp r1
@end example
 
This should create two relocs, both pointing to @code{_foo}, and with
0x12340000 in their addend field. The data would consist of:
 
@example
RELOCATION RECORDS FOR [.text]:
offset type value
00000002 HVRT16 _foo+0x12340000
00000006 LVRT16 _foo+0x12340000
 
00000000 5da05678 ; or.u r13,r0,0x5678
00000004 1c4d5678 ; ld.b r2,r13,0x5678
00000008 f400c001 ; jmp r1
@end example
 
The relocation routine digs out the value from the data, adds
it to the addend to get the original offset, and then adds the
value of @code{_foo}. Note that all 32 bits have to be kept around
somewhere, to cope with carry from bit 15 to bit 16.
 
One further example is the sparc and the a.out format. The
sparc has a similar problem to the 88k, in that some
instructions don't have room for an entire offset, but on the
sparc the parts are created in odd sized lumps. The designers of
the a.out format chose to not use the data within the section
for storing part of the offset; all the offset is kept within
the reloc. Anything in the data should be ignored.
 
@example
save %sp,-112,%sp
sethi %hi(_foo+0x12345678),%g2
ldsb [%g2+%lo(_foo+0x12345678)],%i0
ret
restore
@end example
 
Both relocs contain a pointer to @code{foo}, and the offsets
contain junk.
 
@example
RELOCATION RECORDS FOR [.text]:
offset type value
00000004 HI22 _foo+0x12345678
00000008 LO10 _foo+0x12345678
 
00000000 9de3bf90 ; save %sp,-112,%sp
00000004 05000000 ; sethi %hi(_foo+0),%g2
00000008 f048a000 ; ldsb [%g2+%lo(_foo+0)],%i0
0000000c 81c7e008 ; ret
00000010 81e80000 ; restore
@end example
 
@itemize @bullet
 
@item
@code{howto}
@end itemize
The @code{howto} field can be imagined as a
relocation instruction. It is a pointer to a structure which
contains information on what to do with all of the other
information in the reloc record and data section. A back end
would normally have a relocation instruction set and turn
relocations into pointers to the correct structure on input -
but it would be possible to create each howto field on demand.
 
@subsubsection @code{enum complain_overflow}
Indicates what sort of overflow checking should be done when
performing a relocation.
 
 
@example
 
enum complain_overflow
@{
/* Do not complain on overflow. */
complain_overflow_dont,
 
/* Complain if the bitfield overflows, whether it is considered
as signed or unsigned. */
complain_overflow_bitfield,
 
/* Complain if the value overflows when considered as signed
number. */
complain_overflow_signed,
 
/* Complain if the value overflows when considered as an
unsigned number. */
complain_overflow_unsigned
@};
@end example
@subsubsection @code{reloc_howto_type}
The @code{reloc_howto_type} is a structure which contains all the
information that libbfd needs to know to tie up a back end's data.
 
 
@example
struct symbol_cache_entry; /* Forward declaration */
 
struct reloc_howto_struct
@{
/* The type field has mainly a documentary use - the back end can
do what it wants with it, though normally the back end's
external idea of what a reloc number is stored
in this field. For example, a PC relative word relocation
in a coff environment has the type 023 - because that's
what the outside world calls a R_PCRWORD reloc. */
unsigned int type;
 
/* The value the final relocation is shifted right by. This drops
unwanted data from the relocation. */
unsigned int rightshift;
 
/* The size of the item to be relocated. This is *not* a
power-of-two measure. To get the number of bytes operated
on by a type of relocation, use bfd_get_reloc_size. */
int size;
 
/* The number of bits in the item to be relocated. This is used
when doing overflow checking. */
unsigned int bitsize;
 
/* Notes that the relocation is relative to the location in the
data section of the addend. The relocation function will
subtract from the relocation value the address of the location
being relocated. */
boolean pc_relative;
 
/* The bit position of the reloc value in the destination.
The relocated value is left shifted by this amount. */
unsigned int bitpos;
 
/* What type of overflow error should be checked for when
relocating. */
enum complain_overflow complain_on_overflow;
 
/* If this field is non null, then the supplied function is
called rather than the normal function. This allows really
strange relocation methods to be accomodated (e.g., i960 callj
instructions). */
bfd_reloc_status_type (*special_function)
PARAMS ((bfd *abfd,
arelent *reloc_entry,
struct symbol_cache_entry *symbol,
PTR data,
asection *input_section,
bfd *output_bfd,
char **error_message));
 
/* The textual name of the relocation type. */
char *name;
 
/* Some formats record a relocation addend in the section contents
rather than with the relocation. For ELF formats this is the
distinction between USE_REL and USE_RELA (though the code checks
for USE_REL == 1/0). The value of this field is TRUE if the
addend is recorded with the section contents; when performing a
partial link (ld -r) the section contents (the data) will be
modified. The value of this field is FALSE if addends are
recorded with the relocation (in arelent.addend); when performing
a partial link the relocation will be modified.
All relocations for all ELF USE_RELA targets should set this field
to FALSE (values of TRUE should be looked on with suspicion).
However, the converse is not true: not all relocations of all ELF
USE_REL targets set this field to TRUE. Why this is so is peculiar
to each particular target. For relocs that aren't used in partial
links (e.g. GOT stuff) it doesn't matter what this is set to. */
boolean partial_inplace;
 
/* The src_mask selects which parts of the read in data
are to be used in the relocation sum. E.g., if this was an 8 bit
byte of data which we read and relocated, this would be
0x000000ff. When we have relocs which have an addend, such as
sun4 extended relocs, the value in the offset part of a
relocating field is garbage so we never use it. In this case
the mask would be 0x00000000. */
bfd_vma src_mask;
 
/* The dst_mask selects which parts of the instruction are replaced
into the instruction. In most cases src_mask == dst_mask,
except in the above special case, where dst_mask would be
0x000000ff, and src_mask would be 0x00000000. */
bfd_vma dst_mask;
 
/* When some formats create PC relative instructions, they leave
the value of the pc of the place being relocated in the offset
slot of the instruction, so that a PC relative relocation can
be made just by adding in an ordinary offset (e.g., sun3 a.out).
Some formats leave the displacement part of an instruction
empty (e.g., m88k bcs); this flag signals the fact.*/
boolean pcrel_offset;
 
@};
@end example
@findex The HOWTO Macro
@subsubsection @code{The HOWTO Macro}
@strong{Description}@*
The HOWTO define is horrible and will go away.
@example
#define HOWTO(C, R,S,B, P, BI, O, SF, NAME, INPLACE, MASKSRC, MASKDST, PC) \
@{(unsigned)C,R,S,B, P, BI, O,SF,NAME,INPLACE,MASKSRC,MASKDST,PC@}
@end example
 
@strong{Description}@*
And will be replaced with the totally magic way. But for the
moment, we are compatible, so do it this way.
@example
#define NEWHOWTO( FUNCTION, NAME,SIZE,REL,IN) HOWTO(0,0,SIZE,0,REL,0,complain_overflow_dont,FUNCTION, NAME,false,0,0,IN)
 
@end example
 
@strong{Description}@*
This is used to fill in an empty howto entry in an array.
@example
#define EMPTY_HOWTO(C) \
HOWTO((C),0,0,0,false,0,complain_overflow_dont,NULL,NULL,false,0,0,false)
 
@end example
 
@strong{Description}@*
Helper routine to turn a symbol into a relocation value.
@example
#define HOWTO_PREPARE(relocation, symbol) \
@{ \
if (symbol != (asymbol *)NULL) @{ \
if (bfd_is_com_section (symbol->section)) @{ \
relocation = 0; \
@} \
else @{ \
relocation = symbol->value; \
@} \
@} \
@}
@end example
 
@findex bfd_get_reloc_size
@subsubsection @code{bfd_get_reloc_size}
@strong{Synopsis}
@example
unsigned int bfd_get_reloc_size (reloc_howto_type *);
@end example
@strong{Description}@*
For a reloc_howto_type that operates on a fixed number of bytes,
this returns the number of bytes operated on.
 
@findex arelent_chain
@subsubsection @code{arelent_chain}
@strong{Description}@*
How relocs are tied together in an @code{asection}:
@example
typedef struct relent_chain @{
arelent relent;
struct relent_chain *next;
@} arelent_chain;
@end example
 
@findex bfd_check_overflow
@subsubsection @code{bfd_check_overflow}
@strong{Synopsis}
@example
bfd_reloc_status_type
bfd_check_overflow
(enum complain_overflow how,
unsigned int bitsize,
unsigned int rightshift,
unsigned int addrsize,
bfd_vma relocation);
@end example
@strong{Description}@*
Perform overflow checking on @var{relocation} which has
@var{bitsize} significant bits and will be shifted right by
@var{rightshift} bits, on a machine with addresses containing
@var{addrsize} significant bits. The result is either of
@code{bfd_reloc_ok} or @code{bfd_reloc_overflow}.
 
@findex bfd_perform_relocation
@subsubsection @code{bfd_perform_relocation}
@strong{Synopsis}
@example
bfd_reloc_status_type
bfd_perform_relocation
(bfd *abfd,
arelent *reloc_entry,
PTR data,
asection *input_section,
bfd *output_bfd,
char **error_message);
@end example
@strong{Description}@*
If @var{output_bfd} is supplied to this function, the
generated image will be relocatable; the relocations are
copied to the output file after they have been changed to
reflect the new state of the world. There are two ways of
reflecting the results of partial linkage in an output file:
by modifying the output data in place, and by modifying the
relocation record. Some native formats (e.g., basic a.out and
basic coff) have no way of specifying an addend in the
relocation type, so the addend has to go in the output data.
This is no big deal since in these formats the output data
slot will always be big enough for the addend. Complex reloc
types with addends were invented to solve just this problem.
The @var{error_message} argument is set to an error message if
this return @code{bfd_reloc_dangerous}.
 
@findex bfd_install_relocation
@subsubsection @code{bfd_install_relocation}
@strong{Synopsis}
@example
bfd_reloc_status_type
bfd_install_relocation
(bfd *abfd,
arelent *reloc_entry,
PTR data, bfd_vma data_start,
asection *input_section,
char **error_message);
@end example
@strong{Description}@*
This looks remarkably like @code{bfd_perform_relocation}, except it
does not expect that the section contents have been filled in.
I.e., it's suitable for use when creating, rather than applying
a relocation.
 
For now, this function should be considered reserved for the
assembler.
 
 
@node howto manager, , typedef arelent, Relocations
@section The howto manager
When an application wants to create a relocation, but doesn't
know what the target machine might call it, it can find out by
using this bit of code.
 
@findex bfd_reloc_code_type
@subsubsection @code{bfd_reloc_code_type}
@strong{Description}@*
The insides of a reloc code. The idea is that, eventually, there
will be one enumerator for every type of relocation we ever do.
Pass one of these values to @code{bfd_reloc_type_lookup}, and it'll
return a howto pointer.
 
This does mean that the application must determine the correct
enumerator value; you can't get a howto pointer from a random set
of attributes.
 
Here are the possible values for @code{enum bfd_reloc_code_real}:
 
@deffn {} BFD_RELOC_64
@deffnx {} BFD_RELOC_32
@deffnx {} BFD_RELOC_26
@deffnx {} BFD_RELOC_24
@deffnx {} BFD_RELOC_16
@deffnx {} BFD_RELOC_14
@deffnx {} BFD_RELOC_8
Basic absolute relocations of N bits.
@end deffn
@deffn {} BFD_RELOC_64_PCREL
@deffnx {} BFD_RELOC_32_PCREL
@deffnx {} BFD_RELOC_24_PCREL
@deffnx {} BFD_RELOC_16_PCREL
@deffnx {} BFD_RELOC_12_PCREL
@deffnx {} BFD_RELOC_8_PCREL
PC-relative relocations. Sometimes these are relative to the address
of the relocation itself; sometimes they are relative to the start of
the section containing the relocation. It depends on the specific target.
 
The 24-bit relocation is used in some Intel 960 configurations.
@end deffn
@deffn {} BFD_RELOC_32_GOT_PCREL
@deffnx {} BFD_RELOC_16_GOT_PCREL
@deffnx {} BFD_RELOC_8_GOT_PCREL
@deffnx {} BFD_RELOC_32_GOTOFF
@deffnx {} BFD_RELOC_16_GOTOFF
@deffnx {} BFD_RELOC_LO16_GOTOFF
@deffnx {} BFD_RELOC_HI16_GOTOFF
@deffnx {} BFD_RELOC_HI16_S_GOTOFF
@deffnx {} BFD_RELOC_8_GOTOFF
@deffnx {} BFD_RELOC_32_PLT_PCREL
@deffnx {} BFD_RELOC_24_PLT_PCREL
@deffnx {} BFD_RELOC_16_PLT_PCREL
@deffnx {} BFD_RELOC_8_PLT_PCREL
@deffnx {} BFD_RELOC_32_PLTOFF
@deffnx {} BFD_RELOC_16_PLTOFF
@deffnx {} BFD_RELOC_LO16_PLTOFF
@deffnx {} BFD_RELOC_HI16_PLTOFF
@deffnx {} BFD_RELOC_HI16_S_PLTOFF
@deffnx {} BFD_RELOC_8_PLTOFF
For ELF.
@end deffn
@deffn {} BFD_RELOC_68K_GLOB_DAT
@deffnx {} BFD_RELOC_68K_JMP_SLOT
@deffnx {} BFD_RELOC_68K_RELATIVE
Relocations used by 68K ELF.
@end deffn
@deffn {} BFD_RELOC_32_BASEREL
@deffnx {} BFD_RELOC_16_BASEREL
@deffnx {} BFD_RELOC_LO16_BASEREL
@deffnx {} BFD_RELOC_HI16_BASEREL
@deffnx {} BFD_RELOC_HI16_S_BASEREL
@deffnx {} BFD_RELOC_8_BASEREL
@deffnx {} BFD_RELOC_RVA
Linkage-table relative.
@end deffn
@deffn {} BFD_RELOC_8_FFnn
Absolute 8-bit relocation, but used to form an address like 0xFFnn.
@end deffn
@deffn {} BFD_RELOC_32_PCREL_S2
@deffnx {} BFD_RELOC_16_PCREL_S2
@deffnx {} BFD_RELOC_23_PCREL_S2
These PC-relative relocations are stored as word displacements --
i.e., byte displacements shifted right two bits. The 30-bit word
displacement (<<32_PCREL_S2>> -- 32 bits, shifted 2) is used on the
SPARC. (SPARC tools generally refer to this as <<WDISP30>>.) The
signed 16-bit displacement is used on the MIPS, and the 23-bit
displacement is used on the Alpha.
@end deffn
@deffn {} BFD_RELOC_HI22
@deffnx {} BFD_RELOC_LO10
High 22 bits and low 10 bits of 32-bit value, placed into lower bits of
the target word. These are used on the SPARC.
@end deffn
@deffn {} BFD_RELOC_GPREL16
@deffnx {} BFD_RELOC_GPREL32
For systems that allocate a Global Pointer register, these are
displacements off that register. These relocation types are
handled specially, because the value the register will have is
decided relatively late.
@end deffn
@deffn {} BFD_RELOC_I960_CALLJ
Reloc types used for i960/b.out.
@end deffn
@deffn {} BFD_RELOC_NONE
@deffnx {} BFD_RELOC_SPARC_WDISP22
@deffnx {} BFD_RELOC_SPARC22
@deffnx {} BFD_RELOC_SPARC13
@deffnx {} BFD_RELOC_SPARC_GOT10
@deffnx {} BFD_RELOC_SPARC_GOT13
@deffnx {} BFD_RELOC_SPARC_GOT22
@deffnx {} BFD_RELOC_SPARC_PC10
@deffnx {} BFD_RELOC_SPARC_PC22
@deffnx {} BFD_RELOC_SPARC_WPLT30
@deffnx {} BFD_RELOC_SPARC_COPY
@deffnx {} BFD_RELOC_SPARC_GLOB_DAT
@deffnx {} BFD_RELOC_SPARC_JMP_SLOT
@deffnx {} BFD_RELOC_SPARC_RELATIVE
@deffnx {} BFD_RELOC_SPARC_UA32
SPARC ELF relocations. There is probably some overlap with other
relocation types already defined.
@end deffn
@deffn {} BFD_RELOC_SPARC_BASE13
@deffnx {} BFD_RELOC_SPARC_BASE22
I think these are specific to SPARC a.out (e.g., Sun 4).
@end deffn
@deffn {} BFD_RELOC_SPARC_64
@deffnx {} BFD_RELOC_SPARC_10
@deffnx {} BFD_RELOC_SPARC_11
@deffnx {} BFD_RELOC_SPARC_OLO10
@deffnx {} BFD_RELOC_SPARC_HH22
@deffnx {} BFD_RELOC_SPARC_HM10
@deffnx {} BFD_RELOC_SPARC_LM22
@deffnx {} BFD_RELOC_SPARC_PC_HH22
@deffnx {} BFD_RELOC_SPARC_PC_HM10
@deffnx {} BFD_RELOC_SPARC_PC_LM22
@deffnx {} BFD_RELOC_SPARC_WDISP16
@deffnx {} BFD_RELOC_SPARC_WDISP19
@deffnx {} BFD_RELOC_SPARC_7
@deffnx {} BFD_RELOC_SPARC_6
@deffnx {} BFD_RELOC_SPARC_5
@deffnx {} BFD_RELOC_SPARC_DISP64
@deffnx {} BFD_RELOC_SPARC_PLT64
@deffnx {} BFD_RELOC_SPARC_HIX22
@deffnx {} BFD_RELOC_SPARC_LOX10
@deffnx {} BFD_RELOC_SPARC_H44
@deffnx {} BFD_RELOC_SPARC_M44
@deffnx {} BFD_RELOC_SPARC_L44
@deffnx {} BFD_RELOC_SPARC_REGISTER
SPARC64 relocations
@end deffn
@deffn {} BFD_RELOC_SPARC_REV32
SPARC little endian relocation
@end deffn
@deffn {} BFD_RELOC_ALPHA_GPDISP_HI16
Alpha ECOFF and ELF relocations. Some of these treat the symbol or
"addend" in some special way.
For GPDISP_HI16 ("gpdisp") relocations, the symbol is ignored when
writing; when reading, it will be the absolute section symbol. The
addend is the displacement in bytes of the "lda" instruction from
the "ldah" instruction (which is at the address of this reloc).
@end deffn
@deffn {} BFD_RELOC_ALPHA_GPDISP_LO16
For GPDISP_LO16 ("ignore") relocations, the symbol is handled as
with GPDISP_HI16 relocs. The addend is ignored when writing the
relocations out, and is filled in with the file's GP value on
reading, for convenience.
@end deffn
@deffn {} BFD_RELOC_ALPHA_GPDISP
The ELF GPDISP relocation is exactly the same as the GPDISP_HI16
relocation except that there is no accompanying GPDISP_LO16
relocation.
@end deffn
@deffn {} BFD_RELOC_ALPHA_LITERAL
@deffnx {} BFD_RELOC_ALPHA_ELF_LITERAL
@deffnx {} BFD_RELOC_ALPHA_LITUSE
The Alpha LITERAL/LITUSE relocs are produced by a symbol reference;
the assembler turns it into a LDQ instruction to load the address of
the symbol, and then fills in a register in the real instruction.
 
The LITERAL reloc, at the LDQ instruction, refers to the .lita
section symbol. The addend is ignored when writing, but is filled
in with the file's GP value on reading, for convenience, as with the
GPDISP_LO16 reloc.
 
The ELF_LITERAL reloc is somewhere between 16_GOTOFF and GPDISP_LO16.
It should refer to the symbol to be referenced, as with 16_GOTOFF,
but it generates output not based on the position within the .got
section, but relative to the GP value chosen for the file during the
final link stage.
 
The LITUSE reloc, on the instruction using the loaded address, gives
information to the linker that it might be able to use to optimize
away some literal section references. The symbol is ignored (read
as the absolute section symbol), and the "addend" indicates the type
of instruction using the register:
1 - "memory" fmt insn
2 - byte-manipulation (byte offset reg)
3 - jsr (target of branch)
 
The GNU linker currently doesn't do any of this optimizing.
@end deffn
@deffn {} BFD_RELOC_ALPHA_USER_LITERAL
@deffnx {} BFD_RELOC_ALPHA_USER_LITUSE_BASE
@deffnx {} BFD_RELOC_ALPHA_USER_LITUSE_BYTOFF
@deffnx {} BFD_RELOC_ALPHA_USER_LITUSE_JSR
@deffnx {} BFD_RELOC_ALPHA_USER_GPDISP
@deffnx {} BFD_RELOC_ALPHA_USER_GPRELHIGH
@deffnx {} BFD_RELOC_ALPHA_USER_GPRELLOW
The BFD_RELOC_ALPHA_USER_* relocations are used by the assembler to
process the explicit !<reloc>!sequence relocations, and are mapped
into the normal relocations at the end of processing.
@end deffn
@deffn {} BFD_RELOC_ALPHA_HINT
The HINT relocation indicates a value that should be filled into the
"hint" field of a jmp/jsr/ret instruction, for possible branch-
prediction logic which may be provided on some processors.
@end deffn
@deffn {} BFD_RELOC_ALPHA_LINKAGE
The LINKAGE relocation outputs a linkage pair in the object file,
which is filled by the linker.
@end deffn
@deffn {} BFD_RELOC_ALPHA_CODEADDR
The CODEADDR relocation outputs a STO_CA in the object file,
which is filled by the linker.
@end deffn
@deffn {} BFD_RELOC_MIPS_JMP
Bits 27..2 of the relocation address shifted right 2 bits;
simple reloc otherwise.
@end deffn
@deffn {} BFD_RELOC_MIPS16_JMP
The MIPS16 jump instruction.
@end deffn
@deffn {} BFD_RELOC_MIPS16_GPREL
MIPS16 GP relative reloc.
@end deffn
@deffn {} BFD_RELOC_HI16
High 16 bits of 32-bit value; simple reloc.
@end deffn
@deffn {} BFD_RELOC_HI16_S
High 16 bits of 32-bit value but the low 16 bits will be sign
extended and added to form the final result. If the low 16
bits form a negative number, we need to add one to the high value
to compensate for the borrow when the low bits are added.
@end deffn
@deffn {} BFD_RELOC_LO16
Low 16 bits.
@end deffn
@deffn {} BFD_RELOC_PCREL_HI16_S
Like BFD_RELOC_HI16_S, but PC relative.
@end deffn
@deffn {} BFD_RELOC_PCREL_LO16
Like BFD_RELOC_LO16, but PC relative.
@end deffn
@deffn {} BFD_RELOC_MIPS_GPREL
Relocation relative to the global pointer.
@end deffn
@deffn {} BFD_RELOC_MIPS_LITERAL
Relocation against a MIPS literal section.
@end deffn
@deffn {} BFD_RELOC_MIPS_GOT16
@deffnx {} BFD_RELOC_MIPS_CALL16
@deffnx {} BFD_RELOC_MIPS_GPREL32
@deffnx {} BFD_RELOC_MIPS_GOT_HI16
@deffnx {} BFD_RELOC_MIPS_GOT_LO16
@deffnx {} BFD_RELOC_MIPS_CALL_HI16
@deffnx {} BFD_RELOC_MIPS_CALL_LO16
@deffnx {} BFD_RELOC_MIPS_SUB
@deffnx {} BFD_RELOC_MIPS_GOT_PAGE
@deffnx {} BFD_RELOC_MIPS_GOT_OFST
@deffnx {} BFD_RELOC_MIPS_GOT_DISP
MIPS ELF relocations.
@end deffn
@deffn {} BFD_RELOC_386_GOT32
@deffnx {} BFD_RELOC_386_PLT32
@deffnx {} BFD_RELOC_386_COPY
@deffnx {} BFD_RELOC_386_GLOB_DAT
@deffnx {} BFD_RELOC_386_JUMP_SLOT
@deffnx {} BFD_RELOC_386_RELATIVE
@deffnx {} BFD_RELOC_386_GOTOFF
@deffnx {} BFD_RELOC_386_GOTPC
i386/elf relocations
@end deffn
@deffn {} BFD_RELOC_NS32K_IMM_8
@deffnx {} BFD_RELOC_NS32K_IMM_16
@deffnx {} BFD_RELOC_NS32K_IMM_32
@deffnx {} BFD_RELOC_NS32K_IMM_8_PCREL
@deffnx {} BFD_RELOC_NS32K_IMM_16_PCREL
@deffnx {} BFD_RELOC_NS32K_IMM_32_PCREL
@deffnx {} BFD_RELOC_NS32K_DISP_8
@deffnx {} BFD_RELOC_NS32K_DISP_16
@deffnx {} BFD_RELOC_NS32K_DISP_32
@deffnx {} BFD_RELOC_NS32K_DISP_8_PCREL
@deffnx {} BFD_RELOC_NS32K_DISP_16_PCREL
@deffnx {} BFD_RELOC_NS32K_DISP_32_PCREL
ns32k relocations
@end deffn
@deffn {} BFD_RELOC_PJ_CODE_HI16
@deffnx {} BFD_RELOC_PJ_CODE_LO16
@deffnx {} BFD_RELOC_PJ_CODE_DIR16
@deffnx {} BFD_RELOC_PJ_CODE_DIR32
@deffnx {} BFD_RELOC_PJ_CODE_REL16
@deffnx {} BFD_RELOC_PJ_CODE_REL32
Picojava relocs. Not all of these appear in object files.
@end deffn
@deffn {} BFD_RELOC_PPC_B26
@deffnx {} BFD_RELOC_PPC_BA26
@deffnx {} BFD_RELOC_PPC_TOC16
@deffnx {} BFD_RELOC_PPC_B16
@deffnx {} BFD_RELOC_PPC_B16_BRTAKEN
@deffnx {} BFD_RELOC_PPC_B16_BRNTAKEN
@deffnx {} BFD_RELOC_PPC_BA16
@deffnx {} BFD_RELOC_PPC_BA16_BRTAKEN
@deffnx {} BFD_RELOC_PPC_BA16_BRNTAKEN
@deffnx {} BFD_RELOC_PPC_COPY
@deffnx {} BFD_RELOC_PPC_GLOB_DAT
@deffnx {} BFD_RELOC_PPC_JMP_SLOT
@deffnx {} BFD_RELOC_PPC_RELATIVE
@deffnx {} BFD_RELOC_PPC_LOCAL24PC
@deffnx {} BFD_RELOC_PPC_EMB_NADDR32
@deffnx {} BFD_RELOC_PPC_EMB_NADDR16
@deffnx {} BFD_RELOC_PPC_EMB_NADDR16_LO
@deffnx {} BFD_RELOC_PPC_EMB_NADDR16_HI
@deffnx {} BFD_RELOC_PPC_EMB_NADDR16_HA
@deffnx {} BFD_RELOC_PPC_EMB_SDAI16
@deffnx {} BFD_RELOC_PPC_EMB_SDA2I16
@deffnx {} BFD_RELOC_PPC_EMB_SDA2REL
@deffnx {} BFD_RELOC_PPC_EMB_SDA21
@deffnx {} BFD_RELOC_PPC_EMB_MRKREF
@deffnx {} BFD_RELOC_PPC_EMB_RELSEC16
@deffnx {} BFD_RELOC_PPC_EMB_RELST_LO
@deffnx {} BFD_RELOC_PPC_EMB_RELST_HI
@deffnx {} BFD_RELOC_PPC_EMB_RELST_HA
@deffnx {} BFD_RELOC_PPC_EMB_BIT_FLD
@deffnx {} BFD_RELOC_PPC_EMB_RELSDA
Power(rs6000) and PowerPC relocations.
@end deffn
@deffn {} BFD_RELOC_I370_D12
IBM 370/390 relocations
@end deffn
@deffn {} BFD_RELOC_CTOR
The type of reloc used to build a contructor table - at the moment
probably a 32 bit wide absolute relocation, but the target can choose.
It generally does map to one of the other relocation types.
@end deffn
@deffn {} BFD_RELOC_ARM_PCREL_BRANCH
ARM 26 bit pc-relative branch. The lowest two bits must be zero and are
not stored in the instruction.
@end deffn
@deffn {} BFD_RELOC_ARM_PCREL_BLX
ARM 26 bit pc-relative branch. The lowest bit must be zero and is
not stored in the instruction. The 2nd lowest bit comes from a 1 bit
field in the instruction.
@end deffn
@deffn {} BFD_RELOC_THUMB_PCREL_BLX
Thumb 22 bit pc-relative branch. The lowest bit must be zero and is
not stored in the instruction. The 2nd lowest bit comes from a 1 bit
field in the instruction.
@end deffn
@deffn {} BFD_RELOC_ARM_IMMEDIATE
@deffnx {} BFD_RELOC_ARM_ADRL_IMMEDIATE
@deffnx {} BFD_RELOC_ARM_OFFSET_IMM
@deffnx {} BFD_RELOC_ARM_SHIFT_IMM
@deffnx {} BFD_RELOC_ARM_SWI
@deffnx {} BFD_RELOC_ARM_MULTI
@deffnx {} BFD_RELOC_ARM_CP_OFF_IMM
@deffnx {} BFD_RELOC_ARM_ADR_IMM
@deffnx {} BFD_RELOC_ARM_LDR_IMM
@deffnx {} BFD_RELOC_ARM_LITERAL
@deffnx {} BFD_RELOC_ARM_IN_POOL
@deffnx {} BFD_RELOC_ARM_OFFSET_IMM8
@deffnx {} BFD_RELOC_ARM_HWLITERAL
@deffnx {} BFD_RELOC_ARM_THUMB_ADD
@deffnx {} BFD_RELOC_ARM_THUMB_IMM
@deffnx {} BFD_RELOC_ARM_THUMB_SHIFT
@deffnx {} BFD_RELOC_ARM_THUMB_OFFSET
@deffnx {} BFD_RELOC_ARM_GOT12
@deffnx {} BFD_RELOC_ARM_GOT32
@deffnx {} BFD_RELOC_ARM_JUMP_SLOT
@deffnx {} BFD_RELOC_ARM_COPY
@deffnx {} BFD_RELOC_ARM_GLOB_DAT
@deffnx {} BFD_RELOC_ARM_PLT32
@deffnx {} BFD_RELOC_ARM_RELATIVE
@deffnx {} BFD_RELOC_ARM_GOTOFF
@deffnx {} BFD_RELOC_ARM_GOTPC
These relocs are only used within the ARM assembler. They are not
(at present) written to any object files.
@end deffn
@deffn {} BFD_RELOC_SH_PCDISP8BY2
@deffnx {} BFD_RELOC_SH_PCDISP12BY2
@deffnx {} BFD_RELOC_SH_IMM4
@deffnx {} BFD_RELOC_SH_IMM4BY2
@deffnx {} BFD_RELOC_SH_IMM4BY4
@deffnx {} BFD_RELOC_SH_IMM8
@deffnx {} BFD_RELOC_SH_IMM8BY2
@deffnx {} BFD_RELOC_SH_IMM8BY4
@deffnx {} BFD_RELOC_SH_PCRELIMM8BY2
@deffnx {} BFD_RELOC_SH_PCRELIMM8BY4
@deffnx {} BFD_RELOC_SH_SWITCH16
@deffnx {} BFD_RELOC_SH_SWITCH32
@deffnx {} BFD_RELOC_SH_USES
@deffnx {} BFD_RELOC_SH_COUNT
@deffnx {} BFD_RELOC_SH_ALIGN
@deffnx {} BFD_RELOC_SH_CODE
@deffnx {} BFD_RELOC_SH_DATA
@deffnx {} BFD_RELOC_SH_LABEL
@deffnx {} BFD_RELOC_SH_LOOP_START
@deffnx {} BFD_RELOC_SH_LOOP_END
Hitachi SH relocs. Not all of these appear in object files.
@end deffn
@deffn {} BFD_RELOC_THUMB_PCREL_BRANCH9
@deffnx {} BFD_RELOC_THUMB_PCREL_BRANCH12
@deffnx {} BFD_RELOC_THUMB_PCREL_BRANCH23
Thumb 23-, 12- and 9-bit pc-relative branches. The lowest bit must
be zero and is not stored in the instruction.
@end deffn
@deffn {} BFD_RELOC_ARC_B22_PCREL
Argonaut RISC Core (ARC) relocs.
ARC 22 bit pc-relative branch. The lowest two bits must be zero and are
not stored in the instruction. The high 20 bits are installed in bits 26
through 7 of the instruction.
@end deffn
@deffn {} BFD_RELOC_ARC_B26
ARC 26 bit absolute branch. The lowest two bits must be zero and are not
stored in the instruction. The high 24 bits are installed in bits 23
through 0.
@end deffn
@deffn {} BFD_RELOC_D10V_10_PCREL_R
Mitsubishi D10V relocs.
This is a 10-bit reloc with the right 2 bits
assumed to be 0.
@end deffn
@deffn {} BFD_RELOC_D10V_10_PCREL_L
Mitsubishi D10V relocs.
This is a 10-bit reloc with the right 2 bits
assumed to be 0. This is the same as the previous reloc
except it is in the left container, i.e.,
shifted left 15 bits.
@end deffn
@deffn {} BFD_RELOC_D10V_18
This is an 18-bit reloc with the right 2 bits
assumed to be 0.
@end deffn
@deffn {} BFD_RELOC_D10V_18_PCREL
This is an 18-bit reloc with the right 2 bits
assumed to be 0.
@end deffn
@deffn {} BFD_RELOC_D30V_6
Mitsubishi D30V relocs.
This is a 6-bit absolute reloc.
@end deffn
@deffn {} BFD_RELOC_D30V_9_PCREL
This is a 6-bit pc-relative reloc with
the right 3 bits assumed to be 0.
@end deffn
@deffn {} BFD_RELOC_D30V_9_PCREL_R
This is a 6-bit pc-relative reloc with
the right 3 bits assumed to be 0. Same
as the previous reloc but on the right side
of the container.
@end deffn
@deffn {} BFD_RELOC_D30V_15
This is a 12-bit absolute reloc with the
right 3 bitsassumed to be 0.
@end deffn
@deffn {} BFD_RELOC_D30V_15_PCREL
This is a 12-bit pc-relative reloc with
the right 3 bits assumed to be 0.
@end deffn
@deffn {} BFD_RELOC_D30V_15_PCREL_R
This is a 12-bit pc-relative reloc with
the right 3 bits assumed to be 0. Same
as the previous reloc but on the right side
of the container.
@end deffn
@deffn {} BFD_RELOC_D30V_21
This is an 18-bit absolute reloc with
the right 3 bits assumed to be 0.
@end deffn
@deffn {} BFD_RELOC_D30V_21_PCREL
This is an 18-bit pc-relative reloc with
the right 3 bits assumed to be 0.
@end deffn
@deffn {} BFD_RELOC_D30V_21_PCREL_R
This is an 18-bit pc-relative reloc with
the right 3 bits assumed to be 0. Same
as the previous reloc but on the right side
of the container.
@end deffn
@deffn {} BFD_RELOC_D30V_32
This is a 32-bit absolute reloc.
@end deffn
@deffn {} BFD_RELOC_D30V_32_PCREL
This is a 32-bit pc-relative reloc.
@end deffn
@deffn {} BFD_RELOC_M32R_24
Mitsubishi M32R relocs.
This is a 24 bit absolute address.
@end deffn
@deffn {} BFD_RELOC_M32R_10_PCREL
This is a 10-bit pc-relative reloc with the right 2 bits assumed to be 0.
@end deffn
@deffn {} BFD_RELOC_M32R_18_PCREL
This is an 18-bit reloc with the right 2 bits assumed to be 0.
@end deffn
@deffn {} BFD_RELOC_M32R_26_PCREL
This is a 26-bit reloc with the right 2 bits assumed to be 0.
@end deffn
@deffn {} BFD_RELOC_M32R_HI16_ULO
This is a 16-bit reloc containing the high 16 bits of an address
used when the lower 16 bits are treated as unsigned.
@end deffn
@deffn {} BFD_RELOC_M32R_HI16_SLO
This is a 16-bit reloc containing the high 16 bits of an address
used when the lower 16 bits are treated as signed.
@end deffn
@deffn {} BFD_RELOC_M32R_LO16
This is a 16-bit reloc containing the lower 16 bits of an address.
@end deffn
@deffn {} BFD_RELOC_M32R_SDA16
This is a 16-bit reloc containing the small data area offset for use in
add3, load, and store instructions.
@end deffn
@deffn {} BFD_RELOC_V850_9_PCREL
This is a 9-bit reloc
@end deffn
@deffn {} BFD_RELOC_V850_22_PCREL
This is a 22-bit reloc
@end deffn
@deffn {} BFD_RELOC_V850_SDA_16_16_OFFSET
This is a 16 bit offset from the short data area pointer.
@end deffn
@deffn {} BFD_RELOC_V850_SDA_15_16_OFFSET
This is a 16 bit offset (of which only 15 bits are used) from the
short data area pointer.
@end deffn
@deffn {} BFD_RELOC_V850_ZDA_16_16_OFFSET
This is a 16 bit offset from the zero data area pointer.
@end deffn
@deffn {} BFD_RELOC_V850_ZDA_15_16_OFFSET
This is a 16 bit offset (of which only 15 bits are used) from the
zero data area pointer.
@end deffn
@deffn {} BFD_RELOC_V850_TDA_6_8_OFFSET
This is an 8 bit offset (of which only 6 bits are used) from the
tiny data area pointer.
@end deffn
@deffn {} BFD_RELOC_V850_TDA_7_8_OFFSET
This is an 8bit offset (of which only 7 bits are used) from the tiny
data area pointer.
@end deffn
@deffn {} BFD_RELOC_V850_TDA_7_7_OFFSET
This is a 7 bit offset from the tiny data area pointer.
@end deffn
@deffn {} BFD_RELOC_V850_TDA_16_16_OFFSET
This is a 16 bit offset from the tiny data area pointer.
@end deffn
@deffn {} BFD_RELOC_V850_TDA_4_5_OFFSET
This is a 5 bit offset (of which only 4 bits are used) from the tiny
data area pointer.
@end deffn
@deffn {} BFD_RELOC_V850_TDA_4_4_OFFSET
This is a 4 bit offset from the tiny data area pointer.
@end deffn
@deffn {} BFD_RELOC_V850_SDA_16_16_SPLIT_OFFSET
This is a 16 bit offset from the short data area pointer, with the
bits placed non-contigously in the instruction.
@end deffn
@deffn {} BFD_RELOC_V850_ZDA_16_16_SPLIT_OFFSET
This is a 16 bit offset from the zero data area pointer, with the
bits placed non-contigously in the instruction.
@end deffn
@deffn {} BFD_RELOC_V850_CALLT_6_7_OFFSET
This is a 6 bit offset from the call table base pointer.
@end deffn
@deffn {} BFD_RELOC_V850_CALLT_16_16_OFFSET
This is a 16 bit offset from the call table base pointer.
@end deffn
@deffn {} BFD_RELOC_MN10300_32_PCREL
This is a 32bit pcrel reloc for the mn10300, offset by two bytes in the
instruction.
@end deffn
@deffn {} BFD_RELOC_MN10300_16_PCREL
This is a 16bit pcrel reloc for the mn10300, offset by two bytes in the
instruction.
@end deffn
@deffn {} BFD_RELOC_TIC30_LDP
This is a 8bit DP reloc for the tms320c30, where the most
significant 8 bits of a 24 bit word are placed into the least
significant 8 bits of the opcode.
@end deffn
@deffn {} BFD_RELOC_TIC54X_PARTLS7
This is a 7bit reloc for the tms320c54x, where the least
significant 7 bits of a 16 bit word are placed into the least
significant 7 bits of the opcode.
@end deffn
@deffn {} BFD_RELOC_TIC54X_PARTMS9
This is a 9bit DP reloc for the tms320c54x, where the most
significant 9 bits of a 16 bit word are placed into the least
significant 9 bits of the opcode.
@end deffn
@deffn {} BFD_RELOC_TIC54X_23
This is an extended address 23-bit reloc for the tms320c54x.
@end deffn
@deffn {} BFD_RELOC_TIC54X_16_OF_23
This is a 16-bit reloc for the tms320c54x, where the least
significant 16 bits of a 23-bit extended address are placed into
the opcode.
@end deffn
@deffn {} BFD_RELOC_TIC54X_MS7_OF_23
This is a reloc for the tms320c54x, where the most
significant 7 bits of a 23-bit extended address are placed into
the opcode.
@end deffn
@deffn {} BFD_RELOC_FR30_48
This is a 48 bit reloc for the FR30 that stores 32 bits.
@end deffn
@deffn {} BFD_RELOC_FR30_20
This is a 32 bit reloc for the FR30 that stores 20 bits split up into
two sections.
@end deffn
@deffn {} BFD_RELOC_FR30_6_IN_4
This is a 16 bit reloc for the FR30 that stores a 6 bit word offset in
4 bits.
@end deffn
@deffn {} BFD_RELOC_FR30_8_IN_8
This is a 16 bit reloc for the FR30 that stores an 8 bit byte offset
into 8 bits.
@end deffn
@deffn {} BFD_RELOC_FR30_9_IN_8
This is a 16 bit reloc for the FR30 that stores a 9 bit short offset
into 8 bits.
@end deffn
@deffn {} BFD_RELOC_FR30_10_IN_8
This is a 16 bit reloc for the FR30 that stores a 10 bit word offset
into 8 bits.
@end deffn
@deffn {} BFD_RELOC_FR30_9_PCREL
This is a 16 bit reloc for the FR30 that stores a 9 bit pc relative
short offset into 8 bits.
@end deffn
@deffn {} BFD_RELOC_FR30_12_PCREL
This is a 16 bit reloc for the FR30 that stores a 12 bit pc relative
short offset into 11 bits.
@end deffn
@deffn {} BFD_RELOC_MCORE_PCREL_IMM8BY4
@deffnx {} BFD_RELOC_MCORE_PCREL_IMM11BY2
@deffnx {} BFD_RELOC_MCORE_PCREL_IMM4BY2
@deffnx {} BFD_RELOC_MCORE_PCREL_32
@deffnx {} BFD_RELOC_MCORE_PCREL_JSR_IMM11BY2
@deffnx {} BFD_RELOC_MCORE_RVA
Motorola Mcore relocations.
@end deffn
@deffn {} BFD_RELOC_AVR_7_PCREL
This is a 16 bit reloc for the AVR that stores 8 bit pc relative
short offset into 7 bits.
@end deffn
@deffn {} BFD_RELOC_AVR_13_PCREL
This is a 16 bit reloc for the AVR that stores 13 bit pc relative
short offset into 12 bits.
@end deffn
@deffn {} BFD_RELOC_AVR_16_PM
This is a 16 bit reloc for the AVR that stores 17 bit value (usually
program memory address) into 16 bits.
@end deffn
@deffn {} BFD_RELOC_AVR_LO8_LDI
This is a 16 bit reloc for the AVR that stores 8 bit value (usually
data memory address) into 8 bit immediate value of LDI insn.
@end deffn
@deffn {} BFD_RELOC_AVR_HI8_LDI
This is a 16 bit reloc for the AVR that stores 8 bit value (high 8 bit
of data memory address) into 8 bit immediate value of LDI insn.
@end deffn
@deffn {} BFD_RELOC_AVR_HH8_LDI
This is a 16 bit reloc for the AVR that stores 8 bit value (most high 8 bit
of program memory address) into 8 bit immediate value of LDI insn.
@end deffn
@deffn {} BFD_RELOC_AVR_LO8_LDI_NEG
This is a 16 bit reloc for the AVR that stores negated 8 bit value
(usually data memory address) into 8 bit immediate value of SUBI insn.
@end deffn
@deffn {} BFD_RELOC_AVR_HI8_LDI_NEG
This is a 16 bit reloc for the AVR that stores negated 8 bit value
(high 8 bit of data memory address) into 8 bit immediate value of
SUBI insn.
@end deffn
@deffn {} BFD_RELOC_AVR_HH8_LDI_NEG
This is a 16 bit reloc for the AVR that stores negated 8 bit value
(most high 8 bit of program memory address) into 8 bit immediate value
of LDI or SUBI insn.
@end deffn
@deffn {} BFD_RELOC_AVR_LO8_LDI_PM
This is a 16 bit reloc for the AVR that stores 8 bit value (usually
command address) into 8 bit immediate value of LDI insn.
@end deffn
@deffn {} BFD_RELOC_AVR_HI8_LDI_PM
This is a 16 bit reloc for the AVR that stores 8 bit value (high 8 bit
of command address) into 8 bit immediate value of LDI insn.
@end deffn
@deffn {} BFD_RELOC_AVR_HH8_LDI_PM
This is a 16 bit reloc for the AVR that stores 8 bit value (most high 8 bit
of command address) into 8 bit immediate value of LDI insn.
@end deffn
@deffn {} BFD_RELOC_AVR_LO8_LDI_PM_NEG
This is a 16 bit reloc for the AVR that stores negated 8 bit value
(usually command address) into 8 bit immediate value of SUBI insn.
@end deffn
@deffn {} BFD_RELOC_AVR_HI8_LDI_PM_NEG
This is a 16 bit reloc for the AVR that stores negated 8 bit value
(high 8 bit of 16 bit command address) into 8 bit immediate value
of SUBI insn.
@end deffn
@deffn {} BFD_RELOC_AVR_HH8_LDI_PM_NEG
This is a 16 bit reloc for the AVR that stores negated 8 bit value
(high 6 bit of 22 bit command address) into 8 bit immediate
value of SUBI insn.
@end deffn
@deffn {} BFD_RELOC_AVR_CALL
This is a 32 bit reloc for the AVR that stores 23 bit value
into 22 bits.
@end deffn
@deffn {} BFD_RELOC_VTABLE_INHERIT
@deffnx {} BFD_RELOC_VTABLE_ENTRY
These two relocations are used by the linker to determine which of
the entries in a C++ virtual function table are actually used. When
the --gc-sections option is given, the linker will zero out the entries
that are not used, so that the code for those functions need not be
included in the output.
 
VTABLE_INHERIT is a zero-space relocation used to describe to the
linker the inheritence tree of a C++ virtual function table. The
relocation's symbol should be the parent class' vtable, and the
relocation should be located at the child vtable.
 
VTABLE_ENTRY is a zero-space relocation that describes the use of a
virtual function table entry. The reloc's symbol should refer to the
table of the class mentioned in the code. Off of that base, an offset
describes the entry that is being used. For Rela hosts, this offset
is stored in the reloc's addend. For Rel hosts, we are forced to put
this offset in the reloc's section offset.
@end deffn
 
@example
 
typedef enum bfd_reloc_code_real bfd_reloc_code_real_type;
@end example
@findex bfd_reloc_type_lookup
@subsubsection @code{bfd_reloc_type_lookup}
@strong{Synopsis}
@example
reloc_howto_type *
bfd_reloc_type_lookup (bfd *abfd, bfd_reloc_code_real_type code);
@end example
@strong{Description}@*
Return a pointer to a howto structure which, when
invoked, will perform the relocation @var{code} on data from the
architecture noted.
 
@findex bfd_default_reloc_type_lookup
@subsubsection @code{bfd_default_reloc_type_lookup}
@strong{Synopsis}
@example
reloc_howto_type *bfd_default_reloc_type_lookup
(bfd *abfd, bfd_reloc_code_real_type code);
@end example
@strong{Description}@*
Provides a default relocation lookup routine for any architecture.
 
@findex bfd_get_reloc_code_name
@subsubsection @code{bfd_get_reloc_code_name}
@strong{Synopsis}
@example
const char *bfd_get_reloc_code_name (bfd_reloc_code_real_type code);
@end example
@strong{Description}@*
Provides a printable name for the supplied relocation code.
Useful mainly for printing error messages.
 
@findex bfd_generic_relax_section
@subsubsection @code{bfd_generic_relax_section}
@strong{Synopsis}
@example
boolean bfd_generic_relax_section
(bfd *abfd,
asection *section,
struct bfd_link_info *,
boolean *);
@end example
@strong{Description}@*
Provides default handling for relaxing for back ends which
don't do relaxing -- i.e., does nothing.
 
@findex bfd_generic_gc_sections
@subsubsection @code{bfd_generic_gc_sections}
@strong{Synopsis}
@example
boolean bfd_generic_gc_sections
(bfd *, struct bfd_link_info *);
@end example
@strong{Description}@*
Provides default handling for relaxing for back ends which
don't do section gc -- i.e., does nothing.
 
@findex bfd_generic_get_relocated_section_contents
@subsubsection @code{bfd_generic_get_relocated_section_contents}
@strong{Synopsis}
@example
bfd_byte *
bfd_generic_get_relocated_section_contents (bfd *abfd,
struct bfd_link_info *link_info,
struct bfd_link_order *link_order,
bfd_byte *data,
boolean relocateable,
asymbol **symbols);
@end example
@strong{Description}@*
Provides default handling of relocation effort for back ends
which can't be bothered to do it efficiently.
 
/doc.str
0,0 → 1,158
: DOCDD
skip_past_newline
get_stuff_in_command kill_bogus_lines catstr
;
 
: ENDDD
skip_past_newline
;
 
: EXAMPLE
skip_past_newline
get_stuff_in_command kill_bogus_lines do_fancy_stuff translatecomments
courierize catstr
 
;
 
: INODE
"@node " catstr skip_past_newline copy_past_newline catstr
;
 
: CODE_FRAGMENT
EXAMPLE
;
 
: COMMENT
skip_past_newline
get_stuff_in_command
drop
;
 
: SYNOPSIS
skip_past_newline
"@strong{Synopsis}\n" catstr
"@example\n" catstr
get_stuff_in_command
kill_bogus_lines
indent
catstr
"@end example\n" catstr
 
;
 
: func
"@findex " - a
skip_past_newline
copy_past_newline
dup - a x x
"@subsubsection @code{" - a x x b
swap
remchar
"}\n" - a x b x c
catstr catstr catstr catstr catstr
;
 
: FUNCTION
"@findex " - a
skip_past_newline
copy_past_newline
dup - a x x
"@subsubsection @code{" - a x x b
swap
remchar
"}\n" - a x b x c
catstr catstr catstr catstr catstr
;
 
: bodytext
get_stuff_in_command
bulletize
kill_bogus_lines
do_fancy_stuff
courierize
catstr
"\n" catstr
;
 
: asection
skip_past_newline
catstr
copy_past_newline
do_fancy_stuff catstr
bodytext
;
 
: SECTION
"@section " asection ;
 
: SUBSECTION
"@subsection " asection ;
 
: SUBSUBSECTION
"@subsubsection " asection ;
 
: subhead
skip_past_newline
bodytext
;
 
 
 
: DESCRIPTION
"@strong{Description}@*\n" catstr subhead ;
 
: RETURNS
"@strong{Returns}@*\n" catstr subhead ;
 
: INTERNAL_FUNCTION
func ;
 
 
: INTERNAL_DEFINITION
func ;
 
 
: INTERNAL
func ;
 
: TYPEDEF
FUNCTION ;
 
: SENUM
skip_past_newline
"Here are the possible values for @code{enum "
copy_past_newline remchar catstr
"}:\n\n" catstr catstr
;
: ENUM
skip_past_newline
"@deffn {} "
copy_past_newline catstr catstr
;
: ENUMX
skip_past_newline
"@deffnx {} "
copy_past_newline catstr
catstr
;
: ENUMEQ
skip_past_newline
"@deffn {} "
copy_past_newline catstr catstr
skip_past_newline
;
: ENUMEQX
skip_past_newline
"@deffnx {} "
copy_past_newline catstr
catstr
skip_past_newline
;
: ENUMDOC
skip_past_newline
get_stuff_in_command
strip_trailing_newlines
catstr
"\n@end deffn\n" catstr
;
/targets.texi
0,0 → 1,508
@section Targets
 
 
@strong{Description}@*
Each port of BFD to a different machine requries the creation
of a target back end. All the back end provides to the root
part of BFD is a structure containing pointers to functions
which perform certain low level operations on files. BFD
translates the applications's requests through a pointer into
calls to the back end routines.
 
When a file is opened with @code{bfd_openr}, its format and
target are unknown. BFD uses various mechanisms to determine
how to interpret the file. The operations performed are:
 
@itemize @bullet
 
@item
Create a BFD by calling the internal routine
@code{_bfd_new_bfd}, then call @code{bfd_find_target} with the
target string supplied to @code{bfd_openr} and the new BFD pointer.
 
@item
If a null target string was provided to @code{bfd_find_target},
look up the environment variable @code{GNUTARGET} and use
that as the target string.
 
@item
If the target string is still @code{NULL}, or the target string is
@code{default}, then use the first item in the target vector
as the target type, and set @code{target_defaulted} in the BFD to
cause @code{bfd_check_format} to loop through all the targets.
@xref{bfd_target}. @xref{Formats}.
 
@item
Otherwise, inspect the elements in the target vector
one by one, until a match on target name is found. When found,
use it.
 
@item
Otherwise return the error @code{bfd_error_invalid_target} to
@code{bfd_openr}.
 
@item
@code{bfd_openr} attempts to open the file using
@code{bfd_open_file}, and returns the BFD.
@end itemize
Once the BFD has been opened and the target selected, the file
format may be determined. This is done by calling
@code{bfd_check_format} on the BFD with a suggested format.
If @code{target_defaulted} has been set, each possible target
type is tried to see if it recognizes the specified format.
@code{bfd_check_format} returns @code{true} when the caller guesses right.
@menu
* bfd_target::
@end menu
 
@node bfd_target, , Targets, Targets
 
@subsection bfd_target
 
 
@strong{Description}@*
This structure contains everything that BFD knows about a
target. It includes things like its byte order, name, and which
routines to call to do various operations.
 
Every BFD points to a target structure with its @code{xvec}
member.
 
The macros below are used to dispatch to functions through the
@code{bfd_target} vector. They are used in a number of macros further
down in @file{bfd.h}, and are also used when calling various
routines by hand inside the BFD implementation. The @var{arglist}
argument must be parenthesized; it contains all the arguments
to the called function.
 
They make the documentation (more) unpleasant to read, so if
someone wants to fix this and not break the above, please do.
@example
#define BFD_SEND(bfd, message, arglist) \
((*((bfd)->xvec->message)) arglist)
 
#ifdef DEBUG_BFD_SEND
#undef BFD_SEND
#define BFD_SEND(bfd, message, arglist) \
(((bfd) && (bfd)->xvec && (bfd)->xvec->message) ? \
((*((bfd)->xvec->message)) arglist) : \
(bfd_assert (__FILE__,__LINE__), NULL))
#endif
@end example
For operations which index on the BFD format:
@example
#define BFD_SEND_FMT(bfd, message, arglist) \
(((bfd)->xvec->message[(int)((bfd)->format)]) arglist)
 
#ifdef DEBUG_BFD_SEND
#undef BFD_SEND_FMT
#define BFD_SEND_FMT(bfd, message, arglist) \
(((bfd) && (bfd)->xvec && (bfd)->xvec->message) ? \
(((bfd)->xvec->message[(int)((bfd)->format)]) arglist) : \
(bfd_assert (__FILE__,__LINE__), NULL))
#endif
@end example
This is the structure which defines the type of BFD this is. The
@code{xvec} member of the struct @code{bfd} itself points here. Each
module that implements access to a different target under BFD,
defines one of these.
 
FIXME, these names should be rationalised with the names of
the entry points which call them. Too bad we can't have one
macro to define them both!
@example
enum bfd_flavour @{
bfd_target_unknown_flavour,
bfd_target_aout_flavour,
bfd_target_coff_flavour,
bfd_target_ecoff_flavour,
bfd_target_elf_flavour,
bfd_target_ieee_flavour,
bfd_target_nlm_flavour,
bfd_target_oasys_flavour,
bfd_target_tekhex_flavour,
bfd_target_srec_flavour,
bfd_target_ihex_flavour,
bfd_target_som_flavour,
bfd_target_os9k_flavour,
bfd_target_versados_flavour,
bfd_target_msdos_flavour,
bfd_target_ovax_flavour,
bfd_target_evax_flavour
@};
 
enum bfd_endian @{ BFD_ENDIAN_BIG, BFD_ENDIAN_LITTLE, BFD_ENDIAN_UNKNOWN @};
 
/* Forward declaration. */
typedef struct bfd_link_info _bfd_link_info;
 
typedef struct bfd_target
@{
@end example
Identifies the kind of target, e.g., SunOS4, Ultrix, etc.
@example
char *name;
@end example
The "flavour" of a back end is a general indication about the contents
of a file.
@example
enum bfd_flavour flavour;
@end example
The order of bytes within the data area of a file.
@example
enum bfd_endian byteorder;
@end example
The order of bytes within the header parts of a file.
@example
enum bfd_endian header_byteorder;
@end example
A mask of all the flags which an executable may have set -
from the set @code{BFD_NO_FLAGS}, @code{HAS_RELOC}, ...@code{D_PAGED}.
@example
flagword object_flags;
@end example
A mask of all the flags which a section may have set - from
the set @code{SEC_NO_FLAGS}, @code{SEC_ALLOC}, ...@code{SET_NEVER_LOAD}.
@example
flagword section_flags;
@end example
The character normally found at the front of a symbol
(if any), perhaps `_'.
@example
char symbol_leading_char;
@end example
The pad character for file names within an archive header.
@example
char ar_pad_char;
@end example
The maximum number of characters in an archive header.
@example
unsigned short ar_max_namelen;
@end example
Entries for byte swapping for data. These are different from the other
entry points, since they don't take a BFD asthe first argument.
Certain other handlers could do the same.
@example
bfd_vma (*bfd_getx64) PARAMS ((const bfd_byte *));
bfd_signed_vma (*bfd_getx_signed_64) PARAMS ((const bfd_byte *));
void (*bfd_putx64) PARAMS ((bfd_vma, bfd_byte *));
bfd_vma (*bfd_getx32) PARAMS ((const bfd_byte *));
bfd_signed_vma (*bfd_getx_signed_32) PARAMS ((const bfd_byte *));
void (*bfd_putx32) PARAMS ((bfd_vma, bfd_byte *));
bfd_vma (*bfd_getx16) PARAMS ((const bfd_byte *));
bfd_signed_vma (*bfd_getx_signed_16) PARAMS ((const bfd_byte *));
void (*bfd_putx16) PARAMS ((bfd_vma, bfd_byte *));
@end example
Byte swapping for the headers
@example
bfd_vma (*bfd_h_getx64) PARAMS ((const bfd_byte *));
bfd_signed_vma (*bfd_h_getx_signed_64) PARAMS ((const bfd_byte *));
void (*bfd_h_putx64) PARAMS ((bfd_vma, bfd_byte *));
bfd_vma (*bfd_h_getx32) PARAMS ((const bfd_byte *));
bfd_signed_vma (*bfd_h_getx_signed_32) PARAMS ((const bfd_byte *));
void (*bfd_h_putx32) PARAMS ((bfd_vma, bfd_byte *));
bfd_vma (*bfd_h_getx16) PARAMS ((const bfd_byte *));
bfd_signed_vma (*bfd_h_getx_signed_16) PARAMS ((const bfd_byte *));
void (*bfd_h_putx16) PARAMS ((bfd_vma, bfd_byte *));
@end example
Format dependent routines: these are vectors of entry points
within the target vector structure, one for each format to check.
 
Check the format of a file being read. Return a @code{bfd_target *} or zero.
@example
const struct bfd_target *(*_bfd_check_format[bfd_type_end]) PARAMS ((bfd *));
@end example
Set the format of a file being written.
@example
boolean (*_bfd_set_format[bfd_type_end]) PARAMS ((bfd *));
@end example
Write cached information into a file being written, at @code{bfd_close}.
@example
boolean (*_bfd_write_contents[bfd_type_end]) PARAMS ((bfd *));
@end example
The general target vector. These vectors are initialized using the
BFD_JUMP_TABLE macros.
@example
 
/* Generic entry points. */
#define BFD_JUMP_TABLE_GENERIC(NAME)\
CAT(NAME,_close_and_cleanup),\
CAT(NAME,_bfd_free_cached_info),\
CAT(NAME,_new_section_hook),\
CAT(NAME,_get_section_contents),\
CAT(NAME,_get_section_contents_in_window)
 
/* Called when the BFD is being closed to do any necessary cleanup. */
boolean (*_close_and_cleanup) PARAMS ((bfd *));
/* Ask the BFD to free all cached information. */
boolean (*_bfd_free_cached_info) PARAMS ((bfd *));
/* Called when a new section is created. */
boolean (*_new_section_hook) PARAMS ((bfd *, sec_ptr));
/* Read the contents of a section. */
boolean (*_bfd_get_section_contents) PARAMS ((bfd *, sec_ptr, PTR,
file_ptr, bfd_size_type));
boolean (*_bfd_get_section_contents_in_window)
PARAMS ((bfd *, sec_ptr, bfd_window *,
file_ptr, bfd_size_type));
 
/* Entry points to copy private data. */
#define BFD_JUMP_TABLE_COPY(NAME)\
CAT(NAME,_bfd_copy_private_bfd_data),\
CAT(NAME,_bfd_merge_private_bfd_data),\
CAT(NAME,_bfd_copy_private_section_data),\
CAT(NAME,_bfd_copy_private_symbol_data),\
CAT(NAME,_bfd_set_private_flags),\
CAT(NAME,_bfd_print_private_bfd_data)\
/* Called to copy BFD general private data from one object file
to another. */
boolean (*_bfd_copy_private_bfd_data) PARAMS ((bfd *, bfd *));
/* Called to merge BFD general private data from one object file
to a common output file when linking. */
boolean (*_bfd_merge_private_bfd_data) PARAMS ((bfd *, bfd *));
/* Called to copy BFD private section data from one object file
to another. */
boolean (*_bfd_copy_private_section_data) PARAMS ((bfd *, sec_ptr,
bfd *, sec_ptr));
/* Called to copy BFD private symbol data from one symbol
to another. */
boolean (*_bfd_copy_private_symbol_data) PARAMS ((bfd *, asymbol *,
bfd *, asymbol *));
/* Called to set private backend flags */
boolean (*_bfd_set_private_flags) PARAMS ((bfd *, flagword));
 
/* Called to print private BFD data */
boolean (*_bfd_print_private_bfd_data) PARAMS ((bfd *, PTR));
 
/* Core file entry points. */
#define BFD_JUMP_TABLE_CORE(NAME)\
CAT(NAME,_core_file_failing_command),\
CAT(NAME,_core_file_failing_signal),\
CAT(NAME,_core_file_matches_executable_p)
char * (*_core_file_failing_command) PARAMS ((bfd *));
int (*_core_file_failing_signal) PARAMS ((bfd *));
boolean (*_core_file_matches_executable_p) PARAMS ((bfd *, bfd *));
 
/* Archive entry points. */
#define BFD_JUMP_TABLE_ARCHIVE(NAME)\
CAT(NAME,_slurp_armap),\
CAT(NAME,_slurp_extended_name_table),\
CAT(NAME,_construct_extended_name_table),\
CAT(NAME,_truncate_arname),\
CAT(NAME,_write_armap),\
CAT(NAME,_read_ar_hdr),\
CAT(NAME,_openr_next_archived_file),\
CAT(NAME,_get_elt_at_index),\
CAT(NAME,_generic_stat_arch_elt),\
CAT(NAME,_update_armap_timestamp)
boolean (*_bfd_slurp_armap) PARAMS ((bfd *));
boolean (*_bfd_slurp_extended_name_table) PARAMS ((bfd *));
boolean (*_bfd_construct_extended_name_table)
PARAMS ((bfd *, char **, bfd_size_type *, const char **));
void (*_bfd_truncate_arname) PARAMS ((bfd *, CONST char *, char *));
boolean (*write_armap) PARAMS ((bfd *arch,
unsigned int elength,
struct orl *map,
unsigned int orl_count,
int stridx));
PTR (*_bfd_read_ar_hdr_fn) PARAMS ((bfd *));
bfd * (*openr_next_archived_file) PARAMS ((bfd *arch, bfd *prev));
#define bfd_get_elt_at_index(b,i) BFD_SEND(b, _bfd_get_elt_at_index, (b,i))
bfd * (*_bfd_get_elt_at_index) PARAMS ((bfd *, symindex));
int (*_bfd_stat_arch_elt) PARAMS ((bfd *, struct stat *));
boolean (*_bfd_update_armap_timestamp) PARAMS ((bfd *));
 
/* Entry points used for symbols. */
#define BFD_JUMP_TABLE_SYMBOLS(NAME)\
CAT(NAME,_get_symtab_upper_bound),\
CAT(NAME,_get_symtab),\
CAT(NAME,_make_empty_symbol),\
CAT(NAME,_print_symbol),\
CAT(NAME,_get_symbol_info),\
CAT(NAME,_bfd_is_local_label_name),\
CAT(NAME,_get_lineno),\
CAT(NAME,_find_nearest_line),\
CAT(NAME,_bfd_make_debug_symbol),\
CAT(NAME,_read_minisymbols),\
CAT(NAME,_minisymbol_to_symbol)
long (*_bfd_get_symtab_upper_bound) PARAMS ((bfd *));
long (*_bfd_canonicalize_symtab) PARAMS ((bfd *,
struct symbol_cache_entry **));
struct symbol_cache_entry *
(*_bfd_make_empty_symbol) PARAMS ((bfd *));
void (*_bfd_print_symbol) PARAMS ((bfd *, PTR,
struct symbol_cache_entry *,
bfd_print_symbol_type));
#define bfd_print_symbol(b,p,s,e) BFD_SEND(b, _bfd_print_symbol, (b,p,s,e))
void (*_bfd_get_symbol_info) PARAMS ((bfd *,
struct symbol_cache_entry *,
symbol_info *));
#define bfd_get_symbol_info(b,p,e) BFD_SEND(b, _bfd_get_symbol_info, (b,p,e))
boolean (*_bfd_is_local_label_name) PARAMS ((bfd *, const char *));
 
alent * (*_get_lineno) PARAMS ((bfd *, struct symbol_cache_entry *));
boolean (*_bfd_find_nearest_line) PARAMS ((bfd *abfd,
struct sec *section, struct symbol_cache_entry **symbols,
bfd_vma offset, CONST char **file, CONST char **func,
unsigned int *line));
/* Back-door to allow format-aware applications to create debug symbols
while using BFD for everything else. Currently used by the assembler
when creating COFF files. */
asymbol * (*_bfd_make_debug_symbol) PARAMS ((
bfd *abfd,
void *ptr,
unsigned long size));
#define bfd_read_minisymbols(b, d, m, s) \
BFD_SEND (b, _read_minisymbols, (b, d, m, s))
long (*_read_minisymbols) PARAMS ((bfd *, boolean, PTR *,
unsigned int *));
#define bfd_minisymbol_to_symbol(b, d, m, f) \
BFD_SEND (b, _minisymbol_to_symbol, (b, d, m, f))
asymbol *(*_minisymbol_to_symbol) PARAMS ((bfd *, boolean, const PTR,
asymbol *));
 
/* Routines for relocs. */
#define BFD_JUMP_TABLE_RELOCS(NAME)\
CAT(NAME,_get_reloc_upper_bound),\
CAT(NAME,_canonicalize_reloc),\
CAT(NAME,_bfd_reloc_type_lookup)
long (*_get_reloc_upper_bound) PARAMS ((bfd *, sec_ptr));
long (*_bfd_canonicalize_reloc) PARAMS ((bfd *, sec_ptr, arelent **,
struct symbol_cache_entry **));
/* See documentation on reloc types. */
reloc_howto_type *
(*reloc_type_lookup) PARAMS ((bfd *abfd,
bfd_reloc_code_real_type code));
 
/* Routines used when writing an object file. */
#define BFD_JUMP_TABLE_WRITE(NAME)\
CAT(NAME,_set_arch_mach),\
CAT(NAME,_set_section_contents)
boolean (*_bfd_set_arch_mach) PARAMS ((bfd *, enum bfd_architecture,
unsigned long));
boolean (*_bfd_set_section_contents) PARAMS ((bfd *, sec_ptr, PTR,
file_ptr, bfd_size_type));
 
/* Routines used by the linker. */
#define BFD_JUMP_TABLE_LINK(NAME)\
CAT(NAME,_sizeof_headers),\
CAT(NAME,_bfd_get_relocated_section_contents),\
CAT(NAME,_bfd_relax_section),\
CAT(NAME,_bfd_link_hash_table_create),\
CAT(NAME,_bfd_link_add_symbols),\
CAT(NAME,_bfd_final_link),\
CAT(NAME,_bfd_link_split_section),\
CAT(NAME,_bfd_gc_sections)
int (*_bfd_sizeof_headers) PARAMS ((bfd *, boolean));
bfd_byte * (*_bfd_get_relocated_section_contents) PARAMS ((bfd *,
struct bfd_link_info *, struct bfd_link_order *,
bfd_byte *data, boolean relocateable,
struct symbol_cache_entry **));
 
boolean (*_bfd_relax_section) PARAMS ((bfd *, struct sec *,
struct bfd_link_info *, boolean *again));
 
/* Create a hash table for the linker. Different backends store
different information in this table. */
struct bfd_link_hash_table *(*_bfd_link_hash_table_create) PARAMS ((bfd *));
 
/* Add symbols from this object file into the hash table. */
boolean (*_bfd_link_add_symbols) PARAMS ((bfd *, struct bfd_link_info *));
 
/* Do a link based on the link_order structures attached to each
section of the BFD. */
boolean (*_bfd_final_link) PARAMS ((bfd *, struct bfd_link_info *));
 
/* Should this section be split up into smaller pieces during linking. */
boolean (*_bfd_link_split_section) PARAMS ((bfd *, struct sec *));
 
/* Remove sections that are not referenced from the output. */
boolean (*_bfd_gc_sections) PARAMS ((bfd *, struct bfd_link_info *));
 
/* Routines to handle dynamic symbols and relocs. */
#define BFD_JUMP_TABLE_DYNAMIC(NAME)\
CAT(NAME,_get_dynamic_symtab_upper_bound),\
CAT(NAME,_canonicalize_dynamic_symtab),\
CAT(NAME,_get_dynamic_reloc_upper_bound),\
CAT(NAME,_canonicalize_dynamic_reloc)
/* Get the amount of memory required to hold the dynamic symbols. */
long (*_bfd_get_dynamic_symtab_upper_bound) PARAMS ((bfd *));
/* Read in the dynamic symbols. */
long (*_bfd_canonicalize_dynamic_symtab)
PARAMS ((bfd *, struct symbol_cache_entry **));
/* Get the amount of memory required to hold the dynamic relocs. */
long (*_bfd_get_dynamic_reloc_upper_bound) PARAMS ((bfd *));
/* Read in the dynamic relocs. */
long (*_bfd_canonicalize_dynamic_reloc)
PARAMS ((bfd *, arelent **, struct symbol_cache_entry **));
 
@end example
A pointer to an alternative bfd_target in case the current one is not
satisfactory. This can happen when the target cpu supports both big
and little endian code, and target chosen by the linker has the wrong
endianness. The function open_output() in ld/ldlang.c uses this field
to find an alternative output format that is suitable.
@example
/* Opposite endian version of this target. */
const struct bfd_target * alternative_target;
@end example
Data for use by back-end routines, which isn't generic enough to belong
in this structure.
@example
PTR backend_data;
@} bfd_target;
@end example
 
@findex bfd_set_default_target
@subsubsection @code{bfd_set_default_target}
@strong{Synopsis}
@example
boolean bfd_set_default_target (const char *name);
@end example
@strong{Description}@*
Set the default target vector to use when recognizing a BFD.
This takes the name of the target, which may be a BFD target
name or a configuration triplet.
 
@findex bfd_find_target
@subsubsection @code{bfd_find_target}
@strong{Synopsis}
@example
const bfd_target *bfd_find_target(CONST char *target_name, bfd *abfd);
@end example
@strong{Description}@*
Return a pointer to the transfer vector for the object target
named @var{target_name}. If @var{target_name} is @code{NULL}, choose the
one in the environment variable @code{GNUTARGET}; if that is null or not
defined, then choose the first entry in the target list.
Passing in the string "default" or setting the environment
variable to "default" will cause the first entry in the target
list to be returned, and "target_defaulted" will be set in the
BFD. This causes @code{bfd_check_format} to loop over all the
targets to find the one that matches the file being read.
 
@findex bfd_target_list
@subsubsection @code{bfd_target_list}
@strong{Synopsis}
@example
const char **bfd_target_list(void);
@end example
@strong{Description}@*
Return a freshly malloced NULL-terminated
vector of the names of all the valid BFD targets. Do not
modify the names.
 
@findex bfd_seach_for_target
@subsubsection @code{bfd_seach_for_target}
@strong{Synopsis}
@example
const bfd_target * bfd_search_for_target (int (* search_func)(const bfd_target *, void *), void *);
@end example
@strong{Description}@*
Return a pointer to the first transfer vector in the list of
transfer vectors maintained by BFD that produces a non-zero
result when passed to the function @var{search_func}. The
parameter @var{data} is passed, unexamined, to the search
function.
 
/makefile.vms
0,0 → 1,5
CFLAGS = /noopt/include=([],[-],[-.-.include])
LDFLAGS = /nomap
LDLIBS = ,sys$$library:vaxcrtl.olb/lib
 
all: chew.exe
/targets.pdf Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream
/targets.pdf
targets.pdf Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: bfd.info-1 =================================================================== --- bfd.info-1 (nonexistent) +++ bfd.info-1 (revision 1765) @@ -0,0 +1,1017 @@ +This is bfd.info, produced by Makeinfo version 3.12f from bfd.texinfo. + +START-INFO-DIR-ENTRY +* Bfd: (bfd). The Binary File Descriptor library. +END-INFO-DIR-ENTRY + + This file documents the BFD library. + + Copyright (C) 1991 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, subject to the +terms of the GNU General Public License, which includes the provision +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: bfd.info, Node: Top, Next: Overview, Prev: (dir), Up: (dir) + + This file documents the binary file descriptor library libbfd. + +* Menu: + +* Overview:: Overview of BFD +* BFD front end:: BFD front end +* BFD back ends:: BFD back ends +* Index:: Index + + +File: bfd.info, Node: Overview, Next: BFD front end, Prev: Top, Up: Top + +Introduction +************ + + BFD is a package which allows applications to use the same routines +to operate on object files whatever the object file format. A new +object file format can be supported simply by creating a new BFD back +end and adding it to the library. + + BFD is split into two parts: the front end, and the back ends (one +for each object file format). + * The front end of BFD provides the interface to the user. It manages + memory and various canonical data structures. The front end also + decides which back end to use and when to call back end routines. + + * The back ends provide BFD its view of the real world. Each back + end provides a set of calls which the BFD front end can use to + maintain its canonical form. The back ends also may keep around + information for their own use, for greater efficiency. + +* Menu: + +* History:: History +* How It Works:: How It Works +* What BFD Version 2 Can Do:: What BFD Version 2 Can Do + + +File: bfd.info, Node: History, Next: How It Works, Prev: Overview, Up: Overview + +History +======= + + One spur behind BFD was the desire, on the part of the GNU 960 team +at Intel Oregon, for interoperability of applications on their COFF and +b.out file formats. Cygnus was providing GNU support for the team, and +was contracted to provide the required functionality. + + The name came from a conversation David Wallace was having with +Richard Stallman about the library: RMS said that it would be quite +hard--David said "BFD". Stallman was right, but the name stuck. + + At the same time, Ready Systems wanted much the same thing, but for +different object file formats: IEEE-695, Oasys, Srecords, a.out and 68k +coff. + + BFD was first implemented by members of Cygnus Support; Steve +Chamberlain (`sac@cygnus.com'), John Gilmore (`gnu@cygnus.com'), K. +Richard Pixley (`rich@cygnus.com') and David Henkel-Wallace +(`gumby@cygnus.com'). + + +File: bfd.info, Node: How It Works, Next: What BFD Version 2 Can Do, Prev: History, Up: Overview + +How To Use BFD +============== + + To use the library, include `bfd.h' and link with `libbfd.a'. + + BFD provides a common interface to the parts of an object file for a +calling application. + + When an application sucessfully opens a target file (object, +archive, or whatever), a pointer to an internal structure is returned. +This pointer points to a structure called `bfd', described in `bfd.h'. +Our convention is to call this pointer a BFD, and instances of it +within code `abfd'. All operations on the target object file are +applied as methods to the BFD. The mapping is defined within `bfd.h' +in a set of macros, all beginning with `bfd_' to reduce namespace +pollution. + + For example, this sequence does what you would probably expect: +return the number of sections in an object file attached to a BFD +`abfd'. + + #include "bfd.h" + + unsigned int number_of_sections(abfd) + bfd *abfd; + { + return bfd_count_sections(abfd); + } + + The abstraction used within BFD is that an object file has: + + * a header, + + * a number of sections containing raw data (*note Sections::.), + + * a set of relocations (*note Relocations::.), and + + * some symbol information (*note Symbols::.). + +Also, BFDs opened for archives have the additional attribute of an index +and contain subordinate BFDs. This approach is fine for a.out and coff, +but loses efficiency when applied to formats such as S-records and +IEEE-695. + + +File: bfd.info, Node: What BFD Version 2 Can Do, Prev: How It Works, Up: Overview + +What BFD Version 2 Can Do +========================= + + When an object file is opened, BFD subroutines automatically +determine the format of the input object file. They then build a +descriptor in memory with pointers to routines that will be used to +access elements of the object file's data structures. + + As different information from the the object files is required, BFD +reads from different sections of the file and processes them. For +example, a very common operation for the linker is processing symbol +tables. Each BFD back end provides a routine for converting between +the object file's representation of symbols and an internal canonical +format. When the linker asks for the symbol table of an object file, it +calls through a memory pointer to the routine from the relevant BFD +back end which reads and converts the table into a canonical form. The +linker then operates upon the canonical form. When the link is finished +and the linker writes the output file's symbol table, another BFD back +end routine is called to take the newly created symbol table and +convert it into the chosen output format. + +* Menu: + +* BFD information loss:: Information Loss +* Canonical format:: The BFD canonical object-file format + + +File: bfd.info, Node: BFD information loss, Next: Canonical format, Up: What BFD Version 2 Can Do + +Information Loss +---------------- + + _Information can be lost during output._ The output formats +supported by BFD do not provide identical facilities, and information +which can be described in one form has nowhere to go in another format. +One example of this is alignment information in `b.out'. There is +nowhere in an `a.out' format file to store alignment information on the +contained data, so when a file is linked from `b.out' and an `a.out' +image is produced, alignment information will not propagate to the +output file. (The linker will still use the alignment information +internally, so the link is performed correctly). + + Another example is COFF section names. COFF files may contain an +unlimited number of sections, each one with a textual section name. If +the target of the link is a format which does not have many sections +(e.g., `a.out') or has sections without names (e.g., the Oasys format), +the link cannot be done simply. You can circumvent this problem by +describing the desired input-to-output section mapping with the linker +command language. + + _Information can be lost during canonicalization._ The BFD internal +canonical form of the external formats is not exhaustive; there are +structures in input formats for which there is no direct representation +internally. This means that the BFD back ends cannot maintain all +possible data richness through the transformation between external to +internal and back to external formats. + + This limitation is only a problem when an application reads one +format and writes another. Each BFD back end is responsible for +maintaining as much data as possible, and the internal BFD canonical +form has structures which are opaque to the BFD core, and exported only +to the back ends. When a file is read in one format, the canonical form +is generated for BFD and the application. At the same time, the back +end saves away any information which may otherwise be lost. If the data +is then written back in the same format, the back end routine will be +able to use the canonical form provided by the BFD core as well as the +information it prepared earlier. Since there is a great deal of +commonality between back ends, there is no information lost when +linking or copying big endian COFF to little endian COFF, or `a.out' to +`b.out'. When a mixture of formats is linked, the information is only +lost from the files whose format differs from the destination. + + +File: bfd.info, Node: Canonical format, Prev: BFD information loss, Up: What BFD Version 2 Can Do + +The BFD canonical object-file format +------------------------------------ + + The greatest potential for loss of information occurs when there is +the least overlap between the information provided by the source +format, that stored by the canonical format, and that needed by the +destination format. A brief description of the canonical form may help +you understand which kinds of data you can count on preserving across +conversions. + +_files_ + Information stored on a per-file basis includes target machine + architecture, particular implementation format type, a demand + pageable bit, and a write protected bit. Information like Unix + magic numbers is not stored here--only the magic numbers' meaning, + so a `ZMAGIC' file would have both the demand pageable bit and the + write protected text bit set. The byte order of the target is + stored on a per-file basis, so that big- and little-endian object + files may be used with one another. + +_sections_ + Each section in the input file contains the name of the section, + the section's original address in the object file, size and + alignment information, various flags, and pointers into other BFD + data structures. + +_symbols_ + Each symbol contains a pointer to the information for the object + file which originally defined it, its name, its value, and various + flag bits. When a BFD back end reads in a symbol table, it + relocates all symbols to make them relative to the base of the + section where they were defined. Doing this ensures that each + symbol points to its containing section. Each symbol also has a + varying amount of hidden private data for the BFD back end. Since + the symbol points to the original file, the private data format + for that symbol is accessible. `ld' can operate on a collection + of symbols of wildly different formats without problems. + + Normal global and simple local symbols are maintained on output, + so an output file (no matter its format) will retain symbols + pointing to functions and to global, static, and common variables. + Some symbol information is not worth retaining; in `a.out', type + information is stored in the symbol table as long symbol names. + This information would be useless to most COFF debuggers; the + linker has command line switches to allow users to throw it away. + + There is one word of type information within the symbol, so if the + format supports symbol type information within symbols (for + example, COFF, IEEE, Oasys) and the type is simple enough to fit + within one word (nearly everything but aggregates), the + information will be preserved. + +_relocation level_ + Each canonical BFD relocation record contains a pointer to the + symbol to relocate to, the offset of the data to relocate, the + section the data is in, and a pointer to a relocation type + descriptor. Relocation is performed by passing messages through + the relocation type descriptor and the symbol pointer. Therefore, + relocations can be performed on output data using a relocation + method that is only available in one of the input formats. For + instance, Oasys provides a byte relocation format. A relocation + record requesting this relocation type would point indirectly to a + routine to perform this, so the relocation may be performed on a + byte being written to a 68k COFF file, even though 68k COFF has no + such relocation type. + +_line numbers_ + Object formats can contain, for debugging purposes, some form of + mapping between symbols, source line numbers, and addresses in the + output file. These addresses have to be relocated along with the + symbol information. Each symbol with an associated list of line + number records points to the first record of the list. The head + of a line number list consists of a pointer to the symbol, which + allows finding out the address of the function whose line number + is being described. The rest of the list is made up of pairs: + offsets into the section and line numbers. Any format which can + simply derive this information can pass it successfully between + formats (COFF, IEEE and Oasys). + + +File: bfd.info, Node: BFD front end, Next: BFD back ends, Prev: Overview, Up: Top + +BFD front end +************* + +`typedef bfd' +============= + + A BFD has type `bfd'; objects of this type are the cornerstone of +any application using BFD. Using BFD consists of making references +though the BFD and to data in the BFD. + + Here is the structure that defines the type `bfd'. It contains the +major data about the file and pointers to the rest of the data. + + + struct _bfd + { + /* The filename the application opened the BFD with. */ + CONST char *filename; + + /* A pointer to the target jump table. */ + const struct bfd_target *xvec; + + /* To avoid dragging too many header files into every file that + includes ``bfd.h'', IOSTREAM has been declared as a "char + *", and MTIME as a "long". Their correct types, to which they + are cast when used, are "FILE *" and "time_t". The iostream + is the result of an fopen on the filename. However, if the + BFD_IN_MEMORY flag is set, then iostream is actually a pointer + to a bfd_in_memory struct. */ + PTR iostream; + + /* Is the file descriptor being cached? That is, can it be closed as + needed, and re-opened when accessed later? */ + + boolean cacheable; + + /* Marks whether there was a default target specified when the + BFD was opened. This is used to select which matching algorithm + to use to choose the back end. */ + + boolean target_defaulted; + + /* The caching routines use these to maintain a + least-recently-used list of BFDs */ + + struct _bfd *lru_prev, *lru_next; + + /* When a file is closed by the caching routines, BFD retains + state information on the file here: */ + + file_ptr where; + + /* and here: (``once'' means at least once) */ + + boolean opened_once; + + /* Set if we have a locally maintained mtime value, rather than + getting it from the file each time: */ + + boolean mtime_set; + + /* File modified time, if mtime_set is true: */ + + long mtime; + + /* Reserved for an unimplemented file locking extension.*/ + + int ifd; + + /* The format which belongs to the BFD. (object, core, etc.) */ + + bfd_format format; + + /* The direction the BFD was opened with*/ + + enum bfd_direction {no_direction = 0, + read_direction = 1, + write_direction = 2, + both_direction = 3} direction; + + /* Format_specific flags*/ + + flagword flags; + + /* Currently my_archive is tested before adding origin to + anything. I believe that this can become always an add of + origin, with origin set to 0 for non archive files. */ + + file_ptr origin; + + /* Remember when output has begun, to stop strange things + from happening. */ + boolean output_has_begun; + + /* Pointer to linked list of sections*/ + struct sec *sections; + + /* The number of sections */ + unsigned int section_count; + + /* Stuff only useful for object files: + The start address. */ + bfd_vma start_address; + + /* Used for input and output*/ + unsigned int symcount; + + /* Symbol table for output BFD (with symcount entries) */ + struct symbol_cache_entry **outsymbols; + + /* Pointer to structure which contains architecture information*/ + const struct bfd_arch_info *arch_info; + + /* Stuff only useful for archives:*/ + PTR arelt_data; + struct _bfd *my_archive; /* The containing archive BFD. */ + struct _bfd *next; /* The next BFD in the archive. */ + struct _bfd *archive_head; /* The first BFD in the archive. */ + boolean has_armap; + + /* A chain of BFD structures involved in a link. */ + struct _bfd *link_next; + + /* A field used by _bfd_generic_link_add_archive_symbols. This will + be used only for archive elements. */ + int archive_pass; + + /* Used by the back end to hold private data. */ + + union + { + struct aout_data_struct *aout_data; + struct artdata *aout_ar_data; + struct _oasys_data *oasys_obj_data; + struct _oasys_ar_data *oasys_ar_data; + struct coff_tdata *coff_obj_data; + struct pe_tdata *pe_obj_data; + struct xcoff_tdata *xcoff_obj_data; + struct ecoff_tdata *ecoff_obj_data; + struct ieee_data_struct *ieee_data; + struct ieee_ar_data_struct *ieee_ar_data; + struct srec_data_struct *srec_data; + struct ihex_data_struct *ihex_data; + struct tekhex_data_struct *tekhex_data; + struct elf_obj_tdata *elf_obj_data; + struct nlm_obj_tdata *nlm_obj_data; + struct bout_data_struct *bout_data; + struct sun_core_struct *sun_core_data; + struct sco5_core_struct *sco5_core_data; + struct trad_core_struct *trad_core_data; + struct som_data_struct *som_data; + struct hpux_core_struct *hpux_core_data; + struct hppabsd_core_struct *hppabsd_core_data; + struct sgi_core_struct *sgi_core_data; + struct lynx_core_struct *lynx_core_data; + struct osf_core_struct *osf_core_data; + struct cisco_core_struct *cisco_core_data; + struct versados_data_struct *versados_data; + struct netbsd_core_struct *netbsd_core_data; + PTR any; + } tdata; + + /* Used by the application to hold private data*/ + PTR usrdata; + + /* Where all the allocated stuff under this BFD goes. This is a + struct objalloc *, but we use PTR to avoid requiring the inclusion of + objalloc.h. */ + PTR memory; + }; + +Error reporting +=============== + + Most BFD functions return nonzero on success (check their individual +documentation for precise semantics). On an error, they call +`bfd_set_error' to set an error condition that callers can check by +calling `bfd_get_error'. If that returns `bfd_error_system_call', then +check `errno'. + + The easiest way to report a BFD error to the user is to use +`bfd_perror'. + +Type `bfd_error_type' +--------------------- + + The values returned by `bfd_get_error' are defined by the enumerated +type `bfd_error_type'. + + + typedef enum bfd_error + { + bfd_error_no_error = 0, + bfd_error_system_call, + bfd_error_invalid_target, + bfd_error_wrong_format, + bfd_error_invalid_operation, + bfd_error_no_memory, + bfd_error_no_symbols, + bfd_error_no_armap, + bfd_error_no_more_archived_files, + bfd_error_malformed_archive, + bfd_error_file_not_recognized, + bfd_error_file_ambiguously_recognized, + bfd_error_no_contents, + bfd_error_nonrepresentable_section, + bfd_error_no_debug_section, + bfd_error_bad_value, + bfd_error_file_truncated, + bfd_error_file_too_big, + bfd_error_invalid_error_code + } bfd_error_type; + +`bfd_get_error' +............... + + *Synopsis* + bfd_error_type bfd_get_error (void); + *Description* +Return the current BFD error condition. + +`bfd_set_error' +............... + + *Synopsis* + void bfd_set_error (bfd_error_type error_tag); + *Description* +Set the BFD error condition to be ERROR_TAG. + +`bfd_errmsg' +............ + + *Synopsis* + CONST char *bfd_errmsg (bfd_error_type error_tag); + *Description* +Return a string describing the error ERROR_TAG, or the system error if +ERROR_TAG is `bfd_error_system_call'. + +`bfd_perror' +............ + + *Synopsis* + void bfd_perror (CONST char *message); + *Description* +Print to the standard error stream a string describing the last BFD +error that occurred, or the last system error if the last BFD error was +a system call failure. If MESSAGE is non-NULL and non-empty, the error +string printed is preceded by MESSAGE, a colon, and a space. It is +followed by a newline. + +BFD error handler +----------------- + + Some BFD functions want to print messages describing the problem. +They call a BFD error handler function. This function may be overriden +by the program. + + The BFD error handler acts like printf. + + + typedef void (*bfd_error_handler_type) PARAMS ((const char *, ...)); + +`bfd_set_error_handler' +....................... + + *Synopsis* + bfd_error_handler_type bfd_set_error_handler (bfd_error_handler_type); + *Description* +Set the BFD error handler function. Returns the previous function. + +`bfd_set_error_program_name' +............................ + + *Synopsis* + void bfd_set_error_program_name (const char *); + *Description* +Set the program name to use when printing a BFD error. This is printed +before the error message followed by a colon and space. The string +must not be changed after it is passed to this function. + +`bfd_get_error_handler' +....................... + + *Synopsis* + bfd_error_handler_type bfd_get_error_handler (void); + *Description* +Return the BFD error handler function. + +Symbols +======= + +`bfd_get_reloc_upper_bound' +........................... + + *Synopsis* + long bfd_get_reloc_upper_bound(bfd *abfd, asection *sect); + *Description* +Return the number of bytes required to store the relocation information +associated with section SECT attached to bfd ABFD. If an error occurs, +return -1. + +`bfd_canonicalize_reloc' +........................ + + *Synopsis* + long bfd_canonicalize_reloc + (bfd *abfd, + asection *sec, + arelent **loc, + asymbol **syms); + *Description* +Call the back end associated with the open BFD ABFD and translate the +external form of the relocation information attached to SEC into the +internal canonical form. Place the table into memory at LOC, which has +been preallocated, usually by a call to `bfd_get_reloc_upper_bound'. +Returns the number of relocs, or -1 on error. + + The SYMS table is also needed for horrible internal magic reasons. + +`bfd_set_reloc' +............... + + *Synopsis* + void bfd_set_reloc + (bfd *abfd, asection *sec, arelent **rel, unsigned int count) + *Description* +Set the relocation pointer and count within section SEC to the values +REL and COUNT. The argument ABFD is ignored. + +`bfd_set_file_flags' +.................... + + *Synopsis* + boolean bfd_set_file_flags(bfd *abfd, flagword flags); + *Description* +Set the flag word in the BFD ABFD to the value FLAGS. + + Possible errors are: + * `bfd_error_wrong_format' - The target bfd was not of object format. + + * `bfd_error_invalid_operation' - The target bfd was open for + reading. + + * `bfd_error_invalid_operation' - The flag word contained a bit + which was not applicable to the type of file. E.g., an attempt + was made to set the `D_PAGED' bit on a BFD format which does not + support demand paging. + +`bfd_set_start_address' +....................... + + *Synopsis* + boolean bfd_set_start_address(bfd *abfd, bfd_vma vma); + *Description* +Make VMA the entry point of output BFD ABFD. + + *Returns* +Returns `true' on success, `false' otherwise. + +`bfd_get_mtime' +............... + + *Synopsis* + long bfd_get_mtime(bfd *abfd); + *Description* +Return the file modification time (as read from the file system, or +from the archive header for archive members). + +`bfd_get_size' +.............. + + *Synopsis* + long bfd_get_size(bfd *abfd); + *Description* +Return the file size (as read from file system) for the file associated +with BFD ABFD. + + The initial motivation for, and use of, this routine is not so we +can get the exact size of the object the BFD applies to, since that +might not be generally possible (archive members for example). It +would be ideal if someone could eventually modify it so that such +results were guaranteed. + + Instead, we want to ask questions like "is this NNN byte sized +object I'm about to try read from file offset YYY reasonable?" As as +example of where we might do this, some object formats use string +tables for which the first `sizeof(long)' bytes of the table contain +the size of the table itself, including the size bytes. If an +application tries to read what it thinks is one of these string tables, +without some way to validate the size, and for some reason the size is +wrong (byte swapping error, wrong location for the string table, etc.), +the only clue is likely to be a read error when it tries to read the +table, or a "virtual memory exhausted" error when it tries to allocate +15 bazillon bytes of space for the 15 bazillon byte table it is about +to read. This function at least allows us to answer the quesion, "is +the size reasonable?". + +`bfd_get_gp_size' +................. + + *Synopsis* + int bfd_get_gp_size(bfd *abfd); + *Description* +Return the maximum size of objects to be optimized using the GP +register under MIPS ECOFF. This is typically set by the `-G' argument +to the compiler, assembler or linker. + +`bfd_set_gp_size' +................. + + *Synopsis* + void bfd_set_gp_size(bfd *abfd, int i); + *Description* +Set the maximum size of objects to be optimized using the GP register +under ECOFF or MIPS ELF. This is typically set by the `-G' argument to +the compiler, assembler or linker. + +`bfd_scan_vma' +.............. + + *Synopsis* + bfd_vma bfd_scan_vma(CONST char *string, CONST char **end, int base); + *Description* +Convert, like `strtoul', a numerical expression STRING into a `bfd_vma' +integer, and return that integer. (Though without as many bells and +whistles as `strtoul'.) The expression is assumed to be unsigned +(i.e., positive). If given a BASE, it is used as the base for +conversion. A base of 0 causes the function to interpret the string in +hex if a leading "0x" or "0X" is found, otherwise in octal if a leading +zero is found, otherwise in decimal. + + Overflow is not detected. + +`bfd_copy_private_bfd_data' +........................... + + *Synopsis* + boolean bfd_copy_private_bfd_data(bfd *ibfd, bfd *obfd); + *Description* +Copy private BFD information from the BFD IBFD to the the BFD OBFD. +Return `true' on success, `false' on error. Possible error returns are: + + * `bfd_error_no_memory' - Not enough memory exists to create private + data for OBFD. + + #define bfd_copy_private_bfd_data(ibfd, obfd) \ + BFD_SEND (obfd, _bfd_copy_private_bfd_data, \ + (ibfd, obfd)) + +`bfd_merge_private_bfd_data' +............................ + + *Synopsis* + boolean bfd_merge_private_bfd_data(bfd *ibfd, bfd *obfd); + *Description* +Merge private BFD information from the BFD IBFD to the the output file +BFD OBFD when linking. Return `true' on success, `false' on error. +Possible error returns are: + + * `bfd_error_no_memory' - Not enough memory exists to create private + data for OBFD. + + #define bfd_merge_private_bfd_data(ibfd, obfd) \ + BFD_SEND (obfd, _bfd_merge_private_bfd_data, \ + (ibfd, obfd)) + +`bfd_set_private_flags' +....................... + + *Synopsis* + boolean bfd_set_private_flags(bfd *abfd, flagword flags); + *Description* +Set private BFD flag information in the BFD ABFD. Return `true' on +success, `false' on error. Possible error returns are: + + * `bfd_error_no_memory' - Not enough memory exists to create private + data for OBFD. + + #define bfd_set_private_flags(abfd, flags) \ + BFD_SEND (abfd, _bfd_set_private_flags, \ + (abfd, flags)) + +`stuff' +....... + + *Description* +Stuff which should be documented: + #define bfd_sizeof_headers(abfd, reloc) \ + BFD_SEND (abfd, _bfd_sizeof_headers, (abfd, reloc)) + + #define bfd_find_nearest_line(abfd, sec, syms, off, file, func, line) \ + BFD_SEND (abfd, _bfd_find_nearest_line, (abfd, sec, syms, off, file, func, line)) + + /* Do these three do anything useful at all, for any back end? */ + #define bfd_debug_info_start(abfd) \ + BFD_SEND (abfd, _bfd_debug_info_start, (abfd)) + + #define bfd_debug_info_end(abfd) \ + BFD_SEND (abfd, _bfd_debug_info_end, (abfd)) + + #define bfd_debug_info_accumulate(abfd, section) \ + BFD_SEND (abfd, _bfd_debug_info_accumulate, (abfd, section)) + + + #define bfd_stat_arch_elt(abfd, stat) \ + BFD_SEND (abfd, _bfd_stat_arch_elt,(abfd, stat)) + + #define bfd_update_armap_timestamp(abfd) \ + BFD_SEND (abfd, _bfd_update_armap_timestamp, (abfd)) + + #define bfd_set_arch_mach(abfd, arch, mach)\ + BFD_SEND ( abfd, _bfd_set_arch_mach, (abfd, arch, mach)) + + #define bfd_relax_section(abfd, section, link_info, again) \ + BFD_SEND (abfd, _bfd_relax_section, (abfd, section, link_info, again)) + + #define bfd_gc_sections(abfd, link_info) \ + BFD_SEND (abfd, _bfd_gc_sections, (abfd, link_info)) + + #define bfd_link_hash_table_create(abfd) \ + BFD_SEND (abfd, _bfd_link_hash_table_create, (abfd)) + + #define bfd_link_add_symbols(abfd, info) \ + BFD_SEND (abfd, _bfd_link_add_symbols, (abfd, info)) + + #define bfd_final_link(abfd, info) \ + BFD_SEND (abfd, _bfd_final_link, (abfd, info)) + + #define bfd_free_cached_info(abfd) \ + BFD_SEND (abfd, _bfd_free_cached_info, (abfd)) + + #define bfd_get_dynamic_symtab_upper_bound(abfd) \ + BFD_SEND (abfd, _bfd_get_dynamic_symtab_upper_bound, (abfd)) + + #define bfd_print_private_bfd_data(abfd, file)\ + BFD_SEND (abfd, _bfd_print_private_bfd_data, (abfd, file)) + + #define bfd_canonicalize_dynamic_symtab(abfd, asymbols) \ + BFD_SEND (abfd, _bfd_canonicalize_dynamic_symtab, (abfd, asymbols)) + + #define bfd_get_dynamic_reloc_upper_bound(abfd) \ + BFD_SEND (abfd, _bfd_get_dynamic_reloc_upper_bound, (abfd)) + + #define bfd_canonicalize_dynamic_reloc(abfd, arels, asyms) \ + BFD_SEND (abfd, _bfd_canonicalize_dynamic_reloc, (abfd, arels, asyms)) + + extern bfd_byte *bfd_get_relocated_section_contents + PARAMS ((bfd *, struct bfd_link_info *, + struct bfd_link_order *, bfd_byte *, + boolean, asymbol **)); + +* Menu: + +* Memory Usage:: +* Initialization:: +* Sections:: +* Symbols:: +* Archives:: +* Formats:: +* Relocations:: +* Core Files:: +* Targets:: +* Architectures:: +* Opening and Closing:: +* Internal:: +* File Caching:: +* Linker Functions:: +* Hash Tables:: + + +File: bfd.info, Node: Memory Usage, Next: Initialization, Prev: BFD front end, Up: BFD front end + +Memory usage +============ + + BFD keeps all of its internal structures in obstacks. There is one +obstack per open BFD file, into which the current state is stored. When +a BFD is closed, the obstack is deleted, and so everything which has +been allocated by BFD for the closing file is thrown away. + + BFD does not free anything created by an application, but pointers +into `bfd' structures become invalid on a `bfd_close'; for example, +after a `bfd_close' the vector passed to `bfd_canonicalize_symtab' is +still around, since it has been allocated by the application, but the +data that it pointed to are lost. + + The general rule is to not close a BFD until all operations dependent +upon data from the BFD have been completed, or all the data from within +the file has been copied. To help with the management of memory, there +is a function (`bfd_alloc_size') which returns the number of bytes in +obstacks associated with the supplied BFD. This could be used to select +the greediest open BFD, close it to reclaim the memory, perform some +operation and reopen the BFD again, to get a fresh copy of the data +structures. + + +File: bfd.info, Node: Initialization, Next: Sections, Prev: Memory Usage, Up: BFD front end + +Initialization +============== + + These are the functions that handle initializing a BFD. + +`bfd_init' +.......... + + *Synopsis* + void bfd_init(void); + *Description* +This routine must be called before any other BFD function to initialize +magical internal data structures. + + +File: bfd.info, Node: Sections, Next: Symbols, Prev: Initialization, Up: BFD front end + +Sections +======== + + The raw data contained within a BFD is maintained through the +section abstraction. A single BFD may have any number of sections. It +keeps hold of them by pointing to the first; each one points to the +next in the list. + + Sections are supported in BFD in `section.c'. + +* Menu: + +* Section Input:: +* Section Output:: +* typedef asection:: +* section prototypes:: + + +File: bfd.info, Node: Section Input, Next: Section Output, Prev: Sections, Up: Sections + +Section input +------------- + + When a BFD is opened for reading, the section structures are created +and attached to the BFD. + + Each section has a name which describes the section in the outside +world--for example, `a.out' would contain at least three sections, +called `.text', `.data' and `.bss'. + + Names need not be unique; for example a COFF file may have several +sections named `.data'. + + Sometimes a BFD will contain more than the "natural" number of +sections. A back end may attach other sections containing constructor +data, or an application may add a section (using `bfd_make_section') to +the sections attached to an already open BFD. For example, the linker +creates an extra section `COMMON' for each input file's BFD to hold +information about common storage. + + The raw data is not necessarily read in when the section descriptor +is created. Some targets may leave the data in place until a +`bfd_get_section_contents' call is made. Other back ends may read in +all the data at once. For example, an S-record file has to be read +once to determine the size of the data. An IEEE-695 file doesn't +contain raw data in sections, but data and relocation expressions +intermixed, so the data area has to be parsed to get out the data and +relocations. + + +File: bfd.info, Node: Section Output, Next: typedef asection, Prev: Section Input, Up: Sections + +Section output +-------------- + + To write a new object style BFD, the various sections to be written +have to be created. They are attached to the BFD in the same way as +input sections; data is written to the sections using +`bfd_set_section_contents'. + + Any program that creates or combines sections (e.g., the assembler +and linker) must use the `asection' fields `output_section' and +`output_offset' to indicate the file sections to which each section +must be written. (If the section is being created from scratch, +`output_section' should probably point to the section itself and +`output_offset' should probably be zero.) + + The data to be written comes from input sections attached (via +`output_section' pointers) to the output sections. The output section +structure can be considered a filter for the input section: the output +section determines the vma of the output data and the name, but the +input section determines the offset into the output section of the data +to be written. + + E.g., to create a section "O", starting at 0x100, 0x123 long, +containing two subsections, "A" at offset 0x0 (i.e., at vma 0x100) and +"B" at offset 0x20 (i.e., at vma 0x120) the `asection' structures would +look like: + + section name "A" + output_offset 0x00 + size 0x20 + output_section -----------> section name "O" + | vma 0x100 + section name "B" | size 0x123 + output_offset 0x20 | + size 0x103 | + output_section --------| + +Link orders +----------- + + The data within a section is stored in a "link_order". These are +much like the fixups in `gas'. The link_order abstraction allows a +section to grow and shrink within itself. + + A link_order knows how big it is, and which is the next link_order +and where the raw data for it is; it also points to a list of +relocations which apply to it. + + The link_order is used by the linker to perform relaxing on final +code. The compiler creates code which is as big as necessary to make +it work without relaxing, and the user can select whether to relax. +Sometimes relaxing takes a lot of time. The linker runs around the +relocations to see if any are attached to data which can be shrunk, if +so it does it on a link_order by link_order basis. + Index: bfd.info-2 =================================================================== --- bfd.info-2 (nonexistent) +++ bfd.info-2 (revision 1765) @@ -0,0 +1,1197 @@ +This is bfd.info, produced by Makeinfo version 3.12f from bfd.texinfo. + +START-INFO-DIR-ENTRY +* Bfd: (bfd). The Binary File Descriptor library. +END-INFO-DIR-ENTRY + + This file documents the BFD library. + + Copyright (C) 1991 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, subject to the +terms of the GNU General Public License, which includes the provision +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: bfd.info, Node: typedef asection, Next: section prototypes, Prev: Section Output, Up: Sections + +typedef asection +---------------- + + Here is the section structure: + + + /* This structure is used for a comdat section, as in PE. A comdat + section is associated with a particular symbol. When the linker + sees a comdat section, it keeps only one of the sections with a + given name and associated with a given symbol. */ + + struct bfd_comdat_info + { + /* The name of the symbol associated with a comdat section. */ + const char *name; + + /* The local symbol table index of the symbol associated with a + comdat section. This is only meaningful to the object file format + specific code; it is not an index into the list returned by + bfd_canonicalize_symtab. */ + long symbol; + + /* If this section is being discarded, the linker uses this field + to point to the input section which is being kept. */ + struct sec *sec; + }; + + typedef struct sec + { + /* The name of the section; the name isn't a copy, the pointer is + the same as that passed to bfd_make_section. */ + + CONST char *name; + + /* Which section is it; 0..nth. */ + + int index; + + /* The next section in the list belonging to the BFD, or NULL. */ + + struct sec *next; + + /* The field flags contains attributes of the section. Some + flags are read in from the object file, and some are + synthesized from other information. */ + + flagword flags; + + #define SEC_NO_FLAGS 0x000 + + /* Tells the OS to allocate space for this section when loading. + This is clear for a section containing debug information + only. */ + #define SEC_ALLOC 0x001 + + /* Tells the OS to load the section from the file when loading. + This is clear for a .bss section. */ + #define SEC_LOAD 0x002 + + /* The section contains data still to be relocated, so there is + some relocation information too. */ + #define SEC_RELOC 0x004 + + #if 0 /* Obsolete ? */ + #define SEC_BALIGN 0x008 + #endif + + /* A signal to the OS that the section contains read only + data. */ + #define SEC_READONLY 0x010 + + /* The section contains code only. */ + #define SEC_CODE 0x020 + + /* The section contains data only. */ + #define SEC_DATA 0x040 + + /* The section will reside in ROM. */ + #define SEC_ROM 0x080 + + /* The section contains constructor information. This section + type is used by the linker to create lists of constructors and + destructors used by `g++'. When a back end sees a symbol + which should be used in a constructor list, it creates a new + section for the type of name (e.g., `__CTOR_LIST__'), attaches + the symbol to it, and builds a relocation. To build the lists + of constructors, all the linker has to do is catenate all the + sections called `__CTOR_LIST__' and relocate the data + contained within - exactly the operations it would peform on + standard data. */ + #define SEC_CONSTRUCTOR 0x100 + + /* The section is a constructor, and should be placed at the + end of the text, data, or bss section(?). */ + #define SEC_CONSTRUCTOR_TEXT 0x1100 + #define SEC_CONSTRUCTOR_DATA 0x2100 + #define SEC_CONSTRUCTOR_BSS 0x3100 + + /* The section has contents - a data section could be + `SEC_ALLOC' | `SEC_HAS_CONTENTS'; a debug section could be + `SEC_HAS_CONTENTS' */ + #define SEC_HAS_CONTENTS 0x200 + + /* An instruction to the linker to not output the section + even if it has information which would normally be written. */ + #define SEC_NEVER_LOAD 0x400 + + /* The section is a COFF shared library section. This flag is + only for the linker. If this type of section appears in + the input file, the linker must copy it to the output file + without changing the vma or size. FIXME: Although this + was originally intended to be general, it really is COFF + specific (and the flag was renamed to indicate this). It + might be cleaner to have some more general mechanism to + allow the back end to control what the linker does with + sections. */ + #define SEC_COFF_SHARED_LIBRARY 0x800 + + /* The section contains common symbols (symbols may be defined + multiple times, the value of a symbol is the amount of + space it requires, and the largest symbol value is the one + used). Most targets have exactly one of these (which we + translate to bfd_com_section_ptr), but ECOFF has two. */ + #define SEC_IS_COMMON 0x8000 + + /* The section contains only debugging information. For + example, this is set for ELF .debug and .stab sections. + strip tests this flag to see if a section can be + discarded. */ + #define SEC_DEBUGGING 0x10000 + + /* The contents of this section are held in memory pointed to + by the contents field. This is checked by + bfd_get_section_contents, and the data is retrieved from + memory if appropriate. */ + #define SEC_IN_MEMORY 0x20000 + + /* The contents of this section are to be excluded by the + linker for executable and shared objects unless those + objects are to be further relocated. */ + #define SEC_EXCLUDE 0x40000 + + /* The contents of this section are to be sorted by the + based on the address specified in the associated symbol + table. */ + #define SEC_SORT_ENTRIES 0x80000 + + /* When linking, duplicate sections of the same name should be + discarded, rather than being combined into a single section as + is usually done. This is similar to how common symbols are + handled. See SEC_LINK_DUPLICATES below. */ + #define SEC_LINK_ONCE 0x100000 + + /* If SEC_LINK_ONCE is set, this bitfield describes how the linker + should handle duplicate sections. */ + #define SEC_LINK_DUPLICATES 0x600000 + + /* This value for SEC_LINK_DUPLICATES means that duplicate + sections with the same name should simply be discarded. */ + #define SEC_LINK_DUPLICATES_DISCARD 0x0 + + /* This value for SEC_LINK_DUPLICATES means that the linker + should warn if there are any duplicate sections, although + it should still only link one copy. */ + #define SEC_LINK_DUPLICATES_ONE_ONLY 0x200000 + + /* This value for SEC_LINK_DUPLICATES means that the linker + should warn if any duplicate sections are a different size. */ + #define SEC_LINK_DUPLICATES_SAME_SIZE 0x400000 + + /* This value for SEC_LINK_DUPLICATES means that the linker + should warn if any duplicate sections contain different + contents. */ + #define SEC_LINK_DUPLICATES_SAME_CONTENTS 0x600000 + + /* This section was created by the linker as part of dynamic + relocation or other arcane processing. It is skipped when + going through the first-pass output, trusting that someone + else up the line will take care of it later. */ + #define SEC_LINKER_CREATED 0x800000 + + /* This section should not be subject to garbage collection. */ + #define SEC_KEEP 0x1000000 + + /* This section contains "short" data, and should be placed + "near" the GP. */ + #define SEC_SMALL_DATA 0x2000000 + + /* This section contains data which may be shared with other + executables or shared objects. */ + #define SEC_SHARED 0x4000000 + + /* When a section with this flag is being linked, then if the size of + the input section is less than a page, it should not cross a page + boundary. If the size of the input section is one page or more, it + should be aligned on a page boundary. */ + #define SEC_BLOCK 0x8000000 + + /* Conditionally link this section; do not link if there are no + references found to any symbol in the section. */ + #define SEC_CLINK 0x10000000 + + /* End of section flags. */ + + /* Some internal packed boolean fields. */ + + /* See the vma field. */ + unsigned int user_set_vma : 1; + + /* Whether relocations have been processed. */ + unsigned int reloc_done : 1; + + /* A mark flag used by some of the linker backends. */ + unsigned int linker_mark : 1; + + /* A mark flag used by some linker backends for garbage collection. */ + unsigned int gc_mark : 1; + + /* End of internal packed boolean fields. */ + + /* The virtual memory address of the section - where it will be + at run time. The symbols are relocated against this. The + user_set_vma flag is maintained by bfd; if it's not set, the + backend can assign addresses (for example, in `a.out', where + the default address for `.data' is dependent on the specific + target and various flags). */ + + bfd_vma vma; + + /* The load address of the section - where it would be in a + rom image; really only used for writing section header + information. */ + + bfd_vma lma; + + /* The size of the section in octets, as it will be output. + Contains a value even if the section has no contents (e.g., the + size of `.bss'). This will be filled in after relocation. */ + + bfd_size_type _cooked_size; + + /* The original size on disk of the section, in octets. Normally this + value is the same as the size, but if some relaxing has + been done, then this value will be bigger. */ + + bfd_size_type _raw_size; + + /* If this section is going to be output, then this value is the + offset in *bytes* into the output section of the first byte in the + input section (byte ==> smallest addressable unit on the + target). In most cases, if this was going to start at the + 100th octet (8-bit quantity) in the output section, this value + would be 100. However, if the target byte size is 16 bits + (bfd_octets_per_byte is "2"), this value would be 50. */ + + bfd_vma output_offset; + + /* The output section through which to map on output. */ + + struct sec *output_section; + + /* The alignment requirement of the section, as an exponent of 2 - + e.g., 3 aligns to 2^3 (or 8). */ + + unsigned int alignment_power; + + /* If an input section, a pointer to a vector of relocation + records for the data in this section. */ + + struct reloc_cache_entry *relocation; + + /* If an output section, a pointer to a vector of pointers to + relocation records for the data in this section. */ + + struct reloc_cache_entry **orelocation; + + /* The number of relocation records in one of the above */ + + unsigned reloc_count; + + /* Information below is back end specific - and not always used + or updated. */ + + /* File position of section data */ + + file_ptr filepos; + + /* File position of relocation info */ + + file_ptr rel_filepos; + + /* File position of line data */ + + file_ptr line_filepos; + + /* Pointer to data for applications */ + + PTR userdata; + + /* If the SEC_IN_MEMORY flag is set, this points to the actual + contents. */ + unsigned char *contents; + + /* Attached line number information */ + + alent *lineno; + + /* Number of line number records */ + + unsigned int lineno_count; + + /* Optional information about a COMDAT entry; NULL if not COMDAT */ + + struct bfd_comdat_info *comdat; + + /* When a section is being output, this value changes as more + linenumbers are written out */ + + file_ptr moving_line_filepos; + + /* What the section number is in the target world */ + + int target_index; + + PTR used_by_bfd; + + /* If this is a constructor section then here is a list of the + relocations created to relocate items within it. */ + + struct relent_chain *constructor_chain; + + /* The BFD which owns the section. */ + + bfd *owner; + + /* A symbol which points at this section only */ + struct symbol_cache_entry *symbol; + struct symbol_cache_entry **symbol_ptr_ptr; + + struct bfd_link_order *link_order_head; + struct bfd_link_order *link_order_tail; + } asection ; + + /* These sections are global, and are managed by BFD. The application + and target back end are not permitted to change the values in + these sections. New code should use the section_ptr macros rather + than referring directly to the const sections. The const sections + may eventually vanish. */ + #define BFD_ABS_SECTION_NAME "*ABS*" + #define BFD_UND_SECTION_NAME "*UND*" + #define BFD_COM_SECTION_NAME "*COM*" + #define BFD_IND_SECTION_NAME "*IND*" + + /* the absolute section */ + extern const asection bfd_abs_section; + #define bfd_abs_section_ptr ((asection *) &bfd_abs_section) + #define bfd_is_abs_section(sec) ((sec) == bfd_abs_section_ptr) + /* Pointer to the undefined section */ + extern const asection bfd_und_section; + #define bfd_und_section_ptr ((asection *) &bfd_und_section) + #define bfd_is_und_section(sec) ((sec) == bfd_und_section_ptr) + /* Pointer to the common section */ + extern const asection bfd_com_section; + #define bfd_com_section_ptr ((asection *) &bfd_com_section) + /* Pointer to the indirect section */ + extern const asection bfd_ind_section; + #define bfd_ind_section_ptr ((asection *) &bfd_ind_section) + #define bfd_is_ind_section(sec) ((sec) == bfd_ind_section_ptr) + + extern const struct symbol_cache_entry * const bfd_abs_symbol; + extern const struct symbol_cache_entry * const bfd_com_symbol; + extern const struct symbol_cache_entry * const bfd_und_symbol; + extern const struct symbol_cache_entry * const bfd_ind_symbol; + #define bfd_get_section_size_before_reloc(section) \ + ((section)->reloc_done ? (abort (), (bfd_size_type) 1) \ + : (section)->_raw_size) + #define bfd_get_section_size_after_reloc(section) \ + ((section)->reloc_done ? (section)->_cooked_size \ + : (abort (), (bfd_size_type) 1)) + + +File: bfd.info, Node: section prototypes, Prev: typedef asection, Up: Sections + +Section prototypes +------------------ + + These are the functions exported by the section handling part of BFD. + +`bfd_get_section_by_name' +......................... + + *Synopsis* + asection *bfd_get_section_by_name(bfd *abfd, CONST char *name); + *Description* +Run through ABFD and return the one of the `asection's whose name +matches NAME, otherwise `NULL'. *Note Sections::, for more information. + + This should only be used in special cases; the normal way to process +all sections of a given name is to use `bfd_map_over_sections' and +`strcmp' on the name (or better yet, base it on the section flags or +something else) for each section. + +`bfd_make_section_old_way' +.......................... + + *Synopsis* + asection *bfd_make_section_old_way(bfd *abfd, CONST char *name); + *Description* +Create a new empty section called NAME and attach it to the end of the +chain of sections for the BFD ABFD. An attempt to create a section with +a name which is already in use returns its pointer without changing the +section chain. + + It has the funny name since this is the way it used to be before it +was rewritten.... + + Possible errors are: + * `bfd_error_invalid_operation' - If output has already started for + this BFD. + + * `bfd_error_no_memory' - If memory allocation fails. + +`bfd_make_section_anyway' +......................... + + *Synopsis* + asection *bfd_make_section_anyway(bfd *abfd, CONST char *name); + *Description* +Create a new empty section called NAME and attach it to the end of the +chain of sections for ABFD. Create a new section even if there is +already a section with that name. + + Return `NULL' and set `bfd_error' on error; possible errors are: + * `bfd_error_invalid_operation' - If output has already started for + ABFD. + + * `bfd_error_no_memory' - If memory allocation fails. + +`bfd_make_section' +.................. + + *Synopsis* + asection *bfd_make_section(bfd *, CONST char *name); + *Description* +Like `bfd_make_section_anyway', but return `NULL' (without calling +bfd_set_error ()) without changing the section chain if there is +already a section named NAME. If there is an error, return `NULL' and +set `bfd_error'. + +`bfd_set_section_flags' +....................... + + *Synopsis* + boolean bfd_set_section_flags(bfd *abfd, asection *sec, flagword flags); + *Description* +Set the attributes of the section SEC in the BFD ABFD to the value +FLAGS. Return `true' on success, `false' on error. Possible error +returns are: + + * `bfd_error_invalid_operation' - The section cannot have one or + more of the attributes requested. For example, a .bss section in + `a.out' may not have the `SEC_HAS_CONTENTS' field set. + +`bfd_map_over_sections' +....................... + + *Synopsis* + void bfd_map_over_sections(bfd *abfd, + void (*func)(bfd *abfd, + asection *sect, + PTR obj), + PTR obj); + *Description* +Call the provided function FUNC for each section attached to the BFD +ABFD, passing OBJ as an argument. The function will be called as if by + + func(abfd, the_section, obj); + + This is the prefered method for iterating over sections; an +alternative would be to use a loop: + + section *p; + for (p = abfd->sections; p != NULL; p = p->next) + func(abfd, p, ...) + +`bfd_set_section_size' +...................... + + *Synopsis* + boolean bfd_set_section_size(bfd *abfd, asection *sec, bfd_size_type val); + *Description* +Set SEC to the size VAL. If the operation is ok, then `true' is +returned, else `false'. + + Possible error returns: + * `bfd_error_invalid_operation' - Writing has started to the BFD, so + setting the size is invalid. + +`bfd_set_section_contents' +.......................... + + *Synopsis* + boolean bfd_set_section_contents + (bfd *abfd, + asection *section, + PTR data, + file_ptr offset, + bfd_size_type count); + *Description* +Sets the contents of the section SECTION in BFD ABFD to the data +starting in memory at DATA. The data is written to the output section +starting at offset OFFSET for COUNT octets. + + Normally `true' is returned, else `false'. Possible error returns +are: + * `bfd_error_no_contents' - The output section does not have the + `SEC_HAS_CONTENTS' attribute, so nothing can be written to it. + + * and some more too + This routine is front end to the back end function +`_bfd_set_section_contents'. + +`bfd_get_section_contents' +.......................... + + *Synopsis* + boolean bfd_get_section_contents + (bfd *abfd, asection *section, PTR location, + file_ptr offset, bfd_size_type count); + *Description* +Read data from SECTION in BFD ABFD into memory starting at LOCATION. +The data is read at an offset of OFFSET from the start of the input +section, and is read for COUNT bytes. + + If the contents of a constructor with the `SEC_CONSTRUCTOR' flag set +are requested or if the section does not have the `SEC_HAS_CONTENTS' +flag set, then the LOCATION is filled with zeroes. If no errors occur, +`true' is returned, else `false'. + +`bfd_copy_private_section_data' +............................... + + *Synopsis* + boolean bfd_copy_private_section_data(bfd *ibfd, asection *isec, bfd *obfd, asection *osec); + *Description* +Copy private section information from ISEC in the BFD IBFD to the +section OSEC in the BFD OBFD. Return `true' on success, `false' on +error. Possible error returns are: + + * `bfd_error_no_memory' - Not enough memory exists to create private + data for OSEC. + + #define bfd_copy_private_section_data(ibfd, isection, obfd, osection) \ + BFD_SEND (obfd, _bfd_copy_private_section_data, \ + (ibfd, isection, obfd, osection)) + +`_bfd_strip_section_from_output' +................................ + + *Synopsis* + void _bfd_strip_section_from_output + (struct bfd_link_info *info, asection *section); + *Description* +Remove SECTION from the output. If the output section becomes empty, +remove it from the output bfd. INFO may be NULL; if it is not, it is +used to decide whether the output section is empty. + + +File: bfd.info, Node: Symbols, Next: Archives, Prev: Sections, Up: BFD front end + +Symbols +======= + + BFD tries to maintain as much symbol information as it can when it +moves information from file to file. BFD passes information to +applications though the `asymbol' structure. When the application +requests the symbol table, BFD reads the table in the native form and +translates parts of it into the internal format. To maintain more than +the information passed to applications, some targets keep some +information "behind the scenes" in a structure only the particular back +end knows about. For example, the coff back end keeps the original +symbol table structure as well as the canonical structure when a BFD is +read in. On output, the coff back end can reconstruct the output symbol +table so that no information is lost, even information unique to coff +which BFD doesn't know or understand. If a coff symbol table were read, +but were written through an a.out back end, all the coff specific +information would be lost. The symbol table of a BFD is not necessarily +read in until a canonicalize request is made. Then the BFD back end +fills in a table provided by the application with pointers to the +canonical information. To output symbols, the application provides BFD +with a table of pointers to pointers to `asymbol's. This allows +applications like the linker to output a symbol as it was read, since +the "behind the scenes" information will be still available. + +* Menu: + +* Reading Symbols:: +* Writing Symbols:: +* Mini Symbols:: +* typedef asymbol:: +* symbol handling functions:: + + +File: bfd.info, Node: Reading Symbols, Next: Writing Symbols, Prev: Symbols, Up: Symbols + +Reading symbols +--------------- + + There are two stages to reading a symbol table from a BFD: +allocating storage, and the actual reading process. This is an excerpt +from an application which reads the symbol table: + + long storage_needed; + asymbol **symbol_table; + long number_of_symbols; + long i; + + storage_needed = bfd_get_symtab_upper_bound (abfd); + + if (storage_needed < 0) + FAIL + + if (storage_needed == 0) { + return ; + } + symbol_table = (asymbol **) xmalloc (storage_needed); + ... + number_of_symbols = + bfd_canonicalize_symtab (abfd, symbol_table); + + if (number_of_symbols < 0) + FAIL + + for (i = 0; i < number_of_symbols; i++) { + process_symbol (symbol_table[i]); + } + + All storage for the symbols themselves is in an objalloc connected +to the BFD; it is freed when the BFD is closed. + + +File: bfd.info, Node: Writing Symbols, Next: Mini Symbols, Prev: Reading Symbols, Up: Symbols + +Writing symbols +--------------- + + Writing of a symbol table is automatic when a BFD open for writing +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 BFD output code must always be +provided with an "owned" symbol: one which has come from another BFD, +or one which has been created using `bfd_make_empty_symbol'. Here is an +example showing the creation of a symbol table with only one element: + + #include "bfd.h" + main() + { + bfd *abfd; + asymbol *ptrs[2]; + asymbol *new; + + abfd = bfd_openw("foo","a.out-sunos-big"); + bfd_set_format(abfd, bfd_object); + new = bfd_make_empty_symbol(abfd); + new->name = "dummy_symbol"; + new->section = bfd_make_section_old_way(abfd, ".text"); + new->flags = BSF_GLOBAL; + new->value = 0x12345; + + ptrs[0] = new; + ptrs[1] = (asymbol *)0; + + bfd_set_symtab(abfd, ptrs, 1); + bfd_close(abfd); + } + + ./makesym + nm foo + 00012345 A dummy_symbol + + Many formats cannot represent arbitary symbol information; for +instance, the `a.out' object format does not allow an arbitary number +of sections. A symbol pointing to a section which is not one of +`.text', `.data' or `.bss' cannot be described. + + +File: bfd.info, Node: Mini Symbols, Next: typedef asymbol, Prev: Writing Symbols, Up: Symbols + +Mini Symbols +------------ + + Mini symbols provide read-only access to the symbol table. They use +less memory space, but require more time to access. They can be useful +for tools like nm or objdump, which may have to handle symbol tables of +extremely large executables. + + The `bfd_read_minisymbols' function will read the symbols into +memory in an internal form. It will return a `void *' pointer to a +block of memory, a symbol count, and the size of each symbol. The +pointer is allocated using `malloc', and should be freed by the caller +when it is no longer needed. + + The function `bfd_minisymbol_to_symbol' will take a pointer to a +minisymbol, and a pointer to a structure returned by +`bfd_make_empty_symbol', and return a `asymbol' structure. The return +value may or may not be the same as the value from +`bfd_make_empty_symbol' which was passed in. + + +File: bfd.info, Node: typedef asymbol, Next: symbol handling functions, Prev: Mini Symbols, Up: Symbols + +typedef asymbol +--------------- + + An `asymbol' has the form: + + + typedef struct symbol_cache_entry + { + /* A pointer to the BFD which owns the symbol. This information + is necessary so that a back end can work out what additional + information (invisible to the application writer) is carried + with the symbol. + + This field is *almost* redundant, since you can use section->owner + instead, except that some symbols point to the global sections + bfd_{abs,com,und}_section. This could be fixed by making + these globals be per-bfd (or per-target-flavor). FIXME. */ + + struct _bfd *the_bfd; /* Use bfd_asymbol_bfd(sym) to access this field. */ + + /* The text of the symbol. The name is left alone, and not copied; the + application may not alter it. */ + CONST char *name; + + /* The value of the symbol. This really should be a union of a + numeric value with a pointer, since some flags indicate that + a pointer to another symbol is stored here. */ + symvalue value; + + /* Attributes of a symbol: */ + + #define BSF_NO_FLAGS 0x00 + + /* The symbol has local scope; `static' in `C'. The value + is the offset into the section of the data. */ + #define BSF_LOCAL 0x01 + + /* The symbol has global scope; initialized data in `C'. The + value is the offset into the section of the data. */ + #define BSF_GLOBAL 0x02 + + /* The symbol has global scope and is exported. The value is + the offset into the section of the data. */ + #define BSF_EXPORT BSF_GLOBAL /* no real difference */ + + /* A normal C symbol would be one of: + `BSF_LOCAL', `BSF_FORT_COMM', `BSF_UNDEFINED' or + `BSF_GLOBAL' */ + + /* The symbol is a debugging record. The value has an arbitary + meaning, unless BSF_DEBUGGING_RELOC is also set. */ + #define BSF_DEBUGGING 0x08 + + /* The symbol denotes a function entry point. Used in ELF, + perhaps others someday. */ + #define BSF_FUNCTION 0x10 + + /* Used by the linker. */ + #define BSF_KEEP 0x20 + #define BSF_KEEP_G 0x40 + + /* A weak global symbol, overridable without warnings by + a regular global symbol of the same name. */ + #define BSF_WEAK 0x80 + + /* This symbol was created to point to a section, e.g. ELF's + STT_SECTION symbols. */ + #define BSF_SECTION_SYM 0x100 + + /* The symbol used to be a common symbol, but now it is + allocated. */ + #define BSF_OLD_COMMON 0x200 + + /* The default value for common data. */ + #define BFD_FORT_COMM_DEFAULT_VALUE 0 + + /* In some files the type of a symbol sometimes alters its + location in an output file - ie in coff a `ISFCN' symbol + which is also `C_EXT' symbol appears where it was + declared and not at the end of a section. This bit is set + by the target BFD part to convey this information. */ + + #define BSF_NOT_AT_END 0x400 + + /* Signal that the symbol is the label of constructor section. */ + #define BSF_CONSTRUCTOR 0x800 + + /* Signal that the symbol is a warning symbol. The name is a + warning. The name of the next symbol is the one to warn about; + if a reference is made to a symbol with the same name as the next + symbol, a warning is issued by the linker. */ + #define BSF_WARNING 0x1000 + + /* Signal that the symbol is indirect. This symbol is an indirect + pointer to the symbol with the same name as the next symbol. */ + #define BSF_INDIRECT 0x2000 + + /* BSF_FILE marks symbols that contain a file name. This is used + for ELF STT_FILE symbols. */ + #define BSF_FILE 0x4000 + + /* Symbol is from dynamic linking information. */ + #define BSF_DYNAMIC 0x8000 + + /* The symbol denotes a data object. Used in ELF, and perhaps + others someday. */ + #define BSF_OBJECT 0x10000 + + /* This symbol is a debugging symbol. The value is the offset + into the section of the data. BSF_DEBUGGING should be set + as well. */ + #define BSF_DEBUGGING_RELOC 0x20000 + + flagword flags; + + /* A pointer to the section to which this symbol is + relative. This will always be non NULL, there are special + sections for undefined and absolute symbols. */ + struct sec *section; + + /* Back end special data. */ + union + { + PTR p; + bfd_vma i; + } udata; + + } asymbol; + + +File: bfd.info, Node: symbol handling functions, Prev: typedef asymbol, Up: Symbols + +Symbol handling functions +------------------------- + +`bfd_get_symtab_upper_bound' +............................ + + *Description* +Return the number of bytes required to store a vector of pointers to +`asymbols' for all the symbols in the BFD ABFD, including a terminal +NULL pointer. If there are no symbols in the BFD, then return 0. If an +error occurs, return -1. + #define bfd_get_symtab_upper_bound(abfd) \ + BFD_SEND (abfd, _bfd_get_symtab_upper_bound, (abfd)) + +`bfd_is_local_label' +.................... + + *Synopsis* + boolean bfd_is_local_label(bfd *abfd, asymbol *sym); + *Description* +Return true if the given symbol SYM in the BFD ABFD is a compiler +generated local label, else return false. + +`bfd_is_local_label_name' +......................... + + *Synopsis* + boolean bfd_is_local_label_name(bfd *abfd, const char *name); + *Description* +Return true if a symbol with the name NAME in the BFD ABFD is a +compiler generated local label, else return false. This just checks +whether the name has the form of a local label. + #define bfd_is_local_label_name(abfd, name) \ + BFD_SEND (abfd, _bfd_is_local_label_name, (abfd, name)) + +`bfd_canonicalize_symtab' +......................... + + *Description* +Read the symbols from the BFD ABFD, and fills in the vector LOCATION +with pointers to the symbols and a trailing NULL. Return the actual +number of symbol pointers, not including the NULL. + #define bfd_canonicalize_symtab(abfd, location) \ + BFD_SEND (abfd, _bfd_canonicalize_symtab,\ + (abfd, location)) + +`bfd_set_symtab' +................ + + *Synopsis* + boolean bfd_set_symtab (bfd *abfd, asymbol **location, unsigned int count); + *Description* +Arrange that when the output BFD ABFD is closed, the table LOCATION of +COUNT pointers to symbols will be written. + +`bfd_print_symbol_vandf' +........................ + + *Synopsis* + void bfd_print_symbol_vandf(PTR file, asymbol *symbol); + *Description* +Print the value and flags of the SYMBOL supplied to the stream FILE. + +`bfd_make_empty_symbol' +....................... + + *Description* +Create a new `asymbol' structure for the BFD ABFD and return a pointer +to it. + + This routine is necessary because each back end has private +information surrounding the `asymbol'. Building your own `asymbol' and +pointing to it will not create the private information, and will cause +problems later on. + #define bfd_make_empty_symbol(abfd) \ + BFD_SEND (abfd, _bfd_make_empty_symbol, (abfd)) + +`bfd_make_debug_symbol' +....................... + + *Description* +Create a new `asymbol' structure for the BFD ABFD, to be used as a +debugging symbol. Further details of its use have yet to be worked out. + #define bfd_make_debug_symbol(abfd,ptr,size) \ + BFD_SEND (abfd, _bfd_make_debug_symbol, (abfd, ptr, size)) + +`bfd_decode_symclass' +..................... + + *Description* +Return a character corresponding to the symbol class of SYMBOL, or '?' +for an unknown class. + + *Synopsis* + int bfd_decode_symclass(asymbol *symbol); + +`bfd_is_undefined_symclass ' +............................ + + *Description* +Returns non-zero if the class symbol returned by bfd_decode_symclass +represents an undefined symbol. Returns zero otherwise. + + *Synopsis* + boolean bfd_is_undefined_symclass (int symclass); + +`bfd_symbol_info' +................. + + *Description* +Fill in the basic info about symbol that nm needs. Additional info may +be added by the back-ends after calling this function. + + *Synopsis* + void bfd_symbol_info(asymbol *symbol, symbol_info *ret); + +`bfd_copy_private_symbol_data' +.............................. + + *Synopsis* + boolean bfd_copy_private_symbol_data(bfd *ibfd, asymbol *isym, bfd *obfd, asymbol *osym); + *Description* +Copy private symbol information from ISYM in the BFD IBFD to the symbol +OSYM in the BFD OBFD. Return `true' on success, `false' on error. +Possible error returns are: + + * `bfd_error_no_memory' - Not enough memory exists to create private + data for OSEC. + + #define bfd_copy_private_symbol_data(ibfd, isymbol, obfd, osymbol) \ + BFD_SEND (obfd, _bfd_copy_private_symbol_data, \ + (ibfd, isymbol, obfd, osymbol)) + + +File: bfd.info, Node: Archives, Next: Formats, Prev: Symbols, Up: BFD front end + +Archives +======== + + *Description* +An archive (or library) is just another BFD. It has a symbol table, +although there's not much a user program will do with it. + + The big difference between an archive BFD and an ordinary BFD is +that the archive doesn't have sections. Instead it has a chain of BFDs +that are considered its contents. These BFDs can be manipulated like +any other. The BFDs contained in an archive opened for reading will +all be opened for reading. You may put either input or output BFDs +into an archive opened for output; they will be handled correctly when +the archive is closed. + + Use `bfd_openr_next_archived_file' to step through the contents of +an archive opened for input. You don't have to read the entire archive +if you don't want to! Read it until you find what you want. + + Archive contents of output BFDs are chained through the `next' +pointer in a BFD. The first one is findable through the `archive_head' +slot of the archive. Set it with `bfd_set_archive_head' (q.v.). A +given BFD may be in only one open output archive at a time. + + As expected, the BFD archive code is more general than the archive +code of any given environment. BFD archives may contain files of +different formats (e.g., a.out and coff) and even different +architectures. You may even place archives recursively into archives! + + This can cause unexpected confusion, since some archive formats are +more expressive than others. For instance, Intel COFF archives can +preserve long filenames; SunOS a.out archives cannot. If you move a +file from the first to the second format and back again, the filename +may be truncated. Likewise, different a.out environments have different +conventions as to how they truncate filenames, whether they preserve +directory names in filenames, etc. When interoperating with native +tools, be sure your files are homogeneous. + + Beware: most of these formats do not react well to the presence of +spaces in filenames. We do the best we can, but can't always handle +this case due to restrictions in the format of archives. Many Unix +utilities are braindead in regards to spaces and such in filenames +anyway, so this shouldn't be much of a restriction. + + Archives are supported in BFD in `archive.c'. + +`bfd_get_next_mapent' +..................... + + *Synopsis* + symindex bfd_get_next_mapent(bfd *abfd, symindex previous, carsym **sym); + *Description* +Step through archive ABFD's symbol table (if it has one). Successively +update SYM with the next symbol's information, returning that symbol's +(internal) index into the symbol table. + + Supply `BFD_NO_MORE_SYMBOLS' as the PREVIOUS entry to get the first +one; returns `BFD_NO_MORE_SYMBOLS' when you've already got the last one. + + A `carsym' is a canonical archive symbol. The only user-visible +element is its name, a null-terminated string. + +`bfd_set_archive_head' +...................... + + *Synopsis* + boolean bfd_set_archive_head(bfd *output, bfd *new_head); + *Description* +Set the head of the chain of BFDs contained in the archive OUTPUT to +NEW_HEAD. + +`bfd_openr_next_archived_file' +.............................. + + *Synopsis* + bfd *bfd_openr_next_archived_file(bfd *archive, bfd *previous); + *Description* +Provided a BFD, ARCHIVE, containing an archive and NULL, open an input +BFD on the first contained element and returns that. Subsequent calls +should pass the archive and the previous return value to return a +created BFD to the next contained element. NULL is returned when there +are no more. + + +File: bfd.info, Node: Formats, Next: Relocations, Prev: Archives, Up: BFD front end + +File formats +============ + + A format is a BFD concept of high level file contents type. The +formats supported by BFD are: + + * `bfd_object' + The BFD may contain data, symbols, relocations and debug info. + + * `bfd_archive' + The BFD contains other BFDs and an optional index. + + * `bfd_core' + The BFD contains the result of an executable core dump. + +`bfd_check_format' +.................. + + *Synopsis* + boolean bfd_check_format(bfd *abfd, bfd_format format); + *Description* +Verify if the file attached to the BFD ABFD is compatible with the +format FORMAT (i.e., one of `bfd_object', `bfd_archive' or `bfd_core'). + + If the BFD has been set to a specific target before the call, only +the named target and format combination is checked. If the target has +not been set, or has been set to `default', then all the known target +backends is interrogated to determine a match. If the default target +matches, it is used. If not, exactly one target must recognize the +file, or an error results. + + The function returns `true' on success, otherwise `false' with one +of the following error codes: + + * `bfd_error_invalid_operation' - if `format' is not one of + `bfd_object', `bfd_archive' or `bfd_core'. + + * `bfd_error_system_call' - if an error occured during a read - even + some file mismatches can cause bfd_error_system_calls. + + * `file_not_recognised' - none of the backends recognised the file + format. + + * `bfd_error_file_ambiguously_recognized' - more than one backend + recognised the file format. + +`bfd_check_format_matches' +.......................... + + *Synopsis* + boolean bfd_check_format_matches(bfd *abfd, bfd_format format, char ***matching); + *Description* +Like `bfd_check_format', except when it returns false with `bfd_errno' +set to `bfd_error_file_ambiguously_recognized'. In that case, if +MATCHING is not NULL, it will be filled in with a NULL-terminated list +of the names of the formats that matched, allocated with `malloc'. +Then the user may choose a format and try again. + + When done with the list that MATCHING points to, the caller should +free it. + +`bfd_set_format' +................ + + *Synopsis* + boolean bfd_set_format(bfd *abfd, bfd_format format); + *Description* +This function sets the file format of the BFD ABFD to the format +FORMAT. If the target set in the BFD does not support the format +requested, the format is invalid, or the BFD is not open for writing, +then an error occurs. + +`bfd_format_string' +................... + + *Synopsis* + CONST char *bfd_format_string(bfd_format format); + *Description* +Return a pointer to a const string `invalid', `object', `archive', +`core', or `unknown', depending upon the value of FORMAT. + + +File: bfd.info, Node: Relocations, Next: Core Files, Prev: Formats, Up: BFD front end + +Relocations +=========== + + BFD maintains relocations in much the same way it maintains symbols: +they are left alone until required, then read in en-mass and translated +into an internal form. A common routine `bfd_perform_relocation' acts +upon the canonical form to do the fixup. + + Relocations are maintained on a per section basis, while symbols are +maintained on a per BFD basis. + + All that a back end has to do to fit the BFD interface is to create +a `struct reloc_cache_entry' for each relocation in a particular +section, and fill in the right bits of the structures. + +* Menu: + +* typedef arelent:: +* howto manager:: + Index: archures.texi =================================================================== --- archures.texi (nonexistent) +++ archures.texi (revision 1765) @@ -0,0 +1,410 @@ +@section Architectures +BFD keeps one atom in a BFD describing the +architecture of the data attached to the BFD: a pointer to a +@code{bfd_arch_info_type}. + +Pointers to structures can be requested independently of a BFD +so that an architecture's information can be interrogated +without access to an open BFD. + +The architecture information is provided by each architecture package. +The set of default architectures is selected by the macro +@code{SELECT_ARCHITECTURES}. This is normally set up in the +@file{config/@var{target}.mt} file of your choice. If the name is not +defined, then all the architectures supported are included. + +When BFD starts up, all the architectures are called with an +initialize method. It is up to the architecture back end to +insert as many items into the list of architectures as it wants to; +generally this would be one for each machine and one for the +default case (an item with a machine field of 0). + +BFD's idea of an architecture is implemented in @file{archures.c}. + +@subsection bfd_architecture + + +@strong{Description}@* +This enum gives the object file's CPU architecture, in a +global sense---i.e., what processor family does it belong to? +Another field indicates which processor within +the family is in use. The machine gives a number which +distinguishes different versions of the architecture, +containing, for example, 2 and 3 for Intel i960 KA and i960 KB, +and 68020 and 68030 for Motorola 68020 and 68030. +@example +enum bfd_architecture +@{ + bfd_arch_unknown, /* File arch not known */ + bfd_arch_obscure, /* Arch known, not one of these */ + bfd_arch_m68k, /* Motorola 68xxx */ +#define bfd_mach_m68000 1 +#define bfd_mach_m68008 2 +#define bfd_mach_m68010 3 +#define bfd_mach_m68020 4 +#define bfd_mach_m68030 5 +#define bfd_mach_m68040 6 +#define bfd_mach_m68060 7 +#define bfd_mach_cpu32 8 + bfd_arch_vax, /* DEC Vax */ + bfd_arch_i960, /* Intel 960 */ + /* The order of the following is important. + lower number indicates a machine type that + only accepts a subset of the instructions + available to machines with higher numbers. + The exception is the "ca", which is + incompatible with all other machines except + "core". */ + +#define bfd_mach_i960_core 1 +#define bfd_mach_i960_ka_sa 2 +#define bfd_mach_i960_kb_sb 3 +#define bfd_mach_i960_mc 4 +#define bfd_mach_i960_xa 5 +#define bfd_mach_i960_ca 6 +#define bfd_mach_i960_jx 7 +#define bfd_mach_i960_hx 8 + + bfd_arch_a29k, /* AMD 29000 */ + bfd_arch_sparc, /* SPARC */ +#define bfd_mach_sparc 1 + /* The difference between v8plus and v9 is that v9 is a true 64 bit env. */ +#define bfd_mach_sparc_sparclet 2 +#define bfd_mach_sparc_sparclite 3 +#define bfd_mach_sparc_v8plus 4 +#define bfd_mach_sparc_v8plusa 5 /* with ultrasparc add'ns */ +#define bfd_mach_sparc_sparclite_le 6 +#define bfd_mach_sparc_v9 7 +#define bfd_mach_sparc_v9a 8 /* with ultrasparc add'ns */ + /* Nonzero if MACH has the v9 instruction set. */ +#define bfd_mach_sparc_v9_p(mach) \ + ((mach) >= bfd_mach_sparc_v8plus && (mach) <= bfd_mach_sparc_v9a) + bfd_arch_mips, /* MIPS Rxxxx */ +#define bfd_mach_mips3000 3000 +#define bfd_mach_mips3900 3900 +#define bfd_mach_mips4000 4000 +#define bfd_mach_mips4010 4010 +#define bfd_mach_mips4100 4100 +#define bfd_mach_mips4111 4111 +#define bfd_mach_mips4300 4300 +#define bfd_mach_mips4400 4400 +#define bfd_mach_mips4600 4600 +#define bfd_mach_mips4650 4650 +#define bfd_mach_mips5000 5000 +#define bfd_mach_mips6000 6000 +#define bfd_mach_mips8000 8000 +#define bfd_mach_mips10000 10000 +#define bfd_mach_mips16 16 + bfd_arch_i386, /* Intel 386 */ +#define bfd_mach_i386_i386 0 +#define bfd_mach_i386_i8086 1 +#define bfd_mach_i386_i386_intel_syntax 2 + bfd_arch_we32k, /* AT&T WE32xxx */ + bfd_arch_tahoe, /* CCI/Harris Tahoe */ + bfd_arch_i860, /* Intel 860 */ + bfd_arch_i370, /* IBM 360/370 Mainframes */ + bfd_arch_romp, /* IBM ROMP PC/RT */ + bfd_arch_alliant, /* Alliant */ + bfd_arch_convex, /* Convex */ + bfd_arch_m88k, /* Motorola 88xxx */ + bfd_arch_pyramid, /* Pyramid Technology */ + bfd_arch_h8300, /* Hitachi H8/300 */ +#define bfd_mach_h8300 1 +#define bfd_mach_h8300h 2 +#define bfd_mach_h8300s 3 + bfd_arch_powerpc, /* PowerPC */ + bfd_arch_rs6000, /* IBM RS/6000 */ + bfd_arch_hppa, /* HP PA RISC */ + bfd_arch_d10v, /* Mitsubishi D10V */ +#define bfd_mach_d10v 0 +#define bfd_mach_d10v_ts2 2 +#define bfd_mach_d10v_ts3 3 + bfd_arch_d30v, /* Mitsubishi D30V */ + bfd_arch_z8k, /* Zilog Z8000 */ +#define bfd_mach_z8001 1 +#define bfd_mach_z8002 2 + bfd_arch_h8500, /* Hitachi H8/500 */ + bfd_arch_sh, /* Hitachi SH */ +#define bfd_mach_sh 0 +#define bfd_mach_sh2 0x20 +#define bfd_mach_sh_dsp 0x2d +#define bfd_mach_sh3 0x30 +#define bfd_mach_sh3_dsp 0x3d +#define bfd_mach_sh3e 0x3e +#define bfd_mach_sh4 0x40 + bfd_arch_alpha, /* Dec Alpha */ +#define bfd_mach_alpha_ev4 0x10 +#define bfd_mach_alpha_ev5 0x20 +#define bfd_mach_alpha_ev6 0x30 + bfd_arch_arm, /* Advanced Risc Machines ARM */ +#define bfd_mach_arm_2 1 +#define bfd_mach_arm_2a 2 +#define bfd_mach_arm_3 3 +#define bfd_mach_arm_3M 4 +#define bfd_mach_arm_4 5 +#define bfd_mach_arm_4T 6 +#define bfd_mach_arm_5 7 +#define bfd_mach_arm_5T 8 + bfd_arch_ns32k, /* National Semiconductors ns32000 */ + bfd_arch_w65, /* WDC 65816 */ + bfd_arch_tic30, /* Texas Instruments TMS320C30 */ + bfd_arch_tic54x, /* Texas Instruments TMS320C54X */ + bfd_arch_tic80, /* TI TMS320c80 (MVP) */ + bfd_arch_v850, /* NEC V850 */ +#define bfd_mach_v850 0 +#define bfd_mach_v850e 'E' +#define bfd_mach_v850ea 'A' + bfd_arch_arc, /* Argonaut RISC Core */ +#define bfd_mach_arc_base 0 + bfd_arch_m32r, /* Mitsubishi M32R/D */ +#define bfd_mach_m32r 0 /* backwards compatibility */ +#define bfd_mach_m32rx 'x' + bfd_arch_mn10200, /* Matsushita MN10200 */ + bfd_arch_mn10300, /* Matsushita MN10300 */ +#define bfd_mach_mn10300 300 +#define bfd_mach_am33 330 + bfd_arch_fr30, +#define bfd_mach_fr30 0x46523330 + bfd_arch_mcore, + bfd_arch_pj, + bfd_arch_avr, /* Atmel AVR microcontrollers */ +#define bfd_mach_avr1 1 +#define bfd_mach_avr2 2 +#define bfd_mach_avr3 3 +#define bfd_mach_avr4 4 + bfd_arch_last + @}; +@end example + +@subsection bfd_arch_info + + +@strong{Description}@* +This structure contains information on architectures for use +within BFD. +@example + +typedef struct bfd_arch_info +@{ + int bits_per_word; + int bits_per_address; + int bits_per_byte; + enum bfd_architecture arch; + unsigned long mach; + const char *arch_name; + const char *printable_name; + unsigned int section_align_power; + /* true if this is the default machine for the architecture */ + boolean the_default; + const struct bfd_arch_info * (*compatible) + PARAMS ((const struct bfd_arch_info *a, + const struct bfd_arch_info *b)); + + boolean (*scan) PARAMS ((const struct bfd_arch_info *, const char *)); + + const struct bfd_arch_info *next; +@} bfd_arch_info_type; +@end example + +@findex bfd_printable_name +@subsubsection @code{bfd_printable_name} +@strong{Synopsis} +@example +const char *bfd_printable_name(bfd *abfd); +@end example +@strong{Description}@* +Return a printable string representing the architecture and machine +from the pointer to the architecture info structure. + +@findex bfd_scan_arch +@subsubsection @code{bfd_scan_arch} +@strong{Synopsis} +@example +const bfd_arch_info_type *bfd_scan_arch(const char *string); +@end example +@strong{Description}@* +Figure out if BFD supports any cpu which could be described with +the name @var{string}. Return a pointer to an @code{arch_info} +structure if a machine is found, otherwise NULL. + +@findex bfd_arch_list +@subsubsection @code{bfd_arch_list} +@strong{Synopsis} +@example +const char **bfd_arch_list(void); +@end example +@strong{Description}@* +Return a freshly malloced NULL-terminated vector of the names +of all the valid BFD architectures. Do not modify the names. + +@findex bfd_arch_get_compatible +@subsubsection @code{bfd_arch_get_compatible} +@strong{Synopsis} +@example +const bfd_arch_info_type *bfd_arch_get_compatible( + const bfd *abfd, + const bfd *bbfd); +@end example +@strong{Description}@* +Determine whether two BFDs' +architectures and machine types are compatible. Calculates +the lowest common denominator between the two architectures +and machine types implied by the BFDs and returns a pointer to +an @code{arch_info} structure describing the compatible machine. + +@findex bfd_default_arch_struct +@subsubsection @code{bfd_default_arch_struct} +@strong{Description}@* +The @code{bfd_default_arch_struct} is an item of +@code{bfd_arch_info_type} which has been initialized to a fairly +generic state. A BFD starts life by pointing to this +structure, until the correct back end has determined the real +architecture of the file. +@example +extern const bfd_arch_info_type bfd_default_arch_struct; +@end example + +@findex bfd_set_arch_info +@subsubsection @code{bfd_set_arch_info} +@strong{Synopsis} +@example +void bfd_set_arch_info(bfd *abfd, const bfd_arch_info_type *arg); +@end example +@strong{Description}@* +Set the architecture info of @var{abfd} to @var{arg}. + +@findex bfd_default_set_arch_mach +@subsubsection @code{bfd_default_set_arch_mach} +@strong{Synopsis} +@example +boolean bfd_default_set_arch_mach(bfd *abfd, + enum bfd_architecture arch, + unsigned long mach); +@end example +@strong{Description}@* +Set the architecture and machine type in BFD @var{abfd} +to @var{arch} and @var{mach}. Find the correct +pointer to a structure and insert it into the @code{arch_info} +pointer. + +@findex bfd_get_arch +@subsubsection @code{bfd_get_arch} +@strong{Synopsis} +@example +enum bfd_architecture bfd_get_arch(bfd *abfd); +@end example +@strong{Description}@* +Return the enumerated type which describes the BFD @var{abfd}'s +architecture. + +@findex bfd_get_mach +@subsubsection @code{bfd_get_mach} +@strong{Synopsis} +@example +unsigned long bfd_get_mach(bfd *abfd); +@end example +@strong{Description}@* +Return the long type which describes the BFD @var{abfd}'s +machine. + +@findex bfd_arch_bits_per_byte +@subsubsection @code{bfd_arch_bits_per_byte} +@strong{Synopsis} +@example +unsigned int bfd_arch_bits_per_byte(bfd *abfd); +@end example +@strong{Description}@* +Return the number of bits in one of the BFD @var{abfd}'s +architecture's bytes. + +@findex bfd_arch_bits_per_address +@subsubsection @code{bfd_arch_bits_per_address} +@strong{Synopsis} +@example +unsigned int bfd_arch_bits_per_address(bfd *abfd); +@end example +@strong{Description}@* +Return the number of bits in one of the BFD @var{abfd}'s +architecture's addresses. + +@findex bfd_default_compatible +@subsubsection @code{bfd_default_compatible} +@strong{Synopsis} +@example +const bfd_arch_info_type *bfd_default_compatible + (const bfd_arch_info_type *a, + const bfd_arch_info_type *b); +@end example +@strong{Description}@* +The default function for testing for compatibility. + +@findex bfd_default_scan +@subsubsection @code{bfd_default_scan} +@strong{Synopsis} +@example +boolean bfd_default_scan(const struct bfd_arch_info *info, const char *string); +@end example +@strong{Description}@* +The default function for working out whether this is an +architecture hit and a machine hit. + +@findex bfd_get_arch_info +@subsubsection @code{bfd_get_arch_info} +@strong{Synopsis} +@example +const bfd_arch_info_type * bfd_get_arch_info(bfd *abfd); +@end example +@strong{Description}@* +Return the architecture info struct in @var{abfd}. + +@findex bfd_lookup_arch +@subsubsection @code{bfd_lookup_arch} +@strong{Synopsis} +@example +const bfd_arch_info_type *bfd_lookup_arch + (enum bfd_architecture + arch, + unsigned long machine); +@end example +@strong{Description}@* +Look for the architecure info structure which matches the +arguments @var{arch} and @var{machine}. A machine of 0 matches the +machine/architecture structure which marks itself as the +default. + +@findex bfd_printable_arch_mach +@subsubsection @code{bfd_printable_arch_mach} +@strong{Synopsis} +@example +const char *bfd_printable_arch_mach + (enum bfd_architecture arch, unsigned long machine); +@end example +@strong{Description}@* +Return a printable string representing the architecture and +machine type. + +This routine is depreciated. + +@findex bfd_octets_per_byte +@subsubsection @code{bfd_octets_per_byte} +@strong{Synopsis} +@example +unsigned int bfd_octets_per_byte(bfd *abfd); +@end example +@strong{Description}@* +Return the number of octets (8-bit quantities) per target byte +(minimum addressable unit). In most cases, this will be one, but some +DSP targets have 16, 32, or even 48 bits per byte. + +@findex bfd_arch_mach_octets_per_byte +@subsubsection @code{bfd_arch_mach_octets_per_byte} +@strong{Synopsis} +@example +unsigned int bfd_arch_mach_octets_per_byte(enum bfd_architecture arch, + unsigned long machine); +@end example +@strong{Description}@* +See bfd_octets_per_byte. +This routine is provided for those cases where a bfd * is not +available + Index: bfd.info =================================================================== --- bfd.info (nonexistent) +++ bfd.info (revision 1765) @@ -0,0 +1,95 @@ +This is bfd.info, produced by Makeinfo version 3.12f from bfd.texinfo. + +START-INFO-DIR-ENTRY +* Bfd: (bfd). The Binary File Descriptor library. +END-INFO-DIR-ENTRY + + This file documents the BFD library. + + Copyright (C) 1991 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, subject to the +terms of the GNU General Public License, which includes the provision +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. + + +Indirect: +bfd.info-1: 918 +bfd.info-2: 37732 +bfd.info-3: 82094 +bfd.info-4: 128064 +bfd.info-5: 177803 +bfd.info-6: 207738 +bfd.info-7: 235343 + +Tag Table: +(Indirect) +Node: Top918 +Node: Overview1183 +Node: History2233 +Node: How It Works3174 +Node: What BFD Version 2 Can Do4715 +Node: BFD information loss6029 +Node: Canonical format8552 +Node: BFD front end12913 +Node: Memory Usage31830 +Node: Initialization33053 +Node: Sections33430 +Node: Section Input33908 +Node: Section Output35264 +Node: typedef asection37732 +Node: section prototypes53756 +Node: Symbols59970 +Node: Reading Symbols61560 +Node: Writing Symbols62734 +Node: Mini Symbols64424 +Node: typedef asymbol65389 +Node: symbol handling functions70618 +Node: Archives74947 +Node: Formats78565 +Node: Relocations81375 +Node: typedef arelent82094 +Node: howto manager98253 +Node: Core Files125080 +Node: Targets126101 +Node: bfd_target128064 +Node: Architectures146974 +Node: Opening and Closing160346 +Node: Internal164743 +Node: File Caching170741 +Node: Linker Functions173519 +Node: Creating a Linker Hash Table175185 +Node: Adding Symbols to the Hash Table176913 +Node: Differing file formats177803 +Node: Adding symbols from an object file179536 +Node: Adding symbols from an archive181672 +Node: Performing the Final Link184071 +Node: Information provided by the linker185302 +Node: Relocating the section contents186438 +Node: Writing the symbol table188175 +Node: Hash Tables190769 +Node: Creating and Freeing a Hash Table191960 +Node: Looking Up or Entering a String193117 +Node: Traversing a Hash Table194359 +Node: Deriving a New Hash Table Type195137 +Node: Define the Derived Structures196192 +Node: Write the Derived Creation Routine197258 +Node: Write Other Derived Routines199957 +Node: BFD back ends201257 +Node: What to Put Where201476 +Node: aout201614 +Node: coff207738 +Node: elf234510 +Node: Index235343 + +End Tag Table Index: bfd.info-3 =================================================================== --- bfd.info-3 (nonexistent) +++ bfd.info-3 (revision 1765) @@ -0,0 +1,1331 @@ +This is bfd.info, produced by Makeinfo version 3.12f from bfd.texinfo. + +START-INFO-DIR-ENTRY +* Bfd: (bfd). The Binary File Descriptor library. +END-INFO-DIR-ENTRY + + This file documents the BFD library. + + Copyright (C) 1991 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, subject to the +terms of the GNU General Public License, which includes the provision +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: bfd.info, Node: typedef arelent, Next: howto manager, Prev: Relocations, Up: Relocations + +typedef arelent +--------------- + + This is the structure of a relocation entry: + + + typedef enum bfd_reloc_status + { + /* No errors detected */ + bfd_reloc_ok, + + /* The relocation was performed, but there was an overflow. */ + bfd_reloc_overflow, + + /* The address to relocate was not within the section supplied. */ + bfd_reloc_outofrange, + + /* Used by special functions */ + bfd_reloc_continue, + + /* Unsupported relocation size requested. */ + bfd_reloc_notsupported, + + /* Unused */ + bfd_reloc_other, + + /* The symbol to relocate against was undefined. */ + bfd_reloc_undefined, + + /* The relocation was performed, but may not be ok - presently + generated only when linking i960 coff files with i960 b.out + symbols. If this type is returned, the error_message argument + to bfd_perform_relocation will be set. */ + bfd_reloc_dangerous + } + bfd_reloc_status_type; + + + typedef struct reloc_cache_entry + { + /* A pointer into the canonical table of pointers */ + struct symbol_cache_entry **sym_ptr_ptr; + + /* offset in section */ + bfd_size_type address; + + /* addend for relocation value */ + bfd_vma addend; + + /* Pointer to how to perform the required relocation */ + reloc_howto_type *howto; + + } arelent; + *Description* +Here is a description of each of the fields within an `arelent': + + * `sym_ptr_ptr' + The symbol table pointer points to a pointer to the symbol +associated with the relocation request. It is the pointer into the +table returned by the back end's `get_symtab' action. *Note Symbols::. +The symbol is referenced through a pointer to a pointer so that tools +like the linker can fix up 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 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. + + * `address' + The `address' field gives the offset in bytes from the base of the +section data which owns the relocation record to the first byte of +relocatable information. The actual data relocated will be relative to +this point; for example, a relocation type which modifies the bottom +two bytes of a four byte word would not touch the first byte pointed to +in a big endian world. + + * `addend' + The `addend' is a value provided by the back end to be added (!) to +the relocation offset. Its interpretation is dependent upon the howto. +For example, on the 68k the code: + + char foo[]; + main() + { + return foo[0x12345678]; + } + + Could be compiled into: + + linkw fp,#-4 + moveb @#12345678,d0 + extbl d0 + unlk fp + rts + + This could create a reloc pointing to `foo', but leave the offset in +the data, something like: + + RELOCATION RECORDS FOR [.text]: + offset type value + 00000006 32 _foo + + 00000000 4e56 fffc ; linkw fp,#-4 + 00000004 1039 1234 5678 ; moveb @#12345678,d0 + 0000000a 49c0 ; extbl d0 + 0000000c 4e5e ; unlk fp + 0000000e 4e75 ; rts + + Using coff and an 88k, some instructions don't have enough space in +them to represent the full address range, and pointers have to be +loaded in two parts. So you'd get something like: + + or.u r13,r0,hi16(_foo+0x12345678) + ld.b r2,r13,lo16(_foo+0x12345678) + jmp r1 + + This should create two relocs, both pointing to `_foo', and with +0x12340000 in their addend field. The data would consist of: + + RELOCATION RECORDS FOR [.text]: + offset type value + 00000002 HVRT16 _foo+0x12340000 + 00000006 LVRT16 _foo+0x12340000 + + 00000000 5da05678 ; or.u r13,r0,0x5678 + 00000004 1c4d5678 ; ld.b r2,r13,0x5678 + 00000008 f400c001 ; jmp r1 + + The relocation routine digs out the value from the data, adds it to +the addend to get the original offset, and then adds the value of +`_foo'. Note that all 32 bits have to be kept around somewhere, to cope +with carry from bit 15 to bit 16. + + One further example is the sparc and the a.out format. The sparc has +a similar problem to the 88k, in that some instructions don't have room +for an entire offset, but on the sparc the parts are created in odd +sized lumps. The designers of the a.out format chose to not use the +data within the section for storing part of the offset; all the offset +is kept within the reloc. Anything in the data should be ignored. + + save %sp,-112,%sp + sethi %hi(_foo+0x12345678),%g2 + ldsb [%g2+%lo(_foo+0x12345678)],%i0 + ret + restore + + Both relocs contain a pointer to `foo', and the offsets contain junk. + + RELOCATION RECORDS FOR [.text]: + offset type value + 00000004 HI22 _foo+0x12345678 + 00000008 LO10 _foo+0x12345678 + + 00000000 9de3bf90 ; save %sp,-112,%sp + 00000004 05000000 ; sethi %hi(_foo+0),%g2 + 00000008 f048a000 ; ldsb [%g2+%lo(_foo+0)],%i0 + 0000000c 81c7e008 ; ret + 00000010 81e80000 ; restore + + * `howto' + The `howto' field can be imagined as a relocation instruction. It is +a pointer to a structure which contains information on what to do with +all of the other information in the reloc record and data section. A +back end would normally have a relocation instruction set and turn +relocations into pointers to the correct structure on input - but it +would be possible to create each howto field on demand. + +`enum complain_overflow' +........................ + + Indicates what sort of overflow checking should be done when +performing a relocation. + + + enum complain_overflow + { + /* Do not complain on overflow. */ + complain_overflow_dont, + + /* Complain if the bitfield overflows, whether it is considered + as signed or unsigned. */ + complain_overflow_bitfield, + + /* Complain if the value overflows when considered as signed + number. */ + complain_overflow_signed, + + /* Complain if the value overflows when considered as an + unsigned number. */ + complain_overflow_unsigned + }; + +`reloc_howto_type' +.................. + + The `reloc_howto_type' is a structure which contains all the +information that libbfd needs to know to tie up a back end's data. + + struct symbol_cache_entry; /* Forward declaration */ + + struct reloc_howto_struct + { + /* The type field has mainly a documentary use - the back end can + do what it wants with it, though normally the back end's + external idea of what a reloc number is stored + in this field. For example, a PC relative word relocation + in a coff environment has the type 023 - because that's + what the outside world calls a R_PCRWORD reloc. */ + unsigned int type; + + /* The value the final relocation is shifted right by. This drops + unwanted data from the relocation. */ + unsigned int rightshift; + + /* The size of the item to be relocated. This is *not* a + power-of-two measure. To get the number of bytes operated + on by a type of relocation, use bfd_get_reloc_size. */ + int size; + + /* The number of bits in the item to be relocated. This is used + when doing overflow checking. */ + unsigned int bitsize; + + /* Notes that the relocation is relative to the location in the + data section of the addend. The relocation function will + subtract from the relocation value the address of the location + being relocated. */ + boolean pc_relative; + + /* The bit position of the reloc value in the destination. + The relocated value is left shifted by this amount. */ + unsigned int bitpos; + + /* What type of overflow error should be checked for when + relocating. */ + enum complain_overflow complain_on_overflow; + + /* If this field is non null, then the supplied function is + called rather than the normal function. This allows really + strange relocation methods to be accomodated (e.g., i960 callj + instructions). */ + bfd_reloc_status_type (*special_function) + PARAMS ((bfd *abfd, + arelent *reloc_entry, + struct symbol_cache_entry *symbol, + PTR data, + asection *input_section, + bfd *output_bfd, + char **error_message)); + + /* The textual name of the relocation type. */ + char *name; + + /* Some formats record a relocation addend in the section contents + rather than with the relocation. For ELF formats this is the + distinction between USE_REL and USE_RELA (though the code checks + for USE_REL == 1/0). The value of this field is TRUE if the + addend is recorded with the section contents; when performing a + partial link (ld -r) the section contents (the data) will be + modified. The value of this field is FALSE if addends are + recorded with the relocation (in arelent.addend); when performing + a partial link the relocation will be modified. + All relocations for all ELF USE_RELA targets should set this field + to FALSE (values of TRUE should be looked on with suspicion). + However, the converse is not true: not all relocations of all ELF + USE_REL targets set this field to TRUE. Why this is so is peculiar + to each particular target. For relocs that aren't used in partial + links (e.g. GOT stuff) it doesn't matter what this is set to. */ + boolean partial_inplace; + + /* The src_mask selects which parts of the read in data + are to be used in the relocation sum. E.g., if this was an 8 bit + byte of data which we read and relocated, this would be + 0x000000ff. When we have relocs which have an addend, such as + sun4 extended relocs, the value in the offset part of a + relocating field is garbage so we never use it. In this case + the mask would be 0x00000000. */ + bfd_vma src_mask; + + /* The dst_mask selects which parts of the instruction are replaced + into the instruction. In most cases src_mask == dst_mask, + except in the above special case, where dst_mask would be + 0x000000ff, and src_mask would be 0x00000000. */ + bfd_vma dst_mask; + + /* When some formats create PC relative instructions, they leave + the value of the pc of the place being relocated in the offset + slot of the instruction, so that a PC relative relocation can + be made just by adding in an ordinary offset (e.g., sun3 a.out). + Some formats leave the displacement part of an instruction + empty (e.g., m88k bcs); this flag signals the fact.*/ + boolean pcrel_offset; + + }; + +`The HOWTO Macro' +................. + + *Description* +The HOWTO define is horrible and will go away. + #define HOWTO(C, R,S,B, P, BI, O, SF, NAME, INPLACE, MASKSRC, MASKDST, PC) \ + {(unsigned)C,R,S,B, P, BI, O,SF,NAME,INPLACE,MASKSRC,MASKDST,PC} + + *Description* +And will be replaced with the totally magic way. But for the moment, we +are compatible, so do it this way. + #define NEWHOWTO( FUNCTION, NAME,SIZE,REL,IN) HOWTO(0,0,SIZE,0,REL,0,complain_overflow_dont,FUNCTION, NAME,false,0,0,IN) + + *Description* +This is used to fill in an empty howto entry in an array. + #define EMPTY_HOWTO(C) \ + HOWTO((C),0,0,0,false,0,complain_overflow_dont,NULL,NULL,false,0,0,false) + + *Description* +Helper routine to turn a symbol into a relocation value. + #define HOWTO_PREPARE(relocation, symbol) \ + { \ + if (symbol != (asymbol *)NULL) { \ + if (bfd_is_com_section (symbol->section)) { \ + relocation = 0; \ + } \ + else { \ + relocation = symbol->value; \ + } \ + } \ + } + +`bfd_get_reloc_size' +.................... + + *Synopsis* + unsigned int bfd_get_reloc_size (reloc_howto_type *); + *Description* +For a reloc_howto_type that operates on a fixed number of bytes, this +returns the number of bytes operated on. + +`arelent_chain' +............... + + *Description* +How relocs are tied together in an `asection': + typedef struct relent_chain { + arelent relent; + struct relent_chain *next; + } arelent_chain; + +`bfd_check_overflow' +.................... + + *Synopsis* + bfd_reloc_status_type + bfd_check_overflow + (enum complain_overflow how, + unsigned int bitsize, + unsigned int rightshift, + unsigned int addrsize, + bfd_vma relocation); + *Description* +Perform overflow checking on RELOCATION which has BITSIZE significant +bits and will be shifted right by RIGHTSHIFT bits, on a machine with +addresses containing ADDRSIZE significant bits. The result is either of +`bfd_reloc_ok' or `bfd_reloc_overflow'. + +`bfd_perform_relocation' +........................ + + *Synopsis* + bfd_reloc_status_type + bfd_perform_relocation + (bfd *abfd, + arelent *reloc_entry, + PTR data, + asection *input_section, + bfd *output_bfd, + char **error_message); + *Description* +If OUTPUT_BFD is supplied to this function, the generated image will be +relocatable; the relocations are copied to the output file after they +have been changed to reflect the new state of the world. There are two +ways of reflecting the results of partial linkage in an output file: by +modifying the output data in place, and by modifying the relocation +record. Some native formats (e.g., basic a.out and basic coff) have no +way of specifying an addend in the relocation type, so the addend has +to go in the output data. This is no big deal since in these formats +the output data slot will always be big enough for the addend. Complex +reloc types with addends were invented to solve just this problem. The +ERROR_MESSAGE argument is set to an error message if this return +`bfd_reloc_dangerous'. + +`bfd_install_relocation' +........................ + + *Synopsis* + bfd_reloc_status_type + bfd_install_relocation + (bfd *abfd, + arelent *reloc_entry, + PTR data, bfd_vma data_start, + asection *input_section, + char **error_message); + *Description* +This looks remarkably like `bfd_perform_relocation', except it does not +expect that the section contents have been filled in. I.e., it's +suitable for use when creating, rather than applying a relocation. + + For now, this function should be considered reserved for the +assembler. + + +File: bfd.info, Node: howto manager, Prev: typedef arelent, Up: Relocations + +The howto manager +================= + + When an application wants to create a relocation, but doesn't know +what the target machine might call it, it can find out by using this +bit of code. + +`bfd_reloc_code_type' +..................... + + *Description* +The insides of a reloc code. The idea is that, eventually, there will +be one enumerator for every type of relocation we ever do. Pass one of +these values to `bfd_reloc_type_lookup', and it'll return a howto +pointer. + + This does mean that the application must determine the correct +enumerator value; you can't get a howto pointer from a random set of +attributes. + + Here are the possible values for `enum bfd_reloc_code_real': + + - : BFD_RELOC_64 + - : BFD_RELOC_32 + - : BFD_RELOC_26 + - : BFD_RELOC_24 + - : BFD_RELOC_16 + - : BFD_RELOC_14 + - : BFD_RELOC_8 + Basic absolute relocations of N bits. + + - : BFD_RELOC_64_PCREL + - : BFD_RELOC_32_PCREL + - : BFD_RELOC_24_PCREL + - : BFD_RELOC_16_PCREL + - : BFD_RELOC_12_PCREL + - : BFD_RELOC_8_PCREL + PC-relative relocations. Sometimes these are relative to the + address of the relocation itself; sometimes they are relative to + the start of the section containing the relocation. It depends on + the specific target. + + The 24-bit relocation is used in some Intel 960 configurations. + + - : BFD_RELOC_32_GOT_PCREL + - : BFD_RELOC_16_GOT_PCREL + - : BFD_RELOC_8_GOT_PCREL + - : BFD_RELOC_32_GOTOFF + - : BFD_RELOC_16_GOTOFF + - : BFD_RELOC_LO16_GOTOFF + - : BFD_RELOC_HI16_GOTOFF + - : BFD_RELOC_HI16_S_GOTOFF + - : BFD_RELOC_8_GOTOFF + - : BFD_RELOC_32_PLT_PCREL + - : BFD_RELOC_24_PLT_PCREL + - : BFD_RELOC_16_PLT_PCREL + - : BFD_RELOC_8_PLT_PCREL + - : BFD_RELOC_32_PLTOFF + - : BFD_RELOC_16_PLTOFF + - : BFD_RELOC_LO16_PLTOFF + - : BFD_RELOC_HI16_PLTOFF + - : BFD_RELOC_HI16_S_PLTOFF + - : BFD_RELOC_8_PLTOFF + For ELF. + + - : BFD_RELOC_68K_GLOB_DAT + - : BFD_RELOC_68K_JMP_SLOT + - : BFD_RELOC_68K_RELATIVE + Relocations used by 68K ELF. + + - : BFD_RELOC_32_BASEREL + - : BFD_RELOC_16_BASEREL + - : BFD_RELOC_LO16_BASEREL + - : BFD_RELOC_HI16_BASEREL + - : BFD_RELOC_HI16_S_BASEREL + - : BFD_RELOC_8_BASEREL + - : BFD_RELOC_RVA + Linkage-table relative. + + - : BFD_RELOC_8_FFnn + Absolute 8-bit relocation, but used to form an address like 0xFFnn. + + - : BFD_RELOC_32_PCREL_S2 + - : BFD_RELOC_16_PCREL_S2 + - : BFD_RELOC_23_PCREL_S2 + These PC-relative relocations are stored as word displacements - + i.e., byte displacements shifted right two bits. The 30-bit word + displacement (<<32_PCREL_S2>> - 32 bits, shifted 2) is used on the + SPARC. (SPARC tools generally refer to this as <>.) The + signed 16-bit displacement is used on the MIPS, and the 23-bit + displacement is used on the Alpha. + + - : BFD_RELOC_HI22 + - : BFD_RELOC_LO10 + High 22 bits and low 10 bits of 32-bit value, placed into lower + bits of the target word. These are used on the SPARC. + + - : BFD_RELOC_GPREL16 + - : BFD_RELOC_GPREL32 + For systems that allocate a Global Pointer register, these are + displacements off that register. These relocation types are + handled specially, because the value the register will have is + decided relatively late. + + - : BFD_RELOC_I960_CALLJ + Reloc types used for i960/b.out. + + - : BFD_RELOC_NONE + - : BFD_RELOC_SPARC_WDISP22 + - : BFD_RELOC_SPARC22 + - : BFD_RELOC_SPARC13 + - : BFD_RELOC_SPARC_GOT10 + - : BFD_RELOC_SPARC_GOT13 + - : BFD_RELOC_SPARC_GOT22 + - : BFD_RELOC_SPARC_PC10 + - : BFD_RELOC_SPARC_PC22 + - : BFD_RELOC_SPARC_WPLT30 + - : BFD_RELOC_SPARC_COPY + - : BFD_RELOC_SPARC_GLOB_DAT + - : BFD_RELOC_SPARC_JMP_SLOT + - : BFD_RELOC_SPARC_RELATIVE + - : BFD_RELOC_SPARC_UA32 + SPARC ELF relocations. There is probably some overlap with other + relocation types already defined. + + - : BFD_RELOC_SPARC_BASE13 + - : BFD_RELOC_SPARC_BASE22 + I think these are specific to SPARC a.out (e.g., Sun 4). + + - : BFD_RELOC_SPARC_64 + - : BFD_RELOC_SPARC_10 + - : BFD_RELOC_SPARC_11 + - : BFD_RELOC_SPARC_OLO10 + - : BFD_RELOC_SPARC_HH22 + - : BFD_RELOC_SPARC_HM10 + - : BFD_RELOC_SPARC_LM22 + - : BFD_RELOC_SPARC_PC_HH22 + - : BFD_RELOC_SPARC_PC_HM10 + - : BFD_RELOC_SPARC_PC_LM22 + - : BFD_RELOC_SPARC_WDISP16 + - : BFD_RELOC_SPARC_WDISP19 + - : BFD_RELOC_SPARC_7 + - : BFD_RELOC_SPARC_6 + - : BFD_RELOC_SPARC_5 + - : BFD_RELOC_SPARC_DISP64 + - : BFD_RELOC_SPARC_PLT64 + - : BFD_RELOC_SPARC_HIX22 + - : BFD_RELOC_SPARC_LOX10 + - : BFD_RELOC_SPARC_H44 + - : BFD_RELOC_SPARC_M44 + - : BFD_RELOC_SPARC_L44 + - : BFD_RELOC_SPARC_REGISTER + SPARC64 relocations + + - : BFD_RELOC_SPARC_REV32 + SPARC little endian relocation + + - : BFD_RELOC_ALPHA_GPDISP_HI16 + Alpha ECOFF and ELF relocations. Some of these treat the symbol or + "addend" in some special way. For GPDISP_HI16 ("gpdisp") + relocations, the symbol is ignored when writing; when reading, it + will be the absolute section symbol. The addend is the + displacement in bytes of the "lda" instruction from the "ldah" + instruction (which is at the address of this reloc). + + - : BFD_RELOC_ALPHA_GPDISP_LO16 + For GPDISP_LO16 ("ignore") relocations, the symbol is handled as + with GPDISP_HI16 relocs. The addend is ignored when writing the + relocations out, and is filled in with the file's GP value on + reading, for convenience. + + - : BFD_RELOC_ALPHA_GPDISP + The ELF GPDISP relocation is exactly the same as the GPDISP_HI16 + relocation except that there is no accompanying GPDISP_LO16 + relocation. + + - : BFD_RELOC_ALPHA_LITERAL + - : BFD_RELOC_ALPHA_ELF_LITERAL + - : BFD_RELOC_ALPHA_LITUSE + The Alpha LITERAL/LITUSE relocs are produced by a symbol reference; + the assembler turns it into a LDQ instruction to load the address + of the symbol, and then fills in a register in the real + instruction. + + The LITERAL reloc, at the LDQ instruction, refers to the .lita + section symbol. The addend is ignored when writing, but is filled + in with the file's GP value on reading, for convenience, as with + the GPDISP_LO16 reloc. + + The ELF_LITERAL reloc is somewhere between 16_GOTOFF and + GPDISP_LO16. It should refer to the symbol to be referenced, as + with 16_GOTOFF, but it generates output not based on the position + within the .got section, but relative to the GP value chosen for + the file during the final link stage. + + The LITUSE reloc, on the instruction using the loaded address, + gives information to the linker that it might be able to use to + optimize away some literal section references. The symbol is + ignored (read as the absolute section symbol), and the "addend" + indicates the type of instruction using the register: 1 - "memory" + fmt insn 2 - byte-manipulation (byte offset reg) 3 - jsr (target + of branch) + + The GNU linker currently doesn't do any of this optimizing. + + - : BFD_RELOC_ALPHA_USER_LITERAL + - : BFD_RELOC_ALPHA_USER_LITUSE_BASE + - : BFD_RELOC_ALPHA_USER_LITUSE_BYTOFF + - : BFD_RELOC_ALPHA_USER_LITUSE_JSR + - : BFD_RELOC_ALPHA_USER_GPDISP + - : BFD_RELOC_ALPHA_USER_GPRELHIGH + - : BFD_RELOC_ALPHA_USER_GPRELLOW + The BFD_RELOC_ALPHA_USER_* relocations are used by the assembler to + process the explicit !!sequence relocations, and are mapped + into the normal relocations at the end of processing. + + - : BFD_RELOC_ALPHA_HINT + The HINT relocation indicates a value that should be filled into + the "hint" field of a jmp/jsr/ret instruction, for possible branch- + prediction logic which may be provided on some processors. + + - : BFD_RELOC_ALPHA_LINKAGE + The LINKAGE relocation outputs a linkage pair in the object file, + which is filled by the linker. + + - : BFD_RELOC_ALPHA_CODEADDR + The CODEADDR relocation outputs a STO_CA in the object file, which + is filled by the linker. + + - : BFD_RELOC_MIPS_JMP + Bits 27..2 of the relocation address shifted right 2 bits; simple + reloc otherwise. + + - : BFD_RELOC_MIPS16_JMP + The MIPS16 jump instruction. + + - : BFD_RELOC_MIPS16_GPREL + MIPS16 GP relative reloc. + + - : BFD_RELOC_HI16 + High 16 bits of 32-bit value; simple reloc. + + - : BFD_RELOC_HI16_S + High 16 bits of 32-bit value but the low 16 bits will be sign + extended and added to form the final result. If the low 16 bits + form a negative number, we need to add one to the high value to + compensate for the borrow when the low bits are added. + + - : BFD_RELOC_LO16 + Low 16 bits. + + - : BFD_RELOC_PCREL_HI16_S + Like BFD_RELOC_HI16_S, but PC relative. + + - : BFD_RELOC_PCREL_LO16 + Like BFD_RELOC_LO16, but PC relative. + + - : BFD_RELOC_MIPS_GPREL + Relocation relative to the global pointer. + + - : BFD_RELOC_MIPS_LITERAL + Relocation against a MIPS literal section. + + - : BFD_RELOC_MIPS_GOT16 + - : BFD_RELOC_MIPS_CALL16 + - : BFD_RELOC_MIPS_GPREL32 + - : BFD_RELOC_MIPS_GOT_HI16 + - : BFD_RELOC_MIPS_GOT_LO16 + - : BFD_RELOC_MIPS_CALL_HI16 + - : BFD_RELOC_MIPS_CALL_LO16 + - : BFD_RELOC_MIPS_SUB + - : BFD_RELOC_MIPS_GOT_PAGE + - : BFD_RELOC_MIPS_GOT_OFST + - : BFD_RELOC_MIPS_GOT_DISP + MIPS ELF relocations. + + - : BFD_RELOC_386_GOT32 + - : BFD_RELOC_386_PLT32 + - : BFD_RELOC_386_COPY + - : BFD_RELOC_386_GLOB_DAT + - : BFD_RELOC_386_JUMP_SLOT + - : BFD_RELOC_386_RELATIVE + - : BFD_RELOC_386_GOTOFF + - : BFD_RELOC_386_GOTPC + i386/elf relocations + + - : BFD_RELOC_NS32K_IMM_8 + - : BFD_RELOC_NS32K_IMM_16 + - : BFD_RELOC_NS32K_IMM_32 + - : BFD_RELOC_NS32K_IMM_8_PCREL + - : BFD_RELOC_NS32K_IMM_16_PCREL + - : BFD_RELOC_NS32K_IMM_32_PCREL + - : BFD_RELOC_NS32K_DISP_8 + - : BFD_RELOC_NS32K_DISP_16 + - : BFD_RELOC_NS32K_DISP_32 + - : BFD_RELOC_NS32K_DISP_8_PCREL + - : BFD_RELOC_NS32K_DISP_16_PCREL + - : BFD_RELOC_NS32K_DISP_32_PCREL + ns32k relocations + + - : BFD_RELOC_PJ_CODE_HI16 + - : BFD_RELOC_PJ_CODE_LO16 + - : BFD_RELOC_PJ_CODE_DIR16 + - : BFD_RELOC_PJ_CODE_DIR32 + - : BFD_RELOC_PJ_CODE_REL16 + - : BFD_RELOC_PJ_CODE_REL32 + Picojava relocs. Not all of these appear in object files. + + - : BFD_RELOC_PPC_B26 + - : BFD_RELOC_PPC_BA26 + - : BFD_RELOC_PPC_TOC16 + - : BFD_RELOC_PPC_B16 + - : BFD_RELOC_PPC_B16_BRTAKEN + - : BFD_RELOC_PPC_B16_BRNTAKEN + - : BFD_RELOC_PPC_BA16 + - : BFD_RELOC_PPC_BA16_BRTAKEN + - : BFD_RELOC_PPC_BA16_BRNTAKEN + - : BFD_RELOC_PPC_COPY + - : BFD_RELOC_PPC_GLOB_DAT + - : BFD_RELOC_PPC_JMP_SLOT + - : BFD_RELOC_PPC_RELATIVE + - : BFD_RELOC_PPC_LOCAL24PC + - : BFD_RELOC_PPC_EMB_NADDR32 + - : BFD_RELOC_PPC_EMB_NADDR16 + - : BFD_RELOC_PPC_EMB_NADDR16_LO + - : BFD_RELOC_PPC_EMB_NADDR16_HI + - : BFD_RELOC_PPC_EMB_NADDR16_HA + - : BFD_RELOC_PPC_EMB_SDAI16 + - : BFD_RELOC_PPC_EMB_SDA2I16 + - : BFD_RELOC_PPC_EMB_SDA2REL + - : BFD_RELOC_PPC_EMB_SDA21 + - : BFD_RELOC_PPC_EMB_MRKREF + - : BFD_RELOC_PPC_EMB_RELSEC16 + - : BFD_RELOC_PPC_EMB_RELST_LO + - : BFD_RELOC_PPC_EMB_RELST_HI + - : BFD_RELOC_PPC_EMB_RELST_HA + - : BFD_RELOC_PPC_EMB_BIT_FLD + - : BFD_RELOC_PPC_EMB_RELSDA + Power(rs6000) and PowerPC relocations. + + - : BFD_RELOC_I370_D12 + IBM 370/390 relocations + + - : BFD_RELOC_CTOR + The type of reloc used to build a contructor table - at the moment + probably a 32 bit wide absolute relocation, but the target can + choose. It generally does map to one of the other relocation + types. + + - : BFD_RELOC_ARM_PCREL_BRANCH + ARM 26 bit pc-relative branch. The lowest two bits must be zero + and are not stored in the instruction. + + - : BFD_RELOC_ARM_PCREL_BLX + ARM 26 bit pc-relative branch. The lowest bit must be zero and is + not stored in the instruction. The 2nd lowest bit comes from a 1 + bit field in the instruction. + + - : BFD_RELOC_THUMB_PCREL_BLX + Thumb 22 bit pc-relative branch. The lowest bit must be zero and + is not stored in the instruction. The 2nd lowest bit comes from a + 1 bit field in the instruction. + + - : BFD_RELOC_ARM_IMMEDIATE + - : BFD_RELOC_ARM_ADRL_IMMEDIATE + - : BFD_RELOC_ARM_OFFSET_IMM + - : BFD_RELOC_ARM_SHIFT_IMM + - : BFD_RELOC_ARM_SWI + - : BFD_RELOC_ARM_MULTI + - : BFD_RELOC_ARM_CP_OFF_IMM + - : BFD_RELOC_ARM_ADR_IMM + - : BFD_RELOC_ARM_LDR_IMM + - : BFD_RELOC_ARM_LITERAL + - : BFD_RELOC_ARM_IN_POOL + - : BFD_RELOC_ARM_OFFSET_IMM8 + - : BFD_RELOC_ARM_HWLITERAL + - : BFD_RELOC_ARM_THUMB_ADD + - : BFD_RELOC_ARM_THUMB_IMM + - : BFD_RELOC_ARM_THUMB_SHIFT + - : BFD_RELOC_ARM_THUMB_OFFSET + - : BFD_RELOC_ARM_GOT12 + - : BFD_RELOC_ARM_GOT32 + - : BFD_RELOC_ARM_JUMP_SLOT + - : BFD_RELOC_ARM_COPY + - : BFD_RELOC_ARM_GLOB_DAT + - : BFD_RELOC_ARM_PLT32 + - : BFD_RELOC_ARM_RELATIVE + - : BFD_RELOC_ARM_GOTOFF + - : BFD_RELOC_ARM_GOTPC + These relocs are only used within the ARM assembler. They are not + (at present) written to any object files. + + - : BFD_RELOC_SH_PCDISP8BY2 + - : BFD_RELOC_SH_PCDISP12BY2 + - : BFD_RELOC_SH_IMM4 + - : BFD_RELOC_SH_IMM4BY2 + - : BFD_RELOC_SH_IMM4BY4 + - : BFD_RELOC_SH_IMM8 + - : BFD_RELOC_SH_IMM8BY2 + - : BFD_RELOC_SH_IMM8BY4 + - : BFD_RELOC_SH_PCRELIMM8BY2 + - : BFD_RELOC_SH_PCRELIMM8BY4 + - : BFD_RELOC_SH_SWITCH16 + - : BFD_RELOC_SH_SWITCH32 + - : BFD_RELOC_SH_USES + - : BFD_RELOC_SH_COUNT + - : BFD_RELOC_SH_ALIGN + - : BFD_RELOC_SH_CODE + - : BFD_RELOC_SH_DATA + - : BFD_RELOC_SH_LABEL + - : BFD_RELOC_SH_LOOP_START + - : BFD_RELOC_SH_LOOP_END + Hitachi SH relocs. Not all of these appear in object files. + + - : BFD_RELOC_THUMB_PCREL_BRANCH9 + - : BFD_RELOC_THUMB_PCREL_BRANCH12 + - : BFD_RELOC_THUMB_PCREL_BRANCH23 + Thumb 23-, 12- and 9-bit pc-relative branches. The lowest bit must + be zero and is not stored in the instruction. + + - : BFD_RELOC_ARC_B22_PCREL + Argonaut RISC Core (ARC) relocs. ARC 22 bit pc-relative branch. + The lowest two bits must be zero and are not stored in the + instruction. The high 20 bits are installed in bits 26 through 7 + of the instruction. + + - : BFD_RELOC_ARC_B26 + ARC 26 bit absolute branch. The lowest two bits must be zero and + are not stored in the instruction. The high 24 bits are installed + in bits 23 through 0. + + - : BFD_RELOC_D10V_10_PCREL_R + Mitsubishi D10V relocs. This is a 10-bit reloc with the right 2 + bits assumed to be 0. + + - : BFD_RELOC_D10V_10_PCREL_L + Mitsubishi D10V relocs. This is a 10-bit reloc with the right 2 + bits assumed to be 0. This is the same as the previous reloc + except it is in the left container, i.e., shifted left 15 bits. + + - : BFD_RELOC_D10V_18 + This is an 18-bit reloc with the right 2 bits assumed to be 0. + + - : BFD_RELOC_D10V_18_PCREL + This is an 18-bit reloc with the right 2 bits assumed to be 0. + + - : BFD_RELOC_D30V_6 + Mitsubishi D30V relocs. This is a 6-bit absolute reloc. + + - : BFD_RELOC_D30V_9_PCREL + This is a 6-bit pc-relative reloc with the right 3 bits assumed to + be 0. + + - : BFD_RELOC_D30V_9_PCREL_R + This is a 6-bit pc-relative reloc with the right 3 bits assumed to + be 0. Same as the previous reloc but on the right side of the + container. + + - : BFD_RELOC_D30V_15 + This is a 12-bit absolute reloc with the right 3 bitsassumed to be + 0. + + - : BFD_RELOC_D30V_15_PCREL + This is a 12-bit pc-relative reloc with the right 3 bits assumed + to be 0. + + - : BFD_RELOC_D30V_15_PCREL_R + This is a 12-bit pc-relative reloc with the right 3 bits assumed + to be 0. Same as the previous reloc but on the right side of the + container. + + - : BFD_RELOC_D30V_21 + This is an 18-bit absolute reloc with the right 3 bits assumed to + be 0. + + - : BFD_RELOC_D30V_21_PCREL + This is an 18-bit pc-relative reloc with the right 3 bits assumed + to be 0. + + - : BFD_RELOC_D30V_21_PCREL_R + This is an 18-bit pc-relative reloc with the right 3 bits assumed + to be 0. Same as the previous reloc but on the right side of the + container. + + - : BFD_RELOC_D30V_32 + This is a 32-bit absolute reloc. + + - : BFD_RELOC_D30V_32_PCREL + This is a 32-bit pc-relative reloc. + + - : BFD_RELOC_M32R_24 + Mitsubishi M32R relocs. This is a 24 bit absolute address. + + - : BFD_RELOC_M32R_10_PCREL + This is a 10-bit pc-relative reloc with the right 2 bits assumed + to be 0. + + - : BFD_RELOC_M32R_18_PCREL + This is an 18-bit reloc with the right 2 bits assumed to be 0. + + - : BFD_RELOC_M32R_26_PCREL + This is a 26-bit reloc with the right 2 bits assumed to be 0. + + - : BFD_RELOC_M32R_HI16_ULO + This is a 16-bit reloc containing the high 16 bits of an address + used when the lower 16 bits are treated as unsigned. + + - : BFD_RELOC_M32R_HI16_SLO + This is a 16-bit reloc containing the high 16 bits of an address + used when the lower 16 bits are treated as signed. + + - : BFD_RELOC_M32R_LO16 + This is a 16-bit reloc containing the lower 16 bits of an address. + + - : BFD_RELOC_M32R_SDA16 + This is a 16-bit reloc containing the small data area offset for + use in add3, load, and store instructions. + + - : BFD_RELOC_V850_9_PCREL + This is a 9-bit reloc + + - : BFD_RELOC_V850_22_PCREL + This is a 22-bit reloc + + - : BFD_RELOC_V850_SDA_16_16_OFFSET + This is a 16 bit offset from the short data area pointer. + + - : BFD_RELOC_V850_SDA_15_16_OFFSET + This is a 16 bit offset (of which only 15 bits are used) from the + short data area pointer. + + - : BFD_RELOC_V850_ZDA_16_16_OFFSET + This is a 16 bit offset from the zero data area pointer. + + - : BFD_RELOC_V850_ZDA_15_16_OFFSET + This is a 16 bit offset (of which only 15 bits are used) from the + zero data area pointer. + + - : BFD_RELOC_V850_TDA_6_8_OFFSET + This is an 8 bit offset (of which only 6 bits are used) from the + tiny data area pointer. + + - : BFD_RELOC_V850_TDA_7_8_OFFSET + This is an 8bit offset (of which only 7 bits are used) from the + tiny data area pointer. + + - : BFD_RELOC_V850_TDA_7_7_OFFSET + This is a 7 bit offset from the tiny data area pointer. + + - : BFD_RELOC_V850_TDA_16_16_OFFSET + This is a 16 bit offset from the tiny data area pointer. + + - : BFD_RELOC_V850_TDA_4_5_OFFSET + This is a 5 bit offset (of which only 4 bits are used) from the + tiny data area pointer. + + - : BFD_RELOC_V850_TDA_4_4_OFFSET + This is a 4 bit offset from the tiny data area pointer. + + - : BFD_RELOC_V850_SDA_16_16_SPLIT_OFFSET + This is a 16 bit offset from the short data area pointer, with the + bits placed non-contigously in the instruction. + + - : BFD_RELOC_V850_ZDA_16_16_SPLIT_OFFSET + This is a 16 bit offset from the zero data area pointer, with the + bits placed non-contigously in the instruction. + + - : BFD_RELOC_V850_CALLT_6_7_OFFSET + This is a 6 bit offset from the call table base pointer. + + - : BFD_RELOC_V850_CALLT_16_16_OFFSET + This is a 16 bit offset from the call table base pointer. + + - : BFD_RELOC_MN10300_32_PCREL + This is a 32bit pcrel reloc for the mn10300, offset by two bytes + in the instruction. + + - : BFD_RELOC_MN10300_16_PCREL + This is a 16bit pcrel reloc for the mn10300, offset by two bytes + in the instruction. + + - : BFD_RELOC_TIC30_LDP + This is a 8bit DP reloc for the tms320c30, where the most + significant 8 bits of a 24 bit word are placed into the least + significant 8 bits of the opcode. + + - : BFD_RELOC_TIC54X_PARTLS7 + This is a 7bit reloc for the tms320c54x, where the least + significant 7 bits of a 16 bit word are placed into the least + significant 7 bits of the opcode. + + - : BFD_RELOC_TIC54X_PARTMS9 + This is a 9bit DP reloc for the tms320c54x, where the most + significant 9 bits of a 16 bit word are placed into the least + significant 9 bits of the opcode. + + - : BFD_RELOC_TIC54X_23 + This is an extended address 23-bit reloc for the tms320c54x. + + - : BFD_RELOC_TIC54X_16_OF_23 + This is a 16-bit reloc for the tms320c54x, where the least + significant 16 bits of a 23-bit extended address are placed into + the opcode. + + - : BFD_RELOC_TIC54X_MS7_OF_23 + This is a reloc for the tms320c54x, where the most significant 7 + bits of a 23-bit extended address are placed into the opcode. + + - : BFD_RELOC_FR30_48 + This is a 48 bit reloc for the FR30 that stores 32 bits. + + - : BFD_RELOC_FR30_20 + This is a 32 bit reloc for the FR30 that stores 20 bits split up + into two sections. + + - : BFD_RELOC_FR30_6_IN_4 + This is a 16 bit reloc for the FR30 that stores a 6 bit word + offset in 4 bits. + + - : BFD_RELOC_FR30_8_IN_8 + This is a 16 bit reloc for the FR30 that stores an 8 bit byte + offset into 8 bits. + + - : BFD_RELOC_FR30_9_IN_8 + This is a 16 bit reloc for the FR30 that stores a 9 bit short + offset into 8 bits. + + - : BFD_RELOC_FR30_10_IN_8 + This is a 16 bit reloc for the FR30 that stores a 10 bit word + offset into 8 bits. + + - : BFD_RELOC_FR30_9_PCREL + This is a 16 bit reloc for the FR30 that stores a 9 bit pc relative + short offset into 8 bits. + + - : BFD_RELOC_FR30_12_PCREL + This is a 16 bit reloc for the FR30 that stores a 12 bit pc + relative short offset into 11 bits. + + - : BFD_RELOC_MCORE_PCREL_IMM8BY4 + - : BFD_RELOC_MCORE_PCREL_IMM11BY2 + - : BFD_RELOC_MCORE_PCREL_IMM4BY2 + - : BFD_RELOC_MCORE_PCREL_32 + - : BFD_RELOC_MCORE_PCREL_JSR_IMM11BY2 + - : BFD_RELOC_MCORE_RVA + Motorola Mcore relocations. + + - : BFD_RELOC_AVR_7_PCREL + This is a 16 bit reloc for the AVR that stores 8 bit pc relative + short offset into 7 bits. + + - : BFD_RELOC_AVR_13_PCREL + This is a 16 bit reloc for the AVR that stores 13 bit pc relative + short offset into 12 bits. + + - : BFD_RELOC_AVR_16_PM + This is a 16 bit reloc for the AVR that stores 17 bit value + (usually program memory address) into 16 bits. + + - : BFD_RELOC_AVR_LO8_LDI + This is a 16 bit reloc for the AVR that stores 8 bit value (usually + data memory address) into 8 bit immediate value of LDI insn. + + - : BFD_RELOC_AVR_HI8_LDI + This is a 16 bit reloc for the AVR that stores 8 bit value (high 8 + bit of data memory address) into 8 bit immediate value of LDI insn. + + - : BFD_RELOC_AVR_HH8_LDI + This is a 16 bit reloc for the AVR that stores 8 bit value (most + high 8 bit of program memory address) into 8 bit immediate value + of LDI insn. + + - : BFD_RELOC_AVR_LO8_LDI_NEG + This is a 16 bit reloc for the AVR that stores negated 8 bit value + (usually data memory address) into 8 bit immediate value of SUBI + insn. + + - : BFD_RELOC_AVR_HI8_LDI_NEG + This is a 16 bit reloc for the AVR that stores negated 8 bit value + (high 8 bit of data memory address) into 8 bit immediate value of + SUBI insn. + + - : BFD_RELOC_AVR_HH8_LDI_NEG + This is a 16 bit reloc for the AVR that stores negated 8 bit value + (most high 8 bit of program memory address) into 8 bit immediate + value of LDI or SUBI insn. + + - : BFD_RELOC_AVR_LO8_LDI_PM + This is a 16 bit reloc for the AVR that stores 8 bit value (usually + command address) into 8 bit immediate value of LDI insn. + + - : BFD_RELOC_AVR_HI8_LDI_PM + This is a 16 bit reloc for the AVR that stores 8 bit value (high 8 + bit of command address) into 8 bit immediate value of LDI insn. + + - : BFD_RELOC_AVR_HH8_LDI_PM + This is a 16 bit reloc for the AVR that stores 8 bit value (most + high 8 bit of command address) into 8 bit immediate value of LDI + insn. + + - : BFD_RELOC_AVR_LO8_LDI_PM_NEG + This is a 16 bit reloc for the AVR that stores negated 8 bit value + (usually command address) into 8 bit immediate value of SUBI insn. + + - : BFD_RELOC_AVR_HI8_LDI_PM_NEG + This is a 16 bit reloc for the AVR that stores negated 8 bit value + (high 8 bit of 16 bit command address) into 8 bit immediate value + of SUBI insn. + + - : BFD_RELOC_AVR_HH8_LDI_PM_NEG + This is a 16 bit reloc for the AVR that stores negated 8 bit value + (high 6 bit of 22 bit command address) into 8 bit immediate value + of SUBI insn. + + - : BFD_RELOC_AVR_CALL + This is a 32 bit reloc for the AVR that stores 23 bit value into + 22 bits. + + - : BFD_RELOC_VTABLE_INHERIT + - : BFD_RELOC_VTABLE_ENTRY + These two relocations are used by the linker to determine which of + the entries in a C++ virtual function table are actually used. + When the -gc-sections option is given, the linker will zero out + the entries that are not used, so that the code for those + functions need not be included in the output. + + VTABLE_INHERIT is a zero-space relocation used to describe to the + linker the inheritence tree of a C++ virtual function table. The + relocation's symbol should be the parent class' vtable, and the + relocation should be located at the child vtable. + + VTABLE_ENTRY is a zero-space relocation that describes the use of a + virtual function table entry. The reloc's symbol should refer to + the table of the class mentioned in the code. Off of that base, + an offset describes the entry that is being used. For Rela hosts, + this offset is stored in the reloc's addend. For Rel hosts, we + are forced to put this offset in the reloc's section offset. + + + typedef enum bfd_reloc_code_real bfd_reloc_code_real_type; + +`bfd_reloc_type_lookup' +....................... + + *Synopsis* + reloc_howto_type * + bfd_reloc_type_lookup (bfd *abfd, bfd_reloc_code_real_type code); + *Description* +Return a pointer to a howto structure which, when invoked, will perform +the relocation CODE on data from the architecture noted. + +`bfd_default_reloc_type_lookup' +............................... + + *Synopsis* + reloc_howto_type *bfd_default_reloc_type_lookup + (bfd *abfd, bfd_reloc_code_real_type code); + *Description* +Provides a default relocation lookup routine for any architecture. + +`bfd_get_reloc_code_name' +......................... + + *Synopsis* + const char *bfd_get_reloc_code_name (bfd_reloc_code_real_type code); + *Description* +Provides a printable name for the supplied relocation code. Useful +mainly for printing error messages. + +`bfd_generic_relax_section' +........................... + + *Synopsis* + boolean bfd_generic_relax_section + (bfd *abfd, + asection *section, + struct bfd_link_info *, + boolean *); + *Description* +Provides default handling for relaxing for back ends which don't do +relaxing - i.e., does nothing. + +`bfd_generic_gc_sections' +......................... + + *Synopsis* + boolean bfd_generic_gc_sections + (bfd *, struct bfd_link_info *); + *Description* +Provides default handling for relaxing for back ends which don't do +section gc - i.e., does nothing. + +`bfd_generic_get_relocated_section_contents' +............................................ + + *Synopsis* + bfd_byte * + bfd_generic_get_relocated_section_contents (bfd *abfd, + struct bfd_link_info *link_info, + struct bfd_link_order *link_order, + bfd_byte *data, + boolean relocateable, + asymbol **symbols); + *Description* +Provides default handling of relocation effort for back ends which +can't be bothered to do it efficiently. + + +File: bfd.info, Node: Core Files, Next: Targets, Prev: Relocations, Up: BFD front end + +Core files +========== + + *Description* +These are functions pertaining to core files. + +`bfd_core_file_failing_command' +............................... + + *Synopsis* + CONST char *bfd_core_file_failing_command(bfd *abfd); + *Description* +Return a read-only string explaining which program was running when it +failed and produced the core file ABFD. + +`bfd_core_file_failing_signal' +.............................. + + *Synopsis* + int bfd_core_file_failing_signal(bfd *abfd); + *Description* +Returns the signal number which caused the core dump which generated +the file the BFD ABFD is attached to. + +`core_file_matches_executable_p' +................................ + + *Synopsis* + boolean core_file_matches_executable_p + (bfd *core_bfd, bfd *exec_bfd); + *Description* +Return `true' if the core file attached to CORE_BFD was generated by a +run of the executable file attached to EXEC_BFD, `false' otherwise. + + +File: bfd.info, Node: Targets, Next: Architectures, Prev: Core Files, Up: BFD front end + +Targets +======= + + *Description* +Each port of BFD to a different machine requries the creation of a +target back end. All the back end provides to the root part of BFD is a +structure containing pointers to functions which perform certain low +level operations on files. BFD translates the applications's requests +through a pointer into calls to the back end routines. + + When a file is opened with `bfd_openr', its format and target are +unknown. BFD uses various mechanisms to determine how to interpret the +file. The operations performed are: + + * Create a BFD by calling the internal routine `_bfd_new_bfd', then + call `bfd_find_target' with the target string supplied to + `bfd_openr' and the new BFD pointer. + + * If a null target string was provided to `bfd_find_target', look up + the environment variable `GNUTARGET' and use that as the target + string. + + * If the target string is still `NULL', or the target string is + `default', then use the first item in the target vector as the + target type, and set `target_defaulted' in the BFD to cause + `bfd_check_format' to loop through all the targets. *Note + bfd_target::. *Note Formats::. + + * Otherwise, inspect the elements in the target vector one by one, + until a match on target name is found. When found, use it. + + * Otherwise return the error `bfd_error_invalid_target' to + `bfd_openr'. + + * `bfd_openr' attempts to open the file using `bfd_open_file', and + returns the BFD. + Once the BFD has been opened and the target selected, the file +format may be determined. This is done by calling `bfd_check_format' on +the BFD with a suggested format. If `target_defaulted' has been set, +each possible target type is tried to see if it recognizes the +specified format. `bfd_check_format' returns `true' when the caller +guesses right. + +* Menu: + +* bfd_target:: + Index: bfd.info-4 =================================================================== --- bfd.info-4 (nonexistent) +++ bfd.info-4 (revision 1765) @@ -0,0 +1,1293 @@ +This is bfd.info, produced by Makeinfo version 3.12f from bfd.texinfo. + +START-INFO-DIR-ENTRY +* Bfd: (bfd). The Binary File Descriptor library. +END-INFO-DIR-ENTRY + + This file documents the BFD library. + + Copyright (C) 1991 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, subject to the +terms of the GNU General Public License, which includes the provision +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: bfd.info, Node: bfd_target, Prev: Targets, Up: Targets + +bfd_target +---------- + + *Description* +This structure contains everything that BFD knows about a target. It +includes things like its byte order, name, and which routines to call +to do various operations. + + Every BFD points to a target structure with its `xvec' member. + + The macros below are used to dispatch to functions through the +`bfd_target' vector. They are used in a number of macros further down +in `bfd.h', and are also used when calling various routines by hand +inside the BFD implementation. The ARGLIST argument must be +parenthesized; it contains all the arguments to the called function. + + They make the documentation (more) unpleasant to read, so if someone +wants to fix this and not break the above, please do. + #define BFD_SEND(bfd, message, arglist) \ + ((*((bfd)->xvec->message)) arglist) + + #ifdef DEBUG_BFD_SEND + #undef BFD_SEND + #define BFD_SEND(bfd, message, arglist) \ + (((bfd) && (bfd)->xvec && (bfd)->xvec->message) ? \ + ((*((bfd)->xvec->message)) arglist) : \ + (bfd_assert (__FILE__,__LINE__), NULL)) + #endif + For operations which index on the BFD format: + #define BFD_SEND_FMT(bfd, message, arglist) \ + (((bfd)->xvec->message[(int)((bfd)->format)]) arglist) + + #ifdef DEBUG_BFD_SEND + #undef BFD_SEND_FMT + #define BFD_SEND_FMT(bfd, message, arglist) \ + (((bfd) && (bfd)->xvec && (bfd)->xvec->message) ? \ + (((bfd)->xvec->message[(int)((bfd)->format)]) arglist) : \ + (bfd_assert (__FILE__,__LINE__), NULL)) + #endif + This is the structure which defines the type of BFD this is. The +`xvec' member of the struct `bfd' itself points here. Each module that +implements access to a different target under BFD, defines one of these. + + FIXME, these names should be rationalised with the names of the +entry points which call them. Too bad we can't have one macro to define +them both! + enum bfd_flavour { + bfd_target_unknown_flavour, + bfd_target_aout_flavour, + bfd_target_coff_flavour, + bfd_target_ecoff_flavour, + bfd_target_elf_flavour, + bfd_target_ieee_flavour, + bfd_target_nlm_flavour, + bfd_target_oasys_flavour, + bfd_target_tekhex_flavour, + bfd_target_srec_flavour, + bfd_target_ihex_flavour, + bfd_target_som_flavour, + bfd_target_os9k_flavour, + bfd_target_versados_flavour, + bfd_target_msdos_flavour, + bfd_target_ovax_flavour, + bfd_target_evax_flavour + }; + + enum bfd_endian { BFD_ENDIAN_BIG, BFD_ENDIAN_LITTLE, BFD_ENDIAN_UNKNOWN }; + + /* Forward declaration. */ + typedef struct bfd_link_info _bfd_link_info; + + typedef struct bfd_target + { + Identifies the kind of target, e.g., SunOS4, Ultrix, etc. + char *name; + The "flavour" of a back end is a general indication about the +contents of a file. + enum bfd_flavour flavour; + The order of bytes within the data area of a file. + enum bfd_endian byteorder; + The order of bytes within the header parts of a file. + enum bfd_endian header_byteorder; + A mask of all the flags which an executable may have set - from the +set `BFD_NO_FLAGS', `HAS_RELOC', ...`D_PAGED'. + flagword object_flags; + A mask of all the flags which a section may have set - from the set +`SEC_NO_FLAGS', `SEC_ALLOC', ...`SET_NEVER_LOAD'. + flagword section_flags; + The character normally found at the front of a symbol (if any), +perhaps `_'. + char symbol_leading_char; + The pad character for file names within an archive header. + char ar_pad_char; + The maximum number of characters in an archive header. + unsigned short ar_max_namelen; + Entries for byte swapping for data. These are different from the +other entry points, since they don't take a BFD asthe first argument. +Certain other handlers could do the same. + bfd_vma (*bfd_getx64) PARAMS ((const bfd_byte *)); + bfd_signed_vma (*bfd_getx_signed_64) PARAMS ((const bfd_byte *)); + void (*bfd_putx64) PARAMS ((bfd_vma, bfd_byte *)); + bfd_vma (*bfd_getx32) PARAMS ((const bfd_byte *)); + bfd_signed_vma (*bfd_getx_signed_32) PARAMS ((const bfd_byte *)); + void (*bfd_putx32) PARAMS ((bfd_vma, bfd_byte *)); + bfd_vma (*bfd_getx16) PARAMS ((const bfd_byte *)); + bfd_signed_vma (*bfd_getx_signed_16) PARAMS ((const bfd_byte *)); + void (*bfd_putx16) PARAMS ((bfd_vma, bfd_byte *)); + Byte swapping for the headers + bfd_vma (*bfd_h_getx64) PARAMS ((const bfd_byte *)); + bfd_signed_vma (*bfd_h_getx_signed_64) PARAMS ((const bfd_byte *)); + void (*bfd_h_putx64) PARAMS ((bfd_vma, bfd_byte *)); + bfd_vma (*bfd_h_getx32) PARAMS ((const bfd_byte *)); + bfd_signed_vma (*bfd_h_getx_signed_32) PARAMS ((const bfd_byte *)); + void (*bfd_h_putx32) PARAMS ((bfd_vma, bfd_byte *)); + bfd_vma (*bfd_h_getx16) PARAMS ((const bfd_byte *)); + bfd_signed_vma (*bfd_h_getx_signed_16) PARAMS ((const bfd_byte *)); + void (*bfd_h_putx16) PARAMS ((bfd_vma, bfd_byte *)); + Format dependent routines: these are vectors of entry points within +the target vector structure, one for each format to check. + + Check the format of a file being read. Return a `bfd_target *' or +zero. + const struct bfd_target *(*_bfd_check_format[bfd_type_end]) PARAMS ((bfd *)); + Set the format of a file being written. + boolean (*_bfd_set_format[bfd_type_end]) PARAMS ((bfd *)); + Write cached information into a file being written, at `bfd_close'. + boolean (*_bfd_write_contents[bfd_type_end]) PARAMS ((bfd *)); + The general target vector. These vectors are initialized using the +BFD_JUMP_TABLE macros. + + /* Generic entry points. */ + #define BFD_JUMP_TABLE_GENERIC(NAME)\ + CAT(NAME,_close_and_cleanup),\ + CAT(NAME,_bfd_free_cached_info),\ + CAT(NAME,_new_section_hook),\ + CAT(NAME,_get_section_contents),\ + CAT(NAME,_get_section_contents_in_window) + + /* Called when the BFD is being closed to do any necessary cleanup. */ + boolean (*_close_and_cleanup) PARAMS ((bfd *)); + /* Ask the BFD to free all cached information. */ + boolean (*_bfd_free_cached_info) PARAMS ((bfd *)); + /* Called when a new section is created. */ + boolean (*_new_section_hook) PARAMS ((bfd *, sec_ptr)); + /* Read the contents of a section. */ + boolean (*_bfd_get_section_contents) PARAMS ((bfd *, sec_ptr, PTR, + file_ptr, bfd_size_type)); + boolean (*_bfd_get_section_contents_in_window) + PARAMS ((bfd *, sec_ptr, bfd_window *, + file_ptr, bfd_size_type)); + + /* Entry points to copy private data. */ + #define BFD_JUMP_TABLE_COPY(NAME)\ + CAT(NAME,_bfd_copy_private_bfd_data),\ + CAT(NAME,_bfd_merge_private_bfd_data),\ + CAT(NAME,_bfd_copy_private_section_data),\ + CAT(NAME,_bfd_copy_private_symbol_data),\ + CAT(NAME,_bfd_set_private_flags),\ + CAT(NAME,_bfd_print_private_bfd_data)\ + /* Called to copy BFD general private data from one object file + to another. */ + boolean (*_bfd_copy_private_bfd_data) PARAMS ((bfd *, bfd *)); + /* Called to merge BFD general private data from one object file + to a common output file when linking. */ + boolean (*_bfd_merge_private_bfd_data) PARAMS ((bfd *, bfd *)); + /* Called to copy BFD private section data from one object file + to another. */ + boolean (*_bfd_copy_private_section_data) PARAMS ((bfd *, sec_ptr, + bfd *, sec_ptr)); + /* Called to copy BFD private symbol data from one symbol + to another. */ + boolean (*_bfd_copy_private_symbol_data) PARAMS ((bfd *, asymbol *, + bfd *, asymbol *)); + /* Called to set private backend flags */ + boolean (*_bfd_set_private_flags) PARAMS ((bfd *, flagword)); + + /* Called to print private BFD data */ + boolean (*_bfd_print_private_bfd_data) PARAMS ((bfd *, PTR)); + + /* Core file entry points. */ + #define BFD_JUMP_TABLE_CORE(NAME)\ + CAT(NAME,_core_file_failing_command),\ + CAT(NAME,_core_file_failing_signal),\ + CAT(NAME,_core_file_matches_executable_p) + char * (*_core_file_failing_command) PARAMS ((bfd *)); + int (*_core_file_failing_signal) PARAMS ((bfd *)); + boolean (*_core_file_matches_executable_p) PARAMS ((bfd *, bfd *)); + + /* Archive entry points. */ + #define BFD_JUMP_TABLE_ARCHIVE(NAME)\ + CAT(NAME,_slurp_armap),\ + CAT(NAME,_slurp_extended_name_table),\ + CAT(NAME,_construct_extended_name_table),\ + CAT(NAME,_truncate_arname),\ + CAT(NAME,_write_armap),\ + CAT(NAME,_read_ar_hdr),\ + CAT(NAME,_openr_next_archived_file),\ + CAT(NAME,_get_elt_at_index),\ + CAT(NAME,_generic_stat_arch_elt),\ + CAT(NAME,_update_armap_timestamp) + boolean (*_bfd_slurp_armap) PARAMS ((bfd *)); + boolean (*_bfd_slurp_extended_name_table) PARAMS ((bfd *)); + boolean (*_bfd_construct_extended_name_table) + PARAMS ((bfd *, char **, bfd_size_type *, const char **)); + void (*_bfd_truncate_arname) PARAMS ((bfd *, CONST char *, char *)); + boolean (*write_armap) PARAMS ((bfd *arch, + unsigned int elength, + struct orl *map, + unsigned int orl_count, + int stridx)); + PTR (*_bfd_read_ar_hdr_fn) PARAMS ((bfd *)); + bfd * (*openr_next_archived_file) PARAMS ((bfd *arch, bfd *prev)); + #define bfd_get_elt_at_index(b,i) BFD_SEND(b, _bfd_get_elt_at_index, (b,i)) + bfd * (*_bfd_get_elt_at_index) PARAMS ((bfd *, symindex)); + int (*_bfd_stat_arch_elt) PARAMS ((bfd *, struct stat *)); + boolean (*_bfd_update_armap_timestamp) PARAMS ((bfd *)); + + /* Entry points used for symbols. */ + #define BFD_JUMP_TABLE_SYMBOLS(NAME)\ + CAT(NAME,_get_symtab_upper_bound),\ + CAT(NAME,_get_symtab),\ + CAT(NAME,_make_empty_symbol),\ + CAT(NAME,_print_symbol),\ + CAT(NAME,_get_symbol_info),\ + CAT(NAME,_bfd_is_local_label_name),\ + CAT(NAME,_get_lineno),\ + CAT(NAME,_find_nearest_line),\ + CAT(NAME,_bfd_make_debug_symbol),\ + CAT(NAME,_read_minisymbols),\ + CAT(NAME,_minisymbol_to_symbol) + long (*_bfd_get_symtab_upper_bound) PARAMS ((bfd *)); + long (*_bfd_canonicalize_symtab) PARAMS ((bfd *, + struct symbol_cache_entry **)); + struct symbol_cache_entry * + (*_bfd_make_empty_symbol) PARAMS ((bfd *)); + void (*_bfd_print_symbol) PARAMS ((bfd *, PTR, + struct symbol_cache_entry *, + bfd_print_symbol_type)); + #define bfd_print_symbol(b,p,s,e) BFD_SEND(b, _bfd_print_symbol, (b,p,s,e)) + void (*_bfd_get_symbol_info) PARAMS ((bfd *, + struct symbol_cache_entry *, + symbol_info *)); + #define bfd_get_symbol_info(b,p,e) BFD_SEND(b, _bfd_get_symbol_info, (b,p,e)) + boolean (*_bfd_is_local_label_name) PARAMS ((bfd *, const char *)); + + alent * (*_get_lineno) PARAMS ((bfd *, struct symbol_cache_entry *)); + boolean (*_bfd_find_nearest_line) PARAMS ((bfd *abfd, + struct sec *section, struct symbol_cache_entry **symbols, + bfd_vma offset, CONST char **file, CONST char **func, + unsigned int *line)); + /* Back-door to allow format-aware applications to create debug symbols + while using BFD for everything else. Currently used by the assembler + when creating COFF files. */ + asymbol * (*_bfd_make_debug_symbol) PARAMS (( + bfd *abfd, + void *ptr, + unsigned long size)); + #define bfd_read_minisymbols(b, d, m, s) \ + BFD_SEND (b, _read_minisymbols, (b, d, m, s)) + long (*_read_minisymbols) PARAMS ((bfd *, boolean, PTR *, + unsigned int *)); + #define bfd_minisymbol_to_symbol(b, d, m, f) \ + BFD_SEND (b, _minisymbol_to_symbol, (b, d, m, f)) + asymbol *(*_minisymbol_to_symbol) PARAMS ((bfd *, boolean, const PTR, + asymbol *)); + + /* Routines for relocs. */ + #define BFD_JUMP_TABLE_RELOCS(NAME)\ + CAT(NAME,_get_reloc_upper_bound),\ + CAT(NAME,_canonicalize_reloc),\ + CAT(NAME,_bfd_reloc_type_lookup) + long (*_get_reloc_upper_bound) PARAMS ((bfd *, sec_ptr)); + long (*_bfd_canonicalize_reloc) PARAMS ((bfd *, sec_ptr, arelent **, + struct symbol_cache_entry **)); + /* See documentation on reloc types. */ + reloc_howto_type * + (*reloc_type_lookup) PARAMS ((bfd *abfd, + bfd_reloc_code_real_type code)); + + /* Routines used when writing an object file. */ + #define BFD_JUMP_TABLE_WRITE(NAME)\ + CAT(NAME,_set_arch_mach),\ + CAT(NAME,_set_section_contents) + boolean (*_bfd_set_arch_mach) PARAMS ((bfd *, enum bfd_architecture, + unsigned long)); + boolean (*_bfd_set_section_contents) PARAMS ((bfd *, sec_ptr, PTR, + file_ptr, bfd_size_type)); + + /* Routines used by the linker. */ + #define BFD_JUMP_TABLE_LINK(NAME)\ + CAT(NAME,_sizeof_headers),\ + CAT(NAME,_bfd_get_relocated_section_contents),\ + CAT(NAME,_bfd_relax_section),\ + CAT(NAME,_bfd_link_hash_table_create),\ + CAT(NAME,_bfd_link_add_symbols),\ + CAT(NAME,_bfd_final_link),\ + CAT(NAME,_bfd_link_split_section),\ + CAT(NAME,_bfd_gc_sections) + int (*_bfd_sizeof_headers) PARAMS ((bfd *, boolean)); + bfd_byte * (*_bfd_get_relocated_section_contents) PARAMS ((bfd *, + struct bfd_link_info *, struct bfd_link_order *, + bfd_byte *data, boolean relocateable, + struct symbol_cache_entry **)); + + boolean (*_bfd_relax_section) PARAMS ((bfd *, struct sec *, + struct bfd_link_info *, boolean *again)); + + /* Create a hash table for the linker. Different backends store + different information in this table. */ + struct bfd_link_hash_table *(*_bfd_link_hash_table_create) PARAMS ((bfd *)); + + /* Add symbols from this object file into the hash table. */ + boolean (*_bfd_link_add_symbols) PARAMS ((bfd *, struct bfd_link_info *)); + + /* Do a link based on the link_order structures attached to each + section of the BFD. */ + boolean (*_bfd_final_link) PARAMS ((bfd *, struct bfd_link_info *)); + + /* Should this section be split up into smaller pieces during linking. */ + boolean (*_bfd_link_split_section) PARAMS ((bfd *, struct sec *)); + + /* Remove sections that are not referenced from the output. */ + boolean (*_bfd_gc_sections) PARAMS ((bfd *, struct bfd_link_info *)); + + /* Routines to handle dynamic symbols and relocs. */ + #define BFD_JUMP_TABLE_DYNAMIC(NAME)\ + CAT(NAME,_get_dynamic_symtab_upper_bound),\ + CAT(NAME,_canonicalize_dynamic_symtab),\ + CAT(NAME,_get_dynamic_reloc_upper_bound),\ + CAT(NAME,_canonicalize_dynamic_reloc) + /* Get the amount of memory required to hold the dynamic symbols. */ + long (*_bfd_get_dynamic_symtab_upper_bound) PARAMS ((bfd *)); + /* Read in the dynamic symbols. */ + long (*_bfd_canonicalize_dynamic_symtab) + PARAMS ((bfd *, struct symbol_cache_entry **)); + /* Get the amount of memory required to hold the dynamic relocs. */ + long (*_bfd_get_dynamic_reloc_upper_bound) PARAMS ((bfd *)); + /* Read in the dynamic relocs. */ + long (*_bfd_canonicalize_dynamic_reloc) + PARAMS ((bfd *, arelent **, struct symbol_cache_entry **)); + A pointer to an alternative bfd_target in case the current one is not +satisfactory. This can happen when the target cpu supports both big +and little endian code, and target chosen by the linker has the wrong +endianness. The function open_output() in ld/ldlang.c uses this field +to find an alternative output format that is suitable. + /* Opposite endian version of this target. */ + const struct bfd_target * alternative_target; + Data for use by back-end routines, which isn't generic enough to +belong in this structure. + PTR backend_data; + + } bfd_target; + +`bfd_set_default_target' +........................ + + *Synopsis* + boolean bfd_set_default_target (const char *name); + *Description* +Set the default target vector to use when recognizing a BFD. This +takes the name of the target, which may be a BFD target name or a +configuration triplet. + +`bfd_find_target' +................. + + *Synopsis* + const bfd_target *bfd_find_target(CONST char *target_name, bfd *abfd); + *Description* +Return a pointer to the transfer vector for the object target named +TARGET_NAME. If TARGET_NAME is `NULL', choose the one in the +environment variable `GNUTARGET'; if that is null or not defined, then +choose the first entry in the target list. Passing in the string +"default" or setting the environment variable to "default" will cause +the first entry in the target list to be returned, and +"target_defaulted" will be set in the BFD. This causes +`bfd_check_format' to loop over all the targets to find the one that +matches the file being read. + +`bfd_target_list' +................. + + *Synopsis* + const char **bfd_target_list(void); + *Description* +Return a freshly malloced NULL-terminated vector of the names of all +the valid BFD targets. Do not modify the names. + +`bfd_seach_for_target' +...................... + + *Synopsis* + const bfd_target * bfd_search_for_target (int (* search_func)(const bfd_target *, void *), void *); + *Description* +Return a pointer to the first transfer vector in the list of transfer +vectors maintained by BFD that produces a non-zero result when passed +to the function SEARCH_FUNC. The parameter DATA is passed, unexamined, +to the search function. + + +File: bfd.info, Node: Architectures, Next: Opening and Closing, Prev: Targets, Up: BFD front end + +Architectures +============= + + BFD keeps one atom in a BFD describing the architecture of the data +attached to the BFD: a pointer to a `bfd_arch_info_type'. + + Pointers to structures can be requested independently of a BFD so +that an architecture's information can be interrogated without access +to an open BFD. + + The architecture information is provided by each architecture +package. The set of default architectures is selected by the macro +`SELECT_ARCHITECTURES'. This is normally set up in the +`config/TARGET.mt' file of your choice. If the name is not defined, +then all the architectures supported are included. + + When BFD starts up, all the architectures are called with an +initialize method. It is up to the architecture back end to insert as +many items into the list of architectures as it wants to; generally +this would be one for each machine and one for the default case (an +item with a machine field of 0). + + BFD's idea of an architecture is implemented in `archures.c'. + +bfd_architecture +---------------- + + *Description* +This enum gives the object file's CPU architecture, in a global +sense--i.e., what processor family does it belong to? Another field +indicates which processor within the family is in use. The machine +gives a number which distinguishes different versions of the +architecture, containing, for example, 2 and 3 for Intel i960 KA and +i960 KB, and 68020 and 68030 for Motorola 68020 and 68030. + enum bfd_architecture + { + bfd_arch_unknown, /* File arch not known */ + bfd_arch_obscure, /* Arch known, not one of these */ + bfd_arch_m68k, /* Motorola 68xxx */ + #define bfd_mach_m68000 1 + #define bfd_mach_m68008 2 + #define bfd_mach_m68010 3 + #define bfd_mach_m68020 4 + #define bfd_mach_m68030 5 + #define bfd_mach_m68040 6 + #define bfd_mach_m68060 7 + #define bfd_mach_cpu32 8 + bfd_arch_vax, /* DEC Vax */ + bfd_arch_i960, /* Intel 960 */ + /* The order of the following is important. + lower number indicates a machine type that + only accepts a subset of the instructions + available to machines with higher numbers. + The exception is the "ca", which is + incompatible with all other machines except + "core". */ + + #define bfd_mach_i960_core 1 + #define bfd_mach_i960_ka_sa 2 + #define bfd_mach_i960_kb_sb 3 + #define bfd_mach_i960_mc 4 + #define bfd_mach_i960_xa 5 + #define bfd_mach_i960_ca 6 + #define bfd_mach_i960_jx 7 + #define bfd_mach_i960_hx 8 + + bfd_arch_a29k, /* AMD 29000 */ + bfd_arch_sparc, /* SPARC */ + #define bfd_mach_sparc 1 + /* The difference between v8plus and v9 is that v9 is a true 64 bit env. */ + #define bfd_mach_sparc_sparclet 2 + #define bfd_mach_sparc_sparclite 3 + #define bfd_mach_sparc_v8plus 4 + #define bfd_mach_sparc_v8plusa 5 /* with ultrasparc add'ns */ + #define bfd_mach_sparc_sparclite_le 6 + #define bfd_mach_sparc_v9 7 + #define bfd_mach_sparc_v9a 8 /* with ultrasparc add'ns */ + /* Nonzero if MACH has the v9 instruction set. */ + #define bfd_mach_sparc_v9_p(mach) \ + ((mach) >= bfd_mach_sparc_v8plus && (mach) <= bfd_mach_sparc_v9a) + bfd_arch_mips, /* MIPS Rxxxx */ + #define bfd_mach_mips3000 3000 + #define bfd_mach_mips3900 3900 + #define bfd_mach_mips4000 4000 + #define bfd_mach_mips4010 4010 + #define bfd_mach_mips4100 4100 + #define bfd_mach_mips4111 4111 + #define bfd_mach_mips4300 4300 + #define bfd_mach_mips4400 4400 + #define bfd_mach_mips4600 4600 + #define bfd_mach_mips4650 4650 + #define bfd_mach_mips5000 5000 + #define bfd_mach_mips6000 6000 + #define bfd_mach_mips8000 8000 + #define bfd_mach_mips10000 10000 + #define bfd_mach_mips16 16 + bfd_arch_i386, /* Intel 386 */ + #define bfd_mach_i386_i386 0 + #define bfd_mach_i386_i8086 1 + #define bfd_mach_i386_i386_intel_syntax 2 + bfd_arch_we32k, /* AT&T WE32xxx */ + bfd_arch_tahoe, /* CCI/Harris Tahoe */ + bfd_arch_i860, /* Intel 860 */ + bfd_arch_i370, /* IBM 360/370 Mainframes */ + bfd_arch_romp, /* IBM ROMP PC/RT */ + bfd_arch_alliant, /* Alliant */ + bfd_arch_convex, /* Convex */ + bfd_arch_m88k, /* Motorola 88xxx */ + bfd_arch_pyramid, /* Pyramid Technology */ + bfd_arch_h8300, /* Hitachi H8/300 */ + #define bfd_mach_h8300 1 + #define bfd_mach_h8300h 2 + #define bfd_mach_h8300s 3 + bfd_arch_powerpc, /* PowerPC */ + bfd_arch_rs6000, /* IBM RS/6000 */ + bfd_arch_hppa, /* HP PA RISC */ + bfd_arch_d10v, /* Mitsubishi D10V */ + #define bfd_mach_d10v 0 + #define bfd_mach_d10v_ts2 2 + #define bfd_mach_d10v_ts3 3 + bfd_arch_d30v, /* Mitsubishi D30V */ + bfd_arch_z8k, /* Zilog Z8000 */ + #define bfd_mach_z8001 1 + #define bfd_mach_z8002 2 + bfd_arch_h8500, /* Hitachi H8/500 */ + bfd_arch_sh, /* Hitachi SH */ + #define bfd_mach_sh 0 + #define bfd_mach_sh2 0x20 + #define bfd_mach_sh_dsp 0x2d + #define bfd_mach_sh3 0x30 + #define bfd_mach_sh3_dsp 0x3d + #define bfd_mach_sh3e 0x3e + #define bfd_mach_sh4 0x40 + bfd_arch_alpha, /* Dec Alpha */ + #define bfd_mach_alpha_ev4 0x10 + #define bfd_mach_alpha_ev5 0x20 + #define bfd_mach_alpha_ev6 0x30 + bfd_arch_arm, /* Advanced Risc Machines ARM */ + #define bfd_mach_arm_2 1 + #define bfd_mach_arm_2a 2 + #define bfd_mach_arm_3 3 + #define bfd_mach_arm_3M 4 + #define bfd_mach_arm_4 5 + #define bfd_mach_arm_4T 6 + #define bfd_mach_arm_5 7 + #define bfd_mach_arm_5T 8 + bfd_arch_ns32k, /* National Semiconductors ns32000 */ + bfd_arch_w65, /* WDC 65816 */ + bfd_arch_tic30, /* Texas Instruments TMS320C30 */ + bfd_arch_tic54x, /* Texas Instruments TMS320C54X */ + bfd_arch_tic80, /* TI TMS320c80 (MVP) */ + bfd_arch_v850, /* NEC V850 */ + #define bfd_mach_v850 0 + #define bfd_mach_v850e 'E' + #define bfd_mach_v850ea 'A' + bfd_arch_arc, /* Argonaut RISC Core */ + #define bfd_mach_arc_base 0 + bfd_arch_m32r, /* Mitsubishi M32R/D */ + #define bfd_mach_m32r 0 /* backwards compatibility */ + #define bfd_mach_m32rx 'x' + bfd_arch_mn10200, /* Matsushita MN10200 */ + bfd_arch_mn10300, /* Matsushita MN10300 */ + #define bfd_mach_mn10300 300 + #define bfd_mach_am33 330 + bfd_arch_fr30, + #define bfd_mach_fr30 0x46523330 + bfd_arch_mcore, + bfd_arch_pj, + bfd_arch_avr, /* Atmel AVR microcontrollers */ + #define bfd_mach_avr1 1 + #define bfd_mach_avr2 2 + #define bfd_mach_avr3 3 + #define bfd_mach_avr4 4 + bfd_arch_last + }; + +bfd_arch_info +------------- + + *Description* +This structure contains information on architectures for use within BFD. + + typedef struct bfd_arch_info + { + int bits_per_word; + int bits_per_address; + int bits_per_byte; + enum bfd_architecture arch; + unsigned long mach; + const char *arch_name; + const char *printable_name; + unsigned int section_align_power; + /* true if this is the default machine for the architecture */ + boolean the_default; + const struct bfd_arch_info * (*compatible) + PARAMS ((const struct bfd_arch_info *a, + const struct bfd_arch_info *b)); + + boolean (*scan) PARAMS ((const struct bfd_arch_info *, const char *)); + + const struct bfd_arch_info *next; + } bfd_arch_info_type; + +`bfd_printable_name' +.................... + + *Synopsis* + const char *bfd_printable_name(bfd *abfd); + *Description* +Return a printable string representing the architecture and machine +from the pointer to the architecture info structure. + +`bfd_scan_arch' +............... + + *Synopsis* + const bfd_arch_info_type *bfd_scan_arch(const char *string); + *Description* +Figure out if BFD supports any cpu which could be described with the +name STRING. Return a pointer to an `arch_info' structure if a machine +is found, otherwise NULL. + +`bfd_arch_list' +............... + + *Synopsis* + const char **bfd_arch_list(void); + *Description* +Return a freshly malloced NULL-terminated vector of the names of all +the valid BFD architectures. Do not modify the names. + +`bfd_arch_get_compatible' +......................... + + *Synopsis* + const bfd_arch_info_type *bfd_arch_get_compatible( + const bfd *abfd, + const bfd *bbfd); + *Description* +Determine whether two BFDs' architectures and machine types are +compatible. Calculates the lowest common denominator between the two +architectures and machine types implied by the BFDs and returns a +pointer to an `arch_info' structure describing the compatible machine. + +`bfd_default_arch_struct' +......................... + + *Description* +The `bfd_default_arch_struct' is an item of `bfd_arch_info_type' which +has been initialized to a fairly generic state. A BFD starts life by +pointing to this structure, until the correct back end has determined +the real architecture of the file. + extern const bfd_arch_info_type bfd_default_arch_struct; + +`bfd_set_arch_info' +................... + + *Synopsis* + void bfd_set_arch_info(bfd *abfd, const bfd_arch_info_type *arg); + *Description* +Set the architecture info of ABFD to ARG. + +`bfd_default_set_arch_mach' +........................... + + *Synopsis* + boolean bfd_default_set_arch_mach(bfd *abfd, + enum bfd_architecture arch, + unsigned long mach); + *Description* +Set the architecture and machine type in BFD ABFD to ARCH and MACH. +Find the correct pointer to a structure and insert it into the +`arch_info' pointer. + +`bfd_get_arch' +.............. + + *Synopsis* + enum bfd_architecture bfd_get_arch(bfd *abfd); + *Description* +Return the enumerated type which describes the BFD ABFD's architecture. + +`bfd_get_mach' +.............. + + *Synopsis* + unsigned long bfd_get_mach(bfd *abfd); + *Description* +Return the long type which describes the BFD ABFD's machine. + +`bfd_arch_bits_per_byte' +........................ + + *Synopsis* + unsigned int bfd_arch_bits_per_byte(bfd *abfd); + *Description* +Return the number of bits in one of the BFD ABFD's architecture's bytes. + +`bfd_arch_bits_per_address' +........................... + + *Synopsis* + unsigned int bfd_arch_bits_per_address(bfd *abfd); + *Description* +Return the number of bits in one of the BFD ABFD's architecture's +addresses. + +`bfd_default_compatible' +........................ + + *Synopsis* + const bfd_arch_info_type *bfd_default_compatible + (const bfd_arch_info_type *a, + const bfd_arch_info_type *b); + *Description* +The default function for testing for compatibility. + +`bfd_default_scan' +.................. + + *Synopsis* + boolean bfd_default_scan(const struct bfd_arch_info *info, const char *string); + *Description* +The default function for working out whether this is an architecture +hit and a machine hit. + +`bfd_get_arch_info' +................... + + *Synopsis* + const bfd_arch_info_type * bfd_get_arch_info(bfd *abfd); + *Description* +Return the architecture info struct in ABFD. + +`bfd_lookup_arch' +................. + + *Synopsis* + const bfd_arch_info_type *bfd_lookup_arch + (enum bfd_architecture + arch, + unsigned long machine); + *Description* +Look for the architecure info structure which matches the arguments +ARCH and MACHINE. A machine of 0 matches the machine/architecture +structure which marks itself as the default. + +`bfd_printable_arch_mach' +......................... + + *Synopsis* + const char *bfd_printable_arch_mach + (enum bfd_architecture arch, unsigned long machine); + *Description* +Return a printable string representing the architecture and machine +type. + + This routine is depreciated. + +`bfd_octets_per_byte' +..................... + + *Synopsis* + unsigned int bfd_octets_per_byte(bfd *abfd); + *Description* +Return the number of octets (8-bit quantities) per target byte (minimum +addressable unit). In most cases, this will be one, but some DSP +targets have 16, 32, or even 48 bits per byte. + +`bfd_arch_mach_octets_per_byte' +............................... + + *Synopsis* + unsigned int bfd_arch_mach_octets_per_byte(enum bfd_architecture arch, + unsigned long machine); + *Description* +See bfd_octets_per_byte. This routine is provided for those cases +where a bfd * is not available + + +File: bfd.info, Node: Opening and Closing, Next: Internal, Prev: Architectures, Up: BFD front end + +Opening and closing BFDs +======================== + +`bfd_openr' +........... + + *Synopsis* + bfd *bfd_openr(CONST char *filename, CONST char *target); + *Description* +Open the file FILENAME (using `fopen') with the target TARGET. Return +a pointer to the created BFD. + + Calls `bfd_find_target', so TARGET is interpreted as by that +function. + + If `NULL' is returned then an error has occured. Possible errors +are `bfd_error_no_memory', `bfd_error_invalid_target' or `system_call' +error. + +`bfd_fdopenr' +............. + + *Synopsis* + bfd *bfd_fdopenr(CONST char *filename, CONST char *target, int fd); + *Description* +`bfd_fdopenr' is to `bfd_fopenr' much like `fdopen' is to `fopen'. It +opens a BFD on a file already described by the FD supplied. + + When the file is later `bfd_close'd, the file descriptor will be +closed. + + If the caller desires that this file descriptor be cached by BFD +(opened as needed, closed as needed to free descriptors for other +opens), with the supplied FD used as an initial file descriptor (but +subject to closure at any time), call bfd_set_cacheable(bfd, 1) on the +returned BFD. The default is to assume no cacheing; the file +descriptor will remain open until `bfd_close', and will not be affected +by BFD operations on other files. + + Possible errors are `bfd_error_no_memory', +`bfd_error_invalid_target' and `bfd_error_system_call'. + +`bfd_openstreamr' +................. + + *Synopsis* + bfd *bfd_openstreamr(const char *, const char *, PTR); + *Description* +Open a BFD for read access on an existing stdio stream. When the BFD +is passed to `bfd_close', the stream will be closed. + +`bfd_openw' +........... + + *Synopsis* + bfd *bfd_openw(CONST char *filename, CONST char *target); + *Description* +Create a BFD, associated with file FILENAME, using the file format +TARGET, and return a pointer to it. + + Possible errors are `bfd_error_system_call', `bfd_error_no_memory', +`bfd_error_invalid_target'. + +`bfd_close' +........... + + *Synopsis* + boolean bfd_close(bfd *abfd); + *Description* +Close a BFD. If the BFD was open for writing, then pending operations +are completed and the file written out and closed. If the created file +is executable, then `chmod' is called to mark it as such. + + All memory attached to the BFD is released. + + The file descriptor associated with the BFD is closed (even if it +was passed in to BFD by `bfd_fdopenr'). + + *Returns* +`true' is returned if all is ok, otherwise `false'. + +`bfd_close_all_done' +.................... + + *Synopsis* + boolean bfd_close_all_done(bfd *); + *Description* +Close a BFD. Differs from `bfd_close' since it does not complete any +pending operations. This routine would be used if the application had +just used BFD for swapping and didn't want to use any of the writing +code. + + If the created file is executable, then `chmod' is called to mark it +as such. + + All memory attached to the BFD is released. + + *Returns* +`true' is returned if all is ok, otherwise `false'. + +`bfd_create' +............ + + *Synopsis* + bfd *bfd_create(CONST char *filename, bfd *templ); + *Description* +Create a new BFD in the manner of `bfd_openw', but without opening a +file. The new BFD takes the target from the target used by TEMPLATE. The +format is always set to `bfd_object'. + +`bfd_make_writable' +................... + + *Synopsis* + boolean bfd_make_writable(bfd *abfd); + *Description* +Takes a BFD as created by `bfd_create' and converts it into one like as +returned by `bfd_openw'. It does this by converting the BFD to +BFD_IN_MEMORY. It's assumed that you will call `bfd_make_readable' on +this bfd later. + + *Returns* +`true' is returned if all is ok, otherwise `false'. + +`bfd_make_readable' +................... + + *Synopsis* + boolean bfd_make_readable(bfd *abfd); + *Description* +Takes a BFD as created by `bfd_create' and `bfd_make_writable' and +converts it into one like as returned by `bfd_openr'. It does this by +writing the contents out to the memory buffer, then reversing the +direction. + + *Returns* +`true' is returned if all is ok, otherwise `false'. + +`bfd_alloc' +........... + + *Synopsis* + PTR bfd_alloc (bfd *abfd, size_t wanted); + *Description* +Allocate a block of WANTED bytes of memory attached to `abfd' and +return a pointer to it. + + +File: bfd.info, Node: Internal, Next: File Caching, Prev: Opening and Closing, Up: BFD front end + +Internal functions +================== + + *Description* +These routines are used within BFD. They are not intended for export, +but are documented here for completeness. + +`bfd_write_bigendian_4byte_int' +............................... + + *Synopsis* + void bfd_write_bigendian_4byte_int(bfd *abfd, int i); + *Description* +Write a 4 byte integer I to the output BFD ABFD, in big endian order +regardless of what else is going on. This is useful in archives. + +`bfd_put_size' +.............. + +`bfd_get_size' +.............. + + *Description* +These macros as used for reading and writing raw data in sections; each +access (except for bytes) is vectored through the target format of the +BFD and mangled accordingly. The mangling performs any necessary endian +translations and removes alignment restrictions. Note that types +accepted and returned by these macros are identical so they can be +swapped around in macros--for example, `libaout.h' defines `GET_WORD' +to either `bfd_get_32' or `bfd_get_64'. + + In the put routines, VAL must be a `bfd_vma'. If we are on a system +without prototypes, the caller is responsible for making sure that is +true, with a cast if necessary. We don't cast them in the macro +definitions because that would prevent `lint' or `gcc -Wall' from +detecting sins such as passing a pointer. To detect calling these with +less than a `bfd_vma', use `gcc -Wconversion' on a host with 64 bit +`bfd_vma''s. + + /* Byte swapping macros for user section data. */ + + #define bfd_put_8(abfd, val, ptr) \ + ((void) (*((unsigned char *)(ptr)) = (unsigned char)(val))) + #define bfd_put_signed_8 \ + bfd_put_8 + #define bfd_get_8(abfd, ptr) \ + (*(unsigned char *)(ptr)) + #define bfd_get_signed_8(abfd, ptr) \ + ((*(unsigned char *)(ptr) ^ 0x80) - 0x80) + + #define bfd_put_16(abfd, val, ptr) \ + BFD_SEND(abfd, bfd_putx16, ((val),(ptr))) + #define bfd_put_signed_16 \ + bfd_put_16 + #define bfd_get_16(abfd, ptr) \ + BFD_SEND(abfd, bfd_getx16, (ptr)) + #define bfd_get_signed_16(abfd, ptr) \ + BFD_SEND (abfd, bfd_getx_signed_16, (ptr)) + + #define bfd_put_32(abfd, val, ptr) \ + BFD_SEND(abfd, bfd_putx32, ((val),(ptr))) + #define bfd_put_signed_32 \ + bfd_put_32 + #define bfd_get_32(abfd, ptr) \ + BFD_SEND(abfd, bfd_getx32, (ptr)) + #define bfd_get_signed_32(abfd, ptr) \ + BFD_SEND(abfd, bfd_getx_signed_32, (ptr)) + + #define bfd_put_64(abfd, val, ptr) \ + BFD_SEND(abfd, bfd_putx64, ((val), (ptr))) + #define bfd_put_signed_64 \ + bfd_put_64 + #define bfd_get_64(abfd, ptr) \ + BFD_SEND(abfd, bfd_getx64, (ptr)) + #define bfd_get_signed_64(abfd, ptr) \ + BFD_SEND(abfd, bfd_getx_signed_64, (ptr)) + + #define bfd_get(bits, abfd, ptr) \ + ((bits) == 8 ? bfd_get_8 (abfd, ptr) \ + : (bits) == 16 ? bfd_get_16 (abfd, ptr) \ + : (bits) == 32 ? bfd_get_32 (abfd, ptr) \ + : (bits) == 64 ? bfd_get_64 (abfd, ptr) \ + : (abort (), (bfd_vma) - 1)) + + #define bfd_put(bits, abfd, val, ptr) \ + ((bits) == 8 ? bfd_put_8 (abfd, val, ptr) \ + : (bits) == 16 ? bfd_put_16 (abfd, val, ptr) \ + : (bits) == 32 ? bfd_put_32 (abfd, val, ptr) \ + : (bits) == 64 ? bfd_put_64 (abfd, val, ptr) \ + : (abort (), (void) 0)) + +`bfd_h_put_size' +................ + + *Description* +These macros have the same function as their `bfd_get_x' bretheren, +except that they are used for removing information for the header +records of object files. Believe it or not, some object files keep +their header records in big endian order and their data in little +endian order. + + /* Byte swapping macros for file header data. */ + + #define bfd_h_put_8(abfd, val, ptr) \ + bfd_put_8 (abfd, val, ptr) + #define bfd_h_put_signed_8(abfd, val, ptr) \ + bfd_put_8 (abfd, val, ptr) + #define bfd_h_get_8(abfd, ptr) \ + bfd_get_8 (abfd, ptr) + #define bfd_h_get_signed_8(abfd, ptr) \ + bfd_get_signed_8 (abfd, ptr) + + #define bfd_h_put_16(abfd, val, ptr) \ + BFD_SEND(abfd, bfd_h_putx16,(val,ptr)) + #define bfd_h_put_signed_16 \ + bfd_h_put_16 + #define bfd_h_get_16(abfd, ptr) \ + BFD_SEND(abfd, bfd_h_getx16,(ptr)) + #define bfd_h_get_signed_16(abfd, ptr) \ + BFD_SEND(abfd, bfd_h_getx_signed_16, (ptr)) + + #define bfd_h_put_32(abfd, val, ptr) \ + BFD_SEND(abfd, bfd_h_putx32,(val,ptr)) + #define bfd_h_put_signed_32 \ + bfd_h_put_32 + #define bfd_h_get_32(abfd, ptr) \ + BFD_SEND(abfd, bfd_h_getx32,(ptr)) + #define bfd_h_get_signed_32(abfd, ptr) \ + BFD_SEND(abfd, bfd_h_getx_signed_32, (ptr)) + + #define bfd_h_put_64(abfd, val, ptr) \ + BFD_SEND(abfd, bfd_h_putx64,(val, ptr)) + #define bfd_h_put_signed_64 \ + bfd_h_put_64 + #define bfd_h_get_64(abfd, ptr) \ + BFD_SEND(abfd, bfd_h_getx64,(ptr)) + #define bfd_h_get_signed_64(abfd, ptr) \ + BFD_SEND(abfd, bfd_h_getx_signed_64, (ptr)) + +`bfd_log2' +.......... + + *Synopsis* + unsigned int bfd_log2(bfd_vma x); + *Description* +Return the log base 2 of the value supplied, rounded up. E.g., an X of +1025 returns 11. + + +File: bfd.info, Node: File Caching, Next: Linker Functions, Prev: Internal, Up: BFD front end + +File caching +============ + + The file caching mechanism is embedded within BFD and allows the +application to open as many BFDs as it wants without regard to the +underlying operating system's file descriptor limit (often as low as 20 +open files). The module in `cache.c' maintains a least recently used +list of `BFD_CACHE_MAX_OPEN' files, and exports the name +`bfd_cache_lookup', which runs around and makes sure that the required +BFD is open. If not, then it chooses a file to close, closes it and +opens the one wanted, returning its file handle. + +`BFD_CACHE_MAX_OPEN macro' +.......................... + + *Description* +The maximum number of files which the cache will keep open at one time. + #define BFD_CACHE_MAX_OPEN 10 + +`bfd_last_cache' +................ + + *Synopsis* + extern bfd *bfd_last_cache; + *Description* +Zero, or a pointer to the topmost BFD on the chain. This is used by +the `bfd_cache_lookup' macro in `libbfd.h' to determine when it can +avoid a function call. + +`bfd_cache_lookup' +.................. + + *Description* +Check to see if the required BFD is the same as the last one looked up. +If so, then it can use the stream in the BFD with impunity, since it +can't have changed since the last lookup; otherwise, it has to perform +the complicated lookup function. + #define bfd_cache_lookup(x) \ + ((x)==bfd_last_cache? \ + (FILE*)(bfd_last_cache->iostream): \ + bfd_cache_lookup_worker(x)) + +`bfd_cache_init' +................ + + *Synopsis* + boolean bfd_cache_init (bfd *abfd); + *Description* +Add a newly opened BFD to the cache. + +`bfd_cache_close' +................. + + *Synopsis* + boolean bfd_cache_close (bfd *abfd); + *Description* +Remove the BFD ABFD from the cache. If the attached file is open, then +close it too. + + *Returns* +`false' is returned if closing the file fails, `true' is returned if +all is well. + +`bfd_open_file' +............... + + *Synopsis* + FILE* bfd_open_file(bfd *abfd); + *Description* +Call the OS to open a file for ABFD. Return the `FILE *' (possibly +`NULL') that results from this operation. Set up the BFD so that +future accesses know the file is open. If the `FILE *' returned is +`NULL', then it won't have been put in the cache, so it won't have to +be removed from it. + +`bfd_cache_lookup_worker' +......................... + + *Synopsis* + FILE *bfd_cache_lookup_worker(bfd *abfd); + *Description* +Called when the macro `bfd_cache_lookup' fails to find a quick answer. +Find a file descriptor for ABFD. If necessary, it open it. If there +are already more than `BFD_CACHE_MAX_OPEN' files open, it tries to +close one first, to avoid running out of file descriptors. + + +File: bfd.info, Node: Linker Functions, Next: Hash Tables, Prev: File Caching, Up: BFD front end + +Linker Functions +================ + + The linker uses three special entry points in the BFD target vector. +It is not necessary to write special routines for these entry points +when creating a new BFD back end, since generic versions are provided. +However, writing them can speed up linking and make it use +significantly less runtime memory. + + The first routine creates a hash table used by the other routines. +The second routine adds the symbols from an object file to the hash +table. The third routine takes all the object files and links them +together to create the output file. These routines are designed so +that the linker proper does not need to know anything about the symbols +in the object files that it is linking. The linker merely arranges the +sections as directed by the linker script and lets BFD handle the +details of symbols and relocs. + + The second routine and third routines are passed a pointer to a +`struct bfd_link_info' structure (defined in `bfdlink.h') which holds +information relevant to the link, including the linker hash table +(which was created by the first routine) and a set of callback +functions to the linker proper. + + The generic linker routines are in `linker.c', and use the header +file `genlink.h'. As of this writing, the only back ends which have +implemented versions of these routines are a.out (in `aoutx.h') and +ECOFF (in `ecoff.c'). The a.out routines are used as examples +throughout this section. + +* Menu: + +* Creating a Linker Hash Table:: +* Adding Symbols to the Hash Table:: +* Performing the Final Link:: + + +File: bfd.info, Node: Creating a Linker Hash Table, Next: Adding Symbols to the Hash Table, Prev: Linker Functions, Up: Linker Functions + +Creating a linker hash table +---------------------------- + + The linker routines must create a hash table, which must be derived +from `struct bfd_link_hash_table' described in `bfdlink.c'. *Note Hash +Tables::, for information on how to create a derived hash table. This +entry point is called using the target vector of the linker output file. + + The `_bfd_link_hash_table_create' entry point must allocate and +initialize an instance of the desired hash table. If the back end does +not require any additional information to be stored with the entries in +the hash table, the entry point may simply create a `struct +bfd_link_hash_table'. Most likely, however, some additional +information will be needed. + + For example, with each entry in the hash table the a.out linker +keeps the index the symbol has in the final output file (this index +number is used so that when doing a relocateable link the symbol index +used in the output file can be quickly filled in when copying over a +reloc). The a.out linker code defines the required structures and +functions for a hash table derived from `struct bfd_link_hash_table'. +The a.out linker hash table is created by the function +`NAME(aout,link_hash_table_create)'; it simply allocates space for the +hash table, initializes it, and returns a pointer to it. + + When writing the linker routines for a new back end, you will +generally not know exactly which fields will be required until you have +finished. You should simply create a new hash table which defines no +additional fields, and then simply add fields as they become necessary. + + +File: bfd.info, Node: Adding Symbols to the Hash Table, Next: Performing the Final Link, Prev: Creating a Linker Hash Table, Up: Linker Functions + +Adding symbols to the hash table +-------------------------------- + + The linker proper will call the `_bfd_link_add_symbols' entry point +for each object file or archive which is to be linked (typically these +are the files named on the command line, but some may also come from +the linker script). The entry point is responsible for examining the +file. For an object file, BFD must add any relevant symbol information +to the hash table. For an archive, BFD must determine which elements +of the archive should be used and adding them to the link. + + The a.out version of this entry point is +`NAME(aout,link_add_symbols)'. + +* Menu: + +* Differing file formats:: +* Adding symbols from an object file:: +* Adding symbols from an archive:: + Index: ChangeLog =================================================================== --- ChangeLog (nonexistent) +++ ChangeLog (revision 1765) @@ -0,0 +1,399 @@ +Wed Apr 26 17:57:26 2000 Andrew Cagney + + * Makefile.in: Rebuild using autoconf/automake snapshot with fixed + TEXINPUTS bug. + +Fri Apr 7 17:54:38 2000 Andrew Cagney + + * Makefile.in: Rebuild with current autoconf/automake. + +Thu Feb 4 23:21:36 1999 Ian Lance Taylor + + * Makefile.in: Rebuild with current autoconf/automake. + +Thu Jul 23 09:36:44 1998 Nick Clifton + + * bfdint.texi (BFD ELF processor required): Add paragraph + describing the necessity to create "include/elf/CPU.h". + +Thu May 7 14:45:43 1998 Ian Lance Taylor + + * Makefile.am (chew.o): Add -I options for intl srcdir and + objdir. + * Makefile.in: Rebuild. + +Mon Apr 27 20:19:24 1998 Ian Lance Taylor + + * bfdint.texi: New file. + * Makefile.am (noinst_TEXINFOS): New variable. + * Makefile.in: Rebuild. + +Mon Apr 13 16:48:56 1998 Ian Lance Taylor + + * Makefile.in: Rebuild. + +Mon Apr 6 14:06:55 1998 Ian Lance Taylor + + * Makefile.am (STAGESTUFF): Remove variable. + (CLEANFILES): Don't remove $(STAGESTUFF). + (DISTCLEANFILES, MAINTAINERCLEANFILES): New variables. + * Makefile.in: Rebuild. + +Fri Mar 27 16:25:25 1998 Ian Lance Taylor + + * chew.c (skip_white_and_starts): Remove unused declaration. + (skip_white_and_stars): Add casts to avoid warnings. + (skip_trailing_newlines, paramstuff, courierize): Likewise. + (bulletize, do_fancy_stuff, iscommand): Likewise. + (kill_bogus_lines, nextword, main): Likewise. + (manglecomments): Comment out. + (outputdots, kill_bogus_lines): Remove unused local variables. + (perform, compile): Likewise. + (courierize): Fully parenthesize expression. + (copy_past_newline): Declare return value. + (print): Change printf format string. + (main): Call usage for an unrecognized option. + +Fri Feb 13 14:37:14 1998 Ian Lance Taylor + + * Makefile.am (AUTOMAKE_OPTIONS): Define. + * Makefile.in: Rebuild. + +Mon Jan 26 15:38:36 1998 Andreas Schwab + + * doc.str (bodytext): Don't output @* at the end. + * chew.c (kill_bogus_lines): Make sure that a period at the + beginning is recognized. + (indent): Don't put indentation at the end. + (copy_past_newline): Expand tabs. + * Makefile.am (s-reloc, s-syms): Depend on doc.str. + * Makefile.in: Rebuild. + +Wed Oct 1 14:41:28 1997 Ian Lance Taylor + + * Makefile.am (libbfd.h): Don't use cpu-h8300.c, cpu-i960.c, or + elfcode.h as input files; they don't contribute anything. + * Makefile.in: Rebuild. + +Fri Aug 15 04:55:15 1997 Doug Evans + + * Makefile.am (libbfd.h, libcoff.h): Invoke $(MKDOC) as ./$(MKDOC). + * Makefile.in: Rebuild. + +Fri Aug 1 12:59:58 1997 Ian Lance Taylor + + * Makefile.am (CC_FOR_BUILD): Don't set explicitly. + * Makefile.in: Rebuild. + +Thu Jul 31 20:00:12 1997 Ian Lance Taylor + + * Makefile.am: New file, based on old Makefile.in. + * Makefile.in: Now built with automake. + +Tue Jul 22 14:44:00 1997 Robert Hoehne + + * Makefile.in: Change stamp-* files to s-* files. Use bfdt.texi + rather than bfd.texi. + (DOCFILES): Change bfd.texi to bfdt.texi. + * bfd.texinfo: Include bfdt.texi, not bfd.texi. + +Mon Jun 16 15:33:15 1997 Ian Lance Taylor + + * Makefile.in (CC, CFLAGS): Substitute from configure script. + From Jeff Makey . + +Tue Apr 15 12:37:41 1997 Ian Lance Taylor + + * Makefile.in (install-info): Use mkinstalldirs to build + $(infodir). + +Tue Apr 8 12:49:46 1997 Ian Lance Taylor + + * Makefile.in (install-info): Permit info files to be in srcdir. + (stamp-*): Add a stamp-X target for each X.texi target. + (*.texi): Just depend upon stamp-X. + (clean): Remove stamp-*. + (distclean): Depend upon mostlyclean. Remove stamp-*. Don't + remove $(DOCFILES). + +Mon Apr 7 15:23:26 1997 Ian Lance Taylor + + * Makefile.in (distclean): Don't remove *.info files. + +Thu Feb 13 20:50:02 1997 Klaus Kaempf (kkaempf@progis.de) + + * makefile.vms: New file. + +Tue Jun 18 18:32:28 1996 Ian Lance Taylor + + * chew.c (kill_bogus_lines): Reset sl when not at the start of a + line. From Uwe Ohse . + +Tue Jan 30 14:10:46 1996 Ian Lance Taylor + + From Ronald F. Guilmette : + * Makefile.in (libbfd.h): Depend upon proto.str. + (libcoff.h, bfd.h): Likewise. + +Fri Nov 3 14:46:48 1995 Fred Fish + + * Makefile.in (SRCDOC, SRCPROT, core.texi, bfd.h): Use corefile.c, + renamed from core.c. + +Wed Nov 1 14:28:23 1995 Manfred Hollstein KS/EF4A 60/1F/110 #40283 + + * chew.c: Include . + +Fri Oct 6 16:23:34 1995 Ken Raeburn + + Mon Sep 25 22:49:32 1995 Andreas Schwab + + * Makefile.in (Makefile): Only remake this Makefile. + +Wed Oct 4 15:51:05 1995 Ken Raeburn + + * chew.c: Include . + +Tue Sep 12 18:14:50 1995 Ian Lance Taylor + + * Makefile.in (maintainer-clean): New target. + +Thu Aug 31 12:18:43 1995 Ian Lance Taylor + + * Makefile.in (bfd.h): Add additional #endif at end of bfd.h if + __cplusplus is defined. + +Tue Nov 29 16:13:34 1994 Doug Evans + + * chew.c (write_buffer): New argument `f', all callers changed. + (stdout, stderr, print, drop, idrop): New forth words. + * proto.str (COMMENT): New command. + * doc.str (COMMENT): Likewise. + +Mon Sep 12 11:44:17 1994 Ian Lance Taylor (ian@sanguine.cygnus.com) + + * Makefile.in (DOCFILES): Remove ctor.texi. + (IPROTOS): Remove ctor.ip. + (SRCIPROT): Remove $(srcdir)/../ctor.c. + (ctor.texi): Remove target. + (libbfd.h): Remove dependency on $(srcdir)/../ctor.c. Remove + $(MKDOC) run on $(srcdir)/../ctor.c. + * bfd.texinfo (Constructors): Remove section. + +Fri Sep 2 13:33:44 1994 Ken Raeburn (raeburn@cujo.cygnus.com) + + * chew.c: Include assert.h. Added prototypes for most functions. + Changed most uses of int to long. Do bounds checking on the + stacks. Added comment at the beginning documenting most of the + intrinsics. Lots of whitespace changes. Re-ordered some + functions. + (die, check_range, icheck_range): New functions. + (strip_trailing_newlines, print_stack_level): New functions. + (translatecomments): Don't insert tab before "/*". + (iscommand): Minimum command length is now 4. + (nextword): Handle some \-sequences. + (push_addr): Deleted. + (main): Add new intrinsics strip_trailing_newlines and + print_stack_level. Complain at end if stack contains more than + one element, or less. + (remchar): Make sure the string is not empty before chopping off a + character. + + * doc.str, proto.str: Handle new commands SENUM, ENUM, ENUMX, + ENUMEQ, ENUMEQX, ENUMDOC. + +Wed Jan 12 18:37:12 1994 Ian Lance Taylor (ian@tweedledumb.cygnus.com) + + * bfd.texinfo: Added Linker Functions node. + * doc/Makefile.in (DOCFILES): Added linker.texi. + (SRCDOC): Added linker.c. + (linker.texi): New target. + +Tue Jan 4 10:52:56 1994 Ian Lance Taylor (ian@tweedledumb.cygnus.com) + + * chew.c: Don't rely on a correct declaration of exit. + (chew_exit): New function which just calls exit. + (main): Use it. + +Mon Jan 3 11:40:40 1994 Ian Lance Taylor (ian@tweedledumb.cygnus.com) + + * bfd.texinfo: Added Hash Tables node. + * Makefile.in (DOCFILES): Added hash.texi. + (SRCDOC): Added hash.c. + (hash.texi): New target. + +Thu Dec 30 16:57:04 1993 Ken Raeburn (raeburn@cujo.cygnus.com) + + * Makefile.in: Delete all references to seclet.c, since it's just + been deleted. Don't mention hash.c, linker.c, or genlink.h yet, + since they don't contain documentation yet (hint, hint!). + +Fri Nov 5 10:58:53 1993 David J. Mackenzie (djm@thepub.cygnus.com) + + * bfd.texinfo: Small cleanups. + +Fri Nov 19 03:46:11 1993 Ken Raeburn (raeburn@cambridge.cygnus.com) + + * Makefile.in (archures.texi): Depends on $(MKDOC). + +Tue Aug 10 14:22:39 1993 Ken Raeburn (raeburn@cambridge.cygnus.com) + + * bfd.texinfo (BFD back end): Don't include elfcode.texi, since + it's empty now and that triggers a makeinfo bug. + +Mon Aug 9 16:27:30 1993 Ken Raeburn (raeburn@cambridge.cygnus.com) + + * bfd.texinfo (BFD back end): New section on ELF, includes + elf.texi and elfcode.texi. + * Makefile.in (DOCFILES): Include elf.texi, elfcode.texi. + (SRCDOC): Include elfcode.h, elf.c. + (elf.texi, elfcode.texi): New intermediate targets. + +Thu Jun 24 13:48:13 1993 David J. Mackenzie (djm@thepub.cygnus.com) + + * Makefile.in (.c.o, chew.o): Put CFLAGS last. + * bfdsumm.texi: New file, broken out of bfd.texinfo, to share + with ld.texinfo. + +Mon Jun 14 12:07:07 1993 david d `zoo' zuhn (zoo at rtl.cygnus.com) + + * Makefile.in (install-info): remove parentdir cruft, + +Wed Jun 9 16:00:32 1993 Jim Kingdon (kingdon@cygnus.com) + + * Makefile.in (mostlyclean): Remove chew.o. + +Tue May 25 14:46:58 1993 Ken Raeburn (raeburn@cambridge.cygnus.com) + + * Makefile.in (libbfd.h): Use elfcode.h, not elf32.c. + +Mon May 24 15:50:07 1993 Ken Raeburn (raeburn@cygnus.com) + + * chew.c (compile): Add a couple of missing casts. + +Wed May 12 14:45:14 1993 Ian Lance Taylor (ian@cygnus.com) + + * Makefile.in (CC_FOR_BUILD): New variable, define to be $(CC). + (chew.o, $(MKDOC)): Build using CC_FOR_BUILD rather than CC, since + it must run on the build machine. + +Tue Apr 6 22:38:10 1993 John Gilmore (gnu@cygnus.com) + + * Makefile.in (chew): Don't compile from .c to executable in a + single step; it puts a temporary .o filename into the executable, + which makes multi-stage comparisons fail. Compile chew.c to + chew.o, and link that, which makes identical executables every time. + +Wed Mar 24 17:26:29 1993 david d `zoo' zuhn (zoo at poseidon.cygnus.com) + + * Makefile.in: fix typo (bfd.texinfo not bfd.texino) + +Fri Mar 19 01:13:00 1993 Ken Raeburn (raeburn@kr-pc.cygnus.com) + + * bfd.texinfo: Since BFD version number has been bumped, do same + to "version number" on title page, and elsewhere. Should be + fixed to extract real version number. + +Tue Mar 16 12:15:13 1993 Per Bothner (bothner@rtl.cygnus.com) + + * Makefile.in: Add *clean rules. + +Mon Jan 11 18:43:56 1993 Ian Lance Taylor (ian@tweedledumb.cygnus.com) + + * Makefile.in (libbfd.h): Removed duplicate init.c and libbfd.c. + Added seclet.c. + (bfd.h): Added dependency on bfd.c and seclet.c. Added seclet.c + to build. + +Thu Dec 17 19:35:43 1992 david d `zoo' zuhn (zoo at cirdan.cygnus.com) + + * Makefile.in: added dvi target, define and use $(TEXI2DVI) + +Thu Dec 3 17:42:48 1992 Ken Raeburn (raeburn@cambridge.cygnus.com) + + * Makefile.in (TEXIDIR): New variable. + (bfd.dvi): Look for bfd.texinfo in $(srcdir). Generate index. + + * bfd.texinfo: Minor doc fixes. + +Thu Nov 5 03:13:55 1992 John Gilmore (gnu@cygnus.com) + + Cleanup: Replace all uses of EXFUN in the BFD sources, with PARAMS. + + * doc/chew.c (exfunstuff): Eliminate. + (paramstuff): Replace exfunstuff with function to generate PARAMS. + * doc/proto.str: Use paramstuff rather than exfunstuff. + +Mon Aug 17 12:40:32 1992 Steve Chamberlain (sac@thepub.cygnus.com) + + * chew.c: various patches provided by Howard Chu. + +Fri Jun 19 18:59:54 1992 John Gilmore (gnu at cygnus.com) + + * Makefile.in (libbfd.h): Add elf.c as a source of prototypes. + +Mon May 11 18:55:59 1992 John Gilmore (gnu at cygnus.com) + + * chew.c: exit() should be declared by config files, not by + portable source code. Its type could be int or void function. + +Mon May 4 13:45:57 1992 K. Richard Pixley (rich@rtl.cygnus.com) + + * Makefile.in: another CFLAGS correction. + +Tue Apr 28 10:21:32 1992 K. Richard Pixley (rich@rtl.cygnus.com) + + * Makefile.in: Do the CFLAGS thing. + +Fri Apr 10 22:34:52 1992 Fred Fish (fnf@cygnus.com) + + * Makefile.in (MINUS_G): Add macro and default to -g. + +Fri Mar 6 18:53:18 1992 Steve Chamberlain (sac@thepub.cygnus.com) + + * chew.c: now has -w switch turn on warnings + +Wed Feb 26 18:04:40 1992 K. Richard Pixley (rich@cygnus.com) + + * Makefile.in, configure.in: removed traces of namesubdir, + -subdirs, $(subdir), $(unsubdir), some rcs triggers. Forced + copyrights to '92, changed some from Cygnus to FSF. + +Tue Dec 10 22:11:05 1991 K. Richard Pixley (rich at rtl.cygnus.com) + + * Makefile.in: build chew into the current directory. Complete + the MKDOC macro transition. + +Tue Dec 10 08:26:28 1991 Steve Chamberlain (sac at rtl.cygnus.com) + + * chew.c: don't core dump when can't open file + * Makefile.in: get proto.str from the right place when built in + odd directories + +Tue Dec 10 04:07:25 1991 K. Richard Pixley (rich at rtl.cygnus.com) + + * Makefile.in: infodir belongs in datadir. + +Sat Dec 7 17:01:23 1991 Steve Chamberlain (sac at rtl.cygnus.com) + + * chew.c: Much modified + * proto.str, doc.str: New files for extracting to product + prototypes and documents respectively. + + +Fri Dec 6 22:57:12 1991 K. Richard Pixley (rich at rtl.cygnus.com) + + * Makefile.in: added standards.text support, host/site/target + inclusion hooks, install using INSTALL_DATA rather than cp, + don't echo on install. + +Thu Dec 5 22:46:17 1991 K. Richard Pixley (rich at rtl.cygnus.com) + + * Makefile.in: idestdir and ddestdir go away. Added copyrights + and shift gpl to v2. Added ChangeLog if it didn't exist. docdir + and mandir now keyed off datadir by default. + + +Local Variables: +version-control: never +End: Index: bfd.info-5 =================================================================== --- bfd.info-5 (nonexistent) +++ bfd.info-5 (revision 1765) @@ -0,0 +1,736 @@ +This is bfd.info, produced by Makeinfo version 3.12f from bfd.texinfo. + +START-INFO-DIR-ENTRY +* Bfd: (bfd). The Binary File Descriptor library. +END-INFO-DIR-ENTRY + + This file documents the BFD library. + + Copyright (C) 1991 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, subject to the +terms of the GNU General Public License, which includes the provision +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: bfd.info, Node: Differing file formats, Next: Adding symbols from an object file, Prev: Adding Symbols to the Hash Table, Up: Adding Symbols to the Hash Table + +Differing file formats +...................... + + Normally all the files involved in a link will be of the same +format, but it is also possible to link together different format +object files, and the back end must support that. The +`_bfd_link_add_symbols' entry point is called via the target vector of +the file to be added. This has an important consequence: the function +may not assume that the hash table is the type created by the +corresponding `_bfd_link_hash_table_create' vector. All the +`_bfd_link_add_symbols' function can assume about the hash table is +that it is derived from `struct bfd_link_hash_table'. + + Sometimes the `_bfd_link_add_symbols' function must store some +information in the hash table entry to be used by the `_bfd_final_link' +function. In such a case the `creator' field of the hash table must be +checked to make sure that the hash table was created by an object file +of the same format. + + The `_bfd_final_link' routine must be prepared to handle a hash +entry without any extra information added by the +`_bfd_link_add_symbols' function. A hash entry without extra +information will also occur when the linker script directs the linker +to create a symbol. Note that, regardless of how a hash table entry is +added, all the fields will be initialized to some sort of null value by +the hash table entry initialization function. + + See `ecoff_link_add_externals' for an example of how to check the +`creator' field before saving information (in this case, the ECOFF +external symbol debugging information) in a hash table entry. + + +File: bfd.info, Node: Adding symbols from an object file, Next: Adding symbols from an archive, Prev: Differing file formats, Up: Adding Symbols to the Hash Table + +Adding symbols from an object file +.................................. + + When the `_bfd_link_add_symbols' routine is passed an object file, +it must add all externally visible symbols in that object file to the +hash table. The actual work of adding the symbol to the hash table is +normally handled by the function `_bfd_generic_link_add_one_symbol'. +The `_bfd_link_add_symbols' routine is responsible for reading all the +symbols from the object file and passing the correct information to +`_bfd_generic_link_add_one_symbol'. + + The `_bfd_link_add_symbols' routine should not use +`bfd_canonicalize_symtab' to read the symbols. The point of providing +this routine is to avoid the overhead of converting the symbols into +generic `asymbol' structures. + + `_bfd_generic_link_add_one_symbol' handles the details of combining +common symbols, warning about multiple definitions, and so forth. It +takes arguments which describe the symbol to add, notably symbol flags, +a section, and an offset. The symbol flags include such things as +`BSF_WEAK' or `BSF_INDIRECT'. The section is a section in the object +file, or something like `bfd_und_section_ptr' for an undefined symbol +or `bfd_com_section_ptr' for a common symbol. + + If the `_bfd_final_link' routine is also going to need to read the +symbol information, the `_bfd_link_add_symbols' routine should save it +somewhere attached to the object file BFD. However, the information +should only be saved if the `keep_memory' field of the `info' argument +is true, so that the `-no-keep-memory' linker switch is effective. + + The a.out function which adds symbols from an object file is +`aout_link_add_object_symbols', and most of the interesting work is in +`aout_link_add_symbols'. The latter saves pointers to the hash tables +entries created by `_bfd_generic_link_add_one_symbol' indexed by symbol +number, so that the `_bfd_final_link' routine does not have to call the +hash table lookup routine to locate the entry. + + +File: bfd.info, Node: Adding symbols from an archive, Prev: Adding symbols from an object file, Up: Adding Symbols to the Hash Table + +Adding symbols from an archive +.............................. + + When the `_bfd_link_add_symbols' routine is passed an archive, it +must look through the symbols defined by the archive and decide which +elements of the archive should be included in the link. For each such +element it must call the `add_archive_element' linker callback, and it +must add the symbols from the object file to the linker hash table. + + In most cases the work of looking through the symbols in the archive +should be done by the `_bfd_generic_link_add_archive_symbols' function. +This function builds a hash table from the archive symbol table and +looks through the list of undefined symbols to see which elements +should be included. `_bfd_generic_link_add_archive_symbols' is passed +a function to call to make the final decision about adding an archive +element to the link and to do the actual work of adding the symbols to +the linker hash table. + + The function passed to `_bfd_generic_link_add_archive_symbols' must +read the symbols of the archive element and decide whether the archive +element should be included in the link. If the element is to be +included, the `add_archive_element' linker callback routine must be +called with the element as an argument, and the elements symbols must +be added to the linker hash table just as though the element had itself +been passed to the `_bfd_link_add_symbols' function. + + When the a.out `_bfd_link_add_symbols' function receives an archive, +it calls `_bfd_generic_link_add_archive_symbols' passing +`aout_link_check_archive_element' as the function argument. +`aout_link_check_archive_element' calls `aout_link_check_ar_symbols'. +If the latter decides to add the element (an element is only added if +it provides a real, non-common, definition for a previously undefined +or common symbol) it calls the `add_archive_element' callback and then +`aout_link_check_archive_element' calls `aout_link_add_symbols' to +actually add the symbols to the linker hash table. + + The ECOFF back end is unusual in that it does not normally call +`_bfd_generic_link_add_archive_symbols', because ECOFF archives already +contain a hash table of symbols. The ECOFF back end searches the +archive itself to avoid the overhead of creating a new hash table. + + +File: bfd.info, Node: Performing the Final Link, Prev: Adding Symbols to the Hash Table, Up: Linker Functions + +Performing the final link +------------------------- + + When all the input files have been processed, the linker calls the +`_bfd_final_link' entry point of the output BFD. This routine is +responsible for producing the final output file, which has several +aspects. It must relocate the contents of the input sections and copy +the data into the output sections. It must build an output symbol +table including any local symbols from the input files and the global +symbols from the hash table. When producing relocateable output, it +must modify the input relocs and write them into the output file. +There may also be object format dependent work to be done. + + The linker will also call the `write_object_contents' entry point +when the BFD is closed. The two entry points must work together in +order to produce the correct output file. + + The details of how this works are inevitably dependent upon the +specific object file format. The a.out `_bfd_final_link' routine is +`NAME(aout,final_link)'. + +* Menu: + +* Information provided by the linker:: +* Relocating the section contents:: +* Writing the symbol table:: + + +File: bfd.info, Node: Information provided by the linker, Next: Relocating the section contents, Prev: Performing the Final Link, Up: Performing the Final Link + +Information provided by the linker +.................................. + + Before the linker calls the `_bfd_final_link' entry point, it sets +up some data structures for the function to use. + + The `input_bfds' field of the `bfd_link_info' structure will point +to a list of all the input files included in the link. These files are +linked through the `link_next' field of the `bfd' structure. + + Each section in the output file will have a list of `link_order' +structures attached to the `link_order_head' field (the `link_order' +structure is defined in `bfdlink.h'). These structures describe how to +create the contents of the output section in terms of the contents of +various input sections, fill constants, and, eventually, other types of +information. They also describe relocs that must be created by the BFD +backend, but do not correspond to any input file; this is used to +support -Ur, which builds constructors while generating a relocateable +object file. + + +File: bfd.info, Node: Relocating the section contents, Next: Writing the symbol table, Prev: Information provided by the linker, Up: Performing the Final Link + +Relocating the section contents +............................... + + The `_bfd_final_link' function should look through the `link_order' +structures attached to each section of the output file. Each +`link_order' structure should either be handled specially, or it should +be passed to the function `_bfd_default_link_order' which will do the +right thing (`_bfd_default_link_order' is defined in `linker.c'). + + For efficiency, a `link_order' of type `bfd_indirect_link_order' +whose associated section belongs to a BFD of the same format as the +output BFD must be handled specially. This type of `link_order' +describes part of an output section in terms of a section belonging to +one of the input files. The `_bfd_final_link' function should read the +contents of the section and any associated relocs, apply the relocs to +the section contents, and write out the modified section contents. If +performing a relocateable link, the relocs themselves must also be +modified and written out. + + The functions `_bfd_relocate_contents' and +`_bfd_final_link_relocate' provide some general support for performing +the actual relocations, notably overflow checking. Their arguments +include information about the symbol the relocation is against and a +`reloc_howto_type' argument which describes the relocation to perform. +These functions are defined in `reloc.c'. + + The a.out function which handles reading, relocating, and writing +section contents is `aout_link_input_section'. The actual relocation +is done in `aout_link_input_section_std' and +`aout_link_input_section_ext'. + + +File: bfd.info, Node: Writing the symbol table, Prev: Relocating the section contents, Up: Performing the Final Link + +Writing the symbol table +........................ + + The `_bfd_final_link' function must gather all the symbols in the +input files and write them out. It must also write out all the symbols +in the global hash table. This must be controlled by the `strip' and +`discard' fields of the `bfd_link_info' structure. + + The local symbols of the input files will not have been entered into +the linker hash table. The `_bfd_final_link' routine must consider +each input file and include the symbols in the output file. It may be +convenient to do this when looking through the `link_order' structures, +or it may be done by stepping through the `input_bfds' list. + + The `_bfd_final_link' routine must also traverse the global hash +table to gather all the externally visible symbols. It is possible +that most of the externally visible symbols may be written out when +considering the symbols of each input file, but it is still necessary +to traverse the hash table since the linker script may have defined +some symbols that are not in any of the input files. + + The `strip' field of the `bfd_link_info' structure controls which +symbols are written out. The possible values are listed in +`bfdlink.h'. If the value is `strip_some', then the `keep_hash' field +of the `bfd_link_info' structure is a hash table of symbols to keep; +each symbol should be looked up in this hash table, and only symbols +which are present should be included in the output file. + + If the `strip' field of the `bfd_link_info' structure permits local +symbols to be written out, the `discard' field is used to further +controls which local symbols are included in the output file. If the +value is `discard_l', then all local symbols which begin with a certain +prefix are discarded; this is controlled by the +`bfd_is_local_label_name' entry point. + + The a.out backend handles symbols by calling +`aout_link_write_symbols' on each input BFD and then traversing the +global hash table with the function `aout_link_write_other_symbol'. It +builds a string table while writing out the symbols, which is written +to the output file at the end of `NAME(aout,final_link)'. + +`bfd_link_split_section' +........................ + + *Synopsis* + boolean bfd_link_split_section(bfd *abfd, asection *sec); + *Description* +Return nonzero if SEC should be split during a reloceatable or final +link. + #define bfd_link_split_section(abfd, sec) \ + BFD_SEND (abfd, _bfd_link_split_section, (abfd, sec)) + + +File: bfd.info, Node: Hash Tables, Prev: Linker Functions, Up: BFD front end + +Hash Tables +=========== + + BFD provides a simple set of hash table functions. Routines are +provided to initialize a hash table, to free a hash table, to look up a +string in a hash table and optionally create an entry for it, and to +traverse a hash table. There is currently no routine to delete an +string from a hash table. + + The basic hash table does not permit any data to be stored with a +string. However, a hash table is designed to present a base class from +which other types of hash tables may be derived. These derived types +may store additional information with the string. Hash tables were +implemented in this way, rather than simply providing a data pointer in +a hash table entry, because they were designed for use by the linker +back ends. The linker may create thousands of hash table entries, and +the overhead of allocating private data and storing and following +pointers becomes noticeable. + + The basic hash table code is in `hash.c'. + +* Menu: + +* Creating and Freeing a Hash Table:: +* Looking Up or Entering a String:: +* Traversing a Hash Table:: +* Deriving a New Hash Table Type:: + + +File: bfd.info, Node: Creating and Freeing a Hash Table, Next: Looking Up or Entering a String, Prev: Hash Tables, Up: Hash Tables + +Creating and freeing a hash table +--------------------------------- + + To create a hash table, create an instance of a `struct +bfd_hash_table' (defined in `bfd.h') and call `bfd_hash_table_init' (if +you know approximately how many entries you will need, the function +`bfd_hash_table_init_n', which takes a SIZE argument, may be used). +`bfd_hash_table_init' returns `false' if some sort of error occurs. + + The function `bfd_hash_table_init' take as an argument a function to +use to create new entries. For a basic hash table, use the function +`bfd_hash_newfunc'. *Note Deriving a New Hash Table Type::, for why +you would want to use a different value for this argument. + + `bfd_hash_table_init' will create an objalloc which will be used to +allocate new entries. You may allocate memory on this objalloc using +`bfd_hash_allocate'. + + Use `bfd_hash_table_free' to free up all the memory that has been +allocated for a hash table. This will not free up the `struct +bfd_hash_table' itself, which you must provide. + + +File: bfd.info, Node: Looking Up or Entering a String, Next: Traversing a Hash Table, Prev: Creating and Freeing a Hash Table, Up: Hash Tables + +Looking up or entering a string +------------------------------- + + The function `bfd_hash_lookup' is used both to look up a string in +the hash table and to create a new entry. + + If the CREATE argument is `false', `bfd_hash_lookup' will look up a +string. If the string is found, it will returns a pointer to a `struct +bfd_hash_entry'. If the string is not found in the table +`bfd_hash_lookup' will return `NULL'. You should not modify any of the +fields in the returns `struct bfd_hash_entry'. + + If the CREATE argument is `true', the string will be entered into +the hash table if it is not already there. Either way a pointer to a +`struct bfd_hash_entry' will be returned, either to the existing +structure or to a newly created one. In this case, a `NULL' return +means that an error occurred. + + If the CREATE argument is `true', and a new entry is created, the +COPY argument is used to decide whether to copy the string onto the +hash table objalloc or not. If COPY is passed as `false', you must be +careful not to deallocate or modify the string as long as the hash table +exists. + + +File: bfd.info, Node: Traversing a Hash Table, Next: Deriving a New Hash Table Type, Prev: Looking Up or Entering a String, Up: Hash Tables + +Traversing a hash table +----------------------- + + The function `bfd_hash_traverse' may be used to traverse a hash +table, calling a function on each element. The traversal is done in a +random order. + + `bfd_hash_traverse' takes as arguments a function and a generic +`void *' pointer. The function is called with a hash table entry (a +`struct bfd_hash_entry *') and the generic pointer passed to +`bfd_hash_traverse'. The function must return a `boolean' value, which +indicates whether to continue traversing the hash table. If the +function returns `false', `bfd_hash_traverse' will stop the traversal +and return immediately. + + +File: bfd.info, Node: Deriving a New Hash Table Type, Prev: Traversing a Hash Table, Up: Hash Tables + +Deriving a new hash table type +------------------------------ + + Many uses of hash tables want to store additional information which +each entry in the hash table. Some also find it convenient to store +additional information with the hash table itself. This may be done +using a derived hash table. + + Since C is not an object oriented language, creating a derived hash +table requires sticking together some boilerplate routines with a few +differences specific to the type of hash table you want to create. + + An example of a derived hash table is the linker hash table. The +structures for this are defined in `bfdlink.h'. The functions are in +`linker.c'. + + You may also derive a hash table from an already derived hash table. +For example, the a.out linker backend code uses a hash table derived +from the linker hash table. + +* Menu: + +* Define the Derived Structures:: +* Write the Derived Creation Routine:: +* Write Other Derived Routines:: + + +File: bfd.info, Node: Define the Derived Structures, Next: Write the Derived Creation Routine, Prev: Deriving a New Hash Table Type, Up: Deriving a New Hash Table Type + +Define the derived structures +............................. + + You must define a structure for an entry in the hash table, and a +structure for the hash table itself. + + The first field in the structure for an entry in the hash table must +be of the type used for an entry in the hash table you are deriving +from. If you are deriving from a basic hash table this is `struct +bfd_hash_entry', which is defined in `bfd.h'. The first field in the +structure for the hash table itself must be of the type of the hash +table you are deriving from itself. If you are deriving from a basic +hash table, this is `struct bfd_hash_table'. + + For example, the linker hash table defines `struct +bfd_link_hash_entry' (in `bfdlink.h'). The first field, `root', is of +type `struct bfd_hash_entry'. Similarly, the first field in `struct +bfd_link_hash_table', `table', is of type `struct bfd_hash_table'. + + +File: bfd.info, Node: Write the Derived Creation Routine, Next: Write Other Derived Routines, Prev: Define the Derived Structures, Up: Deriving a New Hash Table Type + +Write the derived creation routine +.................................. + + You must write a routine which will create and initialize an entry +in the hash table. This routine is passed as the function argument to +`bfd_hash_table_init'. + + In order to permit other hash tables to be derived from the hash +table you are creating, this routine must be written in a standard way. + + The first argument to the creation routine is a pointer to a hash +table entry. This may be `NULL', in which case the routine should +allocate the right amount of space. Otherwise the space has already +been allocated by a hash table type derived from this one. + + After allocating space, the creation routine must call the creation +routine of the hash table type it is derived from, passing in a pointer +to the space it just allocated. This will initialize any fields used +by the base hash table. + + Finally the creation routine must initialize any local fields for +the new hash table type. + + Here is a boilerplate example of a creation routine. FUNCTION_NAME +is the name of the routine. ENTRY_TYPE is the type of an entry in the +hash table you are creating. BASE_NEWFUNC is the name of the creation +routine of the hash table type your hash table is derived from. + + struct bfd_hash_entry * + FUNCTION_NAME (entry, table, string) + struct bfd_hash_entry *entry; + struct bfd_hash_table *table; + const char *string; + { + struct ENTRY_TYPE *ret = (ENTRY_TYPE *) entry; + + /* Allocate the structure if it has not already been allocated by a + derived class. */ + if (ret == (ENTRY_TYPE *) NULL) + { + ret = ((ENTRY_TYPE *) + bfd_hash_allocate (table, sizeof (ENTRY_TYPE))); + if (ret == (ENTRY_TYPE *) NULL) + return NULL; + } + + /* Call the allocation method of the base class. */ + ret = ((ENTRY_TYPE *) + BASE_NEWFUNC ((struct bfd_hash_entry *) ret, table, string)); + + /* Initialize the local fields here. */ + + return (struct bfd_hash_entry *) ret; + } + *Description* +The creation routine for the linker hash table, which is in `linker.c', +looks just like this example. FUNCTION_NAME is +`_bfd_link_hash_newfunc'. ENTRY_TYPE is `struct bfd_link_hash_entry'. +BASE_NEWFUNC is `bfd_hash_newfunc', the creation routine for a basic +hash table. + + `_bfd_link_hash_newfunc' also initializes the local fields in a +linker hash table entry: `type', `written' and `next'. + + +File: bfd.info, Node: Write Other Derived Routines, Prev: Write the Derived Creation Routine, Up: Deriving a New Hash Table Type + +Write other derived routines +............................ + + You will want to write other routines for your new hash table, as +well. + + You will want an initialization routine which calls the +initialization routine of the hash table you are deriving from and +initializes any other local fields. For the linker hash table, this is +`_bfd_link_hash_table_init' in `linker.c'. + + You will want a lookup routine which calls the lookup routine of the +hash table you are deriving from and casts the result. The linker hash +table uses `bfd_link_hash_lookup' in `linker.c' (this actually takes an +additional argument which it uses to decide how to return the looked up +value). + + You may want a traversal routine. This should just call the +traversal routine of the hash table you are deriving from with +appropriate casts. The linker hash table uses `bfd_link_hash_traverse' +in `linker.c'. + + These routines may simply be defined as macros. For example, the +a.out backend linker hash table, which is derived from the linker hash +table, uses macros for the lookup and traversal routines. These are +`aout_link_hash_lookup' and `aout_link_hash_traverse' in aoutx.h. + + +File: bfd.info, Node: BFD back ends, Next: Index, Prev: BFD front end, Up: Top + +BFD back ends +************* + +* Menu: + +* What to Put Where:: +* aout :: a.out backends +* coff :: coff backends +* elf :: elf backends + + +File: bfd.info, Node: What to Put Where, Next: aout, Prev: BFD back ends, Up: BFD back ends + + All of BFD lives in one directory. + + +File: bfd.info, Node: aout, Next: coff, Prev: What to Put Where, Up: BFD back ends + +a.out backends +============== + + *Description* +BFD supports a number of different flavours of a.out format, though the +major differences are only the sizes of the structures on disk, and the +shape of the relocation information. + + The support is split into a basic support file `aoutx.h' and other +files which derive functions from the base. One derivation file is +`aoutf1.h' (for a.out flavour 1), and adds to the basic a.out functions +support for sun3, sun4, 386 and 29k a.out files, to create a target +jump vector for a specific target. + + This information is further split out into more specific files for +each machine, including `sunos.c' for sun3 and sun4, `newsos3.c' for +the Sony NEWS, and `demo64.c' for a demonstration of a 64 bit a.out +format. + + The base file `aoutx.h' defines general mechanisms for reading and +writing records to and from disk and various other methods which BFD +requires. It is included by `aout32.c' and `aout64.c' to form the names +`aout_32_swap_exec_header_in', `aout_64_swap_exec_header_in', etc. + + As an example, this is what goes on to make the back end for a sun4, +from `aout32.c': + + #define ARCH_SIZE 32 + #include "aoutx.h" + + Which exports names: + + ... + aout_32_canonicalize_reloc + aout_32_find_nearest_line + aout_32_get_lineno + aout_32_get_reloc_upper_bound + ... + + from `sunos.c': + + #define TARGET_NAME "a.out-sunos-big" + #define VECNAME sunos_big_vec + #include "aoutf1.h" + + requires all the names from `aout32.c', and produces the jump vector + + sunos_big_vec + + The file `host-aout.c' is a special case. It is for a large set of +hosts that use "more or less standard" a.out files, and for which +cross-debugging is not interesting. It uses the standard 32-bit a.out +support routines, but determines the file offsets and addresses of the +text, data, and BSS sections, the machine architecture and machine +type, and the entry point address, in a host-dependent manner. Once +these values have been determined, generic code is used to handle the +object file. + + When porting it to run on a new system, you must supply: + + HOST_PAGE_SIZE + HOST_SEGMENT_SIZE + HOST_MACHINE_ARCH (optional) + HOST_MACHINE_MACHINE (optional) + HOST_TEXT_START_ADDR + HOST_STACK_END_ADDR + + in the file `../include/sys/h-XXX.h' (for your host). These values, +plus the structures and macros defined in `a.out.h' on your host +system, will produce a BFD target that will access ordinary a.out files +on your host. To configure a new machine to use `host-aout.c', specify: + + TDEFAULTS = -DDEFAULT_VECTOR=host_aout_big_vec + TDEPFILES= host-aout.o trad-core.o + + in the `config/XXX.mt' file, and modify `configure.in' to use the +`XXX.mt' file (by setting "`bfd_target=XXX'") when your configuration +is selected. + +Relocations +----------- + + *Description* +The file `aoutx.h' provides for both the _standard_ and _extended_ +forms of a.out relocation records. + + The standard records contain only an address, a symbol index, and a +type field. The extended records (used on 29ks and sparcs) also have a +full integer for an addend. + +Internal entry points +--------------------- + + *Description* +`aoutx.h' exports several routines for accessing the contents of an +a.out file, which are gathered and exported in turn by various format +specific files (eg sunos.c). + +`aout_SIZE_swap_exec_header_in' +............................... + + *Synopsis* + void aout_SIZE_swap_exec_header_in, + (bfd *abfd, + struct external_exec *raw_bytes, + struct internal_exec *execp); + *Description* +Swap the information in an executable header RAW_BYTES taken from a raw +byte stream memory image into the internal exec header structure EXECP. + +`aout_SIZE_swap_exec_header_out' +................................ + + *Synopsis* + void aout_SIZE_swap_exec_header_out + (bfd *abfd, + struct internal_exec *execp, + struct external_exec *raw_bytes); + *Description* +Swap the information in an internal exec header structure EXECP into +the buffer RAW_BYTES ready for writing to disk. + +`aout_SIZE_some_aout_object_p' +.............................. + + *Synopsis* + const bfd_target *aout_SIZE_some_aout_object_p + (bfd *abfd, + const bfd_target *(*callback_to_real_object_p)()); + *Description* +Some a.out variant thinks that the file open in ABFD checking is an +a.out file. Do some more checking, and set up for access if it really +is. Call back to the calling environment's "finish up" function just +before returning, to handle any last-minute setup. + +`aout_SIZE_mkobject' +.................... + + *Synopsis* + boolean aout_SIZE_mkobject, (bfd *abfd); + *Description* +Initialize BFD ABFD for use with a.out files. + +`aout_SIZE_machine_type' +........................ + + *Synopsis* + enum machine_type aout_SIZE_machine_type + (enum bfd_architecture arch, + unsigned long machine)); + *Description* +Keep track of machine architecture and machine type for a.out's. Return +the `machine_type' for a particular architecture and machine, or +`M_UNKNOWN' if that exact architecture and machine can't be represented +in a.out format. + + If the architecture is understood, machine type 0 (default) is +always understood. + +`aout_SIZE_set_arch_mach' +......................... + + *Synopsis* + boolean aout_SIZE_set_arch_mach, + (bfd *, + enum bfd_architecture arch, + unsigned long machine)); + *Description* +Set the architecture and the machine of the BFD ABFD to the values ARCH +and MACHINE. Verify that ABFD's format can support the architecture +required. + +`aout_SIZE_new_section_hook' +............................ + + *Synopsis* + boolean aout_SIZE_new_section_hook, + (bfd *abfd, + asection *newsect)); + *Description* +Called by the BFD in response to a `bfd_make_section' request. + Index: bfd.info-6 =================================================================== --- bfd.info-6 (nonexistent) +++ bfd.info-6 (revision 1765) @@ -0,0 +1,683 @@ +This is bfd.info, produced by Makeinfo version 3.12f from bfd.texinfo. + +START-INFO-DIR-ENTRY +* Bfd: (bfd). The Binary File Descriptor library. +END-INFO-DIR-ENTRY + + This file documents the BFD library. + + Copyright (C) 1991 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, subject to the +terms of the GNU General Public License, which includes the provision +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: bfd.info, Node: coff, Next: elf, Prev: aout, Up: BFD back ends + +coff backends +============= + + BFD supports a number of different flavours of coff format. The +major differences between formats are the sizes and alignments of +fields in structures on disk, and the occasional extra field. + + Coff in all its varieties is implemented with a few common files and +a number of implementation specific files. For example, The 88k bcs +coff format is implemented in the file `coff-m88k.c'. This file +`#include's `coff/m88k.h' which defines the external structure of the +coff format for the 88k, and `coff/internal.h' which defines the +internal structure. `coff-m88k.c' also defines the relocations used by +the 88k format *Note Relocations::. + + The Intel i960 processor version of coff is implemented in +`coff-i960.c'. This file has the same structure as `coff-m88k.c', +except that it includes `coff/i960.h' rather than `coff-m88k.h'. + +Porting to a new version of coff +-------------------------------- + + The recommended method is to select from the existing +implementations the version of coff which is most like the one you want +to use. For example, we'll say that i386 coff is the one you select, +and that your coff flavour is called foo. Copy `i386coff.c' to +`foocoff.c', copy `../include/coff/i386.h' to `../include/coff/foo.h', +and add the lines to `targets.c' and `Makefile.in' so that your new +back end is used. Alter the shapes of the structures in +`../include/coff/foo.h' so that they match what you need. You will +probably also have to add `#ifdef's to the code in `coff/internal.h' and +`coffcode.h' if your version of coff is too wild. + + You can verify that your new BFD backend works quite simply by +building `objdump' from the `binutils' directory, and making sure that +its version of what's going on and your host system's idea (assuming it +has the pretty standard coff dump utility, usually called `att-dump' or +just `dump') are the same. Then clean up your code, and send what +you've done to Cygnus. Then your stuff will be in the next release, and +you won't have to keep integrating it. + +How the coff backend works +-------------------------- + +File layout +........... + + The Coff backend is split into generic routines that are applicable +to any Coff target and routines that are specific to a particular +target. The target-specific routines are further split into ones which +are basically the same for all Coff targets except that they use the +external symbol format or use different values for certain constants. + + The generic routines are in `coffgen.c'. These routines work for +any Coff target. They use some hooks into the target specific code; +the hooks are in a `bfd_coff_backend_data' structure, one of which +exists for each target. + + The essentially similar target-specific routines are in +`coffcode.h'. This header file includes executable C code. The +various Coff targets first include the appropriate Coff header file, +make any special defines that are needed, and then include `coffcode.h'. + + Some of the Coff targets then also have additional routines in the +target source file itself. + + For example, `coff-i960.c' includes `coff/internal.h' and +`coff/i960.h'. It then defines a few constants, such as `I960', and +includes `coffcode.h'. Since the i960 has complex relocation types, +`coff-i960.c' also includes some code to manipulate the i960 relocs. +This code is not in `coffcode.h' because it would not be used by any +other target. + +Bit twiddling +............. + + Each flavour of coff supported in BFD has its own header file +describing the external layout of the structures. There is also an +internal description of the coff layout, in `coff/internal.h'. A major +function of the coff backend is swapping the bytes and twiddling the +bits to translate the external form of the structures into the normal +internal form. This is all performed in the `bfd_swap'_thing_direction +routines. Some elements are different sizes between different versions +of coff; it is the duty of the coff version specific include file to +override the definitions of various packing routines in `coffcode.h'. +E.g., the size of line number entry in coff is sometimes 16 bits, and +sometimes 32 bits. `#define'ing `PUT_LNSZ_LNNO' and `GET_LNSZ_LNNO' +will select the correct one. No doubt, some day someone will find a +version of coff which has a varying field size not catered to at the +moment. To port BFD, that person will have to add more `#defines'. +Three of the bit twiddling routines are exported to `gdb'; +`coff_swap_aux_in', `coff_swap_sym_in' and `coff_swap_lineno_in'. `GDB' +reads the symbol table on its own, but uses BFD to fix things up. More +of the bit twiddlers are exported for `gas'; `coff_swap_aux_out', +`coff_swap_sym_out', `coff_swap_lineno_out', `coff_swap_reloc_out', +`coff_swap_filehdr_out', `coff_swap_aouthdr_out', +`coff_swap_scnhdr_out'. `Gas' currently keeps track of all the symbol +table and reloc drudgery itself, thereby saving the internal BFD +overhead, but uses BFD to swap things on the way out, making cross +ports much safer. Doing so also allows BFD (and thus the linker) to +use the same header files as `gas', which makes one avenue to disaster +disappear. + +Symbol reading +.............. + + The simple canonical form for symbols used by BFD is not rich enough +to keep all the information available in a coff symbol table. The back +end gets around this problem by keeping the original symbol table +around, "behind the scenes". + + When a symbol table is requested (through a call to +`bfd_canonicalize_symtab'), a request gets through to +`coff_get_normalized_symtab'. This reads the symbol table from the coff +file and swaps all the structures inside into the internal form. It +also fixes up all the pointers in the table (represented in the file by +offsets from the first symbol in the table) into physical pointers to +elements in the new internal table. This involves some work since the +meanings of fields change depending upon context: a field that is a +pointer to another structure in the symbol table at one moment may be +the size in bytes of a structure at the next. Another pass is made +over the table. All symbols which mark file names (`C_FILE' symbols) +are modified so that the internal string points to the value in the +auxent (the real filename) rather than the normal text associated with +the symbol (`".file"'). + + At this time the symbol names are moved around. Coff stores all +symbols less than nine characters long physically within the symbol +table; longer strings are kept at the end of the file in the string +table. This pass moves all strings into memory and replaces them with +pointers to the strings. + + The symbol table is massaged once again, this time to create the +canonical table used by the BFD application. Each symbol is inspected +in turn, and a decision made (using the `sclass' field) about the +various flags to set in the `asymbol'. *Note Symbols::. The generated +canonical table shares strings with the hidden internal symbol table. + + Any linenumbers are read from the coff file too, and attached to the +symbols which own the functions the linenumbers belong to. + +Symbol writing +.............. + + Writing a symbol to a coff file which didn't come from a coff file +will lose any debugging information. The `asymbol' structure remembers +the BFD from which the symbol was taken, and on output the back end +makes sure that the same destination target as source target is present. + + When the symbols have come from a coff file then all the debugging +information is preserved. + + Symbol tables are provided for writing to the back end in a vector +of pointers to pointers. This allows applications like the linker to +accumulate and output large symbol tables without having to do too much +byte copying. + + This function runs through the provided symbol table and patches +each symbol marked as a file place holder (`C_FILE') to point to the +next file place holder in the list. It also marks each `offset' field +in the list with the offset from the first symbol of the current symbol. + + Another function of this procedure is to turn the canonical value +form of BFD into the form used by coff. Internally, BFD expects symbol +values to be offsets from a section base; so a symbol physically at +0x120, but in a section starting at 0x100, would have the value 0x20. +Coff expects symbols to contain their final value, so symbols have +their values changed at this point to reflect their sum with their +owning section. This transformation uses the `output_section' field of +the `asymbol''s `asection' *Note Sections::. + + * `coff_mangle_symbols' + This routine runs though the provided symbol table and uses the +offsets generated by the previous pass and the pointers generated when +the symbol table was read in to create the structured hierachy required +by coff. It changes each pointer to a symbol into the index into the +symbol table of the asymbol. + + * `coff_write_symbols' + This routine runs through the symbol table and patches up the +symbols from their internal form into the coff way, calls the bit +twiddlers, and writes out the table to the file. + +`coff_symbol_type' +.................. + + *Description* +The hidden information for an `asymbol' is described in a +`combined_entry_type': + + + typedef struct coff_ptr_struct + { + + /* Remembers the offset from the first symbol in the file for + this symbol. Generated by coff_renumber_symbols. */ + unsigned int offset; + + /* Should the value of this symbol be renumbered. Used for + XCOFF C_BSTAT symbols. Set by coff_slurp_symbol_table. */ + unsigned int fix_value : 1; + + /* Should the tag field of this symbol be renumbered. + Created by coff_pointerize_aux. */ + unsigned int fix_tag : 1; + + /* Should the endidx field of this symbol be renumbered. + Created by coff_pointerize_aux. */ + unsigned int fix_end : 1; + + /* Should the x_csect.x_scnlen field be renumbered. + Created by coff_pointerize_aux. */ + unsigned int fix_scnlen : 1; + + /* Fix up an XCOFF C_BINCL/C_EINCL symbol. The value is the + index into the line number entries. Set by + coff_slurp_symbol_table. */ + unsigned int fix_line : 1; + + /* The container for the symbol structure as read and translated + from the file. */ + + union { + union internal_auxent auxent; + struct internal_syment syment; + } u; + } combined_entry_type; + + + /* Each canonical asymbol really looks like this: */ + + typedef struct coff_symbol_struct + { + /* The actual symbol which the rest of BFD works with */ + asymbol symbol; + + /* A pointer to the hidden information for this symbol */ + combined_entry_type *native; + + /* A pointer to the linenumber information for this symbol */ + struct lineno_cache_entry *lineno; + + /* Have the line numbers been relocated yet ? */ + boolean done_lineno; + } coff_symbol_type; + +`bfd_coff_backend_data' +....................... + + /* COFF symbol classifications. */ + + enum coff_symbol_classification + { + /* Global symbol. */ + COFF_SYMBOL_GLOBAL, + /* Common symbol. */ + COFF_SYMBOL_COMMON, + /* Undefined symbol. */ + COFF_SYMBOL_UNDEFINED, + /* Local symbol. */ + COFF_SYMBOL_LOCAL, + /* PE section symbol. */ + COFF_SYMBOL_PE_SECTION + }; + Special entry points for gdb to swap in coff symbol table parts: + typedef struct + { + void (*_bfd_coff_swap_aux_in) PARAMS (( + bfd *abfd, + PTR ext, + int type, + int class, + int indaux, + int numaux, + PTR in)); + + void (*_bfd_coff_swap_sym_in) PARAMS (( + bfd *abfd , + PTR ext, + PTR in)); + + void (*_bfd_coff_swap_lineno_in) PARAMS (( + bfd *abfd, + PTR ext, + PTR in)); + Special entry points for gas to swap out coff parts: + unsigned int (*_bfd_coff_swap_aux_out) PARAMS (( + bfd *abfd, + PTR in, + int type, + int class, + int indaux, + int numaux, + PTR ext)); + + unsigned int (*_bfd_coff_swap_sym_out) PARAMS (( + bfd *abfd, + PTR in, + PTR ext)); + + unsigned int (*_bfd_coff_swap_lineno_out) PARAMS (( + bfd *abfd, + PTR in, + PTR ext)); + + unsigned int (*_bfd_coff_swap_reloc_out) PARAMS (( + bfd *abfd, + PTR src, + PTR dst)); + + unsigned int (*_bfd_coff_swap_filehdr_out) PARAMS (( + bfd *abfd, + PTR in, + PTR out)); + + unsigned int (*_bfd_coff_swap_aouthdr_out) PARAMS (( + bfd *abfd, + PTR in, + PTR out)); + + unsigned int (*_bfd_coff_swap_scnhdr_out) PARAMS (( + bfd *abfd, + PTR in, + PTR out)); + Special entry points for generic COFF routines to call target +dependent COFF routines: + unsigned int _bfd_filhsz; + unsigned int _bfd_aoutsz; + unsigned int _bfd_scnhsz; + unsigned int _bfd_symesz; + unsigned int _bfd_auxesz; + unsigned int _bfd_relsz; + unsigned int _bfd_linesz; + unsigned int _bfd_filnmlen; + boolean _bfd_coff_long_filenames; + boolean _bfd_coff_long_section_names; + unsigned int _bfd_coff_default_section_alignment_power; + void (*_bfd_coff_swap_filehdr_in) PARAMS (( + bfd *abfd, + PTR ext, + PTR in)); + void (*_bfd_coff_swap_aouthdr_in) PARAMS (( + bfd *abfd, + PTR ext, + PTR in)); + void (*_bfd_coff_swap_scnhdr_in) PARAMS (( + bfd *abfd, + PTR ext, + PTR in)); + void (*_bfd_coff_swap_reloc_in) PARAMS (( + bfd *abfd, + PTR ext, + PTR in)); + boolean (*_bfd_coff_bad_format_hook) PARAMS (( + bfd *abfd, + PTR internal_filehdr)); + boolean (*_bfd_coff_set_arch_mach_hook) PARAMS (( + bfd *abfd, + PTR internal_filehdr)); + PTR (*_bfd_coff_mkobject_hook) PARAMS (( + bfd *abfd, + PTR internal_filehdr, + PTR internal_aouthdr)); + flagword (*_bfd_styp_to_sec_flags_hook) PARAMS (( + bfd *abfd, + PTR internal_scnhdr, + const char *name, + asection *section)); + void (*_bfd_set_alignment_hook) PARAMS (( + bfd *abfd, + asection *sec, + PTR internal_scnhdr)); + boolean (*_bfd_coff_slurp_symbol_table) PARAMS (( + bfd *abfd)); + boolean (*_bfd_coff_symname_in_debug) PARAMS (( + bfd *abfd, + struct internal_syment *sym)); + boolean (*_bfd_coff_pointerize_aux_hook) PARAMS (( + bfd *abfd, + combined_entry_type *table_base, + combined_entry_type *symbol, + unsigned int indaux, + combined_entry_type *aux)); + boolean (*_bfd_coff_print_aux) PARAMS (( + bfd *abfd, + FILE *file, + combined_entry_type *table_base, + combined_entry_type *symbol, + combined_entry_type *aux, + unsigned int indaux)); + void (*_bfd_coff_reloc16_extra_cases) PARAMS (( + bfd *abfd, + struct bfd_link_info *link_info, + struct bfd_link_order *link_order, + arelent *reloc, + bfd_byte *data, + unsigned int *src_ptr, + unsigned int *dst_ptr)); + int (*_bfd_coff_reloc16_estimate) PARAMS (( + bfd *abfd, + asection *input_section, + arelent *r, + unsigned int shrink, + struct bfd_link_info *link_info)); + enum coff_symbol_classification (*_bfd_coff_classify_symbol) PARAMS (( + bfd *abfd, + struct internal_syment *)); + boolean (*_bfd_coff_compute_section_file_positions) PARAMS (( + bfd *abfd)); + boolean (*_bfd_coff_start_final_link) PARAMS (( + bfd *output_bfd, + struct bfd_link_info *info)); + boolean (*_bfd_coff_relocate_section) PARAMS (( + bfd *output_bfd, + struct bfd_link_info *info, + bfd *input_bfd, + asection *input_section, + bfd_byte *contents, + struct internal_reloc *relocs, + struct internal_syment *syms, + asection **sections)); + reloc_howto_type *(*_bfd_coff_rtype_to_howto) PARAMS (( + bfd *abfd, + asection *sec, + struct internal_reloc *rel, + struct coff_link_hash_entry *h, + struct internal_syment *sym, + bfd_vma *addendp)); + boolean (*_bfd_coff_adjust_symndx) PARAMS (( + bfd *obfd, + struct bfd_link_info *info, + bfd *ibfd, + asection *sec, + struct internal_reloc *reloc, + boolean *adjustedp)); + boolean (*_bfd_coff_link_add_one_symbol) PARAMS (( + struct bfd_link_info *info, + bfd *abfd, + const char *name, + flagword flags, + asection *section, + bfd_vma value, + const char *string, + boolean copy, + boolean collect, + struct bfd_link_hash_entry **hashp)); + + boolean (*_bfd_coff_link_output_has_begun) PARAMS (( + bfd * abfd, + struct coff_final_link_info * pfinfo)); + boolean (*_bfd_coff_final_link_postscript) PARAMS (( + bfd * abfd, + struct coff_final_link_info * pfinfo)); + + } bfd_coff_backend_data; + + #define coff_backend_info(abfd) ((bfd_coff_backend_data *) (abfd)->xvec->backend_data) + + #define bfd_coff_swap_aux_in(a,e,t,c,ind,num,i) \ + ((coff_backend_info (a)->_bfd_coff_swap_aux_in) (a,e,t,c,ind,num,i)) + + #define bfd_coff_swap_sym_in(a,e,i) \ + ((coff_backend_info (a)->_bfd_coff_swap_sym_in) (a,e,i)) + + #define bfd_coff_swap_lineno_in(a,e,i) \ + ((coff_backend_info ( a)->_bfd_coff_swap_lineno_in) (a,e,i)) + + #define bfd_coff_swap_reloc_out(abfd, i, o) \ + ((coff_backend_info (abfd)->_bfd_coff_swap_reloc_out) (abfd, i, o)) + + #define bfd_coff_swap_lineno_out(abfd, i, o) \ + ((coff_backend_info (abfd)->_bfd_coff_swap_lineno_out) (abfd, i, o)) + + #define bfd_coff_swap_aux_out(a,i,t,c,ind,num,o) \ + ((coff_backend_info (a)->_bfd_coff_swap_aux_out) (a,i,t,c,ind,num,o)) + + #define bfd_coff_swap_sym_out(abfd, i,o) \ + ((coff_backend_info (abfd)->_bfd_coff_swap_sym_out) (abfd, i, o)) + + #define bfd_coff_swap_scnhdr_out(abfd, i,o) \ + ((coff_backend_info (abfd)->_bfd_coff_swap_scnhdr_out) (abfd, i, o)) + + #define bfd_coff_swap_filehdr_out(abfd, i,o) \ + ((coff_backend_info (abfd)->_bfd_coff_swap_filehdr_out) (abfd, i, o)) + + #define bfd_coff_swap_aouthdr_out(abfd, i,o) \ + ((coff_backend_info (abfd)->_bfd_coff_swap_aouthdr_out) (abfd, i, o)) + + #define bfd_coff_filhsz(abfd) (coff_backend_info (abfd)->_bfd_filhsz) + #define bfd_coff_aoutsz(abfd) (coff_backend_info (abfd)->_bfd_aoutsz) + #define bfd_coff_scnhsz(abfd) (coff_backend_info (abfd)->_bfd_scnhsz) + #define bfd_coff_symesz(abfd) (coff_backend_info (abfd)->_bfd_symesz) + #define bfd_coff_auxesz(abfd) (coff_backend_info (abfd)->_bfd_auxesz) + #define bfd_coff_relsz(abfd) (coff_backend_info (abfd)->_bfd_relsz) + #define bfd_coff_linesz(abfd) (coff_backend_info (abfd)->_bfd_linesz) + #define bfd_coff_filnmlen(abfd) (coff_backend_info (abfd)->_bfd_filnmlen) + #define bfd_coff_long_filenames(abfd) (coff_backend_info (abfd)->_bfd_coff_long_filenames) + #define bfd_coff_long_section_names(abfd) \ + (coff_backend_info (abfd)->_bfd_coff_long_section_names) + #define bfd_coff_default_section_alignment_power(abfd) \ + (coff_backend_info (abfd)->_bfd_coff_default_section_alignment_power) + #define bfd_coff_swap_filehdr_in(abfd, i,o) \ + ((coff_backend_info (abfd)->_bfd_coff_swap_filehdr_in) (abfd, i, o)) + + #define bfd_coff_swap_aouthdr_in(abfd, i,o) \ + ((coff_backend_info (abfd)->_bfd_coff_swap_aouthdr_in) (abfd, i, o)) + + #define bfd_coff_swap_scnhdr_in(abfd, i,o) \ + ((coff_backend_info (abfd)->_bfd_coff_swap_scnhdr_in) (abfd, i, o)) + + #define bfd_coff_swap_reloc_in(abfd, i, o) \ + ((coff_backend_info (abfd)->_bfd_coff_swap_reloc_in) (abfd, i, o)) + + #define bfd_coff_bad_format_hook(abfd, filehdr) \ + ((coff_backend_info (abfd)->_bfd_coff_bad_format_hook) (abfd, filehdr)) + + #define bfd_coff_set_arch_mach_hook(abfd, filehdr)\ + ((coff_backend_info (abfd)->_bfd_coff_set_arch_mach_hook) (abfd, filehdr)) + #define bfd_coff_mkobject_hook(abfd, filehdr, aouthdr)\ + ((coff_backend_info (abfd)->_bfd_coff_mkobject_hook) (abfd, filehdr, aouthdr)) + + #define bfd_coff_styp_to_sec_flags_hook(abfd, scnhdr, name, section)\ + ((coff_backend_info (abfd)->_bfd_styp_to_sec_flags_hook)\ + (abfd, scnhdr, name, section)) + + #define bfd_coff_set_alignment_hook(abfd, sec, scnhdr)\ + ((coff_backend_info (abfd)->_bfd_set_alignment_hook) (abfd, sec, scnhdr)) + + #define bfd_coff_slurp_symbol_table(abfd)\ + ((coff_backend_info (abfd)->_bfd_coff_slurp_symbol_table) (abfd)) + + #define bfd_coff_symname_in_debug(abfd, sym)\ + ((coff_backend_info (abfd)->_bfd_coff_symname_in_debug) (abfd, sym)) + + #define bfd_coff_print_aux(abfd, file, base, symbol, aux, indaux)\ + ((coff_backend_info (abfd)->_bfd_coff_print_aux)\ + (abfd, file, base, symbol, aux, indaux)) + + #define bfd_coff_reloc16_extra_cases(abfd, link_info, link_order, reloc, data, src_ptr, dst_ptr)\ + ((coff_backend_info (abfd)->_bfd_coff_reloc16_extra_cases)\ + (abfd, link_info, link_order, reloc, data, src_ptr, dst_ptr)) + + #define bfd_coff_reloc16_estimate(abfd, section, reloc, shrink, link_info)\ + ((coff_backend_info (abfd)->_bfd_coff_reloc16_estimate)\ + (abfd, section, reloc, shrink, link_info)) + + #define bfd_coff_classify_symbol(abfd, sym)\ + ((coff_backend_info (abfd)->_bfd_coff_classify_symbol)\ + (abfd, sym)) + + #define bfd_coff_compute_section_file_positions(abfd)\ + ((coff_backend_info (abfd)->_bfd_coff_compute_section_file_positions)\ + (abfd)) + + #define bfd_coff_start_final_link(obfd, info)\ + ((coff_backend_info (obfd)->_bfd_coff_start_final_link)\ + (obfd, info)) + #define bfd_coff_relocate_section(obfd,info,ibfd,o,con,rel,isyms,secs)\ + ((coff_backend_info (ibfd)->_bfd_coff_relocate_section)\ + (obfd, info, ibfd, o, con, rel, isyms, secs)) + #define bfd_coff_rtype_to_howto(abfd, sec, rel, h, sym, addendp)\ + ((coff_backend_info (abfd)->_bfd_coff_rtype_to_howto)\ + (abfd, sec, rel, h, sym, addendp)) + #define bfd_coff_adjust_symndx(obfd, info, ibfd, sec, rel, adjustedp)\ + ((coff_backend_info (abfd)->_bfd_coff_adjust_symndx)\ + (obfd, info, ibfd, sec, rel, adjustedp)) + #define bfd_coff_link_add_one_symbol(info,abfd,name,flags,section,value,string,cp,coll,hashp)\ + ((coff_backend_info (abfd)->_bfd_coff_link_add_one_symbol)\ + (info, abfd, name, flags, section, value, string, cp, coll, hashp)) + + #define bfd_coff_link_output_has_begun(a,p) \ + ((coff_backend_info (a)->_bfd_coff_link_output_has_begun) (a,p)) + #define bfd_coff_final_link_postscript(a,p) \ + ((coff_backend_info (a)->_bfd_coff_final_link_postscript) (a,p)) + +Writing relocations +................... + + To write relocations, the back end steps though the canonical +relocation table and create an `internal_reloc'. The symbol index to +use is removed from the `offset' field in the symbol table supplied. +The address comes directly from the sum of the section base address and +the relocation offset; the type is dug directly from the howto field. +Then the `internal_reloc' is swapped into the shape of an +`external_reloc' and written out to disk. + +Reading linenumbers +................... + + Creating the linenumber table is done by reading in the entire coff +linenumber table, and creating another table for internal use. + + A coff linenumber table is structured so that each function is +marked as having a line number of 0. Each line within the function is +an offset from the first line in the function. The base of the line +number information for the table is stored in the symbol associated +with the function. + + Note: The PE format uses line number 0 for a flag indicating a new +source file. + + The information is copied from the external to the internal table, +and each symbol which marks a function is marked by pointing its... + + How does this work ? + +Reading relocations +................... + + Coff relocations are easily transformed into the internal BFD form +(`arelent'). + + Reading a coff relocation table is done in the following stages: + + * Read the entire coff relocation table into memory. + + * Process each relocation in turn; first swap it from the external + to the internal form. + + * Turn the symbol referenced in the relocation's symbol index into a + pointer into the canonical symbol table. This table is the same + as the one returned by a call to `bfd_canonicalize_symtab'. The + back end will call that routine and save the result if a + canonicalization hasn't been done. + + * The reloc index is turned into a pointer to a howto structure, in + a back end specific way. For instance, the 386 and 960 use the + `r_type' to directly produce an index into a howto table vector; + the 88k subtracts a number from the `r_type' field and creates an + addend field. + + +File: bfd.info, Node: elf, Prev: coff, Up: BFD back ends + +ELF backends +============ + + BFD support for ELF formats is being worked on. Currently, the best +supported back ends are for sparc and i386 (running svr4 or Solaris 2). + + Documentation of the internals of the support code still needs to be +written. The code is changing quickly enough that we haven't bothered +yet. + +`bfd_elf_find_section' +...................... + + *Synopsis* + struct elf_internal_shdr *bfd_elf_find_section (bfd *abfd, char *name); + *Description* +Helper functions for GDB to locate the string tables. Since BFD hides +string tables from callers, GDB needs to use an internal hook to find +them. Sun's .stabstr, in particular, isn't even pointed to by the +.stab section, so ordinary mechanisms wouldn't work to find it, even if +we had some. + Index: bfd.info-7 =================================================================== --- bfd.info-7 (nonexistent) +++ bfd.info-7 (revision 1765) @@ -0,0 +1,500 @@ +This is bfd.info, produced by Makeinfo version 3.12f from bfd.texinfo. + +START-INFO-DIR-ENTRY +* Bfd: (bfd). The Binary File Descriptor library. +END-INFO-DIR-ENTRY + + This file documents the BFD library. + + Copyright (C) 1991 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, subject to the +terms of the GNU General Public License, which includes the provision +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: bfd.info, Node: Index, Prev: BFD back ends, Up: Top + +Index +***** + +* Menu: + +* BFD: Overview. +* BFD canonical format: Canonical format. +* BFD_CACHE_MAX_OPEN macro: File Caching. +* BFD_RELOC_12_PCREL: howto manager. +* BFD_RELOC_14: howto manager. +* BFD_RELOC_16: howto manager. +* BFD_RELOC_16_BASEREL: howto manager. +* BFD_RELOC_16_GOTOFF: howto manager. +* BFD_RELOC_16_GOT_PCREL: howto manager. +* BFD_RELOC_16_PCREL: howto manager. +* BFD_RELOC_16_PCREL_S2: howto manager. +* BFD_RELOC_16_PLTOFF: howto manager. +* BFD_RELOC_16_PLT_PCREL: howto manager. +* BFD_RELOC_23_PCREL_S2: howto manager. +* BFD_RELOC_24: howto manager. +* BFD_RELOC_24_PCREL: howto manager. +* BFD_RELOC_24_PLT_PCREL: howto manager. +* BFD_RELOC_26: howto manager. +* BFD_RELOC_32: howto manager. +* BFD_RELOC_32_BASEREL: howto manager. +* BFD_RELOC_32_GOTOFF: howto manager. +* BFD_RELOC_32_GOT_PCREL: howto manager. +* BFD_RELOC_32_PCREL: howto manager. +* BFD_RELOC_32_PCREL_S2: howto manager. +* BFD_RELOC_32_PLTOFF: howto manager. +* BFD_RELOC_32_PLT_PCREL: howto manager. +* BFD_RELOC_386_COPY: howto manager. +* BFD_RELOC_386_GLOB_DAT: howto manager. +* BFD_RELOC_386_GOT32: howto manager. +* BFD_RELOC_386_GOTOFF: howto manager. +* BFD_RELOC_386_GOTPC: howto manager. +* BFD_RELOC_386_JUMP_SLOT: howto manager. +* BFD_RELOC_386_PLT32: howto manager. +* BFD_RELOC_386_RELATIVE: howto manager. +* BFD_RELOC_64: howto manager. +* BFD_RELOC_64_PCREL: howto manager. +* BFD_RELOC_68K_GLOB_DAT: howto manager. +* BFD_RELOC_68K_JMP_SLOT: howto manager. +* BFD_RELOC_68K_RELATIVE: howto manager. +* BFD_RELOC_8: howto manager. +* BFD_RELOC_8_BASEREL: howto manager. +* BFD_RELOC_8_FFnn: howto manager. +* BFD_RELOC_8_GOTOFF: howto manager. +* BFD_RELOC_8_GOT_PCREL: howto manager. +* BFD_RELOC_8_PCREL: howto manager. +* BFD_RELOC_8_PLTOFF: howto manager. +* BFD_RELOC_8_PLT_PCREL: howto manager. +* BFD_RELOC_ALPHA_CODEADDR: howto manager. +* BFD_RELOC_ALPHA_ELF_LITERAL: howto manager. +* BFD_RELOC_ALPHA_GPDISP: howto manager. +* BFD_RELOC_ALPHA_GPDISP_HI16: howto manager. +* BFD_RELOC_ALPHA_GPDISP_LO16: howto manager. +* BFD_RELOC_ALPHA_HINT: howto manager. +* BFD_RELOC_ALPHA_LINKAGE: howto manager. +* BFD_RELOC_ALPHA_LITERAL: howto manager. +* BFD_RELOC_ALPHA_LITUSE: howto manager. +* BFD_RELOC_ALPHA_USER_GPDISP: howto manager. +* BFD_RELOC_ALPHA_USER_GPRELHIGH: howto manager. +* BFD_RELOC_ALPHA_USER_GPRELLOW: howto manager. +* BFD_RELOC_ALPHA_USER_LITERAL: howto manager. +* BFD_RELOC_ALPHA_USER_LITUSE_BASE: howto manager. +* BFD_RELOC_ALPHA_USER_LITUSE_BYTOFF: howto manager. +* BFD_RELOC_ALPHA_USER_LITUSE_JSR: howto manager. +* BFD_RELOC_ARC_B22_PCREL: howto manager. +* BFD_RELOC_ARC_B26: howto manager. +* BFD_RELOC_ARM_ADRL_IMMEDIATE: howto manager. +* BFD_RELOC_ARM_ADR_IMM: howto manager. +* BFD_RELOC_ARM_COPY: howto manager. +* BFD_RELOC_ARM_CP_OFF_IMM: howto manager. +* BFD_RELOC_ARM_GLOB_DAT: howto manager. +* BFD_RELOC_ARM_GOT12: howto manager. +* BFD_RELOC_ARM_GOT32: howto manager. +* BFD_RELOC_ARM_GOTOFF: howto manager. +* BFD_RELOC_ARM_GOTPC: howto manager. +* BFD_RELOC_ARM_HWLITERAL: howto manager. +* BFD_RELOC_ARM_IMMEDIATE: howto manager. +* BFD_RELOC_ARM_IN_POOL: howto manager. +* BFD_RELOC_ARM_JUMP_SLOT: howto manager. +* BFD_RELOC_ARM_LDR_IMM: howto manager. +* BFD_RELOC_ARM_LITERAL: howto manager. +* BFD_RELOC_ARM_MULTI: howto manager. +* BFD_RELOC_ARM_OFFSET_IMM: howto manager. +* BFD_RELOC_ARM_OFFSET_IMM8: howto manager. +* BFD_RELOC_ARM_PCREL_BLX: howto manager. +* BFD_RELOC_ARM_PCREL_BRANCH: howto manager. +* BFD_RELOC_ARM_PLT32: howto manager. +* BFD_RELOC_ARM_RELATIVE: howto manager. +* BFD_RELOC_ARM_SHIFT_IMM: howto manager. +* BFD_RELOC_ARM_SWI: howto manager. +* BFD_RELOC_ARM_THUMB_ADD: howto manager. +* BFD_RELOC_ARM_THUMB_IMM: howto manager. +* BFD_RELOC_ARM_THUMB_OFFSET: howto manager. +* BFD_RELOC_ARM_THUMB_SHIFT: howto manager. +* BFD_RELOC_AVR_13_PCREL: howto manager. +* BFD_RELOC_AVR_16_PM: howto manager. +* BFD_RELOC_AVR_7_PCREL: howto manager. +* BFD_RELOC_AVR_CALL: howto manager. +* BFD_RELOC_AVR_HH8_LDI: howto manager. +* BFD_RELOC_AVR_HH8_LDI_NEG: howto manager. +* BFD_RELOC_AVR_HH8_LDI_PM: howto manager. +* BFD_RELOC_AVR_HH8_LDI_PM_NEG: howto manager. +* BFD_RELOC_AVR_HI8_LDI: howto manager. +* BFD_RELOC_AVR_HI8_LDI_NEG: howto manager. +* BFD_RELOC_AVR_HI8_LDI_PM: howto manager. +* BFD_RELOC_AVR_HI8_LDI_PM_NEG: howto manager. +* BFD_RELOC_AVR_LO8_LDI: howto manager. +* BFD_RELOC_AVR_LO8_LDI_NEG: howto manager. +* BFD_RELOC_AVR_LO8_LDI_PM: howto manager. +* BFD_RELOC_AVR_LO8_LDI_PM_NEG: howto manager. +* BFD_RELOC_CTOR: howto manager. +* BFD_RELOC_D10V_10_PCREL_L: howto manager. +* BFD_RELOC_D10V_10_PCREL_R: howto manager. +* BFD_RELOC_D10V_18: howto manager. +* BFD_RELOC_D10V_18_PCREL: howto manager. +* BFD_RELOC_D30V_15: howto manager. +* BFD_RELOC_D30V_15_PCREL: howto manager. +* BFD_RELOC_D30V_15_PCREL_R: howto manager. +* BFD_RELOC_D30V_21: howto manager. +* BFD_RELOC_D30V_21_PCREL: howto manager. +* BFD_RELOC_D30V_21_PCREL_R: howto manager. +* BFD_RELOC_D30V_32: howto manager. +* BFD_RELOC_D30V_32_PCREL: howto manager. +* BFD_RELOC_D30V_6: howto manager. +* BFD_RELOC_D30V_9_PCREL: howto manager. +* BFD_RELOC_D30V_9_PCREL_R: howto manager. +* BFD_RELOC_FR30_10_IN_8: howto manager. +* BFD_RELOC_FR30_12_PCREL: howto manager. +* BFD_RELOC_FR30_20: howto manager. +* BFD_RELOC_FR30_48: howto manager. +* BFD_RELOC_FR30_6_IN_4: howto manager. +* BFD_RELOC_FR30_8_IN_8: howto manager. +* BFD_RELOC_FR30_9_IN_8: howto manager. +* BFD_RELOC_FR30_9_PCREL: howto manager. +* BFD_RELOC_GPREL16: howto manager. +* BFD_RELOC_GPREL32: howto manager. +* BFD_RELOC_HI16: howto manager. +* BFD_RELOC_HI16_BASEREL: howto manager. +* BFD_RELOC_HI16_GOTOFF: howto manager. +* BFD_RELOC_HI16_PLTOFF: howto manager. +* BFD_RELOC_HI16_S: howto manager. +* BFD_RELOC_HI16_S_BASEREL: howto manager. +* BFD_RELOC_HI16_S_GOTOFF: howto manager. +* BFD_RELOC_HI16_S_PLTOFF: howto manager. +* BFD_RELOC_HI22: howto manager. +* BFD_RELOC_I370_D12: howto manager. +* BFD_RELOC_I960_CALLJ: howto manager. +* BFD_RELOC_LO10: howto manager. +* BFD_RELOC_LO16: howto manager. +* BFD_RELOC_LO16_BASEREL: howto manager. +* BFD_RELOC_LO16_GOTOFF: howto manager. +* BFD_RELOC_LO16_PLTOFF: howto manager. +* BFD_RELOC_M32R_10_PCREL: howto manager. +* BFD_RELOC_M32R_18_PCREL: howto manager. +* BFD_RELOC_M32R_24: howto manager. +* BFD_RELOC_M32R_26_PCREL: howto manager. +* BFD_RELOC_M32R_HI16_SLO: howto manager. +* BFD_RELOC_M32R_HI16_ULO: howto manager. +* BFD_RELOC_M32R_LO16: howto manager. +* BFD_RELOC_M32R_SDA16: howto manager. +* BFD_RELOC_MCORE_PCREL_32: howto manager. +* BFD_RELOC_MCORE_PCREL_IMM11BY2: howto manager. +* BFD_RELOC_MCORE_PCREL_IMM4BY2: howto manager. +* BFD_RELOC_MCORE_PCREL_IMM8BY4: howto manager. +* BFD_RELOC_MCORE_PCREL_JSR_IMM11BY2: howto manager. +* BFD_RELOC_MCORE_RVA: howto manager. +* BFD_RELOC_MIPS16_GPREL: howto manager. +* BFD_RELOC_MIPS16_JMP: howto manager. +* BFD_RELOC_MIPS_CALL16: howto manager. +* BFD_RELOC_MIPS_CALL_HI16: howto manager. +* BFD_RELOC_MIPS_CALL_LO16: howto manager. +* BFD_RELOC_MIPS_GOT16: howto manager. +* BFD_RELOC_MIPS_GOT_DISP: howto manager. +* BFD_RELOC_MIPS_GOT_HI16: howto manager. +* BFD_RELOC_MIPS_GOT_LO16: howto manager. +* BFD_RELOC_MIPS_GOT_OFST: howto manager. +* BFD_RELOC_MIPS_GOT_PAGE: howto manager. +* BFD_RELOC_MIPS_GPREL: howto manager. +* BFD_RELOC_MIPS_GPREL32: howto manager. +* BFD_RELOC_MIPS_JMP: howto manager. +* BFD_RELOC_MIPS_LITERAL: howto manager. +* BFD_RELOC_MIPS_SUB: howto manager. +* BFD_RELOC_MN10300_16_PCREL: howto manager. +* BFD_RELOC_MN10300_32_PCREL: howto manager. +* BFD_RELOC_NONE: howto manager. +* BFD_RELOC_NS32K_DISP_16: howto manager. +* BFD_RELOC_NS32K_DISP_16_PCREL: howto manager. +* BFD_RELOC_NS32K_DISP_32: howto manager. +* BFD_RELOC_NS32K_DISP_32_PCREL: howto manager. +* BFD_RELOC_NS32K_DISP_8: howto manager. +* BFD_RELOC_NS32K_DISP_8_PCREL: howto manager. +* BFD_RELOC_NS32K_IMM_16: howto manager. +* BFD_RELOC_NS32K_IMM_16_PCREL: howto manager. +* BFD_RELOC_NS32K_IMM_32: howto manager. +* BFD_RELOC_NS32K_IMM_32_PCREL: howto manager. +* BFD_RELOC_NS32K_IMM_8: howto manager. +* BFD_RELOC_NS32K_IMM_8_PCREL: howto manager. +* BFD_RELOC_PCREL_HI16_S: howto manager. +* BFD_RELOC_PCREL_LO16: howto manager. +* BFD_RELOC_PJ_CODE_DIR16: howto manager. +* BFD_RELOC_PJ_CODE_DIR32: howto manager. +* BFD_RELOC_PJ_CODE_HI16: howto manager. +* BFD_RELOC_PJ_CODE_LO16: howto manager. +* BFD_RELOC_PJ_CODE_REL16: howto manager. +* BFD_RELOC_PJ_CODE_REL32: howto manager. +* BFD_RELOC_PPC_B16: howto manager. +* BFD_RELOC_PPC_B16_BRNTAKEN: howto manager. +* BFD_RELOC_PPC_B16_BRTAKEN: howto manager. +* BFD_RELOC_PPC_B26: howto manager. +* BFD_RELOC_PPC_BA16: howto manager. +* BFD_RELOC_PPC_BA16_BRNTAKEN: howto manager. +* BFD_RELOC_PPC_BA16_BRTAKEN: howto manager. +* BFD_RELOC_PPC_BA26: howto manager. +* BFD_RELOC_PPC_COPY: howto manager. +* BFD_RELOC_PPC_EMB_BIT_FLD: howto manager. +* BFD_RELOC_PPC_EMB_MRKREF: howto manager. +* BFD_RELOC_PPC_EMB_NADDR16: howto manager. +* BFD_RELOC_PPC_EMB_NADDR16_HA: howto manager. +* BFD_RELOC_PPC_EMB_NADDR16_HI: howto manager. +* BFD_RELOC_PPC_EMB_NADDR16_LO: howto manager. +* BFD_RELOC_PPC_EMB_NADDR32: howto manager. +* BFD_RELOC_PPC_EMB_RELSDA: howto manager. +* BFD_RELOC_PPC_EMB_RELSEC16: howto manager. +* BFD_RELOC_PPC_EMB_RELST_HA: howto manager. +* BFD_RELOC_PPC_EMB_RELST_HI: howto manager. +* BFD_RELOC_PPC_EMB_RELST_LO: howto manager. +* BFD_RELOC_PPC_EMB_SDA21: howto manager. +* BFD_RELOC_PPC_EMB_SDA2I16: howto manager. +* BFD_RELOC_PPC_EMB_SDA2REL: howto manager. +* BFD_RELOC_PPC_EMB_SDAI16: howto manager. +* BFD_RELOC_PPC_GLOB_DAT: howto manager. +* BFD_RELOC_PPC_JMP_SLOT: howto manager. +* BFD_RELOC_PPC_LOCAL24PC: howto manager. +* BFD_RELOC_PPC_RELATIVE: howto manager. +* BFD_RELOC_PPC_TOC16: howto manager. +* BFD_RELOC_RVA: howto manager. +* BFD_RELOC_SH_ALIGN: howto manager. +* BFD_RELOC_SH_CODE: howto manager. +* BFD_RELOC_SH_COUNT: howto manager. +* BFD_RELOC_SH_DATA: howto manager. +* BFD_RELOC_SH_IMM4: howto manager. +* BFD_RELOC_SH_IMM4BY2: howto manager. +* BFD_RELOC_SH_IMM4BY4: howto manager. +* BFD_RELOC_SH_IMM8: howto manager. +* BFD_RELOC_SH_IMM8BY2: howto manager. +* BFD_RELOC_SH_IMM8BY4: howto manager. +* BFD_RELOC_SH_LABEL: howto manager. +* BFD_RELOC_SH_LOOP_END: howto manager. +* BFD_RELOC_SH_LOOP_START: howto manager. +* BFD_RELOC_SH_PCDISP12BY2: howto manager. +* BFD_RELOC_SH_PCDISP8BY2: howto manager. +* BFD_RELOC_SH_PCRELIMM8BY2: howto manager. +* BFD_RELOC_SH_PCRELIMM8BY4: howto manager. +* BFD_RELOC_SH_SWITCH16: howto manager. +* BFD_RELOC_SH_SWITCH32: howto manager. +* BFD_RELOC_SH_USES: howto manager. +* BFD_RELOC_SPARC13: howto manager. +* BFD_RELOC_SPARC22: howto manager. +* BFD_RELOC_SPARC_10: howto manager. +* BFD_RELOC_SPARC_11: howto manager. +* BFD_RELOC_SPARC_5: howto manager. +* BFD_RELOC_SPARC_6: howto manager. +* BFD_RELOC_SPARC_64: howto manager. +* BFD_RELOC_SPARC_7: howto manager. +* BFD_RELOC_SPARC_BASE13: howto manager. +* BFD_RELOC_SPARC_BASE22: howto manager. +* BFD_RELOC_SPARC_COPY: howto manager. +* BFD_RELOC_SPARC_DISP64: howto manager. +* BFD_RELOC_SPARC_GLOB_DAT: howto manager. +* BFD_RELOC_SPARC_GOT10: howto manager. +* BFD_RELOC_SPARC_GOT13: howto manager. +* BFD_RELOC_SPARC_GOT22: howto manager. +* BFD_RELOC_SPARC_H44: howto manager. +* BFD_RELOC_SPARC_HH22: howto manager. +* BFD_RELOC_SPARC_HIX22: howto manager. +* BFD_RELOC_SPARC_HM10: howto manager. +* BFD_RELOC_SPARC_JMP_SLOT: howto manager. +* BFD_RELOC_SPARC_L44: howto manager. +* BFD_RELOC_SPARC_LM22: howto manager. +* BFD_RELOC_SPARC_LOX10: howto manager. +* BFD_RELOC_SPARC_M44: howto manager. +* BFD_RELOC_SPARC_OLO10: howto manager. +* BFD_RELOC_SPARC_PC10: howto manager. +* BFD_RELOC_SPARC_PC22: howto manager. +* BFD_RELOC_SPARC_PC_HH22: howto manager. +* BFD_RELOC_SPARC_PC_HM10: howto manager. +* BFD_RELOC_SPARC_PC_LM22: howto manager. +* BFD_RELOC_SPARC_PLT64: howto manager. +* BFD_RELOC_SPARC_REGISTER: howto manager. +* BFD_RELOC_SPARC_RELATIVE: howto manager. +* BFD_RELOC_SPARC_REV32: howto manager. +* BFD_RELOC_SPARC_UA32: howto manager. +* BFD_RELOC_SPARC_WDISP16: howto manager. +* BFD_RELOC_SPARC_WDISP19: howto manager. +* BFD_RELOC_SPARC_WDISP22: howto manager. +* BFD_RELOC_SPARC_WPLT30: howto manager. +* BFD_RELOC_THUMB_PCREL_BLX: howto manager. +* BFD_RELOC_THUMB_PCREL_BRANCH12: howto manager. +* BFD_RELOC_THUMB_PCREL_BRANCH23: howto manager. +* BFD_RELOC_THUMB_PCREL_BRANCH9: howto manager. +* BFD_RELOC_TIC30_LDP: howto manager. +* BFD_RELOC_TIC54X_16_OF_23: howto manager. +* BFD_RELOC_TIC54X_23: howto manager. +* BFD_RELOC_TIC54X_MS7_OF_23: howto manager. +* BFD_RELOC_TIC54X_PARTLS7: howto manager. +* BFD_RELOC_TIC54X_PARTMS9: howto manager. +* BFD_RELOC_V850_22_PCREL: howto manager. +* BFD_RELOC_V850_9_PCREL: howto manager. +* BFD_RELOC_V850_CALLT_16_16_OFFSET: howto manager. +* BFD_RELOC_V850_CALLT_6_7_OFFSET: howto manager. +* BFD_RELOC_V850_SDA_15_16_OFFSET: howto manager. +* BFD_RELOC_V850_SDA_16_16_OFFSET: howto manager. +* BFD_RELOC_V850_SDA_16_16_SPLIT_OFFSET: howto manager. +* BFD_RELOC_V850_TDA_16_16_OFFSET: howto manager. +* BFD_RELOC_V850_TDA_4_4_OFFSET: howto manager. +* BFD_RELOC_V850_TDA_4_5_OFFSET: howto manager. +* BFD_RELOC_V850_TDA_6_8_OFFSET: howto manager. +* BFD_RELOC_V850_TDA_7_7_OFFSET: howto manager. +* BFD_RELOC_V850_TDA_7_8_OFFSET: howto manager. +* BFD_RELOC_V850_ZDA_15_16_OFFSET: howto manager. +* BFD_RELOC_V850_ZDA_16_16_OFFSET: howto manager. +* BFD_RELOC_V850_ZDA_16_16_SPLIT_OFFSET: howto manager. +* BFD_RELOC_VTABLE_ENTRY: howto manager. +* BFD_RELOC_VTABLE_INHERIT: howto manager. +* Hash tables: Hash Tables. +* Linker: Linker Functions. +* The HOWTO Macro: typedef arelent. +* _bfd_final_link_relocate: Relocating the section contents. +* _bfd_generic_link_add_archive_symbols: Adding symbols from an archive. +* _bfd_generic_link_add_one_symbol: Adding symbols from an object file. +* _bfd_link_add_symbols in target vector: Adding Symbols to the Hash Table. +* _bfd_link_final_link in target vector: Performing the Final Link. +* _bfd_link_hash_table_create in target vector: Creating a Linker Hash Table. +* _bfd_relocate_contents: Relocating the section contents. +* _bfd_strip_section_from_output: section prototypes. +* aout_SIZE_machine_type: aout. +* aout_SIZE_mkobject: aout. +* aout_SIZE_new_section_hook: aout. +* aout_SIZE_set_arch_mach: aout. +* aout_SIZE_some_aout_object_p: aout. +* aout_SIZE_swap_exec_header_in: aout. +* aout_SIZE_swap_exec_header_out: aout. +* arelent_chain: typedef arelent. +* bfd_alloc: Opening and Closing. +* bfd_arch_bits_per_address: Architectures. +* bfd_arch_bits_per_byte: Architectures. +* bfd_arch_get_compatible: Architectures. +* bfd_arch_list: Architectures. +* bfd_arch_mach_octets_per_byte: Architectures. +* bfd_cache_close: File Caching. +* bfd_cache_init: File Caching. +* bfd_cache_lookup: File Caching. +* bfd_cache_lookup_worker: File Caching. +* bfd_canonicalize_reloc: BFD front end. +* bfd_canonicalize_symtab: symbol handling functions. +* bfd_check_format: Formats. +* bfd_check_format_matches: Formats. +* bfd_check_overflow: typedef arelent. +* bfd_close: Opening and Closing. +* bfd_close_all_done: Opening and Closing. +* bfd_coff_backend_data: coff. +* bfd_copy_private_bfd_data: BFD front end. +* bfd_copy_private_section_data: section prototypes. +* bfd_copy_private_symbol_data: symbol handling functions. +* bfd_core_file_failing_command: Core Files. +* bfd_core_file_failing_signal: Core Files. +* bfd_create: Opening and Closing. +* bfd_decode_symclass: symbol handling functions. +* bfd_default_arch_struct: Architectures. +* bfd_default_compatible: Architectures. +* bfd_default_reloc_type_lookup: howto manager. +* bfd_default_scan: Architectures. +* bfd_default_set_arch_mach: Architectures. +* bfd_elf_find_section: elf. +* bfd_errmsg: BFD front end. +* bfd_fdopenr: Opening and Closing. +* bfd_find_target: bfd_target. +* bfd_format_string: Formats. +* bfd_generic_gc_sections: howto manager. +* bfd_generic_get_relocated_section_contents: howto manager. +* bfd_generic_relax_section: howto manager. +* bfd_get_arch: Architectures. +* bfd_get_arch_info: Architectures. +* bfd_get_error: BFD front end. +* bfd_get_error_handler: BFD front end. +* bfd_get_gp_size: BFD front end. +* bfd_get_mach: Architectures. +* bfd_get_mtime: BFD front end. +* bfd_get_next_mapent: Archives. +* bfd_get_reloc_code_name: howto manager. +* bfd_get_reloc_size: typedef arelent. +* bfd_get_reloc_upper_bound: BFD front end. +* bfd_get_section_by_name: section prototypes. +* bfd_get_section_contents: section prototypes. +* bfd_get_size <1>: Internal. +* bfd_get_size: BFD front end. +* bfd_get_symtab_upper_bound: symbol handling functions. +* bfd_h_put_size: Internal. +* bfd_hash_allocate: Creating and Freeing a Hash Table. +* bfd_hash_lookup: Looking Up or Entering a String. +* bfd_hash_newfunc: Creating and Freeing a Hash Table. +* bfd_hash_table_free: Creating and Freeing a Hash Table. +* bfd_hash_table_init: Creating and Freeing a Hash Table. +* bfd_hash_table_init_n: Creating and Freeing a Hash Table. +* bfd_hash_traverse: Traversing a Hash Table. +* bfd_init: Initialization. +* bfd_install_relocation: typedef arelent. +* bfd_is_local_label: symbol handling functions. +* bfd_is_local_label_name: symbol handling functions. +* bfd_is_undefined_symclass: symbol handling functions. +* bfd_last_cache: File Caching. +* bfd_link_split_section: Writing the symbol table. +* bfd_log2: Internal. +* bfd_lookup_arch: Architectures. +* bfd_make_debug_symbol: symbol handling functions. +* bfd_make_empty_symbol: symbol handling functions. +* bfd_make_readable: Opening and Closing. +* bfd_make_section: section prototypes. +* bfd_make_section_anyway: section prototypes. +* bfd_make_section_old_way: section prototypes. +* bfd_make_writable: Opening and Closing. +* bfd_map_over_sections: section prototypes. +* bfd_merge_private_bfd_data: BFD front end. +* bfd_octets_per_byte: Architectures. +* bfd_open_file: File Caching. +* bfd_openr: Opening and Closing. +* bfd_openr_next_archived_file: Archives. +* bfd_openstreamr: Opening and Closing. +* bfd_openw: Opening and Closing. +* bfd_perform_relocation: typedef arelent. +* bfd_perror: BFD front end. +* bfd_print_symbol_vandf: symbol handling functions. +* bfd_printable_arch_mach: Architectures. +* bfd_printable_name: Architectures. +* bfd_put_size: Internal. +* bfd_reloc_code_type: howto manager. +* bfd_reloc_type_lookup: howto manager. +* bfd_scan_arch: Architectures. +* bfd_scan_vma: BFD front end. +* bfd_seach_for_target: bfd_target. +* bfd_set_arch_info: Architectures. +* bfd_set_archive_head: Archives. +* bfd_set_default_target: bfd_target. +* bfd_set_error: BFD front end. +* bfd_set_error_handler: BFD front end. +* bfd_set_error_program_name: BFD front end. +* bfd_set_file_flags: BFD front end. +* bfd_set_format: Formats. +* bfd_set_gp_size: BFD front end. +* bfd_set_private_flags: BFD front end. +* bfd_set_reloc: BFD front end. +* bfd_set_section_contents: section prototypes. +* bfd_set_section_flags: section prototypes. +* bfd_set_section_size: section prototypes. +* bfd_set_start_address: BFD front end. +* bfd_set_symtab: symbol handling functions. +* bfd_symbol_info: symbol handling functions. +* bfd_target_list: bfd_target. +* bfd_write_bigendian_4byte_int: Internal. +* coff_symbol_type: coff. +* core_file_matches_executable_p: Core Files. +* internal object-file format: Canonical format. +* stuff: BFD front end. +* target vector (_bfd_final_link): Performing the Final Link. +* target vector (_bfd_link_add_symbols): Adding Symbols to the Hash Table. +* target vector (_bfd_link_hash_table_create): Creating a Linker Hash Table. +* what is it?: Overview. + + Index: libbfd.texi =================================================================== --- libbfd.texi (nonexistent) +++ libbfd.texi (revision 1765) @@ -0,0 +1,156 @@ +@section Internal functions + + +@strong{Description}@* +These routines are used within BFD. +They are not intended for export, but are documented here for +completeness. + +@findex bfd_write_bigendian_4byte_int +@subsubsection @code{bfd_write_bigendian_4byte_int} +@strong{Synopsis} +@example +void bfd_write_bigendian_4byte_int(bfd *abfd, int i); +@end example +@strong{Description}@* +Write a 4 byte integer @var{i} to the output BFD @var{abfd}, in big +endian order regardless of what else is going on. This is useful in +archives. + +@findex bfd_put_size +@subsubsection @code{bfd_put_size} +@findex bfd_get_size +@subsubsection @code{bfd_get_size} +@strong{Description}@* +These macros as used for reading and writing raw data in +sections; each access (except for bytes) is vectored through +the target format of the BFD and mangled accordingly. The +mangling performs any necessary endian translations and +removes alignment restrictions. Note that types accepted and +returned by these macros are identical so they can be swapped +around in macros---for example, @file{libaout.h} defines @code{GET_WORD} +to either @code{bfd_get_32} or @code{bfd_get_64}. + +In the put routines, @var{val} must be a @code{bfd_vma}. If we are on a +system without prototypes, the caller is responsible for making +sure that is true, with a cast if necessary. We don't cast +them in the macro definitions because that would prevent @code{lint} +or @code{gcc -Wall} from detecting sins such as passing a pointer. +To detect calling these with less than a @code{bfd_vma}, use +@code{gcc -Wconversion} on a host with 64 bit @code{bfd_vma}'s. +@example + + /* Byte swapping macros for user section data. */ + +#define bfd_put_8(abfd, val, ptr) \ + ((void) (*((unsigned char *)(ptr)) = (unsigned char)(val))) +#define bfd_put_signed_8 \ + bfd_put_8 +#define bfd_get_8(abfd, ptr) \ + (*(unsigned char *)(ptr)) +#define bfd_get_signed_8(abfd, ptr) \ + ((*(unsigned char *)(ptr) ^ 0x80) - 0x80) + +#define bfd_put_16(abfd, val, ptr) \ + BFD_SEND(abfd, bfd_putx16, ((val),(ptr))) +#define bfd_put_signed_16 \ + bfd_put_16 +#define bfd_get_16(abfd, ptr) \ + BFD_SEND(abfd, bfd_getx16, (ptr)) +#define bfd_get_signed_16(abfd, ptr) \ + BFD_SEND (abfd, bfd_getx_signed_16, (ptr)) + +#define bfd_put_32(abfd, val, ptr) \ + BFD_SEND(abfd, bfd_putx32, ((val),(ptr))) +#define bfd_put_signed_32 \ + bfd_put_32 +#define bfd_get_32(abfd, ptr) \ + BFD_SEND(abfd, bfd_getx32, (ptr)) +#define bfd_get_signed_32(abfd, ptr) \ + BFD_SEND(abfd, bfd_getx_signed_32, (ptr)) + +#define bfd_put_64(abfd, val, ptr) \ + BFD_SEND(abfd, bfd_putx64, ((val), (ptr))) +#define bfd_put_signed_64 \ + bfd_put_64 +#define bfd_get_64(abfd, ptr) \ + BFD_SEND(abfd, bfd_getx64, (ptr)) +#define bfd_get_signed_64(abfd, ptr) \ + BFD_SEND(abfd, bfd_getx_signed_64, (ptr)) + +#define bfd_get(bits, abfd, ptr) \ + ((bits) == 8 ? bfd_get_8 (abfd, ptr) \ + : (bits) == 16 ? bfd_get_16 (abfd, ptr) \ + : (bits) == 32 ? bfd_get_32 (abfd, ptr) \ + : (bits) == 64 ? bfd_get_64 (abfd, ptr) \ + : (abort (), (bfd_vma) - 1)) + +#define bfd_put(bits, abfd, val, ptr) \ + ((bits) == 8 ? bfd_put_8 (abfd, val, ptr) \ + : (bits) == 16 ? bfd_put_16 (abfd, val, ptr) \ + : (bits) == 32 ? bfd_put_32 (abfd, val, ptr) \ + : (bits) == 64 ? bfd_put_64 (abfd, val, ptr) \ + : (abort (), (void) 0)) + +@end example + +@findex bfd_h_put_size +@subsubsection @code{bfd_h_put_size} +@strong{Description}@* +These macros have the same function as their @code{bfd_get_x} +bretheren, except that they are used for removing information +for the header records of object files. Believe it or not, +some object files keep their header records in big endian +order and their data in little endian order. +@example + + /* Byte swapping macros for file header data. */ + +#define bfd_h_put_8(abfd, val, ptr) \ + bfd_put_8 (abfd, val, ptr) +#define bfd_h_put_signed_8(abfd, val, ptr) \ + bfd_put_8 (abfd, val, ptr) +#define bfd_h_get_8(abfd, ptr) \ + bfd_get_8 (abfd, ptr) +#define bfd_h_get_signed_8(abfd, ptr) \ + bfd_get_signed_8 (abfd, ptr) + +#define bfd_h_put_16(abfd, val, ptr) \ + BFD_SEND(abfd, bfd_h_putx16,(val,ptr)) +#define bfd_h_put_signed_16 \ + bfd_h_put_16 +#define bfd_h_get_16(abfd, ptr) \ + BFD_SEND(abfd, bfd_h_getx16,(ptr)) +#define bfd_h_get_signed_16(abfd, ptr) \ + BFD_SEND(abfd, bfd_h_getx_signed_16, (ptr)) + +#define bfd_h_put_32(abfd, val, ptr) \ + BFD_SEND(abfd, bfd_h_putx32,(val,ptr)) +#define bfd_h_put_signed_32 \ + bfd_h_put_32 +#define bfd_h_get_32(abfd, ptr) \ + BFD_SEND(abfd, bfd_h_getx32,(ptr)) +#define bfd_h_get_signed_32(abfd, ptr) \ + BFD_SEND(abfd, bfd_h_getx_signed_32, (ptr)) + +#define bfd_h_put_64(abfd, val, ptr) \ + BFD_SEND(abfd, bfd_h_putx64,(val, ptr)) +#define bfd_h_put_signed_64 \ + bfd_h_put_64 +#define bfd_h_get_64(abfd, ptr) \ + BFD_SEND(abfd, bfd_h_getx64,(ptr)) +#define bfd_h_get_signed_64(abfd, ptr) \ + BFD_SEND(abfd, bfd_h_getx_signed_64, (ptr)) + +@end example + +@findex bfd_log2 +@subsubsection @code{bfd_log2} +@strong{Synopsis} +@example +unsigned int bfd_log2(bfd_vma x); +@end example +@strong{Description}@* +Return the log base 2 of the value supplied, rounded up. E.g., an +@var{x} of 1025 returns 11. + Index: hash.texi =================================================================== --- hash.texi (nonexistent) +++ hash.texi (revision 1765) @@ -0,0 +1,245 @@ +@section Hash Tables +@cindex Hash tables +BFD provides a simple set of hash table functions. Routines +are provided to initialize a hash table, to free a hash table, +to look up a string in a hash table and optionally create an +entry for it, and to traverse a hash table. There is +currently no routine to delete an string from a hash table. + +The basic hash table does not permit any data to be stored +with a string. However, a hash table is designed to present a +base class from which other types of hash tables may be +derived. These derived types may store additional information +with the string. Hash tables were implemented in this way, +rather than simply providing a data pointer in a hash table +entry, because they were designed for use by the linker back +ends. The linker may create thousands of hash table entries, +and the overhead of allocating private data and storing and +following pointers becomes noticeable. + +The basic hash table code is in @code{hash.c}. + +@menu +* Creating and Freeing a Hash Table:: +* Looking Up or Entering a String:: +* Traversing a Hash Table:: +* Deriving a New Hash Table Type:: +@end menu + +@node Creating and Freeing a Hash Table, Looking Up or Entering a String, Hash Tables, Hash Tables +@subsection Creating and freeing a hash table +@findex bfd_hash_table_init +@findex bfd_hash_table_init_n +To create a hash table, create an instance of a @code{struct +bfd_hash_table} (defined in @code{bfd.h}) and call +@code{bfd_hash_table_init} (if you know approximately how many +entries you will need, the function @code{bfd_hash_table_init_n}, +which takes a @var{size} argument, may be used). +@code{bfd_hash_table_init} returns @code{false} if some sort of +error occurs. + +@findex bfd_hash_newfunc +The function @code{bfd_hash_table_init} take as an argument a +function to use to create new entries. For a basic hash +table, use the function @code{bfd_hash_newfunc}. @xref{Deriving +a New Hash Table Type}, for why you would want to use a +different value for this argument. + +@findex bfd_hash_allocate +@code{bfd_hash_table_init} will create an objalloc which will be +used to allocate new entries. You may allocate memory on this +objalloc using @code{bfd_hash_allocate}. + +@findex bfd_hash_table_free +Use @code{bfd_hash_table_free} to free up all the memory that has +been allocated for a hash table. This will not free up the +@code{struct bfd_hash_table} itself, which you must provide. + +@node Looking Up or Entering a String, Traversing a Hash Table, Creating and Freeing a Hash Table, Hash Tables +@subsection Looking up or entering a string +@findex bfd_hash_lookup +The function @code{bfd_hash_lookup} is used both to look up a +string in the hash table and to create a new entry. + +If the @var{create} argument is @code{false}, @code{bfd_hash_lookup} +will look up a string. If the string is found, it will +returns a pointer to a @code{struct bfd_hash_entry}. If the +string is not found in the table @code{bfd_hash_lookup} will +return @code{NULL}. You should not modify any of the fields in +the returns @code{struct bfd_hash_entry}. + +If the @var{create} argument is @code{true}, the string will be +entered into the hash table if it is not already there. +Either way a pointer to a @code{struct bfd_hash_entry} will be +returned, either to the existing structure or to a newly +created one. In this case, a @code{NULL} return means that an +error occurred. + +If the @var{create} argument is @code{true}, and a new entry is +created, the @var{copy} argument is used to decide whether to +copy the string onto the hash table objalloc or not. If +@var{copy} is passed as @code{false}, you must be careful not to +deallocate or modify the string as long as the hash table +exists. + +@node Traversing a Hash Table, Deriving a New Hash Table Type, Looking Up or Entering a String, Hash Tables +@subsection Traversing a hash table +@findex bfd_hash_traverse +The function @code{bfd_hash_traverse} may be used to traverse a +hash table, calling a function on each element. The traversal +is done in a random order. + +@code{bfd_hash_traverse} takes as arguments a function and a +generic @code{void *} pointer. The function is called with a +hash table entry (a @code{struct bfd_hash_entry *}) and the +generic pointer passed to @code{bfd_hash_traverse}. The function +must return a @code{boolean} value, which indicates whether to +continue traversing the hash table. If the function returns +@code{false}, @code{bfd_hash_traverse} will stop the traversal and +return immediately. + +@node Deriving a New Hash Table Type, , Traversing a Hash Table, Hash Tables +@subsection Deriving a new hash table type +Many uses of hash tables want to store additional information +which each entry in the hash table. Some also find it +convenient to store additional information with the hash table +itself. This may be done using a derived hash table. + +Since C is not an object oriented language, creating a derived +hash table requires sticking together some boilerplate +routines with a few differences specific to the type of hash +table you want to create. + +An example of a derived hash table is the linker hash table. +The structures for this are defined in @code{bfdlink.h}. The +functions are in @code{linker.c}. + +You may also derive a hash table from an already derived hash +table. For example, the a.out linker backend code uses a hash +table derived from the linker hash table. + +@menu +* Define the Derived Structures:: +* Write the Derived Creation Routine:: +* Write Other Derived Routines:: +@end menu + +@node Define the Derived Structures, Write the Derived Creation Routine, Deriving a New Hash Table Type, Deriving a New Hash Table Type +@subsubsection Define the derived structures +You must define a structure for an entry in the hash table, +and a structure for the hash table itself. + +The first field in the structure for an entry in the hash +table must be of the type used for an entry in the hash table +you are deriving from. If you are deriving from a basic hash +table this is @code{struct bfd_hash_entry}, which is defined in +@code{bfd.h}. The first field in the structure for the hash +table itself must be of the type of the hash table you are +deriving from itself. If you are deriving from a basic hash +table, this is @code{struct bfd_hash_table}. + +For example, the linker hash table defines @code{struct +bfd_link_hash_entry} (in @code{bfdlink.h}). The first field, +@code{root}, is of type @code{struct bfd_hash_entry}. Similarly, +the first field in @code{struct bfd_link_hash_table}, @code{table}, +is of type @code{struct bfd_hash_table}. + +@node Write the Derived Creation Routine, Write Other Derived Routines, Define the Derived Structures, Deriving a New Hash Table Type +@subsubsection Write the derived creation routine +You must write a routine which will create and initialize an +entry in the hash table. This routine is passed as the +function argument to @code{bfd_hash_table_init}. + +In order to permit other hash tables to be derived from the +hash table you are creating, this routine must be written in a +standard way. + +The first argument to the creation routine is a pointer to a +hash table entry. This may be @code{NULL}, in which case the +routine should allocate the right amount of space. Otherwise +the space has already been allocated by a hash table type +derived from this one. + +After allocating space, the creation routine must call the +creation routine of the hash table type it is derived from, +passing in a pointer to the space it just allocated. This +will initialize any fields used by the base hash table. + +Finally the creation routine must initialize any local fields +for the new hash table type. + +Here is a boilerplate example of a creation routine. +@var{function_name} is the name of the routine. +@var{entry_type} is the type of an entry in the hash table you +are creating. @var{base_newfunc} is the name of the creation +routine of the hash table type your hash table is derived +from. + + +@example +struct bfd_hash_entry * +@var{function_name} (entry, table, string) + struct bfd_hash_entry *entry; + struct bfd_hash_table *table; + const char *string; +@{ + struct @var{entry_type} *ret = (@var{entry_type} *) entry; + + /* Allocate the structure if it has not already been allocated by a + derived class. */ + if (ret == (@var{entry_type} *) NULL) + @{ + ret = ((@var{entry_type} *) + bfd_hash_allocate (table, sizeof (@var{entry_type}))); + if (ret == (@var{entry_type} *) NULL) + return NULL; + @} + + /* Call the allocation method of the base class. */ + ret = ((@var{entry_type} *) + @var{base_newfunc} ((struct bfd_hash_entry *) ret, table, string)); + + /* Initialize the local fields here. */ + + return (struct bfd_hash_entry *) ret; +@} +@end example +@strong{Description}@* +The creation routine for the linker hash table, which is in +@code{linker.c}, looks just like this example. +@var{function_name} is @code{_bfd_link_hash_newfunc}. +@var{entry_type} is @code{struct bfd_link_hash_entry}. +@var{base_newfunc} is @code{bfd_hash_newfunc}, the creation +routine for a basic hash table. + +@code{_bfd_link_hash_newfunc} also initializes the local fields +in a linker hash table entry: @code{type}, @code{written} and +@code{next}. + +@node Write Other Derived Routines, , Write the Derived Creation Routine, Deriving a New Hash Table Type +@subsubsection Write other derived routines +You will want to write other routines for your new hash table, +as well. + +You will want an initialization routine which calls the +initialization routine of the hash table you are deriving from +and initializes any other local fields. For the linker hash +table, this is @code{_bfd_link_hash_table_init} in @code{linker.c}. + +You will want a lookup routine which calls the lookup routine +of the hash table you are deriving from and casts the result. +The linker hash table uses @code{bfd_link_hash_lookup} in +@code{linker.c} (this actually takes an additional argument which +it uses to decide how to return the looked up value). + +You may want a traversal routine. This should just call the +traversal routine of the hash table you are deriving from with +appropriate casts. The linker hash table uses +@code{bfd_link_hash_traverse} in @code{linker.c}. + +These routines may simply be defined as macros. For example, +the a.out backend linker hash table, which is derived from the +linker hash table, uses macros for the lookup and traversal +routines. These are @code{aout_link_hash_lookup} and +@code{aout_link_hash_traverse} in aoutx.h. + Index: linker.texi =================================================================== --- linker.texi (nonexistent) +++ linker.texi (revision 1765) @@ -0,0 +1,365 @@ +@section Linker Functions +@cindex Linker +The linker uses three special entry points in the BFD target +vector. It is not necessary to write special routines for +these entry points when creating a new BFD back end, since +generic versions are provided. However, writing them can +speed up linking and make it use significantly less runtime +memory. + +The first routine creates a hash table used by the other +routines. The second routine adds the symbols from an object +file to the hash table. The third routine takes all the +object files and links them together to create the output +file. These routines are designed so that the linker proper +does not need to know anything about the symbols in the object +files that it is linking. The linker merely arranges the +sections as directed by the linker script and lets BFD handle +the details of symbols and relocs. + +The second routine and third routines are passed a pointer to +a @code{struct bfd_link_info} structure (defined in +@code{bfdlink.h}) which holds information relevant to the link, +including the linker hash table (which was created by the +first routine) and a set of callback functions to the linker +proper. + +The generic linker routines are in @code{linker.c}, and use the +header file @code{genlink.h}. As of this writing, the only back +ends which have implemented versions of these routines are +a.out (in @code{aoutx.h}) and ECOFF (in @code{ecoff.c}). The a.out +routines are used as examples throughout this section. + +@menu +* Creating a Linker Hash Table:: +* Adding Symbols to the Hash Table:: +* Performing the Final Link:: +@end menu + +@node Creating a Linker Hash Table, Adding Symbols to the Hash Table, Linker Functions, Linker Functions +@subsection Creating a linker hash table +@cindex _bfd_link_hash_table_create in target vector +@cindex target vector (_bfd_link_hash_table_create) +The linker routines must create a hash table, which must be +derived from @code{struct bfd_link_hash_table} described in +@code{bfdlink.c}. @xref{Hash Tables}, for information on how to +create a derived hash table. This entry point is called using +the target vector of the linker output file. + +The @code{_bfd_link_hash_table_create} entry point must allocate +and initialize an instance of the desired hash table. If the +back end does not require any additional information to be +stored with the entries in the hash table, the entry point may +simply create a @code{struct bfd_link_hash_table}. Most likely, +however, some additional information will be needed. + +For example, with each entry in the hash table the a.out +linker keeps the index the symbol has in the final output file +(this index number is used so that when doing a relocateable +link the symbol index used in the output file can be quickly +filled in when copying over a reloc). The a.out linker code +defines the required structures and functions for a hash table +derived from @code{struct bfd_link_hash_table}. The a.out linker +hash table is created by the function +@code{NAME(aout,link_hash_table_create)}; it simply allocates +space for the hash table, initializes it, and returns a +pointer to it. + +When writing the linker routines for a new back end, you will +generally not know exactly which fields will be required until +you have finished. You should simply create a new hash table +which defines no additional fields, and then simply add fields +as they become necessary. + +@node Adding Symbols to the Hash Table, Performing the Final Link, Creating a Linker Hash Table, Linker Functions +@subsection Adding symbols to the hash table +@cindex _bfd_link_add_symbols in target vector +@cindex target vector (_bfd_link_add_symbols) +The linker proper will call the @code{_bfd_link_add_symbols} +entry point for each object file or archive which is to be +linked (typically these are the files named on the command +line, but some may also come from the linker script). The +entry point is responsible for examining the file. For an +object file, BFD must add any relevant symbol information to +the hash table. For an archive, BFD must determine which +elements of the archive should be used and adding them to the +link. + +The a.out version of this entry point is +@code{NAME(aout,link_add_symbols)}. + +@menu +* Differing file formats:: +* Adding symbols from an object file:: +* Adding symbols from an archive:: +@end menu + +@node Differing file formats, Adding symbols from an object file, Adding Symbols to the Hash Table, Adding Symbols to the Hash Table +@subsubsection Differing file formats +Normally all the files involved in a link will be of the same +format, but it is also possible to link together different +format object files, and the back end must support that. The +@code{_bfd_link_add_symbols} entry point is called via the target +vector of the file to be added. This has an important +consequence: the function may not assume that the hash table +is the type created by the corresponding +@code{_bfd_link_hash_table_create} vector. All the +@code{_bfd_link_add_symbols} function can assume about the hash +table is that it is derived from @code{struct +bfd_link_hash_table}. + +Sometimes the @code{_bfd_link_add_symbols} function must store +some information in the hash table entry to be used by the +@code{_bfd_final_link} function. In such a case the @code{creator} +field of the hash table must be checked to make sure that the +hash table was created by an object file of the same format. + +The @code{_bfd_final_link} routine must be prepared to handle a +hash entry without any extra information added by the +@code{_bfd_link_add_symbols} function. A hash entry without +extra information will also occur when the linker script +directs the linker to create a symbol. Note that, regardless +of how a hash table entry is added, all the fields will be +initialized to some sort of null value by the hash table entry +initialization function. + +See @code{ecoff_link_add_externals} for an example of how to +check the @code{creator} field before saving information (in this +case, the ECOFF external symbol debugging information) in a +hash table entry. + +@node Adding symbols from an object file, Adding symbols from an archive, Differing file formats, Adding Symbols to the Hash Table +@subsubsection Adding symbols from an object file +When the @code{_bfd_link_add_symbols} routine is passed an object +file, it must add all externally visible symbols in that +object file to the hash table. The actual work of adding the +symbol to the hash table is normally handled by the function +@code{_bfd_generic_link_add_one_symbol}. The +@code{_bfd_link_add_symbols} routine is responsible for reading +all the symbols from the object file and passing the correct +information to @code{_bfd_generic_link_add_one_symbol}. + +The @code{_bfd_link_add_symbols} routine should not use +@code{bfd_canonicalize_symtab} to read the symbols. The point of +providing this routine is to avoid the overhead of converting +the symbols into generic @code{asymbol} structures. + +@findex _bfd_generic_link_add_one_symbol +@code{_bfd_generic_link_add_one_symbol} handles the details of +combining common symbols, warning about multiple definitions, +and so forth. It takes arguments which describe the symbol to +add, notably symbol flags, a section, and an offset. The +symbol flags include such things as @code{BSF_WEAK} or +@code{BSF_INDIRECT}. The section is a section in the object +file, or something like @code{bfd_und_section_ptr} for an undefined +symbol or @code{bfd_com_section_ptr} for a common symbol. + +If the @code{_bfd_final_link} routine is also going to need to +read the symbol information, the @code{_bfd_link_add_symbols} +routine should save it somewhere attached to the object file +BFD. However, the information should only be saved if the +@code{keep_memory} field of the @code{info} argument is true, so +that the @code{-no-keep-memory} linker switch is effective. + +The a.out function which adds symbols from an object file is +@code{aout_link_add_object_symbols}, and most of the interesting +work is in @code{aout_link_add_symbols}. The latter saves +pointers to the hash tables entries created by +@code{_bfd_generic_link_add_one_symbol} indexed by symbol number, +so that the @code{_bfd_final_link} routine does not have to call +the hash table lookup routine to locate the entry. + +@node Adding symbols from an archive, , Adding symbols from an object file, Adding Symbols to the Hash Table +@subsubsection Adding symbols from an archive +When the @code{_bfd_link_add_symbols} routine is passed an +archive, it must look through the symbols defined by the +archive and decide which elements of the archive should be +included in the link. For each such element it must call the +@code{add_archive_element} linker callback, and it must add the +symbols from the object file to the linker hash table. + +@findex _bfd_generic_link_add_archive_symbols +In most cases the work of looking through the symbols in the +archive should be done by the +@code{_bfd_generic_link_add_archive_symbols} function. This +function builds a hash table from the archive symbol table and +looks through the list of undefined symbols to see which +elements should be included. +@code{_bfd_generic_link_add_archive_symbols} is passed a function +to call to make the final decision about adding an archive +element to the link and to do the actual work of adding the +symbols to the linker hash table. + +The function passed to +@code{_bfd_generic_link_add_archive_symbols} must read the +symbols of the archive element and decide whether the archive +element should be included in the link. If the element is to +be included, the @code{add_archive_element} linker callback +routine must be called with the element as an argument, and +the elements symbols must be added to the linker hash table +just as though the element had itself been passed to the +@code{_bfd_link_add_symbols} function. + +When the a.out @code{_bfd_link_add_symbols} function receives an +archive, it calls @code{_bfd_generic_link_add_archive_symbols} +passing @code{aout_link_check_archive_element} as the function +argument. @code{aout_link_check_archive_element} calls +@code{aout_link_check_ar_symbols}. If the latter decides to add +the element (an element is only added if it provides a real, +non-common, definition for a previously undefined or common +symbol) it calls the @code{add_archive_element} callback and then +@code{aout_link_check_archive_element} calls +@code{aout_link_add_symbols} to actually add the symbols to the +linker hash table. + +The ECOFF back end is unusual in that it does not normally +call @code{_bfd_generic_link_add_archive_symbols}, because ECOFF +archives already contain a hash table of symbols. The ECOFF +back end searches the archive itself to avoid the overhead of +creating a new hash table. + +@node Performing the Final Link, , Adding Symbols to the Hash Table, Linker Functions +@subsection Performing the final link +@cindex _bfd_link_final_link in target vector +@cindex target vector (_bfd_final_link) +When all the input files have been processed, the linker calls +the @code{_bfd_final_link} entry point of the output BFD. This +routine is responsible for producing the final output file, +which has several aspects. It must relocate the contents of +the input sections and copy the data into the output sections. +It must build an output symbol table including any local +symbols from the input files and the global symbols from the +hash table. When producing relocateable output, it must +modify the input relocs and write them into the output file. +There may also be object format dependent work to be done. + +The linker will also call the @code{write_object_contents} entry +point when the BFD is closed. The two entry points must work +together in order to produce the correct output file. + +The details of how this works are inevitably dependent upon +the specific object file format. The a.out +@code{_bfd_final_link} routine is @code{NAME(aout,final_link)}. + +@menu +* Information provided by the linker:: +* Relocating the section contents:: +* Writing the symbol table:: +@end menu + +@node Information provided by the linker, Relocating the section contents, Performing the Final Link, Performing the Final Link +@subsubsection Information provided by the linker +Before the linker calls the @code{_bfd_final_link} entry point, +it sets up some data structures for the function to use. + +The @code{input_bfds} field of the @code{bfd_link_info} structure +will point to a list of all the input files included in the +link. These files are linked through the @code{link_next} field +of the @code{bfd} structure. + +Each section in the output file will have a list of +@code{link_order} structures attached to the @code{link_order_head} +field (the @code{link_order} structure is defined in +@code{bfdlink.h}). These structures describe how to create the +contents of the output section in terms of the contents of +various input sections, fill constants, and, eventually, other +types of information. They also describe relocs that must be +created by the BFD backend, but do not correspond to any input +file; this is used to support -Ur, which builds constructors +while generating a relocateable object file. + +@node Relocating the section contents, Writing the symbol table, Information provided by the linker, Performing the Final Link +@subsubsection Relocating the section contents +The @code{_bfd_final_link} function should look through the +@code{link_order} structures attached to each section of the +output file. Each @code{link_order} structure should either be +handled specially, or it should be passed to the function +@code{_bfd_default_link_order} which will do the right thing +(@code{_bfd_default_link_order} is defined in @code{linker.c}). + +For efficiency, a @code{link_order} of type +@code{bfd_indirect_link_order} whose associated section belongs +to a BFD of the same format as the output BFD must be handled +specially. This type of @code{link_order} describes part of an +output section in terms of a section belonging to one of the +input files. The @code{_bfd_final_link} function should read the +contents of the section and any associated relocs, apply the +relocs to the section contents, and write out the modified +section contents. If performing a relocateable link, the +relocs themselves must also be modified and written out. + +@findex _bfd_relocate_contents +@findex _bfd_final_link_relocate +The functions @code{_bfd_relocate_contents} and +@code{_bfd_final_link_relocate} provide some general support for +performing the actual relocations, notably overflow checking. +Their arguments include information about the symbol the +relocation is against and a @code{reloc_howto_type} argument +which describes the relocation to perform. These functions +are defined in @code{reloc.c}. + +The a.out function which handles reading, relocating, and +writing section contents is @code{aout_link_input_section}. The +actual relocation is done in @code{aout_link_input_section_std} +and @code{aout_link_input_section_ext}. + +@node Writing the symbol table, , Relocating the section contents, Performing the Final Link +@subsubsection Writing the symbol table +The @code{_bfd_final_link} function must gather all the symbols +in the input files and write them out. It must also write out +all the symbols in the global hash table. This must be +controlled by the @code{strip} and @code{discard} fields of the +@code{bfd_link_info} structure. + +The local symbols of the input files will not have been +entered into the linker hash table. The @code{_bfd_final_link} +routine must consider each input file and include the symbols +in the output file. It may be convenient to do this when +looking through the @code{link_order} structures, or it may be +done by stepping through the @code{input_bfds} list. + +The @code{_bfd_final_link} routine must also traverse the global +hash table to gather all the externally visible symbols. It +is possible that most of the externally visible symbols may be +written out when considering the symbols of each input file, +but it is still necessary to traverse the hash table since the +linker script may have defined some symbols that are not in +any of the input files. + +The @code{strip} field of the @code{bfd_link_info} structure +controls which symbols are written out. The possible values +are listed in @code{bfdlink.h}. If the value is @code{strip_some}, +then the @code{keep_hash} field of the @code{bfd_link_info} +structure is a hash table of symbols to keep; each symbol +should be looked up in this hash table, and only symbols which +are present should be included in the output file. + +If the @code{strip} field of the @code{bfd_link_info} structure +permits local symbols to be written out, the @code{discard} field +is used to further controls which local symbols are included +in the output file. If the value is @code{discard_l}, then all +local symbols which begin with a certain prefix are discarded; +this is controlled by the @code{bfd_is_local_label_name} entry point. + +The a.out backend handles symbols by calling +@code{aout_link_write_symbols} on each input BFD and then +traversing the global hash table with the function +@code{aout_link_write_other_symbol}. It builds a string table +while writing out the symbols, which is written to the output +file at the end of @code{NAME(aout,final_link)}. + +@findex bfd_link_split_section +@subsubsection @code{bfd_link_split_section} +@strong{Synopsis} +@example +boolean bfd_link_split_section(bfd *abfd, asection *sec); +@end example +@strong{Description}@* +Return nonzero if @var{sec} should be split during a +reloceatable or final link. +@example +#define bfd_link_split_section(abfd, sec) \ + BFD_SEND (abfd, _bfd_link_split_section, (abfd, sec)) + +@end example + Index: format.texi =================================================================== --- format.texi (nonexistent) +++ format.texi (revision 1765) @@ -0,0 +1,108 @@ +@section File formats +A format is a BFD concept of high level file contents type. The +formats supported by BFD are: + +@itemize @bullet + +@item +@code{bfd_object} +@end itemize +The BFD may contain data, symbols, relocations and debug info. + +@itemize @bullet + +@item +@code{bfd_archive} +@end itemize +The BFD contains other BFDs and an optional index. + +@itemize @bullet + +@item +@code{bfd_core} +@end itemize +The BFD contains the result of an executable core dump. + +@findex bfd_check_format +@subsubsection @code{bfd_check_format} +@strong{Synopsis} +@example +boolean bfd_check_format(bfd *abfd, bfd_format format); +@end example +@strong{Description}@* +Verify if the file attached to the BFD @var{abfd} is compatible +with the format @var{format} (i.e., one of @code{bfd_object}, +@code{bfd_archive} or @code{bfd_core}). + +If the BFD has been set to a specific target before the +call, only the named target and format combination is +checked. If the target has not been set, or has been set to +@code{default}, then all the known target backends is +interrogated to determine a match. If the default target +matches, it is used. If not, exactly one target must recognize +the file, or an error results. + +The function returns @code{true} on success, otherwise @code{false} +with one of the following error codes: + +@itemize @bullet + +@item +@code{bfd_error_invalid_operation} - +if @code{format} is not one of @code{bfd_object}, @code{bfd_archive} or +@code{bfd_core}. + +@item +@code{bfd_error_system_call} - +if an error occured during a read - even some file mismatches +can cause bfd_error_system_calls. + +@item +@code{file_not_recognised} - +none of the backends recognised the file format. + +@item +@code{bfd_error_file_ambiguously_recognized} - +more than one backend recognised the file format. +@end itemize + +@findex bfd_check_format_matches +@subsubsection @code{bfd_check_format_matches} +@strong{Synopsis} +@example +boolean bfd_check_format_matches(bfd *abfd, bfd_format format, char ***matching); +@end example +@strong{Description}@* +Like @code{bfd_check_format}, except when it returns false with +@code{bfd_errno} set to @code{bfd_error_file_ambiguously_recognized}. In that +case, if @var{matching} is not NULL, it will be filled in with +a NULL-terminated list of the names of the formats that matched, +allocated with @code{malloc}. +Then the user may choose a format and try again. + +When done with the list that @var{matching} points to, the caller +should free it. + +@findex bfd_set_format +@subsubsection @code{bfd_set_format} +@strong{Synopsis} +@example +boolean bfd_set_format(bfd *abfd, bfd_format format); +@end example +@strong{Description}@* +This function sets the file format of the BFD @var{abfd} to the +format @var{format}. If the target set in the BFD does not +support the format requested, the format is invalid, or the BFD +is not open for writing, then an error occurs. + +@findex bfd_format_string +@subsubsection @code{bfd_format_string} +@strong{Synopsis} +@example +CONST char *bfd_format_string(bfd_format format); +@end example +@strong{Description}@* +Return a pointer to a const string +@code{invalid}, @code{object}, @code{archive}, @code{core}, or @code{unknown}, +depending upon the value of @var{format}. + Index: libbfd.log =================================================================== --- libbfd.log (nonexistent) +++ libbfd.log (revision 1765) @@ -0,0 +1,1007 @@ +This is pdfTeX, Version 3.14159-13d (Web2C 7.3.1) (format=pdftex 2000.7.19) 15 MAY 2001 10:39 +**/home/markom/gdb/gdb-5.0/bfd/doc/libbfd.texi +(/home/markom/gdb/gdb-5.0/bfd/doc/libbfd.texi[/usr/share/texmf/pdftex/config/pd +ftex.cfg] +Babel and hyphenation patterns for american, french, german, ngerman, i +talian, nohyphenation, loaded. +! Missing $ inserted. + + $ + + _ +l.9 @findex bfd_ + write_bigendian_4byte_int +? q +OK, entering \batchmode... +! Missing $ inserted. + + $ + + \par +l.19 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (197.20917pt too wide) in paragraph at lines 9--19 +[]\tenrm @findex bfd$[]\teni rite[]igendian[]byte[]nt\tenrm @\teni subsubsectio +n\tenrm @\teni code[]\tenrm @\teni strong[]\tenrm @\teni examplevoidbfd[]rite[] +igendian[]byte[]nt\tenrm (\teni bfd \tensy ^^C| + +\hbox(7.5+2.5)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm @ +.\tenrm ^^L (ligature fi) +.\tenrm n +.\tenrm d +.etc. + + +Overfull \hbox (312.49408pt too wide) in paragraph at lines 9--19 +\teni abfd; inti\tenrm ); @\teni endexample\tenrm @\teni strong[]\tenrm @ \tens +y ^^C \teni Writea\tenrm 4\teni byteinteger\tenrm @\teni varitotheoutputBFD\ten +rm @\teni var[]; inbigendianorderregardlessofwhatelseisgoingon:Thisisusefulinar +chives:$ | + +\hbox(7.5+2.5)x469.75499, glue set - 1.0 +.\teni a +.\teni b +.\teni f +.\kern1.0764 +.\teni d +.etc. + +! Missing $ inserted. + + $ + + _ +l.20 @findex bfd_ + put_size +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! Missing $ inserted. + + $ + + \par +l.33 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (103.77457pt too wide) in paragraph at lines 20--33 +[]\tenrm @findex bfd$[]\teni ut[]ize\tenrm @\teni subsubsection\tenrm @\teni co +de[]\tenrm @\teni findexbfd[]et[]ize\tenrm @\teni subsubsection\tenrm @\teni co +de[]\tenrm @\teni strong[]\tenrm @ \tensy ^^C| + +\hbox(6.94444+2.86108)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm @ +.\tenrm ^^L (ligature fi) +.\tenrm n +.\tenrm d +.etc. + + +Overfull \hbox (1097.82933pt too wide) in paragraph at lines 20--33 +\teni Thesemacrosasusedforreadingandwritingrawdatainsections\tenrm ; \teni each +access\tenrm (\teni exceptforbytes\tenrm )\teni isvectoredthroughthetargetforma +toftheBFDandmangledaccordingly:Themanglingperformsanynecessaryendiantranslation +sandremovesalignmentrestrictions:Notethattypesacceptedandreturnedbythesemacrosa +reidenticalsotheycanbeswappedaroundinmacros \tensy ^^@| + +\hbox(7.5+2.5)x469.75499, glue set - 1.0 +.\teni T +.\kern1.3889 +.\teni h +.\teni e +.\teni s +.etc. + +! Missing $ inserted. + + $ + + _ +l.34 ...t routines, @var{val} must be a @code{bfd_ + vma}. If we are on a +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! Extra }, or forgotten $. +l.34 ...utines, @var{val} must be a @code{bfd_vma} + . If we are on a +I've deleted a group-closing symbol because it seems to be +spurious, as in `$x}$'. But perhaps the } is legitimate and +you forgot something else, as in `\hbox{$x}'. In such cases +the way to recover is to insert both the forgotten and the +deleted material, e.g., by typing `I$}'. + +! Missing $ inserted. + + $ + + \par +l.42 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (1418.07126pt too wide) in paragraph at lines 34--42 +[]\tenrm In the put rou-tines, @var-val must be a @codebfd$[]\teni ma:Ifweareon +asystemwithoutprototypes; thecallerisresponsibleformakingsurethatistrue; withac +astifnecessary:Wedon[]tcasttheminthemacrodefinitionsbecausethatwouldprevent\ten +rm @\teni code[]or\tenrm @\teni code[]fromdetectingsinssuchaspassingapointer:To +detectcallingthesewithlessthana\tenrm @\teni code[]; use\tenrm @\teni code[]ona +hostwith\tenrm 64\teni bit\tenrm @\teni code[][]s:\tenrm @\teni example$ | + +\hbox(8.36115+1.94444)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm I +.\tenrm n +.\glue 3.33333 plus 1.66666 minus 1.11111 +.\tenrm t +.etc. + +! You can't use `macro parameter character #' in vertical mode. +l.45 # + define bfd_put_8(abfd, val, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + _ +l.45 #define bfd_ + put_8(abfd, val, ptr) \ +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! You can't use `macro parameter character #' in math mode. +l.47 # + define bfd_put_signed_8 \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! You can't use `macro parameter character #' in math mode. +l.49 # + define bfd_get_8(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! You can't use `macro parameter character #' in math mode. +l.51 # + define bfd_get_signed_8(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + \par +l.53 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (558.50003pt too wide) in paragraph at lines 45--53 +[]\tenrm define bfd$[]\teni ut[]\tenrm (\teni abfd; val; ptr\tenrm ) ((\teni vo +id\tenrm )(\tensy ^^C\tenrm ((\teni unsignedchar\tensy ^^C\tenrm )(\teni ptr\te +nrm )) = (\teni unsignedchar\tenrm )(\teni val\tenrm )))\teni definebfd[]ut[]ig +ned[] bfd[]ut[]definebfd[]et[]\tenrm (\teni abfd; ptr\tenrm ) (\tensy ^^C\tenrm + (\teni unsignedchar\tensy ^^C\tenrm )(\teni ptr\tenrm ))\teni definebfd[]et[]i +gned[]\tenrm (\teni abfd; ptr\tenrm ) ((\tensy ^^C\tenrm (\teni unsignedchar\te +nsy ^^C\tenrm )(\teni ptr\tenrm )[]\teni x\tenrm 80) \tensy ^^@| + +\hbox(8.14003+2.86108)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm d +.\tenrm e +.\tenrm ^^L (ligature fi) +.\tenrm n +.etc. + +! You can't use `macro parameter character #' in vertical mode. +l.54 # + define bfd_put_16(abfd, val, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + _ +l.54 #define bfd_ + put_16(abfd, val, ptr) \ +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! You can't use `macro parameter character #' in math mode. +l.56 # + define bfd_put_signed_16 \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! You can't use `macro parameter character #' in math mode. +l.58 # + define bfd_get_16(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! You can't use `macro parameter character #' in math mode. +l.60 # + define bfd_get_signed_16(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + \par +l.62 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (620.64355pt too wide) in paragraph at lines 54--62 +[]\tenrm define bfd$[]\teni ut[]\tenrm 6(\teni abfd; val; ptr\tenrm ) \teni BFD +[]END\tenrm (\teni abfd; bfd[]utx\tenrm 16\teni ; \tenrm ((\teni val\tenrm )\te +ni ; \tenrm (\teni ptr\tenrm )))\teni definebfd[]ut[]igned[]\tenrm 6 \teni bfd[ +]ut[]\tenrm 6\teni definebfd[]et[]\tenrm 6(\teni abfd; ptr\tenrm ) \teni BFD[]E +ND\tenrm (\teni abfd; bfd[]etx\tenrm 16\teni ; \tenrm (\teni ptr\tenrm ))\teni +definebfd[]et[]igned[]\tenrm 6(\teni abfd; ptr\tenrm ) \teni BFD[]END\tenrm (\t +eni abfd; bfd[]etx[]igned[]\tenrm 6\teni ; \tenrm (\teni ptr\tenrm ))$ | + +\hbox(7.5+2.86108)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm d +.\tenrm e +.\tenrm ^^L (ligature fi) +.\tenrm n +.etc. + +! You can't use `macro parameter character #' in vertical mode. +l.63 # + define bfd_put_32(abfd, val, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + _ +l.63 #define bfd_ + put_32(abfd, val, ptr) \ +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! You can't use `macro parameter character #' in math mode. +l.65 # + define bfd_put_signed_32 \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! You can't use `macro parameter character #' in math mode. +l.67 # + define bfd_get_32(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! You can't use `macro parameter character #' in math mode. +l.69 # + define bfd_get_signed_32(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + \par +l.71 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (620.64355pt too wide) in paragraph at lines 63--71 +[]\tenrm define bfd$[]\teni ut[]\tenrm 2(\teni abfd; val; ptr\tenrm ) \teni BFD +[]END\tenrm (\teni abfd; bfd[]utx\tenrm 32\teni ; \tenrm ((\teni val\tenrm )\te +ni ; \tenrm (\teni ptr\tenrm )))\teni definebfd[]ut[]igned[]\tenrm 2 \teni bfd[ +]ut[]\tenrm 2\teni definebfd[]et[]\tenrm 2(\teni abfd; ptr\tenrm ) \teni BFD[]E +ND\tenrm (\teni abfd; bfd[]etx\tenrm 32\teni ; \tenrm (\teni ptr\tenrm ))\teni +definebfd[]et[]igned[]\tenrm 2(\teni abfd; ptr\tenrm ) \teni BFD[]END\tenrm (\t +eni abfd; bfd[]etx[]igned[]\tenrm 2\teni ; \tenrm (\teni ptr\tenrm ))$ | + +\hbox(7.5+2.86108)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm d +.\tenrm e +.\tenrm ^^L (ligature fi) +.\tenrm n +.etc. + +! You can't use `macro parameter character #' in vertical mode. +l.72 # + define bfd_put_64(abfd, val, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + _ +l.72 #define bfd_ + put_64(abfd, val, ptr) \ +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! You can't use `macro parameter character #' in math mode. +l.74 # + define bfd_put_signed_64 \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! You can't use `macro parameter character #' in math mode. +l.76 # + define bfd_get_64(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! You can't use `macro parameter character #' in math mode. +l.78 # + define bfd_get_signed_64(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + \par +l.80 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (620.64355pt too wide) in paragraph at lines 72--80 +[]\tenrm define bfd$[]\teni ut[]\tenrm 4(\teni abfd; val; ptr\tenrm ) \teni BFD +[]END\tenrm (\teni abfd; bfd[]utx\tenrm 64\teni ; \tenrm ((\teni val\tenrm )\te +ni ; \tenrm (\teni ptr\tenrm )))\teni definebfd[]ut[]igned[]\tenrm 4 \teni bfd[ +]ut[]\tenrm 4\teni definebfd[]et[]\tenrm 4(\teni abfd; ptr\tenrm ) \teni BFD[]E +ND\tenrm (\teni abfd; bfd[]etx\tenrm 64\teni ; \tenrm (\teni ptr\tenrm ))\teni +definebfd[]et[]igned[]\tenrm 4(\teni abfd; ptr\tenrm ) \teni BFD[]END\tenrm (\t +eni abfd; bfd[]etx[]igned[]\tenrm 4\teni ; \tenrm (\teni ptr\tenrm ))$ | + +\hbox(7.5+2.86108)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm d +.\tenrm e +.\tenrm ^^L (ligature fi) +.\tenrm n +.etc. + +! You can't use `macro parameter character #' in vertical mode. +l.81 # + define bfd_get(bits, abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + _ +l.81 #define bfd_ + get(bits, abfd, ptr) \ +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! Missing $ inserted. + + $ + + \par +l.87 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! You can't use `macro parameter character #' in vertical mode. +l.88 # + define bfd_put(bits, abfd, val, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + _ +l.88 #define bfd_ + put(bits, abfd, val, ptr) \ +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! Missing $ inserted. + + $ + + \par +l.94 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (31.767pt too wide) in paragraph at lines 88--94 +[]\tenrm define bfd$[]\teni ut\tenrm (\teni bits; abfd; val; ptr\tenrm ) ((\ten +i bits\tenrm ) == 8?\teni bfd[]ut[]\tenrm (\teni abfd; val; ptr\tenrm ) : (\te +ni bits\tenrm ) == 16?\teni bfd[]ut[]\tenrm 6(\teni abfd; val; ptr\tenrm ) :| + +\hbox(7.5+2.86108)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm d +.\tenrm e +.\tenrm ^^L (ligature fi) +.\tenrm n +.etc. + +! Missing $ inserted. + + $ + + _ +l.97 @findex bfd_ + h_put_size +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! Double subscript. +l.97 @findex bfd_h_ + put_size +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.98 @subsubsection @code{bfd_h_ + put_size} +I treat `x_1_2' essentially like `x_1{}_2'. + +! Missing $ inserted. + + $ + + \par +l.106 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (1071.1196pt too wide) in paragraph at lines 97--106 +[]\tenrm @findex bfd$[][]\teni ut[]ize\tenrm @\teni subsubsection\tenrm @\teni +code[]\tenrm @\teni strong[]\tenrm @ \tensy ^^C \teni Thesemacroshavethesamefun +ctionastheir\tenrm @\teni code[]bretheren; exceptthattheyareusedforremovinginfo +rmationfortheheaderrecordsofobjectfiles:Believeitornot; someobjectfileskeepthei +rheaderrecordsinbigendianorderandtheirdatainlittleendianorder:\tenrm @\teni exa +mple$ | + +\hbox(6.94444+2.86108)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm @ +.\tenrm ^^L (ligature fi) +.\tenrm n +.\tenrm d +.etc. + +! You can't use `macro parameter character #' in vertical mode. +l.109 # + define bfd_h_put_8(abfd, val, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + _ +l.109 #define bfd_ + h_put_8(abfd, val, ptr) \ +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! Double subscript. +l.109 #define bfd_h_ + put_8(abfd, val, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! You can't use `macro parameter character #' in math mode. +l.111 # + define bfd_h_put_signed_8(abfd, val, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Double subscript. +l.111 #define bfd_h_ + put_signed_8(abfd, val, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! You can't use `macro parameter character #' in math mode. +l.113 # + define bfd_h_get_8(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Double subscript. +l.113 #define bfd_h_ + get_8(abfd, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! You can't use `macro parameter character #' in math mode. +l.115 # + define bfd_h_get_signed_8(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Double subscript. +l.115 #define bfd_h_ + get_signed_8(abfd, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Missing $ inserted. + + $ + + \par +l.117 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (493.1694pt too wide) in paragraph at lines 109--117 +[]\tenrm define bfd$[][]\teni ut[]\tenrm (\teni abfd; val; ptr\tenrm ) \teni bf +d[]ut[]\tenrm (\teni abfd; val; ptr\tenrm )\teni definebfd[][]ut[]igned[]\tenrm + (\teni abfd; val; ptr\tenrm ) \teni bfd[]ut[]\tenrm (\teni abfd; val; ptr\tenr +m )\teni definebfd[][]et[]\tenrm (\teni abfd; ptr\tenrm ) \teni bfd[]et[]\tenrm + (\teni abfd; ptr\tenrm )\teni definebfd[][]et[]igned[]\tenrm (\teni abfd; ptr\ +tenrm ) \teni bfd[]et[]igned[]\tenrm (\teni abfd; ptr\tenrm )$ | + +\hbox(7.5+2.86108)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm d +.\tenrm e +.\tenrm ^^L (ligature fi) +.\tenrm n +.etc. + +! You can't use `macro parameter character #' in vertical mode. +l.118 # + define bfd_h_put_16(abfd, val, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + _ +l.118 #define bfd_ + h_put_16(abfd, val, ptr) \ +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! Double subscript. +l.118 #define bfd_h_ + put_16(abfd, val, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.119 BFD_SEND(abfd, bfd_h_ + putx16,(val,ptr)) +I treat `x_1_2' essentially like `x_1{}_2'. + +! You can't use `macro parameter character #' in math mode. +l.120 # + define bfd_h_put_signed_16 \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Double subscript. +l.120 #define bfd_h_ + put_signed_16 \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.121 bfd_h_ + put_16 +I treat `x_1_2' essentially like `x_1{}_2'. + +! You can't use `macro parameter character #' in math mode. +l.122 # + define bfd_h_get_16(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Double subscript. +l.122 #define bfd_h_ + get_16(abfd, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.123 BFD_SEND(abfd, bfd_h_ + getx16,(ptr)) +I treat `x_1_2' essentially like `x_1{}_2'. + +! You can't use `macro parameter character #' in math mode. +l.124 # + define bfd_h_get_signed_16(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Double subscript. +l.124 #define bfd_h_ + get_signed_16(abfd, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.125 BFD_SEND(abfd, bfd_h_ + getx_signed_16, (ptr)) +I treat `x_1_2' essentially like `x_1{}_2'. + +! Missing $ inserted. + + $ + + \par +l.126 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (646.54193pt too wide) in paragraph at lines 118--126 +[]\tenrm define bfd$[][]\teni ut[]\tenrm 6(\teni abfd; val; ptr\tenrm ) \teni B +FD[]END\tenrm (\teni abfd; bfd[][]utx\tenrm 16\teni ; \tenrm (\teni val; ptr\te +nrm ))\teni definebfd[][]ut[]igned[]\tenrm 6 \teni bfd[][]ut[]\tenrm 6\teni def +inebfd[][]et[]\tenrm 6(\teni abfd; ptr\tenrm ) \teni BFD[]END\tenrm (\teni abfd +; bfd[][]etx\tenrm 16\teni ; \tenrm (\teni ptr\tenrm ))\teni definebfd[][]et[]i +gned[]\tenrm 6(\teni abfd; ptr\tenrm ) \teni BFD[]END\tenrm (\teni abfd; bfd[][ +]etx[]igned[]\tenrm 6\teni ; \tenrm (\teni ptr\tenrm ))$ | + +\hbox(7.5+2.86108)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm d +.\tenrm e +.\tenrm ^^L (ligature fi) +.\tenrm n +.etc. + +! You can't use `macro parameter character #' in vertical mode. +l.127 # + define bfd_h_put_32(abfd, val, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + _ +l.127 #define bfd_ + h_put_32(abfd, val, ptr) \ +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! Double subscript. +l.127 #define bfd_h_ + put_32(abfd, val, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.128 BFD_SEND(abfd, bfd_h_ + putx32,(val,ptr)) +I treat `x_1_2' essentially like `x_1{}_2'. + +! You can't use `macro parameter character #' in math mode. +l.129 # + define bfd_h_put_signed_32 \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Double subscript. +l.129 #define bfd_h_ + put_signed_32 \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.130 bfd_h_ + put_32 +I treat `x_1_2' essentially like `x_1{}_2'. + +! You can't use `macro parameter character #' in math mode. +l.131 # + define bfd_h_get_32(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Double subscript. +l.131 #define bfd_h_ + get_32(abfd, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.132 BFD_SEND(abfd, bfd_h_ + getx32,(ptr)) +I treat `x_1_2' essentially like `x_1{}_2'. + +! You can't use `macro parameter character #' in math mode. +l.133 # + define bfd_h_get_signed_32(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Double subscript. +l.133 #define bfd_h_ + get_signed_32(abfd, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.134 BFD_SEND(abfd, bfd_h_ + getx_signed_32, (ptr)) +I treat `x_1_2' essentially like `x_1{}_2'. + +! Missing $ inserted. + + $ + + \par +l.135 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (646.54193pt too wide) in paragraph at lines 127--135 +[]\tenrm define bfd$[][]\teni ut[]\tenrm 2(\teni abfd; val; ptr\tenrm ) \teni B +FD[]END\tenrm (\teni abfd; bfd[][]utx\tenrm 32\teni ; \tenrm (\teni val; ptr\te +nrm ))\teni definebfd[][]ut[]igned[]\tenrm 2 \teni bfd[][]ut[]\tenrm 2\teni def +inebfd[][]et[]\tenrm 2(\teni abfd; ptr\tenrm ) \teni BFD[]END\tenrm (\teni abfd +; bfd[][]etx\tenrm 32\teni ; \tenrm (\teni ptr\tenrm ))\teni definebfd[][]et[]i +gned[]\tenrm 2(\teni abfd; ptr\tenrm ) \teni BFD[]END\tenrm (\teni abfd; bfd[][ +]etx[]igned[]\tenrm 2\teni ; \tenrm (\teni ptr\tenrm ))$ | + +\hbox(7.5+2.86108)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm d +.\tenrm e +.\tenrm ^^L (ligature fi) +.\tenrm n +.etc. + +! You can't use `macro parameter character #' in vertical mode. +l.136 # + define bfd_h_put_64(abfd, val, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Missing $ inserted. + + $ + + _ +l.136 #define bfd_ + h_put_64(abfd, val, ptr) \ +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! Double subscript. +l.136 #define bfd_h_ + put_64(abfd, val, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.137 BFD_SEND(abfd, bfd_h_ + putx64,(val, ptr)) +I treat `x_1_2' essentially like `x_1{}_2'. + +! You can't use `macro parameter character #' in math mode. +l.138 # + define bfd_h_put_signed_64 \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Double subscript. +l.138 #define bfd_h_ + put_signed_64 \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.139 bfd_h_ + put_64 +I treat `x_1_2' essentially like `x_1{}_2'. + +! You can't use `macro parameter character #' in math mode. +l.140 # + define bfd_h_get_64(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Double subscript. +l.140 #define bfd_h_ + get_64(abfd, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.141 BFD_SEND(abfd, bfd_h_ + getx64,(ptr)) +I treat `x_1_2' essentially like `x_1{}_2'. + +! You can't use `macro parameter character #' in math mode. +l.142 # + define bfd_h_get_signed_64(abfd, ptr) \ +Sorry, but I'm not programmed to handle this case; +I'll just pretend that you didn't ask for it. +If you're in the wrong mode, you might be able to +return to the right one by typing `I}' or `I$' or `I\par'. + +! Double subscript. +l.142 #define bfd_h_ + get_signed_64(abfd, ptr) \ +I treat `x_1_2' essentially like `x_1{}_2'. + +! Double subscript. +l.143 BFD_SEND(abfd, bfd_h_ + getx_signed_64, (ptr)) +I treat `x_1_2' essentially like `x_1{}_2'. + +! Missing $ inserted. + + $ + + \par +l.144 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (646.54193pt too wide) in paragraph at lines 136--144 +[]\tenrm define bfd$[][]\teni ut[]\tenrm 4(\teni abfd; val; ptr\tenrm ) \teni B +FD[]END\tenrm (\teni abfd; bfd[][]utx\tenrm 64\teni ; \tenrm (\teni val; ptr\te +nrm ))\teni definebfd[][]ut[]igned[]\tenrm 4 \teni bfd[][]ut[]\tenrm 4\teni def +inebfd[][]et[]\tenrm 4(\teni abfd; ptr\tenrm ) \teni BFD[]END\tenrm (\teni abfd +; bfd[][]etx\tenrm 64\teni ; \tenrm (\teni ptr\tenrm ))\teni definebfd[][]et[]i +gned[]\tenrm 4(\teni abfd; ptr\tenrm ) \teni BFD[]END\tenrm (\teni abfd; bfd[][ +]etx[]igned[]\tenrm 4\teni ; \tenrm (\teni ptr\tenrm ))$ | + +\hbox(7.5+2.86108)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm d +.\tenrm e +.\tenrm ^^L (ligature fi) +.\tenrm n +.etc. + +! Missing $ inserted. + + $ + + _ +l.147 @findex bfd_ + log2 +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + +! Missing $ inserted. + + $ + + \par +l.156 + +I've inserted a begin-math/end-math symbol since I think +you left one out. Proceed, with fingers crossed. + + +Overfull \hbox (174.15004pt too wide) in paragraph at lines 147--156 +[]\tenrm @findex bfd$[]\teni og\tenrm 2@\teni subsubsection\tenrm @\teni code[] +\tenrm @\teni strong[]\tenrm @\teni exampleunsignedintbfd[]og\tenrm 2(\teni bfd +[]max\tenrm ); @\teni endexample\tenrm @\teni strong[]\tenrm @ \tensy ^^C| + +\hbox(7.5+2.5)x469.75499, glue set - 1.0 +.\hbox(0.0+0.0)x20.0 +.\tenrm @ +.\tenrm ^^L (ligature fi) +.\tenrm n +.\tenrm d +.etc. + +) +! Emergency stop. +<*> /home/markom/gdb/gdb-5.0/bfd/doc/libbfd.texi + +*** (job aborted, no legal \end found) + +! ==> Fatal error occurred, the output PDF file not finished! Index: syms.texi =================================================================== --- syms.texi (nonexistent) +++ syms.texi (revision 1765) @@ -0,0 +1,424 @@ +@section Symbols +BFD tries to maintain as much symbol information as it can when +it moves information from file to file. BFD passes information +to applications though the @code{asymbol} structure. When the +application requests the symbol table, BFD reads the table in +the native form and translates parts of it into the internal +format. To maintain more than the information passed to +applications, some targets keep some information ``behind the +scenes'' in a structure only the particular back end knows +about. For example, the coff back end keeps the original +symbol table structure as well as the canonical structure when +a BFD is read in. On output, the coff back end can reconstruct +the output symbol table so that no information is lost, even +information unique to coff which BFD doesn't know or +understand. If a coff symbol table were read, but were written +through an a.out back end, all the coff specific information +would be lost. The symbol table of a BFD +is not necessarily read in until a canonicalize request is +made. Then the BFD back end fills in a table provided by the +application with pointers to the canonical information. To +output symbols, the application provides BFD with a table of +pointers to pointers to @code{asymbol}s. This allows applications +like the linker to output a symbol as it was read, since the ``behind +the scenes'' information will be still available. +@menu +* Reading Symbols:: +* Writing Symbols:: +* Mini Symbols:: +* typedef asymbol:: +* symbol handling functions:: +@end menu + +@node Reading Symbols, Writing Symbols, Symbols, Symbols +@subsection Reading symbols +There are two stages to reading a symbol table from a BFD: +allocating storage, and the actual reading process. This is an +excerpt from an application which reads the symbol table: + +@example + long storage_needed; + asymbol **symbol_table; + long number_of_symbols; + long i; + + storage_needed = bfd_get_symtab_upper_bound (abfd); + + if (storage_needed < 0) + FAIL + + if (storage_needed == 0) @{ + return ; + @} + symbol_table = (asymbol **) xmalloc (storage_needed); + ... + number_of_symbols = + bfd_canonicalize_symtab (abfd, symbol_table); + + if (number_of_symbols < 0) + FAIL + + for (i = 0; i < number_of_symbols; i++) @{ + process_symbol (symbol_table[i]); + @} +@end example + +All storage for the symbols themselves is in an objalloc +connected to the BFD; it is freed when the BFD is closed. + +@node Writing Symbols, Mini Symbols, Reading Symbols, Symbols +@subsection Writing symbols +Writing of a symbol table is automatic when a BFD open for +writing 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 BFD output code must always be provided with an +``owned'' symbol: one which has come from another BFD, or one +which has been created using @code{bfd_make_empty_symbol}. Here is an +example showing the creation of a symbol table with only one element: + +@example + #include "bfd.h" + main() + @{ + bfd *abfd; + asymbol *ptrs[2]; + asymbol *new; + + abfd = bfd_openw("foo","a.out-sunos-big"); + bfd_set_format(abfd, bfd_object); + new = bfd_make_empty_symbol(abfd); + new->name = "dummy_symbol"; + new->section = bfd_make_section_old_way(abfd, ".text"); + new->flags = BSF_GLOBAL; + new->value = 0x12345; + + ptrs[0] = new; + ptrs[1] = (asymbol *)0; + + bfd_set_symtab(abfd, ptrs, 1); + bfd_close(abfd); + @} + + ./makesym + nm foo + 00012345 A dummy_symbol +@end example + +Many formats cannot represent arbitary symbol information; for +instance, the @code{a.out} object format does not allow an +arbitary number of sections. A symbol pointing to a section +which is not one of @code{.text}, @code{.data} or @code{.bss} cannot +be described. + +@node Mini Symbols, typedef asymbol, Writing Symbols, Symbols +@subsection Mini Symbols +Mini symbols provide read-only access to the symbol table. +They use less memory space, but require more time to access. +They can be useful for tools like nm or objdump, which may +have to handle symbol tables of extremely large executables. + +The @code{bfd_read_minisymbols} function will read the symbols +into memory in an internal form. It will return a @code{void *} +pointer to a block of memory, a symbol count, and the size of +each symbol. The pointer is allocated using @code{malloc}, and +should be freed by the caller when it is no longer needed. + +The function @code{bfd_minisymbol_to_symbol} will take a pointer +to a minisymbol, and a pointer to a structure returned by +@code{bfd_make_empty_symbol}, and return a @code{asymbol} structure. +The return value may or may not be the same as the value from +@code{bfd_make_empty_symbol} which was passed in. + + +@node typedef asymbol, symbol handling functions, Mini Symbols, Symbols +@subsection typedef asymbol +An @code{asymbol} has the form: + + +@example + +typedef struct symbol_cache_entry +@{ + /* A pointer to the BFD which owns the symbol. This information + is necessary so that a back end can work out what additional + information (invisible to the application writer) is carried + with the symbol. + + This field is *almost* redundant, since you can use section->owner + instead, except that some symbols point to the global sections + bfd_@{abs,com,und@}_section. This could be fixed by making + these globals be per-bfd (or per-target-flavor). FIXME. */ + + struct _bfd *the_bfd; /* Use bfd_asymbol_bfd(sym) to access this field. */ + + /* The text of the symbol. The name is left alone, and not copied; the + application may not alter it. */ + CONST char *name; + + /* The value of the symbol. This really should be a union of a + numeric value with a pointer, since some flags indicate that + a pointer to another symbol is stored here. */ + symvalue value; + + /* Attributes of a symbol: */ + +#define BSF_NO_FLAGS 0x00 + + /* The symbol has local scope; @code{static} in @code{C}. The value + is the offset into the section of the data. */ +#define BSF_LOCAL 0x01 + + /* The symbol has global scope; initialized data in @code{C}. The + value is the offset into the section of the data. */ +#define BSF_GLOBAL 0x02 + + /* The symbol has global scope and is exported. The value is + the offset into the section of the data. */ +#define BSF_EXPORT BSF_GLOBAL /* no real difference */ + + /* A normal C symbol would be one of: + @code{BSF_LOCAL}, @code{BSF_FORT_COMM}, @code{BSF_UNDEFINED} or + @code{BSF_GLOBAL} */ + + /* The symbol is a debugging record. The value has an arbitary + meaning, unless BSF_DEBUGGING_RELOC is also set. */ +#define BSF_DEBUGGING 0x08 + + /* The symbol denotes a function entry point. Used in ELF, + perhaps others someday. */ +#define BSF_FUNCTION 0x10 + + /* Used by the linker. */ +#define BSF_KEEP 0x20 +#define BSF_KEEP_G 0x40 + + /* A weak global symbol, overridable without warnings by + a regular global symbol of the same name. */ +#define BSF_WEAK 0x80 + + /* This symbol was created to point to a section, e.g. ELF's + STT_SECTION symbols. */ +#define BSF_SECTION_SYM 0x100 + + /* The symbol used to be a common symbol, but now it is + allocated. */ +#define BSF_OLD_COMMON 0x200 + + /* The default value for common data. */ +#define BFD_FORT_COMM_DEFAULT_VALUE 0 + + /* In some files the type of a symbol sometimes alters its + location in an output file - ie in coff a @code{ISFCN} symbol + which is also @code{C_EXT} symbol appears where it was + declared and not at the end of a section. This bit is set + by the target BFD part to convey this information. */ + +#define BSF_NOT_AT_END 0x400 + + /* Signal that the symbol is the label of constructor section. */ +#define BSF_CONSTRUCTOR 0x800 + + /* Signal that the symbol is a warning symbol. The name is a + warning. The name of the next symbol is the one to warn about; + if a reference is made to a symbol with the same name as the next + symbol, a warning is issued by the linker. */ +#define BSF_WARNING 0x1000 + + /* Signal that the symbol is indirect. This symbol is an indirect + pointer to the symbol with the same name as the next symbol. */ +#define BSF_INDIRECT 0x2000 + + /* BSF_FILE marks symbols that contain a file name. This is used + for ELF STT_FILE symbols. */ +#define BSF_FILE 0x4000 + + /* Symbol is from dynamic linking information. */ +#define BSF_DYNAMIC 0x8000 + + /* The symbol denotes a data object. Used in ELF, and perhaps + others someday. */ +#define BSF_OBJECT 0x10000 + + /* This symbol is a debugging symbol. The value is the offset + into the section of the data. BSF_DEBUGGING should be set + as well. */ +#define BSF_DEBUGGING_RELOC 0x20000 + + flagword flags; + + /* A pointer to the section to which this symbol is + relative. This will always be non NULL, there are special + sections for undefined and absolute symbols. */ + struct sec *section; + + /* Back end special data. */ + union + @{ + PTR p; + bfd_vma i; + @} udata; + +@} asymbol; +@end example + +@node symbol handling functions, , typedef asymbol, Symbols +@subsection Symbol handling functions + + +@findex bfd_get_symtab_upper_bound +@subsubsection @code{bfd_get_symtab_upper_bound} +@strong{Description}@* +Return the number of bytes required to store a vector of pointers +to @code{asymbols} for all the symbols in the BFD @var{abfd}, +including a terminal NULL pointer. If there are no symbols in +the BFD, then return 0. If an error occurs, return -1. +@example +#define bfd_get_symtab_upper_bound(abfd) \ + BFD_SEND (abfd, _bfd_get_symtab_upper_bound, (abfd)) +@end example + +@findex bfd_is_local_label +@subsubsection @code{bfd_is_local_label} +@strong{Synopsis} +@example +boolean bfd_is_local_label(bfd *abfd, asymbol *sym); +@end example +@strong{Description}@* +Return true if the given symbol @var{sym} in the BFD @var{abfd} is +a compiler generated local label, else return false. + +@findex bfd_is_local_label_name +@subsubsection @code{bfd_is_local_label_name} +@strong{Synopsis} +@example +boolean bfd_is_local_label_name(bfd *abfd, const char *name); +@end example +@strong{Description}@* +Return true if a symbol with the name @var{name} in the BFD +@var{abfd} is a compiler generated local label, else return +false. This just checks whether the name has the form of a +local label. +@example +#define bfd_is_local_label_name(abfd, name) \ + BFD_SEND (abfd, _bfd_is_local_label_name, (abfd, name)) +@end example + +@findex bfd_canonicalize_symtab +@subsubsection @code{bfd_canonicalize_symtab} +@strong{Description}@* +Read the symbols from the BFD @var{abfd}, and fills in +the vector @var{location} with pointers to the symbols and +a trailing NULL. +Return the actual number of symbol pointers, not +including the NULL. +@example +#define bfd_canonicalize_symtab(abfd, location) \ + BFD_SEND (abfd, _bfd_canonicalize_symtab,\ + (abfd, location)) +@end example + +@findex bfd_set_symtab +@subsubsection @code{bfd_set_symtab} +@strong{Synopsis} +@example +boolean bfd_set_symtab (bfd *abfd, asymbol **location, unsigned int count); +@end example +@strong{Description}@* +Arrange that when the output BFD @var{abfd} is closed, +the table @var{location} of @var{count} pointers to symbols +will be written. + +@findex bfd_print_symbol_vandf +@subsubsection @code{bfd_print_symbol_vandf} +@strong{Synopsis} +@example +void bfd_print_symbol_vandf(PTR file, asymbol *symbol); +@end example +@strong{Description}@* +Print the value and flags of the @var{symbol} supplied to the +stream @var{file}. + +@findex bfd_make_empty_symbol +@subsubsection @code{bfd_make_empty_symbol} +@strong{Description}@* +Create a new @code{asymbol} structure for the BFD @var{abfd} +and return a pointer to it. + +This routine is necessary because each back end has private +information surrounding the @code{asymbol}. Building your own +@code{asymbol} and pointing to it will not create the private +information, and will cause problems later on. +@example +#define bfd_make_empty_symbol(abfd) \ + BFD_SEND (abfd, _bfd_make_empty_symbol, (abfd)) +@end example + +@findex bfd_make_debug_symbol +@subsubsection @code{bfd_make_debug_symbol} +@strong{Description}@* +Create a new @code{asymbol} structure for the BFD @var{abfd}, +to be used as a debugging symbol. Further details of its use have +yet to be worked out. +@example +#define bfd_make_debug_symbol(abfd,ptr,size) \ + BFD_SEND (abfd, _bfd_make_debug_symbol, (abfd, ptr, size)) +@end example + +@findex bfd_decode_symclass +@subsubsection @code{bfd_decode_symclass} +@strong{Description}@* +Return a character corresponding to the symbol +class of @var{symbol}, or '?' for an unknown class. + +@strong{Synopsis} +@example +int bfd_decode_symclass(asymbol *symbol); +@end example +@findex bfd_is_undefined_symclass +@subsubsection @code{bfd_is_undefined_symclass } +@strong{Description}@* +Returns non-zero if the class symbol returned by +bfd_decode_symclass represents an undefined symbol. +Returns zero otherwise. + +@strong{Synopsis} +@example +boolean bfd_is_undefined_symclass (int symclass); +@end example +@findex bfd_symbol_info +@subsubsection @code{bfd_symbol_info} +@strong{Description}@* +Fill in the basic info about symbol that nm needs. +Additional info may be added by the back-ends after +calling this function. + +@strong{Synopsis} +@example +void bfd_symbol_info(asymbol *symbol, symbol_info *ret); +@end example +@findex bfd_copy_private_symbol_data +@subsubsection @code{bfd_copy_private_symbol_data} +@strong{Synopsis} +@example +boolean bfd_copy_private_symbol_data(bfd *ibfd, asymbol *isym, bfd *obfd, asymbol *osym); +@end example +@strong{Description}@* +Copy private symbol information from @var{isym} in the BFD +@var{ibfd} to the symbol @var{osym} in the BFD @var{obfd}. +Return @code{true} on success, @code{false} on error. Possible error +returns are: + +@itemize @bullet + +@item +@code{bfd_error_no_memory} - +Not enough memory exists to create private data for @var{osec}. +@end itemize +@example +#define bfd_copy_private_symbol_data(ibfd, isymbol, obfd, osymbol) \ + BFD_SEND (obfd, _bfd_copy_private_symbol_data, \ + (ibfd, isymbol, obfd, osymbol)) +@end example + Index: opncls.texi =================================================================== --- opncls.texi (nonexistent) +++ opncls.texi (revision 1765) @@ -0,0 +1,159 @@ +@section Opening and closing BFDs + + +@findex bfd_openr +@subsubsection @code{bfd_openr} +@strong{Synopsis} +@example +bfd *bfd_openr(CONST char *filename, CONST char *target); +@end example +@strong{Description}@* +Open the file @var{filename} (using @code{fopen}) with the target +@var{target}. Return a pointer to the created BFD. + +Calls @code{bfd_find_target}, so @var{target} is interpreted as by +that function. + +If @code{NULL} is returned then an error has occured. Possible errors +are @code{bfd_error_no_memory}, @code{bfd_error_invalid_target} or @code{system_call} error. + +@findex bfd_fdopenr +@subsubsection @code{bfd_fdopenr} +@strong{Synopsis} +@example +bfd *bfd_fdopenr(CONST char *filename, CONST char *target, int fd); +@end example +@strong{Description}@* +@code{bfd_fdopenr} is to @code{bfd_fopenr} much like @code{fdopen} is to @code{fopen}. +It opens a BFD on a file already described by the @var{fd} +supplied. + +When the file is later @code{bfd_close}d, the file descriptor will be closed. + +If the caller desires that this file descriptor be cached by BFD +(opened as needed, closed as needed to free descriptors for +other opens), with the supplied @var{fd} used as an initial +file descriptor (but subject to closure at any time), call +bfd_set_cacheable(bfd, 1) on the returned BFD. The default is to +assume no cacheing; the file descriptor will remain open until +@code{bfd_close}, and will not be affected by BFD operations on other +files. + +Possible errors are @code{bfd_error_no_memory}, @code{bfd_error_invalid_target} and @code{bfd_error_system_call}. + +@findex bfd_openstreamr +@subsubsection @code{bfd_openstreamr} +@strong{Synopsis} +@example +bfd *bfd_openstreamr(const char *, const char *, PTR); +@end example +@strong{Description}@* +Open a BFD for read access on an existing stdio stream. When +the BFD is passed to @code{bfd_close}, the stream will be closed. + +@findex bfd_openw +@subsubsection @code{bfd_openw} +@strong{Synopsis} +@example +bfd *bfd_openw(CONST char *filename, CONST char *target); +@end example +@strong{Description}@* +Create a BFD, associated with file @var{filename}, using the +file format @var{target}, and return a pointer to it. + +Possible errors are @code{bfd_error_system_call}, @code{bfd_error_no_memory}, +@code{bfd_error_invalid_target}. + +@findex bfd_close +@subsubsection @code{bfd_close} +@strong{Synopsis} +@example +boolean bfd_close(bfd *abfd); +@end example +@strong{Description}@* +Close a BFD. If the BFD was open for writing, +then 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 attached to the BFD is released. + +The file descriptor associated with the BFD is closed (even +if it was passed in to BFD by @code{bfd_fdopenr}). + +@strong{Returns}@* +@code{true} is returned if all is ok, otherwise @code{false}. + +@findex bfd_close_all_done +@subsubsection @code{bfd_close_all_done} +@strong{Synopsis} +@example +boolean bfd_close_all_done(bfd *); +@end example +@strong{Description}@* +Close a BFD. Differs from @code{bfd_close} +since it does not complete any pending operations. This +routine would be used if the application had just used BFD for +swapping and didn't want to use any of the writing code. + +If the created file is executable, then @code{chmod} is called +to mark it as such. + +All memory attached to the BFD is released. + +@strong{Returns}@* +@code{true} is returned if all is ok, otherwise @code{false}. + +@findex bfd_create +@subsubsection @code{bfd_create} +@strong{Synopsis} +@example +bfd *bfd_create(CONST char *filename, bfd *templ); +@end example +@strong{Description}@* +Create a new BFD in the manner of +@code{bfd_openw}, but without opening a file. The new BFD +takes the target from the target used by @var{template}. The +format is always set to @code{bfd_object}. + +@findex bfd_make_writable +@subsubsection @code{bfd_make_writable} +@strong{Synopsis} +@example +boolean bfd_make_writable(bfd *abfd); +@end example +@strong{Description}@* +Takes a BFD as created by @code{bfd_create} and converts it +into one like as returned by @code{bfd_openw}. It does this +by converting the BFD to BFD_IN_MEMORY. It's assumed that +you will call @code{bfd_make_readable} on this bfd later. + +@strong{Returns}@* +@code{true} is returned if all is ok, otherwise @code{false}. + +@findex bfd_make_readable +@subsubsection @code{bfd_make_readable} +@strong{Synopsis} +@example +boolean bfd_make_readable(bfd *abfd); +@end example +@strong{Description}@* +Takes a BFD as created by @code{bfd_create} and +@code{bfd_make_writable} and converts it into one like as +returned by @code{bfd_openr}. It does this by writing the +contents out to the memory buffer, then reversing the +direction. + +@strong{Returns}@* +@code{true} is returned if all is ok, otherwise @code{false}. + +@findex bfd_alloc +@subsubsection @code{bfd_alloc} +@strong{Synopsis} +@example +PTR bfd_alloc (bfd *abfd, size_t wanted); +@end example +@strong{Description}@* +Allocate a block of @var{wanted} bytes of memory attached to +@code{abfd} and return a pointer to it. + Index: chew.c =================================================================== --- chew.c (nonexistent) +++ chew.c (revision 1765) @@ -0,0 +1,1579 @@ +/* chew + Copyright (C) 1990, 91, 92, 93, 94, 95, 96, 1998 + Free Software Foundation, Inc. + Contributed by steve chamberlain @cygnus + +This file is part of BFD, the Binary File Descriptor library. + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or +(at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ + +/* Yet another way of extracting documentation from source. + No, I haven't finished it yet, but I hope you people like it better + than the old way + + sac + + Basically, this is a sort of string forth, maybe we should call it + struth? + + You define new words thus: + : ; + +*/ + +/* Primitives provided by the program: + + Two stacks are provided, a string stack and an integer stack. + + Internal state variables: + internal_wanted - indicates whether `-i' was passed + internal_mode - user-settable + + Commands: + push_text + ! - pop top of integer stack for address, pop next for value; store + @ - treat value on integer stack as the address of an integer; push + that integer on the integer stack after popping the "address" + hello - print "hello\n" to stdout + stdout - put stdout marker on TOS + stderr - put stderr marker on TOS + print - print TOS-1 on TOS (eg: "hello\n" stdout print) + skip_past_newline + catstr - fn icatstr + copy_past_newline - append input, up to and including newline into TOS + dup - fn other_dup + drop - discard TOS + idrop - ditto + remchar - delete last character from TOS + get_stuff_in_command + do_fancy_stuff - translate <> to @code{foo} in TOS + bulletize - if "o" lines found, prepend @itemize @bullet to TOS + and @item to each "o" line; append @end itemize + courierize - put @example around . and | lines, translate {* *} { } + exit - fn chew_exit + swap + outputdots - strip out lines without leading dots + paramstuff - convert full declaration into "PARAMS" form if not already + maybecatstr - do catstr if internal_mode == internal_wanted, discard + value in any case + translatecomments - turn {* and *} into comment delimiters + kill_bogus_lines - get rid of extra newlines + indent + internalmode - pop from integer stack, set `internalmode' to that value + print_stack_level - print current stack depth to stderr + strip_trailing_newlines - go ahead, guess... + [quoted string] - push string onto string stack + [word starting with digit] - push atol(str) onto integer stack + + A command must be all upper-case, and alone on a line. + + Foo. */ + + +#include +#include "sysdep.h" +#include +#include +#include + +#define DEF_SIZE 5000 +#define STACK 50 + +int internal_wanted; +int internal_mode; + +int warning; + +/* Here is a string type ... */ + +typedef struct buffer +{ + char *ptr; + unsigned long write_idx; + unsigned long size; +} string_type; + + +#ifdef __STDC__ +static void init_string_with_size (string_type *, unsigned int); +static void init_string (string_type *); +static int find (string_type *, char *); +static void write_buffer (string_type *, FILE *); +static void delete_string (string_type *); +static char *addr (string_type *, unsigned int); +static char at (string_type *, unsigned int); +static void catchar (string_type *, int); +static void overwrite_string (string_type *, string_type *); +static void catbuf (string_type *, char *, unsigned int); +static void cattext (string_type *, char *); +static void catstr (string_type *, string_type *); +#endif + + +static void DEFUN(init_string_with_size,(buffer, size), + string_type *buffer AND + unsigned int size ) +{ + buffer->write_idx = 0; + buffer->size = size; + buffer->ptr = malloc(size); +} + +static void DEFUN(init_string,(buffer), + string_type *buffer) +{ + init_string_with_size(buffer, DEF_SIZE); + +} + +static int DEFUN(find, (str, what), + string_type *str AND + char *what) +{ + unsigned int i; + char *p; + p = what; + for (i = 0; i < str->write_idx && *p; i++) + { + if (*p == str->ptr[i]) + p++; + else + p = what; + } + return (*p == 0); + +} + +static void DEFUN(write_buffer,(buffer, f), + string_type *buffer AND + FILE *f) +{ + fwrite(buffer->ptr, buffer->write_idx, 1, f); +} + + +static void DEFUN(delete_string,(buffer), + string_type *buffer) +{ + free(buffer->ptr); +} + + +static char *DEFUN(addr, (buffer, idx), + string_type *buffer AND + unsigned int idx) +{ + return buffer->ptr + idx; +} + +static char DEFUN(at,(buffer, pos), + string_type *buffer AND + unsigned int pos) +{ + if (pos >= buffer->write_idx) + return 0; + return buffer->ptr[pos]; +} + +static void DEFUN(catchar,(buffer, ch), + string_type *buffer AND + int ch) +{ + if (buffer->write_idx == buffer->size) + { + buffer->size *=2; + buffer->ptr = realloc(buffer->ptr, buffer->size); + } + + buffer->ptr[buffer->write_idx ++ ] = ch; +} + + +static void DEFUN(overwrite_string,(dst, src), + string_type *dst AND + string_type *src) +{ + free(dst->ptr); + dst->size = src->size; + dst->write_idx = src->write_idx; + dst->ptr = src->ptr; +} + +static void DEFUN(catbuf,(buffer, buf, len), + string_type *buffer AND + char *buf AND + unsigned int len) +{ + if (buffer->write_idx + len >= buffer->size) + { + while (buffer->write_idx + len >= buffer->size) + buffer->size *= 2; + buffer->ptr = realloc (buffer->ptr, buffer->size); + } + memcpy (buffer->ptr + buffer->write_idx, buf, len); + buffer->write_idx += len; +} + +static void DEFUN(cattext,(buffer, string), + string_type *buffer AND + char *string) +{ + catbuf (buffer, string, (unsigned int) strlen (string)); +} + +static void DEFUN(catstr,(dst, src), + string_type *dst AND + string_type *src) +{ + catbuf (dst, src->ptr, src->write_idx); +} + + +static unsigned int +DEFUN(skip_white_and_stars,(src, idx), + string_type *src AND + unsigned int idx) +{ + char c; + while ((c = at(src,idx)), + isspace ((unsigned char) c) + || (c == '*' + /* Don't skip past end-of-comment or star as first + character on its line. */ + && at(src,idx +1) != '/' + && at(src,idx -1) != '\n')) + idx++; + return idx; +} + +/***********************************************************************/ + + +string_type stack[STACK]; +string_type *tos; + +unsigned int idx = 0; /* Pos in input buffer */ +string_type *ptr; /* and the buffer */ +typedef void (*stinst_type)(); +stinst_type *pc; +stinst_type sstack[STACK]; +stinst_type *ssp = &sstack[0]; +long istack[STACK]; +long *isp = &istack[0]; + +typedef int *word_type; + + + +struct dict_struct +{ + char *word; + struct dict_struct *next; + stinst_type *code; + int code_length; + int code_end; + int var; + +}; +typedef struct dict_struct dict_type; +#define WORD(x) static void x() + +static void +die (msg) + char *msg; +{ + fprintf (stderr, "%s\n", msg); + exit (1); +} + +static void +check_range () +{ + if (tos < stack) + die ("underflow in string stack"); + if (tos >= stack + STACK) + die ("overflow in string stack"); +} + +static void +icheck_range () +{ + if (isp < istack) + die ("underflow in integer stack"); + if (isp >= istack + STACK) + die ("overflow in integer stack"); +} + +#ifdef __STDC__ +static void exec (dict_type *); +static void call (void); +static void remchar (void), strip_trailing_newlines (void), push_number (void); +static void push_text (void); +static void remove_noncomments (string_type *, string_type *); +static void print_stack_level (void); +static void paramstuff (void), translatecomments (void); +static void outputdots (void), courierize (void), bulletize (void); +static void do_fancy_stuff (void); +static int iscommand (string_type *, unsigned int); +static int copy_past_newline (string_type *, unsigned int, string_type *); +static void icopy_past_newline (void), kill_bogus_lines (void), indent (void); +static void get_stuff_in_command (void), swap (void), other_dup (void); +static void drop (void), idrop (void); +static void icatstr (void), skip_past_newline (void), internalmode (void); +static void maybecatstr (void); +static char *nextword (char *, char **); +dict_type *lookup_word (char *); +static void perform (void); +dict_type *newentry (char *); +unsigned int add_to_definition (dict_type *, stinst_type); +void add_intrinsic (char *, void (*)()); +void add_var (char *); +void compile (char *); +static void bang (void); +static void atsign (void); +static void hello (void); +static void stdout_ (void); +static void stderr_ (void); +static void print (void); +static void read_in (string_type *, FILE *); +static void usage (void); +static void chew_exit (void); +#endif + +static void DEFUN(exec,(word), + dict_type *word) +{ + pc = word->code; + while (*pc) + (*pc)(); +} +WORD(call) +{ + stinst_type *oldpc = pc; + dict_type *e; + e = (dict_type *)(pc [1]); + exec(e); + pc = oldpc + 2; + +} + +WORD(remchar) +{ + if (tos->write_idx) + tos->write_idx--; + pc++; +} + +static void +strip_trailing_newlines () +{ + while ((isspace ((unsigned char) at (tos, tos->write_idx - 1)) + || at (tos, tos->write_idx - 1) == '\n') + && tos->write_idx > 0) + tos->write_idx--; + pc++; +} + +WORD(push_number) +{ + isp++; + icheck_range (); + pc++; + *isp = (long)(*pc); + pc++; +} + +WORD(push_text) +{ + tos++; + check_range (); + init_string(tos); + pc++; + cattext(tos,*((char **)pc)); + pc++; + +} + + +/* This function removes everything not inside comments starting on + the first char of the line from the string, also when copying + comments, removes blank space and leading *'s. + Blank lines are turned into one blank line. */ + +static void +DEFUN(remove_noncomments,(src,dst), + string_type *src AND + string_type *dst) +{ + unsigned int idx = 0; + + while (at(src,idx)) + { + /* Now see if we have a comment at the start of the line */ + if (at(src,idx) == '\n' + && at(src,idx+1) == '/' + && at(src,idx+2) == '*') + { + idx+=3; + + idx = skip_white_and_stars(src,idx); + + /* Remove leading dot */ + if (at(src, idx) == '.') + idx++; + + /* Copy to the end of the line, or till the end of the + comment */ + while (at(src, idx)) + { + if (at(src, idx) == '\n') + { + /* end of line, echo and scrape of leading blanks */ + if (at(src,idx +1) == '\n') + catchar(dst,'\n'); + catchar(dst,'\n'); + idx++; + idx = skip_white_and_stars(src, idx); + } + else if (at(src, idx) == '*' && at(src,idx+1) == '/') + { + idx +=2 ; + cattext(dst,"\nENDDD\n"); + break; + } + else + { + catchar(dst, at(src, idx)); + idx++; + } + } + } + else idx++; + } +} + +static void +print_stack_level () +{ + fprintf (stderr, "current string stack depth = %d, ", tos - stack); + fprintf (stderr, "current integer stack depth = %d\n", isp - istack); + pc++; +} + +/* turn: + foobar name(stuff); + into: + foobar + name PARAMS ((stuff)); + and a blank line. + */ + +static void +DEFUN_VOID(paramstuff) +{ + unsigned int openp; + unsigned int fname; + unsigned int idx; + string_type out; + init_string(&out); + + + /* make sure that it's not already param'd or proto'd */ + if(find(tos,"PARAMS") || find(tos,"PROTO") || !find(tos,"(")) { + catstr(&out,tos); + } + else + { + /* Find the open paren */ + for (openp = 0; at(tos, openp) != '(' && at(tos,openp); openp++) + ; + + fname = openp; + /* Step back to the fname */ + fname--; + while (fname && isspace((unsigned char) at(tos, fname))) + fname --; + while (fname + && !isspace((unsigned char) at(tos,fname)) + && at(tos,fname) != '*') + fname--; + + fname++; + + for (idx = 0; idx < fname; idx++) /* Output type */ + { + catchar(&out, at(tos,idx)); + } + + cattext(&out, "\n"); /* Insert a newline between type and fnname */ + + for (idx = fname; idx < openp; idx++) /* Output fnname */ + { + catchar(&out, at(tos,idx)); + } + + cattext(&out," PARAMS ("); + + while (at(tos,idx) && at(tos,idx) !=';') + { + catchar(&out, at(tos, idx)); + idx++; + } + cattext(&out,");\n\n"); + } + overwrite_string(tos, &out); + pc++; + +} + + + +/* turn {* + and *} into comments */ + +WORD(translatecomments) +{ + unsigned int idx = 0; + string_type out; + init_string(&out); + + while (at(tos, idx)) + { + if (at(tos,idx) == '{' && at(tos,idx+1) =='*') + { + cattext(&out,"/*"); + idx+=2; + } + else if (at(tos,idx) == '*' && at(tos,idx+1) =='}') + { + cattext(&out,"*/"); + idx+=2; + } + else + { + catchar(&out, at(tos, idx)); + idx++; + } + } + + + overwrite_string(tos, &out); + + pc++; + +} + +#if 0 + +/* This is not currently used. */ + +/* turn everything not starting with a . into a comment */ + +WORD(manglecomments) +{ + unsigned int idx = 0; + string_type out; + init_string(&out); + + while (at(tos, idx)) + { + if (at(tos,idx) == '\n' && at(tos,idx+1) =='*') + { + cattext(&out," /*"); + idx+=2; + } + else if (at(tos,idx) == '*' && at(tos,idx+1) =='}') + { + cattext(&out,"*/"); + idx+=2; + } + else + { + catchar(&out, at(tos, idx)); + idx++; + } + } + + + overwrite_string(tos, &out); + + pc++; + +} + +#endif + +/* Mod tos so that only lines with leading dots remain */ +static void +DEFUN_VOID(outputdots) +{ + unsigned int idx = 0; + string_type out; + init_string(&out); + + while (at(tos, idx)) + { + if (at(tos, idx) == '\n' && at(tos, idx+1) == '.') + { + char c; + idx += 2; + + while ((c = at(tos, idx)) && c != '\n') + { + if (c == '{' && at(tos,idx+1) =='*') + { + cattext(&out," /*"); + idx+=2; + } + else if (c == '*' && at(tos,idx+1) =='}') + { + cattext(&out,"*/"); + idx+=2; + } + else + { + catchar(&out, c); + idx++; + } + } + catchar(&out,'\n'); + } + else + { + idx++; + } + } + + overwrite_string(tos, &out); + pc++; + +} + +/* Find lines starting with . and | and put example around them on tos */ +WORD(courierize) +{ + string_type out; + unsigned int idx = 0; + int command = 0; + + init_string(&out); + + while (at(tos, idx)) + { + if (at(tos, idx) == '\n' + && (at(tos, idx +1 ) == '.' + || at(tos,idx+1) == '|')) + { + cattext(&out,"\n@example\n"); + do + { + idx += 2; + + while (at(tos, idx) && at(tos, idx)!='\n') + { + if (at(tos,idx)=='{' && at(tos,idx+1) =='*') + { + cattext(&out," /*"); + idx+=2; + } + else if (at(tos,idx)=='*' && at(tos,idx+1) =='}') + { + cattext(&out,"*/"); + idx+=2; + } + else if (at(tos,idx) == '{' && !command) + { + cattext(&out,"@{"); + idx++; + } + else if (at(tos,idx) == '}' && !command) + { + cattext(&out,"@}"); + idx++; + } + else + { + if (at(tos,idx) == '@') + command = 1; + else if (isspace((unsigned char) at(tos,idx)) + || at(tos,idx) == '}') + command = 0; + catchar(&out, at(tos, idx)); + idx++; + } + + } + catchar(&out,'\n'); + } + while (at(tos, idx) == '\n' + && ((at(tos, idx+1) == '.') + || (at(tos,idx+1) == '|'))) + ; + cattext(&out,"@end example"); + } + else + { + catchar(&out, at(tos, idx)); + idx++; + } + } + + overwrite_string(tos, &out); + pc++; + + +} + +/* Finds any lines starting with "o ", if there are any, then turns + on @itemize @bullet, and @items each of them. Then ends with @end + itemize, inplace at TOS*/ + + +WORD(bulletize) +{ + unsigned int idx = 0; + int on = 0; + string_type out; + init_string(&out); + + while (at(tos, idx)) { + if (at(tos, idx) == '@' && + at(tos, idx+1) == '*') + { + cattext(&out,"*"); + idx+=2; + } + + else + if (at(tos, idx) == '\n' && + at(tos, idx+1) == 'o' && + isspace((unsigned char) at(tos, idx +2))) + { + if (!on) + { + cattext(&out,"\n@itemize @bullet\n"); + on = 1; + + } + cattext(&out,"\n@item\n"); + idx+=3; + } + else + { + catchar(&out, at(tos, idx)); + if (on && at(tos, idx) == '\n' && + at(tos, idx+1) == '\n' && + at(tos, idx+2) != 'o') + { + cattext(&out, "@end itemize"); + on = 0; + } + idx++; + + } + } + if (on) + { + cattext(&out,"@end itemize\n"); + } + + delete_string(tos); + *tos = out; + pc++; + +} + +/* Turn <> into @code{foo} in place at TOS*/ + + +WORD(do_fancy_stuff) +{ + unsigned int idx = 0; + string_type out; + init_string(&out); + while (at(tos, idx)) + { + if (at(tos, idx) == '<' + && at(tos, idx+1) == '<' + && !isspace((unsigned char) at(tos,idx + 2))) + { + /* This qualifies as a << startup */ + idx +=2; + cattext(&out,"@code{"); + while(at(tos,idx) && + at(tos,idx) != '>' ) + { + catchar(&out, at(tos, idx)); + idx++; + + } + cattext(&out,"}"); + idx+=2; + } + else + { + catchar(&out, at(tos, idx)); + idx++; + } + } + delete_string(tos); + *tos = out; + pc++; + +} +/* A command is all upper case,and alone on a line */ +static int +DEFUN( iscommand,(ptr, idx), + string_type *ptr AND + unsigned int idx) +{ + unsigned int len = 0; + while (at(ptr,idx)) { + if (isupper((unsigned char) at(ptr,idx)) || at(ptr,idx) == ' ' || + at(ptr,idx) == '_') + { + len++; + idx++; + } + else if(at(ptr,idx) == '\n') + { + if (len > 3) return 1; + return 0; + } + else return 0; + } + return 0; + +} + + +static int +DEFUN(copy_past_newline,(ptr, idx, dst), + string_type *ptr AND + unsigned int idx AND + string_type *dst) +{ + int column = 0; + + while (at(ptr, idx) && at(ptr, idx) != '\n') + { + if (at (ptr, idx) == '\t') + { + /* Expand tabs. Neither makeinfo nor TeX can cope well with + them. */ + do + catchar (dst, ' '); + while (++column & 7); + } + else + { + catchar(dst, at(ptr, idx)); + column++; + } + idx++; + + } + catchar(dst, at(ptr, idx)); + idx++; + return idx; + +} + +WORD(icopy_past_newline) +{ + tos++; + check_range (); + init_string(tos); + idx = copy_past_newline(ptr, idx, tos); + pc++; +} + +/* indent + Take the string at the top of the stack, do some prettying */ + + +WORD(kill_bogus_lines) +{ + int sl ; + + int idx = 0; + int c; + int dot = 0 ; + + string_type out; + init_string(&out); + /* Drop leading nl */ + while (at(tos,idx) == '\n') + { + idx++; + } + c = idx; + + /* If the first char is a '.' prepend a newline so that it is + recognized properly later. */ + if (at (tos, idx) == '.') + catchar (&out, '\n'); + + /* Find the last char */ + while (at(tos,idx)) + { + idx++; + } + + /* find the last non white before the nl */ + idx--; + + while (idx && isspace((unsigned char) at(tos,idx))) + idx--; + idx++; + + /* Copy buffer upto last char, but blank lines before and after + dots don't count */ + sl = 1; + + while (c < idx) + { + if (at(tos,c) == '\n' + && at(tos,c+1) == '\n' + && at(tos,c+2) == '.') + { + /* Ignore two newlines before a dot*/ + c++; + } + else if (at(tos,c) == '.' && sl) + { + /* remember that this line started with a dot */ + dot=2; + } + else if (at(tos,c) == '\n' + && at(tos,c+1) == '\n' + && dot) + { + c++; + /* Ignore two newlines when last line was dot */ + } + + catchar(&out, at(tos,c)); + if (at(tos,c) == '\n') + { + sl = 1; + + if (dot == 2)dot=1;else dot = 0; + } + else + sl = 0; + + c++; + + } + + /* Append nl*/ + catchar(&out, '\n'); + pc++; + delete_string(tos); + *tos = out; + + +} + +WORD(indent) +{ + string_type out; + int tab = 0; + int idx = 0; + int ol =0; + init_string(&out); + while (at(tos,idx)) { + switch (at(tos,idx)) + { + case '\n': + cattext(&out,"\n"); + idx++; + if (tab && at(tos,idx)) + { + cattext(&out," "); + } + ol = 0; + break; + case '(': + tab++; + if (ol == 0) + cattext(&out," "); + idx++; + cattext(&out,"("); + ol = 1; + break; + case ')': + tab--; + cattext(&out,")"); + idx++; + ol=1; + + break; + default: + catchar(&out,at(tos,idx)); + ol=1; + + idx++; + break; + } + } + + pc++; + delete_string(tos); + *tos = out; + +} + + +WORD(get_stuff_in_command) +{ + tos++; + check_range (); + init_string(tos); + + while (at(ptr, idx)) { + if (iscommand(ptr, idx)) break; + idx = copy_past_newline(ptr, idx, tos); + } + pc++; +} + +WORD(swap) +{ + string_type t; + + t = tos[0]; + tos[0] = tos[-1]; + tos[-1] =t; + pc++; + +} + +WORD(other_dup) +{ + tos++; + check_range (); + init_string(tos); + catstr(tos, tos-1); + pc++; +} + +WORD(drop) +{ + tos--; + check_range (); + pc++; +} + +WORD(idrop) +{ + isp--; + icheck_range (); + pc++; +} + +WORD(icatstr) +{ + tos--; + check_range (); + catstr(tos, tos+1); + delete_string(tos+1); + pc++; +} + +WORD(skip_past_newline) +{ + while (at(ptr,idx) + && at(ptr,idx) != '\n') + idx++; + idx++; + pc++; +} + + +WORD(internalmode) +{ + internal_mode = *(isp); + isp--; + icheck_range (); + pc++; +} + +WORD(maybecatstr) +{ + if (internal_wanted == internal_mode) + { + catstr(tos-1, tos); + } + delete_string(tos); + tos--; + check_range (); + pc++; +} + +char * +DEFUN(nextword,(string, word), + char *string AND + char **word) +{ + char *word_start; + int idx; + char *dst; + char *src; + + int length = 0; + + while (isspace((unsigned char) *string) || *string == '-') { + if (*string == '-') + { + while (*string && *string != '\n') + string++; + + } + else { + string++; + } + } + if (!*string) return 0; + + word_start = string; + if (*string == '"') + { + do + { + string++; + length++; + if (*string == '\\') + { + string += 2; + length += 2; + } + } + while (*string != '"'); + } + else + { + while (!isspace((unsigned char) *string)) + { + string++; + length++; + + } + } + + *word = malloc(length + 1); + + dst = *word; + src = word_start; + + + for (idx= 0; idx < length; idx++) + { + if (src[idx] == '\\') + switch (src[idx+1]) + { + case 'n': + *dst++ = '\n'; + idx++; + break; + case '"': + case '\\': + *dst++ = src[idx+1]; + idx++; + break; + default: + *dst++ = '\\'; + break; + } + else + *dst++ = src[idx]; + } + *dst++ = 0; + + + + + + if(*string) + return string + 1; + else + return 0; + +} +dict_type *root; +dict_type * +DEFUN(lookup_word,(word), + char *word) +{ + dict_type *ptr = root; + while (ptr) { + if (strcmp(ptr->word, word) == 0) return ptr; + ptr = ptr->next; + + } + if (warning) + fprintf(stderr,"Can't find %s\n",word); + return 0; + + +} + +static void DEFUN_VOID(perform) +{ + tos = stack; + + while (at(ptr, idx)) { + /* It's worth looking through the command list */ + if (iscommand(ptr, idx)) + { + char *next; + dict_type *word ; + + (void) nextword(addr(ptr, idx), &next); + + + word = lookup_word(next); + + + + + if (word) + { + exec(word); + } + else + { + if (warning) + fprintf(stderr,"warning, %s is not recognised\n", next); + skip_past_newline(); + } + + } + else skip_past_newline(); + + } +} + +dict_type * +DEFUN(newentry,(word), + char *word) +{ + dict_type *new = (dict_type *)malloc(sizeof(dict_type)); + new->word = word; + new->next = root; + root = new; + new->code = (stinst_type *)malloc(sizeof(stinst_type )); + new->code_length = 1; + new->code_end = 0; + return new; + +} + + +unsigned int +DEFUN(add_to_definition,(entry, word), + dict_type *entry AND + stinst_type word) +{ + if (entry->code_end == entry->code_length) + { + entry->code_length += 2; + entry->code = + (stinst_type *) realloc((char *)(entry->code), + entry->code_length *sizeof(word_type)); + } + entry->code[entry->code_end] = word; + +return entry->code_end++; +} + + + + + + + +void +DEFUN(add_intrinsic,(name, func), + char *name AND + void (*func)()) +{ + dict_type *new = newentry(name); + add_to_definition(new, func); + add_to_definition(new, 0); +} + +void +DEFUN(add_var,(name), + char *name) +{ + dict_type *new = newentry(name); + add_to_definition(new, push_number); + add_to_definition(new, (stinst_type)(&(new->var))); + add_to_definition(new,0); +} + + +void +DEFUN(compile, (string), + char *string) +{ + /* add words to the dictionary */ + char *word; + string = nextword(string, &word); + while (string && *string && word[0]) + { + if (strcmp(word,"var")==0) + { + string=nextword(string, &word); + + add_var(word); + string=nextword(string, &word); + } +else + + if (word[0] == ':') + { + dict_type *ptr; + /* Compile a word and add to dictionary */ + string = nextword(string, &word); + + ptr = newentry(word); + string = nextword(string, &word); + while (word[0] != ';' ) + { + switch (word[0]) + { + case '"': + /* got a string, embed magic push string + function */ + add_to_definition(ptr, push_text); + add_to_definition(ptr, (stinst_type)(word+1)); + break; + case '0': + case '1': + case '2': + case '3': + case '4': + case '5': + case '6': + case '7': + case '8': + case '9': + /* Got a number, embedd the magic push number + function */ + add_to_definition(ptr, push_number); + add_to_definition(ptr, (stinst_type)atol(word)); + break; + default: + add_to_definition(ptr, call); + add_to_definition(ptr, (stinst_type)lookup_word(word)); + } + + string = nextword(string, &word); + } + add_to_definition(ptr,0); + string = nextword(string, &word); + } + else + { + fprintf(stderr,"syntax error at %s\n",string-1); + } + } + +} + + +static void DEFUN_VOID(bang) +{ + *(long *)((isp[0])) = isp[-1]; + isp-=2; + icheck_range (); + pc++; +} + +WORD(atsign) +{ + isp[0] = *(long *)(isp[0]); + pc++; +} + +WORD(hello) +{ + printf("hello\n"); + pc++; +} + +WORD(stdout_) +{ + isp++; + icheck_range (); + *isp = 1; + pc++; +} + +WORD(stderr_) +{ + isp++; + icheck_range (); + *isp = 2; + pc++; +} + +WORD(print) +{ + if (*isp == 1) + write_buffer (tos, stdout); + else if (*isp == 2) + write_buffer (tos, stderr); + else + fprintf (stderr, "print: illegal print destination `%ld'\n", *isp); + isp--; + tos--; + icheck_range (); + check_range (); + pc++; +} + + +static void DEFUN(read_in, (str, file), + string_type *str AND + FILE *file) +{ + char buff[10000]; + unsigned int r; + do + { + r = fread(buff, 1, sizeof(buff), file); + catbuf(str, buff, r); + } + while (r); + buff[0] = 0; + + catbuf(str, buff,1); +} + + +static void DEFUN_VOID(usage) +{ + fprintf(stderr,"usage: -[d|i|g] file\n"); + exit(33); +} + +/* There is no reliable way to declare exit. Sometimes it returns + int, and sometimes it returns void. Sometimes it changes between + OS releases. Trying to get it declared correctly in the hosts file + is a pointless waste of time. */ + +static void +chew_exit () +{ + exit (0); +} + +int DEFUN(main,(ac,av), +int ac AND +char *av[]) +{ + unsigned int i; + string_type buffer; + string_type pptr; + + init_string(&buffer); + init_string(&pptr); + init_string(stack+0); + tos=stack+1; + ptr = &pptr; + + add_intrinsic("push_text", push_text); + add_intrinsic("!", bang); + add_intrinsic("@", atsign); + add_intrinsic("hello",hello); + add_intrinsic("stdout",stdout_); + add_intrinsic("stderr",stderr_); + add_intrinsic("print",print); + add_intrinsic("skip_past_newline", skip_past_newline ); + add_intrinsic("catstr", icatstr ); + add_intrinsic("copy_past_newline", icopy_past_newline ); + add_intrinsic("dup", other_dup ); + add_intrinsic("drop", drop); + add_intrinsic("idrop", idrop); + add_intrinsic("remchar", remchar ); + add_intrinsic("get_stuff_in_command", get_stuff_in_command ); + add_intrinsic("do_fancy_stuff", do_fancy_stuff ); + add_intrinsic("bulletize", bulletize ); + add_intrinsic("courierize", courierize ); + /* If the following line gives an error, exit() is not declared in the + ../hosts/foo.h file for this host. Fix it there, not here! */ + /* No, don't fix it anywhere; see comment on chew_exit--Ian Taylor. */ + add_intrinsic("exit", chew_exit ); + add_intrinsic("swap", swap ); + add_intrinsic("outputdots", outputdots ); + add_intrinsic("paramstuff", paramstuff ); + add_intrinsic("maybecatstr", maybecatstr ); + add_intrinsic("translatecomments", translatecomments ); + add_intrinsic("kill_bogus_lines", kill_bogus_lines); + add_intrinsic("indent", indent); + add_intrinsic("internalmode", internalmode); + add_intrinsic("print_stack_level", print_stack_level); + add_intrinsic("strip_trailing_newlines", strip_trailing_newlines); + + /* Put a nl at the start */ + catchar(&buffer,'\n'); + + read_in(&buffer, stdin); + remove_noncomments(&buffer, ptr); + for (i= 1; i < (unsigned int) ac; i++) + { + if (av[i][0] == '-') + { + if (av[i][1] == 'f') + { + string_type b; + FILE *f; + init_string(&b); + + f = fopen(av[i+1],"r"); + if (!f) + { + fprintf(stderr,"Can't open the input file %s\n",av[i+1]); + return 33; + } + + read_in(&b, f); + compile(b.ptr); + perform(); + } + else if (av[i][1] == 'i') + { + internal_wanted = 1; + } + else if (av[i][1] == 'w') + { + warning = 1; + } + else + usage (); + } + } + write_buffer(stack+0, stdout); + if (tos != stack) + { + fprintf (stderr, "finishing with current stack level %d\n", tos - stack); + return 1; + } + return 0; +} Index: Makefile.am =================================================================== --- Makefile.am (nonexistent) +++ Makefile.am (revision 1765) @@ -0,0 +1,250 @@ +## Process this file with automake to generate Makefile.in + +AUTOMAKE_OPTIONS = cygnus + +DOCFILES = aoutx.texi archive.texi archures.texi \ + bfdt.texi cache.texi coffcode.texi \ + core.texi elf.texi elfcode.texi format.texi libbfd.texi \ + opncls.texi reloc.texi section.texi \ + syms.texi targets.texi init.texi hash.texi linker.texi + +PROTOS = archive.p archures.p bfd.p \ + core.p format.p \ + libbfd.p opncls.p reloc.p \ + section.p syms.p targets.p \ + format.p core.p init.p + +IPROTOS = cache.ip libbfd.ip reloc.ip init.ip archures.ip coffcode.ip + +# SRCDOC, SRCPROT, SRCIPROT only used to sidestep Sun Make bug in interaction +# between VPATH and suffix rules. If you use GNU Make, perhaps other Makes, +# you don't need these three: +SRCDOC = $(srcdir)/../aoutx.h $(srcdir)/../archive.c \ + $(srcdir)/../archures.c $(srcdir)/../bfd.c \ + $(srcdir)/../cache.c $(srcdir)/../coffcode.h \ + $(srcdir)/../corefile.c $(srcdir)/../elf.c \ + $(srcdir)/../elfcode.h $(srcdir)/../format.c \ + $(srcdir)/../libbfd.c $(srcdir)/../opncls.c \ + $(srcdir)/../reloc.c $(srcdir)/../section.c \ + $(srcdir)/../syms.c $(srcdir)/../targets.c \ + $(srcdir)/../hash.c $(srcdir)/../linker.c + +SRCPROT = $(srcdir)/../archive.c $(srcdir)/../archures.c \ + $(srcdir)/../bfd.c $(srcdir)/../coffcode.h $(srcdir)/../corefile.c \ + $(srcdir)/../format.c $(srcdir)/../libbfd.c \ + $(srcdir)/../opncls.c $(srcdir)/../reloc.c \ + $(srcdir)/../section.c $(srcdir)/../syms.c \ + $(srcdir)/../targets.c $(srcdir)/../init.c + +SRCIPROT = $(srcdir)/../cache.c $(srcdir)/../libbfd.c \ + $(srcdir)/../reloc.c $(srcdir)/../cpu-h8300.c \ + $(srcdir)/../cpu-i960.c $(srcdir)/../archures.c \ + $(srcdir)/../init.c + +TEXIDIR = $(srcdir)/../../texinfo/fsf + +info_TEXINFOS = bfd.texinfo + +MKDOC = chew$(EXEEXT_FOR_BUILD) + +$(MKDOC): chew.o + $(CC_FOR_BUILD) -o $(MKDOC) chew.o $(LOADLIBES) $(LDFLAGS) + +chew.o: chew.c + $(CC_FOR_BUILD) -c -I.. -I$(srcdir)/.. -I$(srcdir)/../../include -I$(srcdir)/../../intl -I../../intl $(H_CFLAGS) $(CFLAGS) $(srcdir)/chew.c + +protos: libbfd.h libcoff.h bfd.h + +bfd.info bfd.dvi: $(DOCFILES) bfdsumm.texi bfd.texinfo + +# We can't replace these rules with an implicit rule, because +# makes without VPATH support couldn't find the .h files in `..'. + +# We use s-XXX targets so that we can distribute the info files, +# and permit people to rebuild them, without requiring the makeinfo +# program. If somebody tries to rebuild info, but none of the .texi +# files have changed, then this Makefile will build chew, and will +# build all of the stamp files, but will not actually have to rebuild +# bfd.info. + +s-aoutx: $(MKDOC) $(srcdir)/../aoutx.h $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../aoutx.h >aoutx.tmp + $(srcdir)/../../move-if-change aoutx.tmp aoutx.texi + touch s-aoutx +aoutx.texi: s-aoutx + +s-archive: $(MKDOC) $(srcdir)/../archive.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../archive.c >archive.tmp + $(srcdir)/../../move-if-change archive.tmp archive.texi + touch s-archive +archive.texi: s-archive + +s-archures: $(MKDOC) $(srcdir)/../archures.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str < $(srcdir)/../archures.c >archures.tmp + $(srcdir)/../../move-if-change archures.tmp archures.texi + touch s-archures +archures.texi: s-archures + +# We use bfdt.texi, rather than bfd.texi, to avoid conflicting with +# bfd.texinfo on an 8.3 filesystem. +s-bfd: $(MKDOC) $(srcdir)/../bfd.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str < $(srcdir)/../bfd.c >bfd.tmp + $(srcdir)/../../move-if-change bfd.tmp bfdt.texi + touch s-bfd +bfdt.texi: s-bfd + +s-cache: $(MKDOC) $(srcdir)/../cache.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str < $(srcdir)/../cache.c >cache.tmp + $(srcdir)/../../move-if-change cache.tmp cache.texi + touch s-cache +cache.texi: s-cache + +s-coffcode: $(MKDOC) $(srcdir)/../coffcode.h $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../coffcode.h >coffcode.tmp + $(srcdir)/../../move-if-change coffcode.tmp coffcode.texi + touch s-coffcode +coffcode.texi: s-coffcode + +s-core: $(MKDOC) $(srcdir)/../corefile.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../corefile.c >core.tmp + $(srcdir)/../../move-if-change core.tmp core.texi + touch s-core +core.texi: s-core + +s-elf: $(MKDOC) $(srcdir)/../elf.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../elf.c >elf.tmp + $(srcdir)/../../move-if-change elf.tmp elf.texi + touch s-elf +elf.texi: s-elf + +s-elfcode: $(MKDOC) $(srcdir)/../elfcode.h $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../elfcode.h >elfcode.tmp + $(srcdir)/../../move-if-change elfcode.tmp elfcode.texi + touch s-elfcode +elfcode.texi: s-elfcode + +s-format: $(MKDOC) $(srcdir)/../format.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../format.c >format.tmp + $(srcdir)/../../move-if-change format.tmp format.texi + touch s-format +format.texi: s-format + +s-libbfd: $(MKDOC) $(srcdir)/../libbfd.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str < $(srcdir)/../libbfd.c >libbfd.tmp + $(srcdir)/../../move-if-change libbfd.tmp libbfd.texi + touch s-libbfd +libbfd.texi: s-libbfd + +s-opncls: $(MKDOC) $(srcdir)/../opncls.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../opncls.c >opncls.tmp + $(srcdir)/../../move-if-change opncls.tmp opncls.texi + touch s-opncls +opncls.texi: s-opncls + +s-reloc: $(MKDOC) $(srcdir)/../reloc.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../reloc.c >reloc.tmp + $(srcdir)/../../move-if-change reloc.tmp reloc.texi + touch s-reloc +reloc.texi: s-reloc + +s-section: $(MKDOC) $(srcdir)/../section.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../section.c >section.tmp + $(srcdir)/../../move-if-change section.tmp section.texi + touch s-section +section.texi: s-section + +s-syms: $(MKDOC) $(srcdir)/../syms.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../syms.c >syms.tmp + $(srcdir)/../../move-if-change syms.tmp syms.texi + touch s-syms +syms.texi: s-syms + +s-targets: $(MKDOC) $(srcdir)/../targets.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../targets.c >targets.tmp + $(srcdir)/../../move-if-change targets.tmp targets.texi + touch s-targets +targets.texi: s-targets + +s-init: $(MKDOC) $(srcdir)/../init.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../init.c >init.tmp + $(srcdir)/../../move-if-change init.tmp init.texi + touch s-init +init.texi: s-init + +s-hash: $(MKDOC) $(srcdir)/../hash.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../hash.c >hash.tmp + $(srcdir)/../../move-if-change hash.tmp hash.texi + touch s-hash +hash.texi: s-hash + +s-linker: $(MKDOC) $(srcdir)/../linker.c $(srcdir)/doc.str + ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../linker.c >linker.tmp + $(srcdir)/../../move-if-change linker.tmp linker.texi + touch s-linker +linker.texi: s-linker + +libbfd.h: $(srcdir)/../libbfd-in.h \ + $(srcdir)/../init.c \ + $(srcdir)/../libbfd.c \ + $(srcdir)/../cache.c \ + $(srcdir)/../reloc.c \ + $(srcdir)/../archures.c \ + $(srcdir)/proto.str \ + $(MKDOC) + cat $(srcdir)/../libbfd-in.h >libbfd.h + ./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../init.c >>libbfd.h + ./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../libbfd.c >>libbfd.h + ./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../cache.c >>libbfd.h + ./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../reloc.c >>libbfd.h + ./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../archures.c >>libbfd.h + ./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../elf.c >>libbfd.h + +libcoff.h: $(srcdir)/../libcoff-in.h \ + $(srcdir)/../coffcode.h \ + $(srcdir)/proto.str \ + $(MKDOC) + cat $(srcdir)/../libcoff-in.h >libcoff.h + ./$(MKDOC) -i -f $(srcdir)/proto.str < $(srcdir)/../coffcode.h >>libcoff.h + +bfd.h: $(srcdir)/../bfd-in.h \ + $(srcdir)/../init.c \ + $(srcdir)/../opncls.c \ + $(srcdir)/../libbfd.c \ + $(srcdir)/../section.c \ + $(srcdir)/../archures.c \ + $(srcdir)/../reloc.c \ + $(srcdir)/../syms.c \ + $(srcdir)/../bfd.c \ + $(srcdir)/../archive.c \ + $(srcdir)/../corefile.c \ + $(srcdir)/../targets.c \ + $(srcdir)/../format.c \ + $(srcdir)/proto.str \ + $(MKDOC) + cat $(srcdir)/../bfd-in.h >bfd.h + ./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../init.c >>bfd.h + ./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../opncls.c >>bfd.h + ./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../libbfd.c >>bfd.h + ./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../section.c >>bfd.h + ./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../archures.c >>bfd.h + ./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../reloc.c >>bfd.h + ./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../syms.c >>bfd.h + ./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../bfd.c >>bfd.h + ./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../archive.c >>bfd.h + ./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../corefile.c >>bfd.h + ./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../targets.c >>bfd.h + ./$(MKDOC) -f $(srcdir)/proto.str<$(srcdir)/../format.c >>bfd.h + echo "#ifdef __cplusplus" >>bfd.h + echo "}" >>bfd.h + echo "#endif" >>bfd.h + echo "#endif" >>bfd.h + +noinst_TEXINFOS = bfdint.texi + +MOSTLYCLEANFILES = $(MKDOC) *.o + +CLEANFILES = s-* *.p *.ip + +DISTCLEANFILES = bfd.?? bfd.??? bfd.h libbfd.h libcoff.h texput.log + +MAINTAINERCLEANFILES = $(DOCFILES) Index: proto.str =================================================================== --- proto.str (nonexistent) +++ proto.str (revision 1765) @@ -0,0 +1,135 @@ + +: SYNOPSIS + skip_past_newline + get_stuff_in_command + paramstuff + indent + maybecatstr +; + +: ignore + skip_past_newline + get_stuff_in_command + outputdots + maybecatstr + ; + +: CODE_FRAGMENT + ignore ; + +: external + 0 internalmode ignore ; + +: internal + 1 internalmode ignore ; + +- input stack { a b } output b if internal, a if external +: ifinternal + "" swap 1 internalmode maybecatstr + swap + "" swap 0 internalmode maybecatstr + catstr + ; + +- Put note in output string, regardless of internal mode. +: COMMENT + skip_past_newline + get_stuff_in_command + translatecomments + catstr + ; + +- SENUM enum-type-name +- ENUM enum-name +- ENUMX addl-enum-name +- ENUMDOC doc for preceding enums +- ENDSENUM max-enum-name + +: make_enum_header + dup + "enum " swap catstr + " {\n" catstr + swap " _dummy_first_" swap catstr catstr + ",\n" catstr + ; +: make_string_table_header + dup + "#ifdef _BFD_MAKE_TABLE_" swap catstr swap + "\n\nstatic const char *const " swap catstr catstr + "_names[] = { \"@@uninitialized@@\",\n" catstr + ; +: SENUM + skip_past_newline + copy_past_newline + remchar + dup + make_enum_header + swap + make_string_table_header + ifinternal + catstr + get_stuff_in_command catstr + translatecomments ; +: ENDSENUM + skip_past_newline + copy_past_newline strip_trailing_newlines + dup + " " swap catstr " };\n" catstr swap + " \"@@overflow: " swap catstr "@@\",\n};\n#endif\n\n" catstr + ifinternal + catstr + ; +: make_enumerator + " " swap catstr + ",\n" catstr + ; +: make_enumerator_string + " \"" swap catstr + "\",\n" catstr + ; +: ENUM + skip_past_newline + copy_past_newline + remchar + dup + make_enumerator + swap + make_enumerator_string + ifinternal + ; +: ENUMX ENUM catstr ; +: ENUMEQ + skip_past_newline + "#define " + copy_past_newline remchar + catstr + " " + catstr + copy_past_newline + catstr + "" swap 0 internalmode maybecatstr + ; +: ENUMEQX ENUMEQ catstr ; +: ENUMDOC + skip_past_newline + get_stuff_in_command + strip_trailing_newlines + "\n{* " swap catstr " *}\n" catstr + translatecomments + - discard it if we're doing internal mode + "" swap 0 internalmode maybecatstr + swap + catstr catstr + ; +: ENDDD external ; +: SECTION ignore ; +: SUBSECTION ignore ; +: SUBSUBSECTION ignore ; +: INTERNAL_DEFINITION internal ; +: DESCRIPTION ignore ; +: FUNCTION external ; +: RETURNS ignore ; +: TYPEDEF external ; +: INTERNAL_FUNCTION internal ; +: INTERNAL internal ; +: INODE ignore ; Index: cache.texi =================================================================== --- cache.texi (nonexistent) +++ cache.texi (revision 1765) @@ -0,0 +1,95 @@ +@section File caching +The file caching mechanism is embedded within BFD and allows +the application to open as many BFDs as it wants without +regard to the underlying operating system's file descriptor +limit (often as low as 20 open files). The module in +@code{cache.c} maintains a least recently used list of +@code{BFD_CACHE_MAX_OPEN} files, and exports the name +@code{bfd_cache_lookup}, which runs around and makes sure that +the required BFD is open. If not, then it chooses a file to +close, closes it and opens the one wanted, returning its file +handle. + +@findex BFD_CACHE_MAX_OPEN macro +@subsubsection @code{BFD_CACHE_MAX_OPEN macro} +@strong{Description}@* +The maximum number of files which the cache will keep open at +one time. +@example +#define BFD_CACHE_MAX_OPEN 10 +@end example + +@findex bfd_last_cache +@subsubsection @code{bfd_last_cache} +@strong{Synopsis} +@example +extern bfd *bfd_last_cache; +@end example +@strong{Description}@* +Zero, or a pointer to the topmost BFD on the chain. This is +used by the @code{bfd_cache_lookup} macro in @file{libbfd.h} to +determine when it can avoid a function call. + +@findex bfd_cache_lookup +@subsubsection @code{bfd_cache_lookup} +@strong{Description}@* +Check to see if the required BFD is the same as the last one +looked up. If so, then it can use the stream in the BFD with +impunity, since it can't have changed since the last lookup; +otherwise, it has to perform the complicated lookup function. +@example +#define bfd_cache_lookup(x) \ + ((x)==bfd_last_cache? \ + (FILE*)(bfd_last_cache->iostream): \ + bfd_cache_lookup_worker(x)) +@end example + +@findex bfd_cache_init +@subsubsection @code{bfd_cache_init} +@strong{Synopsis} +@example +boolean bfd_cache_init (bfd *abfd); +@end example +@strong{Description}@* +Add a newly opened BFD to the cache. + +@findex bfd_cache_close +@subsubsection @code{bfd_cache_close} +@strong{Synopsis} +@example +boolean bfd_cache_close (bfd *abfd); +@end example +@strong{Description}@* +Remove the BFD @var{abfd} from the cache. If the attached file is open, +then close it too. + +@strong{Returns}@* +@code{false} is returned if closing the file fails, @code{true} is +returned if all is well. + +@findex bfd_open_file +@subsubsection @code{bfd_open_file} +@strong{Synopsis} +@example +FILE* bfd_open_file(bfd *abfd); +@end example +@strong{Description}@* +Call the OS to open a file for @var{abfd}. Return the @code{FILE *} +(possibly @code{NULL}) that results from this operation. Set up the +BFD so that future accesses know the file is open. If the @code{FILE *} +returned is @code{NULL}, then it won't have been put in the +cache, so it won't have to be removed from it. + +@findex bfd_cache_lookup_worker +@subsubsection @code{bfd_cache_lookup_worker} +@strong{Synopsis} +@example +FILE *bfd_cache_lookup_worker(bfd *abfd); +@end example +@strong{Description}@* +Called when the macro @code{bfd_cache_lookup} fails to find a +quick answer. Find a file descriptor for @var{abfd}. If +necessary, it open it. If there are already more than +@code{BFD_CACHE_MAX_OPEN} files open, it tries to close one first, to +avoid running out of file descriptors. + Index: section.texi =================================================================== --- section.texi (nonexistent) +++ section.texi (revision 1765) @@ -0,0 +1,717 @@ +@section Sections +The raw data contained within a BFD is maintained through the +section abstraction. A single BFD may have any number of +sections. It keeps hold of them by pointing to the first; +each one points to the next in the list. + +Sections are supported in BFD in @code{section.c}. + +@menu +* Section Input:: +* Section Output:: +* typedef asection:: +* section prototypes:: +@end menu + +@node Section Input, Section Output, Sections, Sections +@subsection Section input +When a BFD is opened for reading, the section structures are +created and attached to the BFD. + +Each section has a name which describes the section in the +outside world---for example, @code{a.out} would contain at least +three sections, called @code{.text}, @code{.data} and @code{.bss}. + +Names need not be unique; for example a COFF file may have several +sections named @code{.data}. + +Sometimes a BFD will contain more than the ``natural'' number of +sections. A back end may attach other sections containing +constructor data, or an application may add a section (using +@code{bfd_make_section}) to the sections attached to an already open +BFD. For example, the linker creates an extra section +@code{COMMON} for each input file's BFD to hold information about +common storage. + +The raw data is not necessarily read in when +the section descriptor is created. Some targets may leave the +data in place until a @code{bfd_get_section_contents} call is +made. Other back ends may read in all the data at once. For +example, an S-record file has to be read once to determine the +size of the data. An IEEE-695 file doesn't contain raw data in +sections, but data and relocation expressions intermixed, so +the data area has to be parsed to get out the data and +relocations. + +@node Section Output, typedef asection, Section Input, Sections +@subsection Section output +To write a new object style BFD, the various sections to be +written have to be created. They are attached to the BFD in +the same way as input sections; data is written to the +sections using @code{bfd_set_section_contents}. + +Any program that creates or combines sections (e.g., the assembler +and linker) must use the @code{asection} fields @code{output_section} and +@code{output_offset} to indicate the file sections to which each +section must be written. (If the section is being created from +scratch, @code{output_section} should probably point to the section +itself and @code{output_offset} should probably be zero.) + +The data to be written comes from input sections attached +(via @code{output_section} pointers) to +the output sections. The output section structure can be +considered a filter for the input section: the output section +determines the vma of the output data and the name, but the +input section determines the offset into the output section of +the data to be written. + +E.g., to create a section "O", starting at 0x100, 0x123 long, +containing two subsections, "A" at offset 0x0 (i.e., at vma +0x100) and "B" at offset 0x20 (i.e., at vma 0x120) the @code{asection} +structures would look like: + +@example + section name "A" + output_offset 0x00 + size 0x20 + output_section -----------> section name "O" + | vma 0x100 + section name "B" | size 0x123 + output_offset 0x20 | + size 0x103 | + output_section --------| +@end example + +@subsection Link orders +The data within a section is stored in a @dfn{link_order}. +These are much like the fixups in @code{gas}. The link_order +abstraction allows a section to grow and shrink within itself. + +A link_order knows how big it is, and which is the next +link_order and where the raw data for it is; it also points to +a list of relocations which apply to it. + +The link_order is used by the linker to perform relaxing on +final code. The compiler creates code which is as big as +necessary to make it work without relaxing, and the user can +select whether to relax. Sometimes relaxing takes a lot of +time. The linker runs around the relocations to see if any +are attached to data which can be shrunk, if so it does it on +a link_order by link_order basis. + + +@node typedef asection, section prototypes, Section Output, Sections +@subsection typedef asection +Here is the section structure: + + +@example + + /* This structure is used for a comdat section, as in PE. A comdat + section is associated with a particular symbol. When the linker + sees a comdat section, it keeps only one of the sections with a + given name and associated with a given symbol. */ + +struct bfd_comdat_info +@{ + /* The name of the symbol associated with a comdat section. */ + const char *name; + + /* The local symbol table index of the symbol associated with a + comdat section. This is only meaningful to the object file format + specific code; it is not an index into the list returned by + bfd_canonicalize_symtab. */ + long symbol; + + /* If this section is being discarded, the linker uses this field + to point to the input section which is being kept. */ + struct sec *sec; +@}; + +typedef struct sec +@{ + /* The name of the section; the name isn't a copy, the pointer is + the same as that passed to bfd_make_section. */ + + CONST char *name; + + /* Which section is it; 0..nth. */ + + int index; + + /* The next section in the list belonging to the BFD, or NULL. */ + + struct sec *next; + + /* The field flags contains attributes of the section. Some + flags are read in from the object file, and some are + synthesized from other information. */ + + flagword flags; + +#define SEC_NO_FLAGS 0x000 + + /* Tells the OS to allocate space for this section when loading. + This is clear for a section containing debug information + only. */ +#define SEC_ALLOC 0x001 + + /* Tells the OS to load the section from the file when loading. + This is clear for a .bss section. */ +#define SEC_LOAD 0x002 + + /* The section contains data still to be relocated, so there is + some relocation information too. */ +#define SEC_RELOC 0x004 + +#if 0 /* Obsolete ? */ +#define SEC_BALIGN 0x008 +#endif + + /* A signal to the OS that the section contains read only + data. */ +#define SEC_READONLY 0x010 + + /* The section contains code only. */ +#define SEC_CODE 0x020 + + /* The section contains data only. */ +#define SEC_DATA 0x040 + + /* The section will reside in ROM. */ +#define SEC_ROM 0x080 + + /* The section contains constructor information. This section + type is used by the linker to create lists of constructors and + destructors used by @code{g++}. When a back end sees a symbol + which should be used in a constructor list, it creates a new + section for the type of name (e.g., @code{__CTOR_LIST__}), attaches + the symbol to it, and builds a relocation. To build the lists + of constructors, all the linker has to do is catenate all the + sections called @code{__CTOR_LIST__} and relocate the data + contained within - exactly the operations it would peform on + standard data. */ +#define SEC_CONSTRUCTOR 0x100 + + /* The section is a constructor, and should be placed at the + end of the text, data, or bss section(?). */ +#define SEC_CONSTRUCTOR_TEXT 0x1100 +#define SEC_CONSTRUCTOR_DATA 0x2100 +#define SEC_CONSTRUCTOR_BSS 0x3100 + + /* The section has contents - a data section could be + @code{SEC_ALLOC} | @code{SEC_HAS_CONTENTS}; a debug section could be + @code{SEC_HAS_CONTENTS} */ +#define SEC_HAS_CONTENTS 0x200 + + /* An instruction to the linker to not output the section + even if it has information which would normally be written. */ +#define SEC_NEVER_LOAD 0x400 + + /* The section is a COFF shared library section. This flag is + only for the linker. If this type of section appears in + the input file, the linker must copy it to the output file + without changing the vma or size. FIXME: Although this + was originally intended to be general, it really is COFF + specific (and the flag was renamed to indicate this). It + might be cleaner to have some more general mechanism to + allow the back end to control what the linker does with + sections. */ +#define SEC_COFF_SHARED_LIBRARY 0x800 + + /* The section contains common symbols (symbols may be defined + multiple times, the value of a symbol is the amount of + space it requires, and the largest symbol value is the one + used). Most targets have exactly one of these (which we + translate to bfd_com_section_ptr), but ECOFF has two. */ +#define SEC_IS_COMMON 0x8000 + + /* The section contains only debugging information. For + example, this is set for ELF .debug and .stab sections. + strip tests this flag to see if a section can be + discarded. */ +#define SEC_DEBUGGING 0x10000 + + /* The contents of this section are held in memory pointed to + by the contents field. This is checked by + bfd_get_section_contents, and the data is retrieved from + memory if appropriate. */ +#define SEC_IN_MEMORY 0x20000 + + /* The contents of this section are to be excluded by the + linker for executable and shared objects unless those + objects are to be further relocated. */ +#define SEC_EXCLUDE 0x40000 + + /* The contents of this section are to be sorted by the + based on the address specified in the associated symbol + table. */ +#define SEC_SORT_ENTRIES 0x80000 + + /* When linking, duplicate sections of the same name should be + discarded, rather than being combined into a single section as + is usually done. This is similar to how common symbols are + handled. See SEC_LINK_DUPLICATES below. */ +#define SEC_LINK_ONCE 0x100000 + + /* If SEC_LINK_ONCE is set, this bitfield describes how the linker + should handle duplicate sections. */ +#define SEC_LINK_DUPLICATES 0x600000 + + /* This value for SEC_LINK_DUPLICATES means that duplicate + sections with the same name should simply be discarded. */ +#define SEC_LINK_DUPLICATES_DISCARD 0x0 + + /* This value for SEC_LINK_DUPLICATES means that the linker + should warn if there are any duplicate sections, although + it should still only link one copy. */ +#define SEC_LINK_DUPLICATES_ONE_ONLY 0x200000 + + /* This value for SEC_LINK_DUPLICATES means that the linker + should warn if any duplicate sections are a different size. */ +#define SEC_LINK_DUPLICATES_SAME_SIZE 0x400000 + + /* This value for SEC_LINK_DUPLICATES means that the linker + should warn if any duplicate sections contain different + contents. */ +#define SEC_LINK_DUPLICATES_SAME_CONTENTS 0x600000 + + /* This section was created by the linker as part of dynamic + relocation or other arcane processing. It is skipped when + going through the first-pass output, trusting that someone + else up the line will take care of it later. */ +#define SEC_LINKER_CREATED 0x800000 + + /* This section should not be subject to garbage collection. */ +#define SEC_KEEP 0x1000000 + + /* This section contains "short" data, and should be placed + "near" the GP. */ +#define SEC_SMALL_DATA 0x2000000 + + /* This section contains data which may be shared with other + executables or shared objects. */ +#define SEC_SHARED 0x4000000 + + /* When a section with this flag is being linked, then if the size of + the input section is less than a page, it should not cross a page + boundary. If the size of the input section is one page or more, it + should be aligned on a page boundary. */ +#define SEC_BLOCK 0x8000000 + + /* Conditionally link this section; do not link if there are no + references found to any symbol in the section. */ +#define SEC_CLINK 0x10000000 + + /* End of section flags. */ + + /* Some internal packed boolean fields. */ + + /* See the vma field. */ + unsigned int user_set_vma : 1; + + /* Whether relocations have been processed. */ + unsigned int reloc_done : 1; + + /* A mark flag used by some of the linker backends. */ + unsigned int linker_mark : 1; + + /* A mark flag used by some linker backends for garbage collection. */ + unsigned int gc_mark : 1; + + /* End of internal packed boolean fields. */ + + /* The virtual memory address of the section - where it will be + at run time. The symbols are relocated against this. The + user_set_vma flag is maintained by bfd; if it's not set, the + backend can assign addresses (for example, in @code{a.out}, where + the default address for @code{.data} is dependent on the specific + target and various flags). */ + + bfd_vma vma; + + /* The load address of the section - where it would be in a + rom image; really only used for writing section header + information. */ + + bfd_vma lma; + + /* The size of the section in octets, as it will be output. + Contains a value even if the section has no contents (e.g., the + size of @code{.bss}). This will be filled in after relocation. */ + + bfd_size_type _cooked_size; + + /* The original size on disk of the section, in octets. Normally this + value is the same as the size, but if some relaxing has + been done, then this value will be bigger. */ + + bfd_size_type _raw_size; + + /* If this section is going to be output, then this value is the + offset in *bytes* into the output section of the first byte in the + input section (byte ==> smallest addressable unit on the + target). In most cases, if this was going to start at the + 100th octet (8-bit quantity) in the output section, this value + would be 100. However, if the target byte size is 16 bits + (bfd_octets_per_byte is "2"), this value would be 50. */ + + bfd_vma output_offset; + + /* The output section through which to map on output. */ + + struct sec *output_section; + + /* The alignment requirement of the section, as an exponent of 2 - + e.g., 3 aligns to 2^3 (or 8). */ + + unsigned int alignment_power; + + /* If an input section, a pointer to a vector of relocation + records for the data in this section. */ + + struct reloc_cache_entry *relocation; + + /* If an output section, a pointer to a vector of pointers to + relocation records for the data in this section. */ + + struct reloc_cache_entry **orelocation; + + /* The number of relocation records in one of the above */ + + unsigned reloc_count; + + /* Information below is back end specific - and not always used + or updated. */ + + /* File position of section data */ + + file_ptr filepos; + + /* File position of relocation info */ + + file_ptr rel_filepos; + + /* File position of line data */ + + file_ptr line_filepos; + + /* Pointer to data for applications */ + + PTR userdata; + + /* If the SEC_IN_MEMORY flag is set, this points to the actual + contents. */ + unsigned char *contents; + + /* Attached line number information */ + + alent *lineno; + + /* Number of line number records */ + + unsigned int lineno_count; + + /* Optional information about a COMDAT entry; NULL if not COMDAT */ + + struct bfd_comdat_info *comdat; + + /* When a section is being output, this value changes as more + linenumbers are written out */ + + file_ptr moving_line_filepos; + + /* What the section number is in the target world */ + + int target_index; + + PTR used_by_bfd; + + /* If this is a constructor section then here is a list of the + relocations created to relocate items within it. */ + + struct relent_chain *constructor_chain; + + /* The BFD which owns the section. */ + + bfd *owner; + + /* A symbol which points at this section only */ + struct symbol_cache_entry *symbol; + struct symbol_cache_entry **symbol_ptr_ptr; + + struct bfd_link_order *link_order_head; + struct bfd_link_order *link_order_tail; +@} asection ; + + /* These sections are global, and are managed by BFD. The application + and target back end are not permitted to change the values in + these sections. New code should use the section_ptr macros rather + than referring directly to the const sections. The const sections + may eventually vanish. */ +#define BFD_ABS_SECTION_NAME "*ABS*" +#define BFD_UND_SECTION_NAME "*UND*" +#define BFD_COM_SECTION_NAME "*COM*" +#define BFD_IND_SECTION_NAME "*IND*" + + /* the absolute section */ +extern const asection bfd_abs_section; +#define bfd_abs_section_ptr ((asection *) &bfd_abs_section) +#define bfd_is_abs_section(sec) ((sec) == bfd_abs_section_ptr) + /* Pointer to the undefined section */ +extern const asection bfd_und_section; +#define bfd_und_section_ptr ((asection *) &bfd_und_section) +#define bfd_is_und_section(sec) ((sec) == bfd_und_section_ptr) + /* Pointer to the common section */ +extern const asection bfd_com_section; +#define bfd_com_section_ptr ((asection *) &bfd_com_section) + /* Pointer to the indirect section */ +extern const asection bfd_ind_section; +#define bfd_ind_section_ptr ((asection *) &bfd_ind_section) +#define bfd_is_ind_section(sec) ((sec) == bfd_ind_section_ptr) + +extern const struct symbol_cache_entry * const bfd_abs_symbol; +extern const struct symbol_cache_entry * const bfd_com_symbol; +extern const struct symbol_cache_entry * const bfd_und_symbol; +extern const struct symbol_cache_entry * const bfd_ind_symbol; +#define bfd_get_section_size_before_reloc(section) \ + ((section)->reloc_done ? (abort (), (bfd_size_type) 1) \ + : (section)->_raw_size) +#define bfd_get_section_size_after_reloc(section) \ + ((section)->reloc_done ? (section)->_cooked_size \ + : (abort (), (bfd_size_type) 1)) +@end example + +@node section prototypes, , typedef asection, Sections +@subsection Section prototypes +These are the functions exported by the section handling part of BFD. + +@findex bfd_get_section_by_name +@subsubsection @code{bfd_get_section_by_name} +@strong{Synopsis} +@example +asection *bfd_get_section_by_name(bfd *abfd, CONST char *name); +@end example +@strong{Description}@* +Run through @var{abfd} and return the one of the +@code{asection}s whose name matches @var{name}, otherwise @code{NULL}. +@xref{Sections}, for more information. + +This should only be used in special cases; the normal way to process +all sections of a given name is to use @code{bfd_map_over_sections} and +@code{strcmp} on the name (or better yet, base it on the section flags +or something else) for each section. + +@findex bfd_make_section_old_way +@subsubsection @code{bfd_make_section_old_way} +@strong{Synopsis} +@example +asection *bfd_make_section_old_way(bfd *abfd, CONST char *name); +@end example +@strong{Description}@* +Create a new empty section called @var{name} +and attach it to the end of the chain of sections for the +BFD @var{abfd}. An attempt to create a section with a name which +is already in use returns its pointer without changing the +section chain. + +It has the funny name since this is the way it used to be +before it was rewritten.... + +Possible errors are: +@itemize @bullet + +@item +@code{bfd_error_invalid_operation} - +If output has already started for this BFD. +@item +@code{bfd_error_no_memory} - +If memory allocation fails. +@end itemize + +@findex bfd_make_section_anyway +@subsubsection @code{bfd_make_section_anyway} +@strong{Synopsis} +@example +asection *bfd_make_section_anyway(bfd *abfd, CONST char *name); +@end example +@strong{Description}@* +Create a new empty section called @var{name} and attach it to the end of +the chain of sections for @var{abfd}. Create a new section even if there +is already a section with that name. + +Return @code{NULL} and set @code{bfd_error} on error; possible errors are: +@itemize @bullet + +@item +@code{bfd_error_invalid_operation} - If output has already started for @var{abfd}. +@item +@code{bfd_error_no_memory} - If memory allocation fails. +@end itemize + +@findex bfd_make_section +@subsubsection @code{bfd_make_section} +@strong{Synopsis} +@example +asection *bfd_make_section(bfd *, CONST char *name); +@end example +@strong{Description}@* +Like @code{bfd_make_section_anyway}, but return @code{NULL} (without calling +bfd_set_error ()) without changing the section chain if there is already a +section named @var{name}. If there is an error, return @code{NULL} and set +@code{bfd_error}. + +@findex bfd_set_section_flags +@subsubsection @code{bfd_set_section_flags} +@strong{Synopsis} +@example +boolean bfd_set_section_flags(bfd *abfd, asection *sec, flagword flags); +@end example +@strong{Description}@* +Set the attributes of the section @var{sec} in the BFD +@var{abfd} to the value @var{flags}. Return @code{true} on success, +@code{false} on error. Possible error returns are: + +@itemize @bullet + +@item +@code{bfd_error_invalid_operation} - +The section cannot have one or more of the attributes +requested. For example, a .bss section in @code{a.out} may not +have the @code{SEC_HAS_CONTENTS} field set. +@end itemize + +@findex bfd_map_over_sections +@subsubsection @code{bfd_map_over_sections} +@strong{Synopsis} +@example +void bfd_map_over_sections(bfd *abfd, + void (*func)(bfd *abfd, + asection *sect, + PTR obj), + PTR obj); +@end example +@strong{Description}@* +Call the provided function @var{func} for each section +attached to the BFD @var{abfd}, passing @var{obj} as an +argument. The function will be called as if by + +@example + func(abfd, the_section, obj); +@end example + +This is the prefered method for iterating over sections; an +alternative would be to use a loop: + +@example + section *p; + for (p = abfd->sections; p != NULL; p = p->next) + func(abfd, p, ...) +@end example + +@findex bfd_set_section_size +@subsubsection @code{bfd_set_section_size} +@strong{Synopsis} +@example +boolean bfd_set_section_size(bfd *abfd, asection *sec, bfd_size_type val); +@end example +@strong{Description}@* +Set @var{sec} to the size @var{val}. If the operation is +ok, then @code{true} is returned, else @code{false}. + +Possible error returns: +@itemize @bullet + +@item +@code{bfd_error_invalid_operation} - +Writing has started to the BFD, so setting the size is invalid. +@end itemize + +@findex bfd_set_section_contents +@subsubsection @code{bfd_set_section_contents} +@strong{Synopsis} +@example +boolean bfd_set_section_contents + (bfd *abfd, + asection *section, + PTR data, + file_ptr offset, + bfd_size_type count); +@end example +@strong{Description}@* +Sets the contents of the section @var{section} in BFD +@var{abfd} to the data starting in memory at @var{data}. The +data is written to the output section starting at offset +@var{offset} for @var{count} octets. + +Normally @code{true} is returned, else @code{false}. Possible error +returns are: +@itemize @bullet + +@item +@code{bfd_error_no_contents} - +The output section does not have the @code{SEC_HAS_CONTENTS} +attribute, so nothing can be written to it. +@item +and some more too +@end itemize +This routine is front end to the back end function +@code{_bfd_set_section_contents}. + +@findex bfd_get_section_contents +@subsubsection @code{bfd_get_section_contents} +@strong{Synopsis} +@example +boolean bfd_get_section_contents + (bfd *abfd, asection *section, PTR location, + file_ptr offset, bfd_size_type count); +@end example +@strong{Description}@* +Read data from @var{section} in BFD @var{abfd} +into memory starting at @var{location}. The data is read at an +offset of @var{offset} from the start of the input section, +and is read for @var{count} bytes. + +If the contents of a constructor with the @code{SEC_CONSTRUCTOR} +flag set are requested or if the section does not have the +@code{SEC_HAS_CONTENTS} flag set, then the @var{location} is filled +with zeroes. If no errors occur, @code{true} is returned, else +@code{false}. + +@findex bfd_copy_private_section_data +@subsubsection @code{bfd_copy_private_section_data} +@strong{Synopsis} +@example +boolean bfd_copy_private_section_data(bfd *ibfd, asection *isec, bfd *obfd, asection *osec); +@end example +@strong{Description}@* +Copy private section information from @var{isec} in the BFD +@var{ibfd} to the section @var{osec} in the BFD @var{obfd}. +Return @code{true} on success, @code{false} on error. Possible error +returns are: + +@itemize @bullet + +@item +@code{bfd_error_no_memory} - +Not enough memory exists to create private data for @var{osec}. +@end itemize +@example +#define bfd_copy_private_section_data(ibfd, isection, obfd, osection) \ + BFD_SEND (obfd, _bfd_copy_private_section_data, \ + (ibfd, isection, obfd, osection)) +@end example + +@findex _bfd_strip_section_from_output +@subsubsection @code{_bfd_strip_section_from_output} +@strong{Synopsis} +@example +void _bfd_strip_section_from_output + (struct bfd_link_info *info, asection *section); +@end example +@strong{Description}@* +Remove @var{section} from the output. If the output section +becomes empty, remove it from the output bfd. @var{info} may +be NULL; if it is not, it is used to decide whether the output +section is empty. + Index: elf.texi =================================================================== --- elf.texi (nonexistent) +++ elf.texi (revision 1765) @@ -0,0 +1,22 @@ +@section ELF backends +BFD support for ELF formats is being worked on. +Currently, the best supported back ends are for sparc and i386 +(running svr4 or Solaris 2). + +Documentation of the internals of the support code still needs +to be written. The code is changing quickly enough that we +haven't bothered yet. + +@findex bfd_elf_find_section +@subsubsection @code{bfd_elf_find_section} +@strong{Synopsis} +@example +struct elf_internal_shdr *bfd_elf_find_section (bfd *abfd, char *name); +@end example +@strong{Description}@* +Helper functions for GDB to locate the string tables. +Since BFD hides string tables from callers, GDB needs to use an +internal hook to find them. Sun's .stabstr, in particular, +isn't even pointed to by the .stab section, so ordinary +mechanisms wouldn't work to find it, even if we had some. + Index: bfdint.texi =================================================================== --- bfdint.texi (nonexistent) +++ bfdint.texi (revision 1765) @@ -0,0 +1,1885 @@ +\input texinfo +@setfilename bfdint.info + +@settitle BFD Internals +@iftex +@titlepage +@title{BFD Internals} +@author{Ian Lance Taylor} +@author{Cygnus Solutions} +@page +@end iftex + +@node Top +@top BFD Internals +@raisesections +@cindex bfd internals + +This document describes some BFD internal information which may be +helpful when working on BFD. It is very incomplete. + +This document is not updated regularly, and may be out of date. It was +last modified on $Date: 2001-05-18 11:00:59 $. + +The initial version of this document was written by Ian Lance Taylor +@email{ian@@cygnus.com}. + +@menu +* BFD overview:: BFD overview +* BFD guidelines:: BFD programming guidelines +* BFD target vector:: BFD target vector +* BFD generated files:: BFD generated files +* BFD multiple compilations:: Files compiled multiple times in BFD +* BFD relocation handling:: BFD relocation handling +* BFD ELF support:: BFD ELF support +* BFD glossary:: Glossary +* Index:: Index +@end menu + +@node BFD overview +@section BFD overview + +BFD is a library which provides a single interface to read and write +object files, executables, archive files, and core files in any format. + +@menu +* BFD library interfaces:: BFD library interfaces +* BFD library users:: BFD library users +* BFD view:: The BFD view of a file +* BFD blindness:: BFD loses information +@end menu + +@node BFD library interfaces +@subsection BFD library interfaces + +One way to look at the BFD library is to divide it into four parts by +type of interface. + +The first interface is the set of generic functions which programs using +the BFD library will call. These generic function normally translate +directly or indirectly into calls to routines which are specific to a +particular object file format. Many of these generic functions are +actually defined as macros in @file{bfd.h}. These functions comprise +the official BFD interface. + +The second interface is the set of functions which appear in the target +vectors. This is the bulk of the code in BFD. A target vector is a set +of function pointers specific to a particular object file format. The +target vector is used to implement the generic BFD functions. These +functions are always called through the target vector, and are never +called directly. The target vector is described in detail in @ref{BFD +target vector}. The set of functions which appear in a particular +target vector is often referred to as a BFD backend. + +The third interface is a set of oddball functions which are typically +specific to a particular object file format, are not generic functions, +and are called from outside of the BFD library. These are used as hooks +by the linker and the assembler when a particular object file format +requires some action which the BFD generic interface does not provide. +These functions are typically declared in @file{bfd.h}, but in many +cases they are only provided when BFD is configured with support for a +particular object file format. These functions live in a grey area, and +are not really part of the official BFD interface. + +The fourth interface is the set of BFD support functions which are +called by the other BFD functions. These manage issues like memory +allocation, error handling, file access, hash tables, swapping, and the +like. These functions are never called from outside of the BFD library. + +@node BFD library users +@subsection BFD library users + +Another way to look at the BFD library is to divide it into three parts +by the manner in which it is used. + +The first use is to read an object file. The object file readers are +programs like @samp{gdb}, @samp{nm}, @samp{objdump}, and @samp{objcopy}. +These programs use BFD to view an object file in a generic form. The +official BFD interface is normally fully adequate for these programs. + +The second use is to write an object file. The object file writers are +programs like @samp{gas} and @samp{objcopy}. These programs use BFD to +create an object file. The official BFD interface is normally adequate +for these programs, but for some object file formats the assembler needs +some additional hooks in order to set particular flags or other +information. The official BFD interface includes functions to copy +private information from one object file to another, and these functions +are used by @samp{objcopy} to avoid information loss. + +The third use is to link object files. There is only one object file +linker, @samp{ld}. Originally, @samp{ld} was an object file reader and +an object file writer, and it did the link operation using the generic +BFD structures. However, this turned out to be too slow and too memory +intensive. + +The official BFD linker functions were written to permit specific BFD +backends to perform the link without translating through the generic +structures, in the normal case where all the input files and output file +have the same object file format. Not all of the backends currently +implement the new interface, and there are default linking functions +within BFD which use the generic structures and which work with all +backends. + +For several object file formats the linker needs additional hooks which +are not provided by the official BFD interface, particularly for dynamic +linking support. These functions are typically called from the linker +emulation template. + +@node BFD view +@subsection The BFD view of a file + +BFD uses generic structures to manage information. It translates data +into the generic form when reading files, and out of the generic form +when writing files. + +BFD describes a file as a pointer to the @samp{bfd} type. A @samp{bfd} +is composed of the following elements. The BFD information can be +displayed using the @samp{objdump} program with various options. + +@table @asis +@item general information +The object file format, a few general flags, the start address. +@item architecture +The architecture, including both a general processor type (m68k, MIPS +etc.) and a specific machine number (m68000, R4000, etc.). +@item sections +A list of sections. +@item symbols +A symbol table. +@end table + +BFD represents a section as a pointer to the @samp{asection} type. Each +section has a name and a size. Most sections also have an associated +block of data, known as the section contents. Sections also have +associated flags, a virtual memory address, a load memory address, a +required alignment, a list of relocations, and other miscellaneous +information. + +BFD represents a relocation as a pointer to the @samp{arelent} type. A +relocation describes an action which the linker must take to modify the +section contents. Relocations have a symbol, an address, an addend, and +a pointer to a howto structure which describes how to perform the +relocation. For more information, see @ref{BFD relocation handling}. + +BFD represents a symbol as a pointer to the @samp{asymbol} type. A +symbol has a name, a pointer to a section, an offset within that +section, and some flags. + +Archive files do not have any sections or symbols. Instead, BFD +represents an archive file as a file which contains a list of +@samp{bfd}s. BFD also provides access to the archive symbol map, as a +list of symbol names. BFD provides a function to return the @samp{bfd} +within the archive which corresponds to a particular entry in the +archive symbol map. + +@node BFD blindness +@subsection BFD loses information + +Most object file formats have information which BFD can not represent in +its generic form, at least as currently defined. + +There is often explicit information which BFD can not represent. For +example, the COFF version stamp, or the ELF program segments. BFD +provides special hooks to handle this information when copying, +printing, or linking an object file. The BFD support for a particular +object file format will normally store this information in private data +and handle it using the special hooks. + +In some cases there is also implicit information which BFD can not +represent. For example, the MIPS processor distinguishes small and +large symbols, and requires that all small symbls be within 32K of the +GP register. This means that the MIPS assembler must be able to mark +variables as either small or large, and the MIPS linker must know to put +small symbols within range of the GP register. Since BFD can not +represent this information, this means that the assembler and linker +must have information that is specific to a particular object file +format which is outside of the BFD library. + +This loss of information indicates areas where the BFD paradigm breaks +down. It is not actually possible to represent the myriad differences +among object file formats using a single generic interface, at least not +in the manner which BFD does it today. + +Nevertheless, the BFD library does greatly simplify the task of dealing +with object files, and particular problems caused by information loss +can normally be solved using some sort of relatively constrained hook +into the library. + + + +@node BFD guidelines +@section BFD programming guidelines +@cindex bfd programming guidelines +@cindex programming guidelines for bfd +@cindex guidelines, bfd programming + +There is a lot of poorly written and confusing code in BFD. New BFD +code should be written to a higher standard. Merely because some BFD +code is written in a particular manner does not mean that you should +emulate it. + +Here are some general BFD programming guidelines: + +@itemize @bullet +@item +Follow the GNU coding standards. + +@item +Avoid global variables. We ideally want BFD to be fully reentrant, so +that it can be used in multiple threads. All uses of global or static +variables interfere with that. Initialized constant variables are OK, +and they should be explicitly marked with const. Instead of global +variables, use data attached to a BFD or to a linker hash table. + +@item +All externally visible functions should have names which start with +@samp{bfd_}. All such functions should be declared in some header file, +typically @file{bfd.h}. See, for example, the various declarations near +the end of @file{bfd-in.h}, which mostly declare functions required by +specific linker emulations. + +@item +All functions which need to be visible from one file to another within +BFD, but should not be visible outside of BFD, should start with +@samp{_bfd_}. Although external names beginning with @samp{_} are +prohibited by the ANSI standard, in practice this usage will always +work, and it is required by the GNU coding standards. + +@item +Always remember that people can compile using @samp{--enable-targets} to +build several, or all, targets at once. It must be possible to link +together the files for all targets. + +@item +BFD code should compile with few or no warnings using @samp{gcc -Wall}. +Some warnings are OK, like the absence of certain function declarations +which may or may not be declared in system header files. Warnings about +ambiguous expressions and the like should always be fixed. +@end itemize + +@node BFD target vector +@section BFD target vector +@cindex bfd target vector +@cindex target vector in bfd + +BFD supports multiple object file formats by using the @dfn{target +vector}. This is simply a set of function pointers which implement +behaviour that is specific to a particular object file format. + +In this section I list all of the entries in the target vector and +describe what they do. + +@menu +* BFD target vector miscellaneous:: Miscellaneous constants +* BFD target vector swap:: Swapping functions +* BFD target vector format:: Format type dependent functions +* BFD_JUMP_TABLE macros:: BFD_JUMP_TABLE macros +* BFD target vector generic:: Generic functions +* BFD target vector copy:: Copy functions +* BFD target vector core:: Core file support functions +* BFD target vector archive:: Archive functions +* BFD target vector symbols:: Symbol table functions +* BFD target vector relocs:: Relocation support +* BFD target vector write:: Output functions +* BFD target vector link:: Linker functions +* BFD target vector dynamic:: Dynamic linking information functions +@end menu + +@node BFD target vector miscellaneous +@subsection Miscellaneous constants + +The target vector starts with a set of constants. + +@table @samp +@item name +The name of the target vector. This is an arbitrary string. This is +how the target vector is named in command line options for tools which +use BFD, such as the @samp{-oformat} linker option. + +@item flavour +A general description of the type of target. The following flavours are +currently defined: + +@table @samp +@item bfd_target_unknown_flavour +Undefined or unknown. +@item bfd_target_aout_flavour +a.out. +@item bfd_target_coff_flavour +COFF. +@item bfd_target_ecoff_flavour +ECOFF. +@item bfd_target_elf_flavour +ELF. +@item bfd_target_ieee_flavour +IEEE-695. +@item bfd_target_nlm_flavour +NLM. +@item bfd_target_oasys_flavour +OASYS. +@item bfd_target_tekhex_flavour +Tektronix hex format. +@item bfd_target_srec_flavour +Motorola S-record format. +@item bfd_target_ihex_flavour +Intel hex format. +@item bfd_target_som_flavour +SOM (used on HP/UX). +@item bfd_target_os9k_flavour +os9000. +@item bfd_target_versados_flavour +VERSAdos. +@item bfd_target_msdos_flavour +MS-DOS. +@item bfd_target_evax_flavour +openVMS. +@end table + +@item byteorder +The byte order of data in the object file. One of +@samp{BFD_ENDIAN_BIG}, @samp{BFD_ENDIAN_LITTLE}, or +@samp{BFD_ENDIAN_UNKNOWN}. The latter would be used for a format such +as S-records which do not record the architecture of the data. + +@item header_byteorder +The byte order of header information in the object file. Normally the +same as the @samp{byteorder} field, but there are certain cases where it +may be different. + +@item object_flags +Flags which may appear in the @samp{flags} field of a BFD with this +format. + +@item section_flags +Flags which may appear in the @samp{flags} field of a section within a +BFD with this format. + +@item symbol_leading_char +A character which the C compiler normally puts before a symbol. For +example, an a.out compiler will typically generate the symbol +@samp{_foo} for a function named @samp{foo} in the C source, in which +case this field would be @samp{_}. If there is no such character, this +field will be @samp{0}. + +@item ar_pad_char +The padding character to use at the end of an archive name. Normally +@samp{/}. + +@item ar_max_namelen +The maximum length of a short name in an archive. Normally @samp{14}. + +@item backend_data +A pointer to constant backend data. This is used by backends to store +whatever additional information they need to distinguish similar target +vectors which use the same sets of functions. +@end table + +@node BFD target vector swap +@subsection Swapping functions + +Every target vector has fuction pointers used for swapping information +in and out of the target representation. There are two sets of +functions: one for data information, and one for header information. +Each set has three sizes: 64-bit, 32-bit, and 16-bit. Each size has +three actual functions: put, get unsigned, and get signed. + +These 18 functions are used to convert data between the host and target +representations. + +@node BFD target vector format +@subsection Format type dependent functions + +Every target vector has three arrays of function pointers which are +indexed by the BFD format type. The BFD format types are as follows: + +@table @samp +@item bfd_unknown +Unknown format. Not used for anything useful. +@item bfd_object +Object file. +@item bfd_archive +Archive file. +@item bfd_core +Core file. +@end table + +The three arrays of function pointers are as follows: + +@table @samp +@item bfd_check_format +Check whether the BFD is of a particular format (object file, archive +file, or core file) corresponding to this target vector. This is called +by the @samp{bfd_check_format} function when examining an existing BFD. +If the BFD matches the desired format, this function will initialize any +format specific information such as the @samp{tdata} field of the BFD. +This function must be called before any other BFD target vector function +on a file opened for reading. + +@item bfd_set_format +Set the format of a BFD which was created for output. This is called by +the @samp{bfd_set_format} function after creating the BFD with a +function such as @samp{bfd_openw}. This function will initialize format +specific information required to write out an object file or whatever of +the given format. This function must be called before any other BFD +target vector function on a file opened for writing. + +@item bfd_write_contents +Write out the contents of the BFD in the given format. This is called +by @samp{bfd_close} function for a BFD opened for writing. This really +should not be an array selected by format type, as the +@samp{bfd_set_format} function provides all the required information. +In fact, BFD will fail if a different format is used when calling +through the @samp{bfd_set_format} and the @samp{bfd_write_contents} +arrays; fortunately, since @samp{bfd_close} gets it right, this is a +difficult error to make. +@end table + +@node BFD_JUMP_TABLE macros +@subsection @samp{BFD_JUMP_TABLE} macros +@cindex @samp{BFD_JUMP_TABLE} + +Most target vectors are defined using @samp{BFD_JUMP_TABLE} macros. +These macros take a single argument, which is a prefix applied to a set +of functions. The macros are then used to initialize the fields in the +target vector. + +For example, the @samp{BFD_JUMP_TABLE_RELOCS} macro defines three +functions: @samp{_get_reloc_upper_bound}, @samp{_canonicalize_reloc}, +and @samp{_bfd_reloc_type_lookup}. A reference like +@samp{BFD_JUMP_TABLE_RELOCS (foo)} will expand into three functions +prefixed with @samp{foo}: @samp{foo_get_reloc_upper_found}, etc. The +@samp{BFD_JUMP_TABLE_RELOCS} macro will be placed such that those three +functions initialize the appropriate fields in the BFD target vector. + +This is done because it turns out that many different target vectors can +share certain classes of functions. For example, archives are similar +on most platforms, so most target vectors can use the same archive +functions. Those target vectors all use @samp{BFD_JUMP_TABLE_ARCHIVE} +with the same argument, calling a set of functions which is defined in +@file{archive.c}. + +Each of the @samp{BFD_JUMP_TABLE} macros is mentioned below along with +the description of the function pointers which it defines. The function +pointers will be described using the name without the prefix which the +@samp{BFD_JUMP_TABLE} macro defines. This name is normally the same as +the name of the field in the target vector structure. Any differences +will be noted. + +@node BFD target vector generic +@subsection Generic functions +@cindex @samp{BFD_JUMP_TABLE_GENERIC} + +The @samp{BFD_JUMP_TABLE_GENERIC} macro is used for some catch all +functions which don't easily fit into other categories. + +@table @samp +@item _close_and_cleanup +Free any target specific information associated with the BFD. This is +called when any BFD is closed (the @samp{bfd_write_contents} function +mentioned earlier is only called for a BFD opened for writing). Most +targets use @samp{bfd_alloc} to allocate all target specific +information, and therefore don't have to do anything in this function. +This function pointer is typically set to +@samp{_bfd_generic_close_and_cleanup}, which simply returns true. + +@item _bfd_free_cached_info +Free any cached information associated with the BFD which can be +recreated later if necessary. This is used to reduce the memory +consumption required by programs using BFD. This is normally called via +the @samp{bfd_free_cached_info} macro. It is used by the default +archive routines when computing the archive map. Most targets do not +do anything special for this entry point, and just set it to +@samp{_bfd_generic_free_cached_info}, which simply returns true. + +@item _new_section_hook +This is called from @samp{bfd_make_section_anyway} whenever a new +section is created. Most targets use it to initialize section specific +information. This function is called whether or not the section +corresponds to an actual section in an actual BFD. + +@item _get_section_contents +Get the contents of a section. This is called from +@samp{bfd_get_section_contents}. Most targets set this to +@samp{_bfd_generic_get_section_contents}, which does a @samp{bfd_seek} +based on the section's @samp{filepos} field and a @samp{bfd_read}. The +corresponding field in the target vector is named +@samp{_bfd_get_section_contents}. + +@item _get_section_contents_in_window +Set a @samp{bfd_window} to hold the contents of a section. This is +called from @samp{bfd_get_section_contents_in_window}. The +@samp{bfd_window} idea never really caught on, and I don't think this is +ever called. Pretty much all targets implement this as +@samp{bfd_generic_get_section_contents_in_window}, which uses +@samp{bfd_get_section_contents} to do the right thing. The +corresponding field in the target vector is named +@samp{_bfd_get_section_contents_in_window}. +@end table + +@node BFD target vector copy +@subsection Copy functions +@cindex @samp{BFD_JUMP_TABLE_COPY} + +The @samp{BFD_JUMP_TABLE_COPY} macro is used for functions which are +called when copying BFDs, and for a couple of functions which deal with +internal BFD information. + +@table @samp +@item _bfd_copy_private_bfd_data +This is called when copying a BFD, via @samp{bfd_copy_private_bfd_data}. +If the input and output BFDs have the same format, this will copy any +private information over. This is called after all the section contents +have been written to the output file. Only a few targets do anything in +this function. + +@item _bfd_merge_private_bfd_data +This is called when linking, via @samp{bfd_merge_private_bfd_data}. It +gives the backend linker code a chance to set any special flags in the +output file based on the contents of the input file. Only a few targets +do anything in this function. + +@item _bfd_copy_private_section_data +This is similar to @samp{_bfd_copy_private_bfd_data}, but it is called +for each section, via @samp{bfd_copy_private_section_data}. This +function is called before any section contents have been written. Only +a few targets do anything in this function. + +@item _bfd_copy_private_symbol_data +This is called via @samp{bfd_copy_private_symbol_data}, but I don't +think anything actually calls it. If it were defined, it could be used +to copy private symbol data from one BFD to another. However, most BFDs +store extra symbol information by allocating space which is larger than +the @samp{asymbol} structure and storing private information in the +extra space. Since @samp{objcopy} and other programs copy symbol +information by copying pointers to @samp{asymbol} structures, the +private symbol information is automatically copied as well. Most +targets do not do anything in this function. + +@item _bfd_set_private_flags +This is called via @samp{bfd_set_private_flags}. It is basically a hook +for the assembler to set magic information. For example, the PowerPC +ELF assembler uses it to set flags which appear in the e_flags field of +the ELF header. Most targets do not do anything in this function. + +@item _bfd_print_private_bfd_data +This is called by @samp{objdump} when the @samp{-p} option is used. It +is called via @samp{bfd_print_private_data}. It prints any interesting +information about the BFD which can not be otherwise represented by BFD +and thus can not be printed by @samp{objdump}. Most targets do not do +anything in this function. +@end table + +@node BFD target vector core +@subsection Core file support functions +@cindex @samp{BFD_JUMP_TABLE_CORE} + +The @samp{BFD_JUMP_TABLE_CORE} macro is used for functions which deal +with core files. Obviously, these functions only do something +interesting for targets which have core file support. + +@table @samp +@item _core_file_failing_command +Given a core file, this returns the command which was run to produce the +core file. + +@item _core_file_failing_signal +Given a core file, this returns the signal number which produced the +core file. + +@item _core_file_matches_executable_p +Given a core file and a BFD for an executable, this returns whether the +core file was generated by the executable. +@end table + +@node BFD target vector archive +@subsection Archive functions +@cindex @samp{BFD_JUMP_TABLE_ARCHIVE} + +The @samp{BFD_JUMP_TABLE_ARCHIVE} macro is used for functions which deal +with archive files. Most targets use COFF style archive files +(including ELF targets), and these use @samp{_bfd_archive_coff} as the +argument to @samp{BFD_JUMP_TABLE_ARCHIVE}. Some targets use BSD/a.out +style archives, and these use @samp{_bfd_archive_bsd}. (The main +difference between BSD and COFF archives is the format of the archive +symbol table). Targets with no archive support use +@samp{_bfd_noarchive}. Finally, a few targets have unusual archive +handling. + +@table @samp +@item _slurp_armap +Read in the archive symbol table, storing it in private BFD data. This +is normally called from the archive @samp{check_format} routine. The +corresponding field in the target vector is named +@samp{_bfd_slurp_armap}. + +@item _slurp_extended_name_table +Read in the extended name table from the archive, if there is one, +storing it in private BFD data. This is normally called from the +archive @samp{check_format} routine. The corresponding field in the +target vector is named @samp{_bfd_slurp_extended_name_table}. + +@item construct_extended_name_table +Build and return an extended name table if one is needed to write out +the archive. This also adjusts the archive headers to refer to the +extended name table appropriately. This is normally called from the +archive @samp{write_contents} routine. The corresponding field in the +target vector is named @samp{_bfd_construct_extended_name_table}. + +@item _truncate_arname +This copies a file name into an archive header, truncating it as +required. It is normally called from the archive @samp{write_contents} +routine. This function is more interesting in targets which do not +support extended name tables, but I think the GNU @samp{ar} program +always uses extended name tables anyhow. The corresponding field in the +target vector is named @samp{_bfd_truncate_arname}. + +@item _write_armap +Write out the archive symbol table using calls to @samp{bfd_write}. +This is normally called from the archive @samp{write_contents} routine. +The corresponding field in the target vector is named @samp{write_armap} +(no leading underscore). + +@item _read_ar_hdr +Read and parse an archive header. This handles expanding the archive +header name into the real file name using the extended name table. This +is called by routines which read the archive symbol table or the archive +itself. The corresponding field in the target vector is named +@samp{_bfd_read_ar_hdr_fn}. + +@item _openr_next_archived_file +Given an archive and a BFD representing a file stored within the +archive, return a BFD for the next file in the archive. This is called +via @samp{bfd_openr_next_archived_file}. The corresponding field in the +target vector is named @samp{openr_next_archived_file} (no leading +underscore). + +@item _get_elt_at_index +Given an archive and an index, return a BFD for the file in the archive +corresponding to that entry in the archive symbol table. This is called +via @samp{bfd_get_elt_at_index}. The corresponding field in the target +vector is named @samp{_bfd_get_elt_at_index}. + +@item _generic_stat_arch_elt +Do a stat on an element of an archive, returning information read from +the archive header (modification time, uid, gid, file mode, size). This +is called via @samp{bfd_stat_arch_elt}. The corresponding field in the +target vector is named @samp{_bfd_stat_arch_elt}. + +@item _update_armap_timestamp +After the entire contents of an archive have been written out, update +the timestamp of the archive symbol table to be newer than that of the +file. This is required for a.out style archives. This is normally +called by the archive @samp{write_contents} routine. The corresponding +field in the target vector is named @samp{_bfd_update_armap_timestamp}. +@end table + +@node BFD target vector symbols +@subsection Symbol table functions +@cindex @samp{BFD_JUMP_TABLE_SYMBOLS} + +The @samp{BFD_JUMP_TABLE_SYMBOLS} macro is used for functions which deal +with symbols. + +@table @samp +@item _get_symtab_upper_bound +Return a sensible upper bound on the amount of memory which will be +required to read the symbol table. In practice most targets return the +amount of memory required to hold @samp{asymbol} pointers for all the +symbols plus a trailing @samp{NULL} entry, and store the actual symbol +information in BFD private data. This is called via +@samp{bfd_get_symtab_upper_bound}. The corresponding field in the +target vector is named @samp{_bfd_get_symtab_upper_bound}. + +@item _get_symtab +Read in the symbol table. This is called via +@samp{bfd_canonicalize_symtab}. The corresponding field in the target +vector is named @samp{_bfd_canonicalize_symtab}. + +@item _make_empty_symbol +Create an empty symbol for the BFD. This is needed because most targets +store extra information with each symbol by allocating a structure +larger than an @samp{asymbol} and storing the extra information at the +end. This function will allocate the right amount of memory, and return +what looks like a pointer to an empty @samp{asymbol}. This is called +via @samp{bfd_make_empty_symbol}. The corresponding field in the target +vector is named @samp{_bfd_make_empty_symbol}. + +@item _print_symbol +Print information about the symbol. This is called via +@samp{bfd_print_symbol}. One of the arguments indicates what sort of +information should be printed: + +@table @samp +@item bfd_print_symbol_name +Just print the symbol name. +@item bfd_print_symbol_more +Print the symbol name and some interesting flags. I don't think +anything actually uses this. +@item bfd_print_symbol_all +Print all information about the symbol. This is used by @samp{objdump} +when run with the @samp{-t} option. +@end table +The corresponding field in the target vector is named +@samp{_bfd_print_symbol}. + +@item _get_symbol_info +Return a standard set of information about the symbol. This is called +via @samp{bfd_symbol_info}. The corresponding field in the target +vector is named @samp{_bfd_get_symbol_info}. + +@item _bfd_is_local_label_name +Return whether the given string would normally represent the name of a +local label. This is called via @samp{bfd_is_local_label} and +@samp{bfd_is_local_label_name}. Local labels are normally discarded by +the assembler. In the linker, this defines the difference between the +@samp{-x} and @samp{-X} options. + +@item _get_lineno +Return line number information for a symbol. This is only meaningful +for a COFF target. This is called when writing out COFF line numbers. + +@item _find_nearest_line +Given an address within a section, use the debugging information to find +the matching file name, function name, and line number, if any. This is +called via @samp{bfd_find_nearest_line}. The corresponding field in the +target vector is named @samp{_bfd_find_nearest_line}. + +@item _bfd_make_debug_symbol +Make a debugging symbol. This is only meaningful for a COFF target, +where it simply returns a symbol which will be placed in the +@samp{N_DEBUG} section when it is written out. This is called via +@samp{bfd_make_debug_symbol}. + +@item _read_minisymbols +Minisymbols are used to reduce the memory requirements of programs like +@samp{nm}. A minisymbol is a cookie pointing to internal symbol +information which the caller can use to extract complete symbol +information. This permits BFD to not convert all the symbols into +generic form, but to instead convert them one at a time. This is called +via @samp{bfd_read_minisymbols}. Most targets do not implement this, +and just use generic support which is based on using standard +@samp{asymbol} structures. + +@item _minisymbol_to_symbol +Convert a minisymbol to a standard @samp{asymbol}. This is called via +@samp{bfd_minisymbol_to_symbol}. +@end table + +@node BFD target vector relocs +@subsection Relocation support +@cindex @samp{BFD_JUMP_TABLE_RELOCS} + +The @samp{BFD_JUMP_TABLE_RELOCS} macro is used for functions which deal +with relocations. + +@table @samp +@item _get_reloc_upper_bound +Return a sensible upper bound on the amount of memory which will be +required to read the relocations for a section. In practice most +targets return the amount of memory required to hold @samp{arelent} +pointers for all the relocations plus a trailing @samp{NULL} entry, and +store the actual relocation information in BFD private data. This is +called via @samp{bfd_get_reloc_upper_bound}. + +@item _canonicalize_reloc +Return the relocation information for a section. This is called via +@samp{bfd_canonicalize_reloc}. The corresponding field in the target +vector is named @samp{_bfd_canonicalize_reloc}. + +@item _bfd_reloc_type_lookup +Given a relocation code, return the corresponding howto structure +(@pxref{BFD relocation codes}). This is called via +@samp{bfd_reloc_type_lookup}. The corresponding field in the target +vector is named @samp{reloc_type_lookup}. +@end table + +@node BFD target vector write +@subsection Output functions +@cindex @samp{BFD_JUMP_TABLE_WRITE} + +The @samp{BFD_JUMP_TABLE_WRITE} macro is used for functions which deal +with writing out a BFD. + +@table @samp +@item _set_arch_mach +Set the architecture and machine number for a BFD. This is called via +@samp{bfd_set_arch_mach}. Most targets implement this by calling +@samp{bfd_default_set_arch_mach}. The corresponding field in the target +vector is named @samp{_bfd_set_arch_mach}. + +@item _set_section_contents +Write out the contents of a section. This is called via +@samp{bfd_set_section_contents}. The corresponding field in the target +vector is named @samp{_bfd_set_section_contents}. +@end table + +@node BFD target vector link +@subsection Linker functions +@cindex @samp{BFD_JUMP_TABLE_LINK} + +The @samp{BFD_JUMP_TABLE_LINK} macro is used for functions called by the +linker. + +@table @samp +@item _sizeof_headers +Return the size of the header information required for a BFD. This is +used to implement the @samp{SIZEOF_HEADERS} linker script function. It +is normally used to align the first section at an efficient position on +the page. This is called via @samp{bfd_sizeof_headers}. The +corresponding field in the target vector is named +@samp{_bfd_sizeof_headers}. + +@item _bfd_get_relocated_section_contents +Read the contents of a section and apply the relocation information. +This handles both a final link and a relocateable link; in the latter +case, it adjust the relocation information as well. This is called via +@samp{bfd_get_relocated_section_contents}. Most targets implement it by +calling @samp{bfd_generic_get_relocated_section_contents}. + +@item _bfd_relax_section +Try to use relaxation to shrink the size of a section. This is called +by the linker when the @samp{-relax} option is used. This is called via +@samp{bfd_relax_section}. Most targets do not support any sort of +relaxation. + +@item _bfd_link_hash_table_create +Create the symbol hash table to use for the linker. This linker hook +permits the backend to control the size and information of the elements +in the linker symbol hash table. This is called via +@samp{bfd_link_hash_table_create}. + +@item _bfd_link_add_symbols +Given an object file or an archive, add all symbols into the linker +symbol hash table. Use callbacks to the linker to include archive +elements in the link. This is called via @samp{bfd_link_add_symbols}. + +@item _bfd_final_link +Finish the linking process. The linker calls this hook after all of the +input files have been read, when it is ready to finish the link and +generate the output file. This is called via @samp{bfd_final_link}. + +@item _bfd_link_split_section +I don't know what this is for. Nothing seems to call it. The only +non-trivial definition is in @file{som.c}. +@end table + +@node BFD target vector dynamic +@subsection Dynamic linking information functions +@cindex @samp{BFD_JUMP_TABLE_DYNAMIC} + +The @samp{BFD_JUMP_TABLE_DYNAMIC} macro is used for functions which read +dynamic linking information. + +@table @samp +@item _get_dynamic_symtab_upper_bound +Return a sensible upper bound on the amount of memory which will be +required to read the dynamic symbol table. In practice most targets +return the amount of memory required to hold @samp{asymbol} pointers for +all the symbols plus a trailing @samp{NULL} entry, and store the actual +symbol information in BFD private data. This is called via +@samp{bfd_get_dynamic_symtab_upper_bound}. The corresponding field in +the target vector is named @samp{_bfd_get_dynamic_symtab_upper_bound}. + +@item _canonicalize_dynamic_symtab +Read the dynamic symbol table. This is called via +@samp{bfd_canonicalize_dynamic_symtab}. The corresponding field in the +target vector is named @samp{_bfd_canonicalize_dynamic_symtab}. + +@item _get_dynamic_reloc_upper_bound +Return a sensible upper bound on the amount of memory which will be +required to read the dynamic relocations. In practice most targets +return the amount of memory required to hold @samp{arelent} pointers for +all the relocations plus a trailing @samp{NULL} entry, and store the +actual relocation information in BFD private data. This is called via +@samp{bfd_get_dynamic_reloc_upper_bound}. The corresponding field in +the target vector is named @samp{_bfd_get_dynamic_reloc_upper_bound}. + +@item _canonicalize_dynamic_reloc +Read the dynamic relocations. This is called via +@samp{bfd_canonicalize_dynamic_reloc}. The corresponding field in the +target vector is named @samp{_bfd_canonicalize_dynamic_reloc}. +@end table + +@node BFD generated files +@section BFD generated files +@cindex generated files in bfd +@cindex bfd generated files + +BFD contains several automatically generated files. This section +describes them. Some files are created at configure time, when you +configure BFD. Some files are created at make time, when you build +time. Some files are automatically rebuilt at make time, but only if +you configure with the @samp{--enable-maintainer-mode} option. Some +files live in the object directory---the directory from which you run +configure---and some live in the source directory. All files that live +in the source directory are checked into the CVS repository. + +@table @file +@item bfd.h +@cindex @file{bfd.h} +@cindex @file{bfd-in3.h} +Lives in the object directory. Created at make time from +@file{bfd-in2.h} via @file{bfd-in3.h}. @file{bfd-in3.h} is created at +configure time from @file{bfd-in2.h}. There are automatic dependencies +to rebuild @file{bfd-in3.h} and hence @file{bfd.h} if @file{bfd-in2.h} +changes, so you can normally ignore @file{bfd-in3.h}, and just think +about @file{bfd-in2.h} and @file{bfd.h}. + +@file{bfd.h} is built by replacing a few strings in @file{bfd-in2.h}. +To see them, search for @samp{@@} in @file{bfd-in2.h}. They mainly +control whether BFD is built for a 32 bit target or a 64 bit target. + +@item bfd-in2.h +@cindex @file{bfd-in2.h} +Lives in the source directory. Created from @file{bfd-in.h} and several +other BFD source files. If you configure with the +@samp{--enable-maintainer-mode} option, @file{bfd-in2.h} is rebuilt +automatically when a source file changes. + +@item elf32-target.h +@itemx elf64-target.h +@cindex @file{elf32-target.h} +@cindex @file{elf64-target.h} +Live in the object directory. Created from @file{elfxx-target.h}. +These files are versions of @file{elfxx-target.h} customized for either +a 32 bit ELF target or a 64 bit ELF target. + +@item libbfd.h +@cindex @file{libbfd.h} +Lives in the source directory. Created from @file{libbfd-in.h} and +several other BFD source files. If you configure with the +@samp{--enable-maintainer-mode} option, @file{libbfd.h} is rebuilt +automatically when a source file changes. + +@item libcoff.h +@cindex @file{libcoff.h} +Lives in the source directory. Created from @file{libcoff-in.h} and +@file{coffcode.h}. If you configure with the +@samp{--enable-maintainer-mode} option, @file{libcoff.h} is rebuilt +automatically when a source file changes. + +@item targmatch.h +@cindex @file{targmatch.h} +Lives in the object directory. Created at make time from +@file{config.bfd}. This file is used to map configuration triplets into +BFD target vector variable names at run time. +@end table + +@node BFD multiple compilations +@section Files compiled multiple times in BFD +Several files in BFD are compiled multiple times. By this I mean that +there are header files which contain function definitions. These header +files are included by other files, and thus the functions are compiled +once per file which includes them. + +Preprocessor macros are used to control the compilation, so that each +time the files are compiled the resulting functions are slightly +different. Naturally, if they weren't different, there would be no +reason to compile them multiple times. + +This is a not a particularly good programming technique, and future BFD +work should avoid it. + +@itemize @bullet +@item +Since this technique is rarely used, even experienced C programmers find +it confusing. + +@item +It is difficult to debug programs which use BFD, since there is no way +to describe which version of a particular function you are looking at. + +@item +Programs which use BFD wind up incorporating two or more slightly +different versions of the same function, which wastes space in the +executable. + +@item +This technique is never required nor is it especially efficient. It is +always possible to use statically initialized structures holding +function pointers and magic constants instead. +@end itemize + +The following is a list of the files which are compiled multiple times. + +@table @file +@item aout-target.h +@cindex @file{aout-target.h} +Describes a few functions and the target vector for a.out targets. This +is used by individual a.out targets with different definitions of +@samp{N_TXTADDR} and similar a.out macros. + +@item aoutf1.h +@cindex @file{aoutf1.h} +Implements standard SunOS a.out files. In principle it supports 64 bit +a.out targets based on the preprocessor macro @samp{ARCH_SIZE}, but +since all known a.out targets are 32 bits, this code may or may not +work. This file is only included by a few other files, and it is +difficult to justify its existence. + +@item aoutx.h +@cindex @file{aoutx.h} +Implements basic a.out support routines. This file can be compiled for +either 32 or 64 bit support. Since all known a.out targets are 32 bits, +the 64 bit support may or may not work. I believe the original +intention was that this file would only be included by @samp{aout32.c} +and @samp{aout64.c}, and that other a.out targets would simply refer to +the functions it defined. Unfortunately, some other a.out targets +started including it directly, leading to a somewhat confused state of +affairs. + +@item coffcode.h +@cindex @file{coffcode.h} +Implements basic COFF support routines. This file is included by every +COFF target. It implements code which handles COFF magic numbers as +well as various hook functions called by the generic COFF functions in +@file{coffgen.c}. This file is controlled by a number of different +macros, and more are added regularly. + +@item coffswap.h +@cindex @file{coffswap.h} +Implements COFF swapping routines. This file is included by +@file{coffcode.h}, and thus by every COFF target. It implements the +routines which swap COFF structures between internal and external +format. The main control for this file is the external structure +definitions in the files in the @file{include/coff} directory. A COFF +target file will include one of those files before including +@file{coffcode.h} and thus @file{coffswap.h}. There are a few other +macros which affect @file{coffswap.h} as well, mostly describing whether +certain fields are present in the external structures. + +@item ecoffswap.h +@cindex @file{ecoffswap.h} +Implements ECOFF swapping routines. This is like @file{coffswap.h}, but +for ECOFF. It is included by the ECOFF target files (of which there are +only two). The control is the preprocessor macro @samp{ECOFF_32} or +@samp{ECOFF_64}. + +@item elfcode.h +@cindex @file{elfcode.h} +Implements ELF functions that use external structure definitions. This +file is included by two other files: @file{elf32.c} and @file{elf64.c}. +It is controlled by the @samp{ARCH_SIZE} macro which is defined to be +@samp{32} or @samp{64} before including it. The @samp{NAME} macro is +used internally to give the functions different names for the two target +sizes. + +@item elfcore.h +@cindex @file{elfcore.h} +Like @file{elfcode.h}, but for functions that are specific to ELF core +files. This is included only by @file{elfcode.h}. + +@item elflink.h +@cindex @file{elflink.h} +Like @file{elfcode.h}, but for functions used by the ELF linker. This +is included only by @file{elfcode.h}. + +@item elfxx-target.h +@cindex @file{elfxx-target.h} +This file is the source for the generated files @file{elf32-target.h} +and @file{elf64-target.h}, one of which is included by every ELF target. +It defines the ELF target vector. + +@item freebsd.h +@cindex @file{freebsd.h} +Presumably intended to be included by all FreeBSD targets, but in fact +there is only one such target, @samp{i386-freebsd}. This defines a +function used to set the right magic number for FreeBSD, as well as +various macros, and includes @file{aout-target.h}. + +@item netbsd.h +@cindex @file{netbsd.h} +Like @file{freebsd.h}, except that there are several files which include +it. + +@item nlm-target.h +@cindex @file{nlm-target.h} +Defines the target vector for a standard NLM target. + +@item nlmcode.h +@cindex @file{nlmcode.h} +Like @file{elfcode.h}, but for NLM targets. This is only included by +@file{nlm32.c} and @file{nlm64.c}, both of which define the macro +@samp{ARCH_SIZE} to an appropriate value. There are no 64 bit NLM +targets anyhow, so this is sort of useless. + +@item nlmswap.h +@cindex @file{nlmswap.h} +Like @file{coffswap.h}, but for NLM targets. This is included by each +NLM target, but I think it winds up compiling to the exact same code for +every target, and as such is fairly useless. + +@item peicode.h +@cindex @file{peicode.h} +Provides swapping routines and other hooks for PE targets. +@file{coffcode.h} will include this rather than @file{coffswap.h} for a +PE target. This defines PE specific versions of the COFF swapping +routines, and also defines some macros which control @file{coffcode.h} +itself. +@end table + +@node BFD relocation handling +@section BFD relocation handling +@cindex bfd relocation handling +@cindex relocations in bfd + +The handling of relocations is one of the more confusing aspects of BFD. +Relocation handling has been implemented in various different ways, all +somewhat incompatible, none perfect. + +@menu +* BFD relocation concepts:: BFD relocation concepts +* BFD relocation functions:: BFD relocation functions +* BFD relocation codes:: BFD relocation codes +* BFD relocation future:: BFD relocation future +@end menu + +@node BFD relocation concepts +@subsection BFD relocation concepts + +A relocation is an action which the linker must take when linking. It +describes a change to the contents of a section. The change is normally +based on the final value of one or more symbols. Relocations are +created by the assembler when it creates an object file. + +Most relocations are simple. A typical simple relocation is to set 32 +bits at a given offset in a section to the value of a symbol. This type +of relocation would be generated for code like @code{int *p = &i;} where +@samp{p} and @samp{i} are global variables. A relocation for the symbol +@samp{i} would be generated such that the linker would initialize the +area of memory which holds the value of @samp{p} to the value of the +symbol @samp{i}. + +Slightly more complex relocations may include an addend, which is a +constant to add to the symbol value before using it. In some cases a +relocation will require adding the symbol value to the existing contents +of the section in the object file. In others the relocation will simply +replace the contents of the section with the symbol value. Some +relocations are PC relative, so that the value to be stored in the +section is the difference between the value of a symbol and the final +address of the section contents. + +In general, relocations can be arbitrarily complex. For example, +relocations used in dynamic linking systems often require the linker to +allocate space in a different section and use the offset within that +section as the value to store. In the IEEE object file format, +relocations may involve arbitrary expressions. + +When doing a relocateable link, the linker may or may not have to do +anything with a relocation, depending upon the definition of the +relocation. Simple relocations generally do not require any special +action. + +@node BFD relocation functions +@subsection BFD relocation functions + +In BFD, each section has an array of @samp{arelent} structures. Each +structure has a pointer to a symbol, an address within the section, an +addend, and a pointer to a @samp{reloc_howto_struct} structure. The +howto structure has a bunch of fields describing the reloc, including a +type field. The type field is specific to the object file format +backend; none of the generic code in BFD examines it. + +Originally, the function @samp{bfd_perform_relocation} was supposed to +handle all relocations. In theory, many relocations would be simple +enough to be described by the fields in the howto structure. For those +that weren't, the howto structure included a @samp{special_function} +field to use as an escape. + +While this seems plausible, a look at @samp{bfd_perform_relocation} +shows that it failed. The function has odd special cases. Some of the +fields in the howto structure, such as @samp{pcrel_offset}, were not +adequately documented. + +The linker uses @samp{bfd_perform_relocation} to do all relocations when +the input and output file have different formats (e.g., when generating +S-records). The generic linker code, which is used by all targets which +do not define their own special purpose linker, uses +@samp{bfd_get_relocated_section_contents}, which for most targets turns +into a call to @samp{bfd_generic_get_relocated_section_contents}, which +calls @samp{bfd_perform_relocation}. So @samp{bfd_perform_relocation} +is still widely used, which makes it difficult to change, since it is +difficult to test all possible cases. + +The assembler used @samp{bfd_perform_relocation} for a while. This +turned out to be the wrong thing to do, since +@samp{bfd_perform_relocation} was written to handle relocations on an +existing object file, while the assembler needed to create relocations +in a new object file. The assembler was changed to use the new function +@samp{bfd_install_relocation} instead, and @samp{bfd_install_relocation} +was created as a copy of @samp{bfd_perform_relocation}. + +Unfortunately, the work did not progress any farther, so +@samp{bfd_install_relocation} remains a simple copy of +@samp{bfd_perform_relocation}, with all the odd special cases and +confusing code. This again is difficult to change, because again any +change can affect any assembler target, and so is difficult to test. + +The new linker, when using the same object file format for all input +files and the output file, does not convert relocations into +@samp{arelent} structures, so it can not use +@samp{bfd_perform_relocation} at all. Instead, users of the new linker +are expected to write a @samp{relocate_section} function which will +handle relocations in a target specific fashion. + +There are two helper functions for target specific relocation: +@samp{_bfd_final_link_relocate} and @samp{_bfd_relocate_contents}. +These functions use a howto structure, but they @emph{do not} use the +@samp{special_function} field. Since the functions are normally called +from target specific code, the @samp{special_function} field adds +little; any relocations which require special handling can be handled +without calling those functions. + +So, if you want to add a new target, or add a new relocation to an +existing target, you need to do the following: + +@itemize @bullet +@item +Make sure you clearly understand what the contents of the section should +look like after assembly, after a relocateable link, and after a final +link. Make sure you clearly understand the operations the linker must +perform during a relocateable link and during a final link. + +@item +Write a howto structure for the relocation. The howto structure is +flexible enough to represent any relocation which should be handled by +setting a contiguous bitfield in the destination to the value of a +symbol, possibly with an addend, possibly adding the symbol value to the +value already present in the destination. + +@item +Change the assembler to generate your relocation. The assembler will +call @samp{bfd_install_relocation}, so your howto structure has to be +able to handle that. You may need to set the @samp{special_function} +field to handle assembly correctly. Be careful to ensure that any code +you write to handle the assembler will also work correctly when doing a +relocateable link. For example, see @samp{bfd_elf_generic_reloc}. + +@item +Test the assembler. Consider the cases of relocation against an +undefined symbol, a common symbol, a symbol defined in the object file +in the same section, and a symbol defined in the object file in a +different section. These cases may not all be applicable for your +reloc. + +@item +If your target uses the new linker, which is recommended, add any +required handling to the target specific relocation function. In simple +cases this will just involve a call to @samp{_bfd_final_link_relocate} +or @samp{_bfd_relocate_contents}, depending upon the definition of the +relocation and whether the link is relocateable or not. + +@item +Test the linker. Test the case of a final link. If the relocation can +overflow, use a linker script to force an overflow and make sure the +error is reported correctly. Test a relocateable link, whether the +symbol is defined or undefined in the relocateable output. For both the +final and relocateable link, test the case when the symbol is a common +symbol, when the symbol looked like a common symbol but became a defined +symbol, when the symbol is defined in a different object file, and when +the symbol is defined in the same object file. + +@item +In order for linking to another object file format, such as S-records, +to work correctly, @samp{bfd_perform_relocation} has to do the right +thing for the relocation. You may need to set the +@samp{special_function} field to handle this correctly. Test this by +doing a link in which the output object file format is S-records. + +@item +Using the linker to generate relocateable output in a different object +file format is impossible in the general case, so you generally don't +have to worry about that. Linking input files of different object file +formats together is quite unusual, but if you're really dedicated you +may want to consider testing this case, both when the output object file +format is the same as your format, and when it is different. +@end itemize + +@node BFD relocation codes +@subsection BFD relocation codes + +BFD has another way of describing relocations besides the howto +structures described above: the enum @samp{bfd_reloc_code_real_type}. + +Every known relocation type can be described as a value in this +enumeration. The enumeration contains many target specific relocations, +but where two or more targets have the same relocation, a single code is +used. For example, the single value @samp{BFD_RELOC_32} is used for all +simple 32 bit relocation types. + +The main purpose of this relocation code is to give the assembler some +mechanism to create @samp{arelent} structures. In order for the +assembler to create an @samp{arelent} structure, it has to be able to +obtain a howto structure. The function @samp{bfd_reloc_type_lookup}, +which simply calls the target vector entry point +@samp{reloc_type_lookup}, takes a relocation code and returns a howto +structure. + +The function @samp{bfd_get_reloc_code_name} returns the name of a +relocation code. This is mainly used in error messages. + +Using both howto structures and relocation codes can be somewhat +confusing. There are many processor specific relocation codes. +However, the relocation is only fully defined by the howto structure. +The same relocation code will map to different howto structures in +different object file formats. For example, the addend handling may be +different. + +Most of the relocation codes are not really general. The assembler can +not use them without already understanding what sorts of relocations can +be used for a particular target. It might be possible to replace the +relocation codes with something simpler. + +@node BFD relocation future +@subsection BFD relocation future + +Clearly the current BFD relocation support is in bad shape. A +wholescale rewrite would be very difficult, because it would require +thorough testing of every BFD target. So some sort of incremental +change is required. + +My vague thoughts on this would involve defining a new, clearly defined, +howto structure. Some mechanism would be used to determine which type +of howto structure was being used by a particular format. + +The new howto structure would clearly define the relocation behaviour in +the case of an assembly, a relocateable link, and a final link. At +least one special function would be defined as an escape, and it might +make sense to define more. + +One or more generic functions similar to @samp{bfd_perform_relocation} +would be written to handle the new howto structure. + +This should make it possible to write a generic version of the relocate +section functions used by the new linker. The target specific code +would provide some mechanism (a function pointer or an initial +conversion) to convert target specific relocations into howto +structures. + +Ideally it would be possible to use this generic relocate section +function for the generic linker as well. That is, it would replace the +@samp{bfd_generic_get_relocated_section_contents} function which is +currently normally used. + +For the special case of ELF dynamic linking, more consideration needs to +be given to writing ELF specific but ELF target generic code to handle +special relocation types such as GOT and PLT. + +@node BFD ELF support +@section BFD ELF support +@cindex elf support in bfd +@cindex bfd elf support + +The ELF object file format is defined in two parts: a generic ABI and a +processor specific supplement. The ELF support in BFD is split in a +similar fashion. The processor specific support is largely kept within +a single file. The generic support is provided by several other files. +The processor specific support provides a set of function pointers and +constants used by the generic support. + +@menu +* BFD ELF sections and segments:: ELF sections and segments +* BFD ELF generic support:: BFD ELF generic support +* BFD ELF processor specific support:: BFD ELF processor specific support +* BFD ELF core files:: BFD ELF core files +* BFD ELF future:: BFD ELF future +@end menu + +@node BFD ELF sections and segments +@subsection ELF sections and segments + +The ELF ABI permits a file to have either sections or segments or both. +Relocateable object files conventionally have only sections. +Executables conventionally have both. Core files conventionally have +only program segments. + +ELF sections are similar to sections in other object file formats: they +have a name, a VMA, file contents, flags, and other miscellaneous +information. ELF relocations are stored in sections of a particular +type; BFD automatically converts these sections into internal relocation +information. + +ELF program segments are intended for fast interpretation by a system +loader. They have a type, a VMA, an LMA, file contents, and a couple of +other fields. When an ELF executable is run on a Unix system, the +system loader will examine the program segments to decide how to load +it. The loader will ignore the section information. Loadable program +segments (type @samp{PT_LOAD}) are directly loaded into memory. Other +program segments are interpreted by the loader, and generally provide +dynamic linking information. + +When an ELF file has both program segments and sections, an ELF program +segment may encompass one or more ELF sections, in the sense that the +portion of the file which corresponds to the program segment may include +the portions of the file corresponding to one or more sections. When +there is more than one section in a loadable program segment, the +relative positions of the section contents in the file must correspond +to the relative positions they should hold when the program segment is +loaded. This requirement should be obvious if you consider that the +system loader will load an entire program segment at a time. + +On a system which supports dynamic paging, such as any native Unix +system, the contents of a loadable program segment must be at the same +offset in the file as in memory, modulo the memory page size used on the +system. This is because the system loader will map the file into memory +starting at the start of a page. The system loader can easily remap +entire pages to the correct load address. However, if the contents of +the file were not correctly aligned within the page, the system loader +would have to shift the contents around within the page, which is too +expensive. For example, if the LMA of a loadable program segment is +@samp{0x40080} and the page size is @samp{0x1000}, then the position of +the segment contents within the file must equal @samp{0x80} modulo +@samp{0x1000}. + +BFD has only a single set of sections. It does not provide any generic +way to examine both sections and segments. When BFD is used to open an +object file or executable, the BFD sections will represent ELF sections. +When BFD is used to open a core file, the BFD sections will represent +ELF program segments. + +When BFD is used to examine an object file or executable, any program +segments will be read to set the LMA of the sections. This is because +ELF sections only have a VMA, while ELF program segments have both a VMA +and an LMA. Any program segments will be copied by the +@samp{copy_private} entry points. They will be printed by the +@samp{print_private} entry point. Otherwise, the program segments are +ignored. In particular, programs which use BFD currently have no direct +access to the program segments. + +When BFD is used to create an executable, the program segments will be +created automatically based on the section information. This is done in +the function @samp{assign_file_positions_for_segments} in @file{elf.c}. +This function has been tweaked many times, and probably still has +problems that arise in particular cases. + +There is a hook which may be used to explicitly define the program +segments when creating an executable: the @samp{bfd_record_phdr} +function in @file{bfd.c}. If this function is called, BFD will not +create program segments itself, but will only create the program +segments specified by the caller. The linker uses this function to +implement the @samp{PHDRS} linker script command. + +@node BFD ELF generic support +@subsection BFD ELF generic support + +In general, functions which do not read external data from the ELF file +are found in @file{elf.c}. They operate on the internal forms of the +ELF structures, which are defined in @file{include/elf/internal.h}. The +internal structures are defined in terms of @samp{bfd_vma}, and so may +be used for both 32 bit and 64 bit ELF targets. + +The file @file{elfcode.h} contains functions which operate on the +external data. @file{elfcode.h} is compiled twice, once via +@file{elf32.c} with @samp{ARCH_SIZE} defined as @samp{32}, and once via +@file{elf64.c} with @samp{ARCH_SIZE} defined as @samp{64}. +@file{elfcode.h} includes functions to swap the ELF structures in and +out of external form, as well as a few more complex functions. + +Linker support is found in @file{elflink.c} and @file{elflink.h}. The +latter file is compiled twice, for both 32 and 64 bit support. The +linker support is only used if the processor specific file defines +@samp{elf_backend_relocate_section}, which is required to relocate the +section contents. If that macro is not defined, the generic linker code +is used, and relocations are handled via @samp{bfd_perform_relocation}. + +The core file support is in @file{elfcore.h}, which is compiled twice, +for both 32 and 64 bit support. The more interesting cases of core file +support only work on a native system which has the @file{sys/procfs.h} +header file. Without that file, the core file support does little more +than read the ELF program segments as BFD sections. + +The BFD internal header file @file{elf-bfd.h} is used for communication +among these files and the processor specific files. + +The default entries for the BFD ELF target vector are found mainly in +@file{elf.c}. Some functions are found in @file{elfcode.h}. + +The processor specific files may override particular entries in the +target vector, but most do not, with one exception: the +@samp{bfd_reloc_type_lookup} entry point is always processor specific. + +@node BFD ELF processor specific support +@subsection BFD ELF processor specific support + +By convention, the processor specific support for a particular processor +will be found in @file{elf@var{nn}-@var{cpu}.c}, where @var{nn} is +either 32 or 64, and @var{cpu} is the name of the processor. + +@menu +* BFD ELF processor required:: Required processor specific support +* BFD ELF processor linker:: Processor specific linker support +* BFD ELF processor other:: Other processor specific support options +@end menu + +@node BFD ELF processor required +@subsubsection Required processor specific support + +When writing a @file{elf@var{nn}-@var{cpu}.c} file, you must do the +following: + +@itemize @bullet +@item +Define either @samp{TARGET_BIG_SYM} or @samp{TARGET_LITTLE_SYM}, or +both, to a unique C name to use for the target vector. This name should +appear in the list of target vectors in @file{targets.c}, and will also +have to appear in @file{config.bfd} and @file{configure.in}. Define +@samp{TARGET_BIG_SYM} for a big-endian processor, +@samp{TARGET_LITTLE_SYM} for a little-endian processor, and define both +for a bi-endian processor. +@item +Define either @samp{TARGET_BIG_NAME} or @samp{TARGET_LITTLE_NAME}, or +both, to a string used as the name of the target vector. This is the +name which a user of the BFD tool would use to specify the object file +format. It would normally appear in a linker emulation parameters +file. +@item +Define @samp{ELF_ARCH} to the BFD architecture (an element of the +@samp{bfd_architecture} enum, typically @samp{bfd_arch_@var{cpu}}). +@item +Define @samp{ELF_MACHINE_CODE} to the magic number which should appear +in the @samp{e_machine} field of the ELF header. As of this writing, +these magic numbers are assigned by SCO; if you want to get a magic +number for a particular processor, try sending a note to +@email{registry@@sco.com}. In the BFD sources, the magic numbers are +found in @file{include/elf/common.h}; they have names beginning with +@samp{EM_}. +@item +Define @samp{ELF_MAXPAGESIZE} to the maximum size of a virtual page in +memory. This can normally be found at the start of chapter 5 in the +processor specific supplement. For a processor which will only be used +in an embedded system, or which has no memory management hardware, this +can simply be @samp{1}. +@item +If the format should use @samp{Rel} rather than @samp{Rela} relocations, +define @samp{USE_REL}. This is normally defined in chapter 4 of the +processor specific supplement. + +In the absence of a supplement, it's easier to work with @samp{Rela} +relocations. @samp{Rela} relocations will require more space in object +files (but not in executables, except when using dynamic linking). +However, this is outweighed by the simplicity of addend handling when +using @samp{Rela} relocations. With @samp{Rel} relocations, the addend +must be stored in the section contents, which makes relocateable links +more complex. + +For example, consider C code like @code{i = a[1000];} where @samp{a} is +a global array. The instructions which load the value of @samp{a[1000]} +will most likely use a relocation which refers to the symbol +representing @samp{a}, with an addend that gives the offset from the +start of @samp{a} to element @samp{1000}. When using @samp{Rel} +relocations, that addend must be stored in the instructions themselves. +If you are adding support for a RISC chip which uses two or more +instructions to load an address, then the addend may not fit in a single +instruction, and will have to be somehow split among the instructions. +This makes linking awkward, particularly when doing a relocateable link +in which the addend may have to be updated. It can be done---the MIPS +ELF support does it---but it should be avoided when possible. + +It is possible, though somewhat awkward, to support both @samp{Rel} and +@samp{Rela} relocations for a single target; @file{elf64-mips.c} does it +by overriding the relocation reading and writing routines. +@item +Define howto structures for all the relocation types. +@item +Define a @samp{bfd_reloc_type_lookup} routine. This must be named +@samp{bfd_elf@var{nn}_bfd_reloc_type_lookup}, and may be either a +function or a macro. It must translate a BFD relocation code into a +howto structure. This is normally a table lookup or a simple switch. +@item +If using @samp{Rel} relocations, define @samp{elf_info_to_howto_rel}. +If using @samp{Rela} relocations, define @samp{elf_info_to_howto}. +Either way, this is a macro defined as the name of a function which +takes an @samp{arelent} and a @samp{Rel} or @samp{Rela} structure, and +sets the @samp{howto} field of the @samp{arelent} based on the +@samp{Rel} or @samp{Rela} structure. This is normally uses +@samp{ELF@var{nn}_R_TYPE} to get the ELF relocation type and uses it as +an index into a table of howto structures. +@end itemize + +You must also add the magic number for this processor to the +@samp{prep_headers} function in @file{elf.c}. + +You must also create a header file in the @file{include/elf} directory +called @file{@var{cpu}.h}. This file should define any target specific +information which may be needed outside of the BFD code. In particular +it should use the @samp{START_RELOC_NUMBERS}, @samp{RELOC_NUMBER}, +@samp{FAKE_RELOC}, @samp{EMPTY_RELOC} and @samp{END_RELOC_NUMBERS} +macros to create a table mapping the number used to indentify a +relocation to a name describing that relocation. + +@node BFD ELF processor linker +@subsubsection Processor specific linker support + +The linker will be much more efficient if you define a relocate section +function. This will permit BFD to use the ELF specific linker support. + +If you do not define a relocate section function, BFD must use the +generic linker support, which requires converting all symbols and +relocations into BFD @samp{asymbol} and @samp{arelent} structures. In +this case, relocations will be handled by calling +@samp{bfd_perform_relocation}, which will use the howto structures you +have defined. @xref{BFD relocation handling}. + +In order to support linking into a different object file format, such as +S-records, @samp{bfd_perform_relocation} must work correctly with your +howto structures, so you can't skip that step. However, if you define +the relocate section function, then in the normal case of linking into +an ELF file the linker will not need to convert symbols and relocations, +and will be much more efficient. + +To use a relocation section function, define the macro +@samp{elf_backend_relocate_section} as the name of a function which will +take the contents of a section, as well as relocation, symbol, and other +information, and modify the section contents according to the relocation +information. In simple cases, this is little more than a loop over the +relocations which computes the value of each relocation and calls +@samp{_bfd_final_link_relocate}. The function must check for a +relocateable link, and in that case normally needs to do nothing other +than adjust the addend for relocations against a section symbol. + +The complex cases generally have to do with dynamic linker support. GOT +and PLT relocations must be handled specially, and the linker normally +arranges to set up the GOT and PLT sections while handling relocations. +When generating a shared library, random relocations must normally be +copied into the shared library, or converted to RELATIVE relocations +when possible. + +@node BFD ELF processor other +@subsubsection Other processor specific support options + +There are many other macros which may be defined in +@file{elf@var{nn}-@var{cpu}.c}. These macros may be found in +@file{elfxx-target.h}. + +Macros may be used to override some of the generic ELF target vector +functions. + +Several processor specific hook functions which may be defined as +macros. These functions are found as function pointers in the +@samp{elf_backend_data} structure defined in @file{elf-bfd.h}. In +general, a hook function is set by defining a macro +@samp{elf_backend_@var{name}}. + +There are a few processor specific constants which may also be defined. +These are again found in the @samp{elf_backend_data} structure. + +I will not define the various functions and constants here; see the +comments in @file{elf-bfd.h}. + +Normally any odd characteristic of a particular ELF processor is handled +via a hook function. For example, the special @samp{SHN_MIPS_SCOMMON} +section number found in MIPS ELF is handled via the hooks +@samp{section_from_bfd_section}, @samp{symbol_processing}, +@samp{add_symbol_hook}, and @samp{output_symbol_hook}. + +Dynamic linking support, which involves processor specific relocations +requiring special handling, is also implemented via hook functions. + +@node BFD ELF core files +@subsection BFD ELF core files +@cindex elf core files + +On native ELF Unix systems, core files are generated without any +sections. Instead, they only have program segments. + +When BFD is used to read an ELF core file, the BFD sections will +actually represent program segments. Since ELF program segments do not +have names, BFD will invent names like @samp{segment@var{n}} where +@var{n} is a number. + +A single ELF program segment may include both an initialized part and an +uninitialized part. The size of the initialized part is given by the +@samp{p_filesz} field. The total size of the segment is given by the +@samp{p_memsz} field. If @samp{p_memsz} is larger than @samp{p_filesz}, +then the extra space is uninitialized, or, more precisely, initialized +to zero. + +BFD will represent such a program segment as two different sections. +The first, named @samp{segment@var{n}a}, will represent the initialized +part of the program segment. The second, named @samp{segment@var{n}b}, +will represent the uninitialized part. + +ELF core files store special information such as register values in +program segments with the type @samp{PT_NOTE}. BFD will attempt to +interpret the information in these segments, and will create additional +sections holding the information. Some of this interpretation requires +information found in the host header file @file{sys/procfs.h}, and so +will only work when BFD is built on a native system. + +BFD does not currently provide any way to create an ELF core file. In +general, BFD does not provide a way to create core files. The way to +implement this would be to write @samp{bfd_set_format} and +@samp{bfd_write_contents} routines for the @samp{bfd_core} type; see +@ref{BFD target vector format}. + +@node BFD ELF future +@subsection BFD ELF future + +The current dynamic linking support has too much code duplication. +While each processor has particular differences, much of the dynamic +linking support is quite similar for each processor. The GOT and PLT +are handled in fairly similar ways, the details of -Bsymbolic linking +are generally similar, etc. This code should be reworked to use more +generic functions, eliminating the duplication. + +Similarly, the relocation handling has too much duplication. Many of +the @samp{reloc_type_lookup} and @samp{info_to_howto} functions are +quite similar. The relocate section functions are also often quite +similar, both in the standard linker handling and the dynamic linker +handling. Many of the COFF processor specific backends share a single +relocate section function (@samp{_bfd_coff_generic_relocate_section}), +and it should be possible to do something like this for the ELF targets +as well. + +The appearance of the processor specific magic number in +@samp{prep_headers} in @file{elf.c} is somewhat bogus. It should be +possible to add support for a new processor without changing the generic +support. + +The processor function hooks and constants are ad hoc and need better +documentation. + +When a linker script uses @samp{SIZEOF_HEADERS}, the ELF backend must +guess at the number of program segments which will be required, in +@samp{get_program_header_size}. This is because the linker calls +@samp{bfd_sizeof_headers} before it knows all the section addresses and +sizes. The ELF backend may later discover, when creating program +segments, that more program segments are required. This is currently +reported as an error in @samp{assign_file_positions_for_segments}. + +In practice this makes it difficult to use @samp{SIZEOF_HEADERS} except +with a carefully defined linker script. Unfortunately, +@samp{SIZEOF_HEADERS} is required for fast program loading on a native +system, since it permits the initial code section to appear on the same +page as the program segments, saving a page read when the program starts +running. Fortunately, native systems permit careful definition of the +linker script. Still, ideally it would be possible to use relaxation to +compute the number of program segments. + +@node BFD glossary +@section BFD glossary +@cindex glossary for bfd +@cindex bfd glossary + +This is a short glossary of some BFD terms. + +@table @asis +@item a.out +The a.out object file format. The original Unix object file format. +Still used on SunOS, though not Solaris. Supports only three sections. + +@item archive +A collection of object files produced and manipulated by the @samp{ar} +program. + +@item backend +The implementation within BFD of a particular object file format. The +set of functions which appear in a particular target vector. + +@item BFD +The BFD library itself. Also, each object file, archive, or exectable +opened by the BFD library has the type @samp{bfd *}, and is sometimes +referred to as a bfd. + +@item COFF +The Common Object File Format. Used on Unix SVR3. Used by some +embedded targets, although ELF is normally better. + +@item DLL +A shared library on Windows. + +@item dynamic linker +When a program linked against a shared library is run, the dynamic +linker will locate the appropriate shared library and arrange to somehow +include it in the running image. + +@item dynamic object +Another name for an ELF shared library. + +@item ECOFF +The Extended Common Object File Format. Used on Alpha Digital Unix +(formerly OSF/1), as well as Ultrix and Irix 4. A variant of COFF. + +@item ELF +The Executable and Linking Format. The object file format used on most +modern Unix systems, including GNU/Linux, Solaris, Irix, and SVR4. Also +used on many embedded systems. + +@item executable +A program, with instructions and symbols, and perhaps dynamic linking +information. Normally produced by a linker. + +@item LMA +Load Memory Address. This is the address at which a section will be +loaded. Compare with VMA, below. + +@item NLM +NetWare Loadable Module. Used to describe the format of an object which +be loaded into NetWare, which is some kind of PC based network server +program. + +@item object file +A binary file including machine instructions, symbols, and relocation +information. Normally produced by an assembler. + +@item object file format +The format of an object file. Typically object files and executables +for a particular system are in the same format, although executables +will not contain any relocation information. + +@item PE +The Portable Executable format. This is the object file format used for +Windows (specifically, Win32) object files. It is based closely on +COFF, but has a few significant differences. + +@item PEI +The Portable Executable Image format. This is the object file format +used for Windows (specifically, Win32) executables. It is very similar +to PE, but includes some additional header information. + +@item relocations +Information used by the linker to adjust section contents. Also called +relocs. + +@item section +Object files and executable are composed of sections. Sections have +optional data and optional relocation information. + +@item shared library +A library of functions which may be used by many executables without +actually being linked into each executable. There are several different +implementations of shared libraries, each having slightly different +features. + +@item symbol +Each object file and executable may have a list of symbols, often +referred to as the symbol table. A symbol is basically a name and an +address. There may also be some additional information like the type of +symbol, although the type of a symbol is normally something simple like +function or object, and should be confused with the more complex C +notion of type. Typically every global function and variable in a C +program will have an associated symbol. + +@item target vector +A set of functions which implement support for a particular object file +format. The @samp{bfd_target} structure. + +@item Win32 +The current Windows API, implemented by Windows 95 and later and Windows +NT 3.51 and later, but not by Windows 3.1. + +@item XCOFF +The eXtended Common Object File Format. Used on AIX. A variant of +COFF, with a completely different symbol table implementation. + +@item VMA +Virtual Memory Address. This is the address a section will have when +an executable is run. Compare with LMA, above. +@end table + +@node Index +@unnumberedsec Index +@printindex cp + +@contents +@bye

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.