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/VER_5_3/gdb-5.3/bfd/doc
    from Rev 1182 to Rev 1765
    ↔ Reverse comparison
  •

Rev 1182 → Rev 1765

/coffcode.texi
0,0 → 1,605
@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 *, PTR, int, int, int, int, PTR));
 
void (*_bfd_coff_swap_sym_in)
PARAMS ((bfd *, PTR, PTR));
 
void (*_bfd_coff_swap_lineno_in)
PARAMS ((bfd *, PTR, PTR));
 
unsigned int (*_bfd_coff_swap_aux_out)
PARAMS ((bfd *, PTR, int, int, int, int, PTR));
 
unsigned int (*_bfd_coff_swap_sym_out)
PARAMS ((bfd *, PTR, PTR));
 
unsigned int (*_bfd_coff_swap_lineno_out)
PARAMS ((bfd *, PTR, PTR));
 
unsigned int (*_bfd_coff_swap_reloc_out)
PARAMS ((bfd *, PTR, PTR));
 
unsigned int (*_bfd_coff_swap_filehdr_out)
PARAMS ((bfd *, PTR, PTR));
 
unsigned int (*_bfd_coff_swap_aouthdr_out)
PARAMS ((bfd *, PTR, PTR));
 
unsigned int (*_bfd_coff_swap_scnhdr_out)
PARAMS ((bfd *, PTR, PTR));
 
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;
boolean _bfd_coff_force_symnames_in_strings;
unsigned int _bfd_coff_debug_string_prefix_length;
 
void (*_bfd_coff_swap_filehdr_in)
PARAMS ((bfd *, PTR, PTR));
 
void (*_bfd_coff_swap_aouthdr_in)
PARAMS ((bfd *, PTR, PTR));
 
void (*_bfd_coff_swap_scnhdr_in)
PARAMS ((bfd *, PTR, PTR));
 
void (*_bfd_coff_swap_reloc_in)
PARAMS ((bfd *abfd, PTR, PTR));
 
boolean (*_bfd_coff_bad_format_hook)
PARAMS ((bfd *, PTR));
 
boolean (*_bfd_coff_set_arch_mach_hook)
PARAMS ((bfd *, PTR));
 
PTR (*_bfd_coff_mkobject_hook)
PARAMS ((bfd *, PTR, PTR));
 
boolean (*_bfd_styp_to_sec_flags_hook)
PARAMS ((bfd *, PTR, const char *, asection *, flagword *));
 
void (*_bfd_set_alignment_hook)
PARAMS ((bfd *, asection *, PTR));
 
boolean (*_bfd_coff_slurp_symbol_table)
PARAMS ((bfd *));
 
boolean (*_bfd_coff_symname_in_debug)
PARAMS ((bfd *, struct internal_syment *));
 
boolean (*_bfd_coff_pointerize_aux_hook)
PARAMS ((bfd *, combined_entry_type *, combined_entry_type *,
unsigned int, combined_entry_type *));
 
boolean (*_bfd_coff_print_aux)
PARAMS ((bfd *, FILE *, combined_entry_type *, combined_entry_type *,
combined_entry_type *, unsigned int));
 
void (*_bfd_coff_reloc16_extra_cases)
PARAMS ((bfd *, struct bfd_link_info *, struct bfd_link_order *, arelent *,
bfd_byte *, unsigned int *, unsigned int *));
 
int (*_bfd_coff_reloc16_estimate)
PARAMS ((bfd *, asection *, arelent *, unsigned int,
struct bfd_link_info *));
 
enum coff_symbol_classification (*_bfd_coff_classify_symbol)
PARAMS ((bfd *, struct internal_syment *));
 
boolean (*_bfd_coff_compute_section_file_positions)
PARAMS ((bfd *));
 
boolean (*_bfd_coff_start_final_link)
PARAMS ((bfd *, struct bfd_link_info *));
 
boolean (*_bfd_coff_relocate_section)
PARAMS ((bfd *, struct bfd_link_info *, bfd *, asection *, bfd_byte *,
struct internal_reloc *, struct internal_syment *, asection **));
 
reloc_howto_type *(*_bfd_coff_rtype_to_howto)
PARAMS ((bfd *, asection *, struct internal_reloc *,
struct coff_link_hash_entry *, struct internal_syment *,
bfd_vma *));
 
boolean (*_bfd_coff_adjust_symndx)\
PARAMS ((bfd *, struct bfd_link_info *, bfd *, asection *,
struct internal_reloc *, boolean *));
 
boolean (*_bfd_coff_link_add_one_symbol)
PARAMS ((struct bfd_link_info *, bfd *, const char *, flagword,
asection *, bfd_vma, const char *, boolean, boolean,
struct bfd_link_hash_entry **));
 
boolean (*_bfd_coff_link_output_has_begun)
PARAMS ((bfd *, struct coff_final_link_info *));
 
boolean (*_bfd_coff_final_link_postscript)
PARAMS ((bfd *, struct coff_final_link_info *));
 
@} 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, flags_ptr)\
((coff_backend_info (abfd)->_bfd_styp_to_sec_flags_hook)\
(abfd, scnhdr, name, section, flags_ptr))
 
#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_force_symnames_in_strings(abfd)\
(coff_backend_info (abfd)->_bfd_coff_force_symnames_in_strings)
 
#define bfd_coff_debug_string_prefix_length(abfd)\
(coff_backend_info (abfd)->_bfd_coff_debug_string_prefix_length)
 
#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,649
# Makefile.in generated automatically by automake 1.4-p5 from Makefile.am
 
# Copyright (C) 1994, 1995-8, 1999, 2001 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@
CXX = @CXX@
CXXCPP = @CXXCPP@
DATADIRNAME = @DATADIRNAME@
DLLTOOL = @DLLTOOL@
EXEEXT = @EXEEXT@
EXEEXT_FOR_BUILD = @EXEEXT_FOR_BUILD@
GCJ = @GCJ@
GCJFLAGS = @GCJFLAGS@
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@
OBJEXT = @OBJEXT@
PACKAGE = @PACKAGE@
POFILES = @POFILES@
POSUB = @POSUB@
RANLIB = @RANLIB@
STRIP = @STRIP@
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_default_target_size = @bfd_default_target_size@
bfd_libs = @bfd_libs@
bfd_machines = @bfd_machines@
bfd_version = @bfd_version@
bfd_version_date = @bfd_version_date@
bfd_version_string = @bfd_version_string@
bfdincludedir = @bfdincludedir@
bfdlibdir = @bfdlibdir@
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 \
mmo.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 \
$(srcdir)/../mmo.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)
 
LIBBFD_H_DEP = \
$(srcdir)/../libbfd-in.h \
$(srcdir)/../init.c \
$(srcdir)/../libbfd.c \
$(srcdir)/../cache.c \
$(srcdir)/../reloc.c \
$(srcdir)/../archures.c \
$(srcdir)/../elf.c \
$(srcdir)/header.sed \
$(srcdir)/proto.str \
$(MKDOC)
 
 
LIBCOFF_H_DEP = \
$(srcdir)/../libcoff-in.h \
$(srcdir)/../coffcode.h \
$(srcdir)/header.sed \
$(srcdir)/proto.str \
$(MKDOC)
 
 
BFD_H_DEP = \
$(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)/header.sed \
$(srcdir)/proto.str \
$(srcdir)/../version.h \
$(MKDOC)
 
 
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 = gtar
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/texinfo.tex:$$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/texinfo.tex:$$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/texinfo.tex:$$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-mmo: $(MKDOC) $(srcdir)/../mmo.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../mmo.c >mmo.tmp
$(srcdir)/../../move-if-change mmo.tmp mmo.texi
touch s-mmo
mmo.texi: s-mmo
 
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: $(LIBBFD_H_DEP)
echo "$(LIBBFD_H_DEP)" | sed -f $(srcdir)/header.sed > $@
for file in $(LIBBFD_H_DEP); do \
case $$file in \
*-in.h) cat $$file >> $@ ;; \
*/header.sed) break ;; \
*) echo $$file | sed -e 's,.*/,,' -e 's,^,/* Extracted from ,' \
-e 's,$$,. */,' >> $@ ; \
./$(MKDOC) -i -f $(srcdir)/proto.str < $$file >> $@ ;; \
esac; \
done
 
libcoff.h: $(LIBCOFF_H_DEP)
echo "$(LIBCOFF_H_DEP)" | sed -f $(srcdir)/header.sed > $@
for file in $(LIBCOFF_H_DEP); do \
case $$file in \
*-in.h) cat $$file >> $@ ;; \
*/header.sed) break ;; \
*) echo $$file | sed -e 's,.*/,,' -e 's,^,/* Extracted from ,' \
-e 's,$$,. */,' >> $@ ; \
./$(MKDOC) -i -f $(srcdir)/proto.str < $$file >> $@ ;; \
esac; \
done
 
bfd.h: $(BFD_H_DEP)
echo "$(BFD_H_DEP)" | sed -f $(srcdir)/header.sed > $@
for file in $(BFD_H_DEP); do \
case $$file in \
*-in.h) cat $$file >> $@ ;; \
*/header.sed) break ;; \
*) echo $$file | sed -e 's,.*/,,' -e 's,^,/* Extracted from ,' \
-e 's,$$,. */,' >> $@ ; \
./$(MKDOC) -f $(srcdir)/proto.str < $$file >> $@ ;; \
esac; \
done
echo "#ifdef __cplusplus" >> $@
echo "}" >> $@
echo "#endif" >> $@
echo "#endif" >> $@
 
# We want install to imply install-info as per GNU standards, despite the
# cygnus option.
install: install-info
 
# 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,672
@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... */
ufile_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 with which the BFD was opened. */
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. */
ufile_ptr origin;
 
/* Remember when output has begun, to stop strange things
from happening. */
boolean output_has_begun;
 
/* A hash table for section names. */
struct bfd_hash_table section_htab;
 
/* Pointer to linked list of sections. */
struct sec *sections;
 
/* The place where we add to the section list. */
struct sec **section_tail;
 
/* 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 mmo_data_struct *mmo_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_wrong_object_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.
 
@findex bfd_archive_filename
@subsubsection @code{bfd_archive_filename}
@strong{Synopsis}
@example
const char *bfd_archive_filename (bfd *);
@end example
@strong{Description}@*
For a BFD that is a component of an archive, returns a string
with both the archive name and file name. For other BFDs, just
returns the file name.
 
@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_get_arch_size
@subsubsection @code{bfd_get_arch_size}
@strong{Synopsis}
@example
int bfd_get_arch_size (bfd *abfd);
@end example
@strong{Description}@*
Returns the architecture address size, in bits, as determined
by the object file's format. For ELF, this information is
included in the header.
 
@strong{Returns}@*
Returns the arch size in bits if known, @code{-1} otherwise.
 
@findex bfd_get_sign_extend_vma
@subsubsection @code{bfd_get_sign_extend_vma}
@strong{Synopsis}
@example
int bfd_get_sign_extend_vma (bfd *abfd);
@end example
@strong{Description}@*
Indicates if the target architecture "naturally" sign extends
an address. Some architectures implicitly sign extend address
values when they are converted to types larger than the size
of an address. For instance, bfd_get_start_address() will
return an address sign extended to fill a bfd_vma when this is
the case.
 
@strong{Returns}@*
Returns @code{1} if the target architecture is known to sign
extend addresses, @code{0} if the target architecture is known to
not sign extend addresses, and @code{-1} otherwise.
 
@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
unsigned 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, unsigned 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.
 
If the value would overflow, the maximum @code{bfd_vma} value is
returned.
 
@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_merge_sections(abfd, link_info) \
BFD_SEND (abfd, _bfd_merge_sections, (abfd, link_info))
 
#define bfd_discard_group(abfd, sec) \
BFD_SEND (abfd, _bfd_discard_group, (abfd, sec))
 
#define bfd_link_hash_table_create(abfd) \
BFD_SEND (abfd, _bfd_link_hash_table_create, (abfd))
 
#define bfd_link_hash_table_free(abfd, hash) \
BFD_SEND (abfd, _bfd_link_hash_table_free, (hash))
 
#define bfd_link_add_symbols(abfd, info) \
BFD_SEND (abfd, _bfd_link_add_symbols, (abfd, info))
 
#define bfd_link_just_syms(sec, info) \
BFD_SEND (abfd, _bfd_link_just_syms, (sec, 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
 
@findex bfd_alt_mach_code
@subsubsection @code{bfd_alt_mach_code}
@strong{Synopsis}
@example
boolean bfd_alt_mach_code(bfd *abfd, int alternative);
@end example
@strong{Description}@*
When more than one machine code number is available for the
same machine type, this function can be used to switch between
the preferred one (alternative == 0) and any others. Currently,
only ELF supports this feature, with up to two alternate
machine codes.
 
/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.
 
/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 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,709
\input texinfo.tex
@setfilename bfd.info
@c Copyright 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1997, 2000
@c Free Software Foundation, Inc.
@c
@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, 2000, 2001 Free Software Foundation, Inc.
 
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
 
@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
@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 % Since no product is stable berfore version 3.0 :-)
@subtitle Original Document Created: 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 Free Software Foundation\par
\hfill sac\@www.gnu.org\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, 2001 Free Software Foundation, Inc.
 
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
 
@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
* GNU Free Documentation License:: GNU Free Documentation License
* 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, GNU Free Documentation License, BFD front end, Top
@chapter BFD back ends
@menu
* What to Put Where::
* aout :: a.out backends
* coff :: coff backends
* elf :: elf backends
* mmo :: mmo backend
@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, mmo, coff, BFD back ends
@include elf.texi
@c Leave this out until the file has some actual contents...
@c @include elfcode.texi
 
@node mmo, , elf, BFD back ends
@include mmo.texi
 
@node GNU Free Documentation License, Index, BFD back ends, Top
@chapter GNU Free Documentation License
@cindex GNU Free Documentation License
 
GNU Free Documentation License
Version 1.1, March 2000
 
Copyright (C) 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
 
 
0. PREAMBLE
 
The purpose of this License is to make a manual, textbook, or other
written document "free" in the sense of freedom: to assure everyone
the effective freedom to copy and redistribute it, with or without
modifying it, either commercially or noncommercially. Secondarily,
this License preserves for the author and publisher a way to get
credit for their work, while not being considered responsible for
modifications made by others.
 
This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense. It
complements the GNU General Public License, which is a copyleft
license designed for free software.
 
We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does. But this License is not limited to software manuals;
it can be used for any textual work, regardless of subject matter or
whether it is published as a printed book. We recommend this License
principally for works whose purpose is instruction or reference.
 
 
1. APPLICABILITY AND DEFINITIONS
 
This License applies to any manual or other work that contains a
notice placed by the copyright holder saying it can be distributed
under the terms of this License. The "Document", below, refers to any
such manual or work. Any member of the public is a licensee, and is
addressed as "you".
 
A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.
 
A "Secondary Section" is a named appendix or a front-matter section of
the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall subject
(or to related matters) and contains nothing that could fall directly
within that overall subject. (For example, if the Document is in part a
textbook of mathematics, a Secondary Section may not explain any
mathematics.) The relationship could be a matter of historical
connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding
them.
 
The "Invariant Sections" are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice
that says that the Document is released under this License.
 
The "Cover Texts" are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
the Document is released under this License.
 
A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the
general public, whose contents can be viewed and edited directly and
straightforwardly with generic text editors or (for images composed of
pixels) generic paint programs or (for drawings) some widely available
drawing editor, and that is suitable for input to text formatters or
for automatic translation to a variety of formats suitable for input
to text formatters. A copy made in an otherwise Transparent file
format whose markup has been designed to thwart or discourage
subsequent modification by readers is not Transparent. A copy that is
not "Transparent" is called "Opaque".
 
Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format, SGML
or XML using a publicly available DTD, and standard-conforming simple
HTML designed for human modification. Opaque formats include
PostScript, PDF, proprietary formats that can be read and edited only
by proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the
machine-generated HTML produced by some word processors for output
purposes only.
 
The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the material
this License requires to appear in the title page. For works in
formats which do not have any title page as such, "Title Page" means
the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.
 
 
2. VERBATIM COPYING
 
You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies
to the Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License. You may not use
technical measures to obstruct or control the reading or further
copying of the copies you make or distribute. However, you may accept
compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.
 
You may also lend copies, under the same conditions stated above, and
you may publicly display copies.
 
 
3. COPYING IN QUANTITY
 
If you publish printed copies of the Document numbering more than 100,
and the Document's license notice requires Cover Texts, you must enclose
the copies in covers that carry, clearly and legibly, all these Cover
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
the back cover. Both covers must also clearly and legibly identify
you as the publisher of these copies. The front cover must present
the full title with all words of the title equally prominent and
visible. You may add other material on the covers in addition.
Copying with changes limited to the covers, as long as they preserve
the title of the Document and satisfy these conditions, can be treated
as verbatim copying in other respects.
 
If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.
 
If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a publicly-accessible computer-network location containing a complete
Transparent copy of the Document, free of added material, which the
general network-using public has access to download anonymously at no
charge using public-standard network protocols. If you use the latter
option, you must take reasonably prudent steps, when you begin
distribution of Opaque copies in quantity, to ensure that this
Transparent copy will remain thus accessible at the stated location
until at least one year after the last time you distribute an Opaque
copy (directly or through your agents or retailers) of that edition to
the public.
 
It is requested, but not required, that you contact the authors of the
Document well before redistributing any large number of copies, to give
them a chance to provide you with an updated version of the Document.
 
 
4. MODIFICATIONS
 
You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release
the Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution
and modification of the Modified Version to whoever possesses a copy
of it. In addition, you must do these things in the Modified Version:
 
A. Use in the Title Page (and on the covers, if any) a title distinct
from that of the Document, and from those of previous versions
(which should, if there were any, be listed in the History section
of the Document). You may use the same title as a previous version
if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has less than five).
C. State on the Title page the name of the publisher of the
Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice
giving the public permission to use the Modified Version under the
terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections
and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section entitled "History", and its title, and add to
it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If
there is no section entitled "History" in the Document, create one
stating the title, year, authors, and publisher of the Document as
given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for
public access to a Transparent copy of the Document, and likewise
the network locations given in the Document for previous versions
it was based on. These may be placed in the "History" section.
You may omit a network location for a work that was published at
least four years before the Document itself, or if the original
publisher of the version it refers to gives permission.
K. In any section entitled "Acknowledgements" or "Dedications",
preserve the section's title, and preserve in the section all the
substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section numbers
or the equivalent are not considered part of the section titles.
M. Delete any section entitled "Endorsements". Such a section
may not be included in the Modified Version.
N. Do not retitle any existing section as "Endorsements"
or to conflict in title with any Invariant Section.
 
If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant. To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.
 
You may add a section entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various
parties--for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a
standard.
 
You may add a passage of up to five words as a Front-Cover Text, and a
passage of up to 25 words as a Back-Cover Text, to the end of the list
of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or
through arrangements made by) any one entity. If the Document already
includes a cover text for the same cover, previously added by you or
by arrangement made by the same entity you are acting on behalf of,
you may not add another; but you may replace the old one, on explicit
permission from the previous publisher that added the old one.
 
The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or
imply endorsement of any Modified Version.
 
 
5. COMBINING DOCUMENTS
 
You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified
versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and
list them all as Invariant Sections of your combined work in its
license notice.
 
The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy. If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original
author or publisher of that section if known, or else a unique number.
Make the same adjustment to the section titles in the list of
Invariant Sections in the license notice of the combined work.
 
In the combination, you must combine any sections entitled "History"
in the various original documents, forming one section entitled
"History"; likewise combine any sections entitled "Acknowledgements",
and any sections entitled "Dedications". You must delete all sections
entitled "Endorsements."
 
 
6. COLLECTIONS OF DOCUMENTS
 
You may make a collection consisting of the Document and other documents
released under this License, and replace the individual copies of this
License in the various documents with a single copy that is included in
the collection, provided that you follow the rules of this License for
verbatim copying of each of the documents in all other respects.
 
You may extract a single document from such a collection, and distribute
it individually under this License, provided you insert a copy of this
License into the extracted document, and follow this License in all
other respects regarding verbatim copying of that document.
 
 
7. AGGREGATION WITH INDEPENDENT WORKS
 
A compilation of the Document or its derivatives with other separate
and independent documents or works, in or on a volume of a storage or
distribution medium, does not as a whole count as a Modified Version
of the Document, provided no compilation copyright is claimed for the
compilation. Such a compilation is called an "aggregate", and this
License does not apply to the other self-contained works thus compiled
with the Document, on account of their being thus compiled, if they
are not themselves derivative works of the Document.
 
If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one quarter
of the entire aggregate, the Document's Cover Texts may be placed on
covers that surround only the Document within the aggregate.
Otherwise they must appear on covers around the whole aggregate.
 
 
8. TRANSLATION
 
Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections. You may include a
translation of this License provided that you also include the
original English version of this License. In case of a disagreement
between the translation and the original English version of this
License, the original English version will prevail.
 
 
9. TERMINATION
 
You may not copy, modify, sublicense, or distribute the Document except
as expressly provided for under this License. Any other attempt to
copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such
parties remain in full compliance.
 
 
10. FUTURE REVISIONS OF THIS LICENSE
 
The Free Software Foundation may publish new, revised versions
of the GNU Free Documentation License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See
http://www.gnu.org/copyleft/.
 
Each version of the License is given a distinguishing version number.
If the Document specifies that a particular numbered version of this
License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or
of any later version that has been published (not as a draft) by the
Free Software Foundation. If the Document does not specify a version
number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation.
 
 
ADDENDUM: How to use this License for your documents
 
To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and
license notices just after the title page:
 
@smallexample
Copyright (c) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
@end smallexample
 
If you have no Invariant Sections, write "with no Invariant Sections"
instead of saying which ones are invariant. If you have no
Front-Cover Texts, write "no Front-Cover Texts" instead of
"Front-Cover Texts being LIST"; likewise for Back-Cover Texts.
 
If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License,
to permit their use in free software.
 
@node Index, , GNU Free Documentation License , 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,1820
@section Relocations
BFD maintains relocations in much the same way it maintains
symbols: they are left alone until required, then read in
en-masse 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 *, arelent *, struct symbol_cache_entry *, PTR, asection *,
bfd *, char **));
 
/* 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_64_PLT_PCREL
@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_64_PLTOFF
@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_UA16
@deffnx {} BFD_RELOC_SPARC_UA32
@deffnx {} BFD_RELOC_SPARC_UA64
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_PLT32
@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)
@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_ALPHA_GPREL_HI16
@deffnx {} BFD_RELOC_ALPHA_GPREL_LO16
The GPREL_HI/LO relocations together form a 32-bit offset from the
GP register.
@end deffn
@deffn {} BFD_RELOC_ALPHA_BRSGP
Like BFD_RELOC_23_PCREL_S2, except that the source and target must
share a common GP, and the target address is adjusted for
STO_ALPHA_STD_GPLOAD.
@end deffn
@deffn {} BFD_RELOC_ALPHA_TLSGD
@deffnx {} BFD_RELOC_ALPHA_TLSLDM
@deffnx {} BFD_RELOC_ALPHA_DTPMOD64
@deffnx {} BFD_RELOC_ALPHA_GOTDTPREL16
@deffnx {} BFD_RELOC_ALPHA_DTPREL64
@deffnx {} BFD_RELOC_ALPHA_DTPREL_HI16
@deffnx {} BFD_RELOC_ALPHA_DTPREL_LO16
@deffnx {} BFD_RELOC_ALPHA_DTPREL16
@deffnx {} BFD_RELOC_ALPHA_GOTTPREL16
@deffnx {} BFD_RELOC_ALPHA_TPREL64
@deffnx {} BFD_RELOC_ALPHA_TPREL_HI16
@deffnx {} BFD_RELOC_ALPHA_TPREL_LO16
@deffnx {} BFD_RELOC_ALPHA_TPREL16
Alpha thread-local storage relocations.
@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_LITERAL
Relocation against a MIPS literal section.
@end deffn
@deffn {} BFD_RELOC_MIPS_GOT16
@deffnx {} BFD_RELOC_MIPS_CALL16
@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
@deffnx {} BFD_RELOC_MIPS_SHIFT5
@deffnx {} BFD_RELOC_MIPS_SHIFT6
@deffnx {} BFD_RELOC_MIPS_INSERT_A
@deffnx {} BFD_RELOC_MIPS_INSERT_B
@deffnx {} BFD_RELOC_MIPS_DELETE
@deffnx {} BFD_RELOC_MIPS_HIGHEST
@deffnx {} BFD_RELOC_MIPS_HIGHER
@deffnx {} BFD_RELOC_MIPS_SCN_DISP
@deffnx {} BFD_RELOC_MIPS_REL16
@deffnx {} BFD_RELOC_MIPS_RELGOT
@deffnx {} BFD_RELOC_MIPS_JALR
@deffn {} BFD_RELOC_FRV_LABEL16
@deffnx {} BFD_RELOC_FRV_LABEL24
@deffnx {} BFD_RELOC_FRV_LO16
@deffnx {} BFD_RELOC_FRV_HI16
@deffnx {} BFD_RELOC_FRV_GPREL12
@deffnx {} BFD_RELOC_FRV_GPRELU12
@deffnx {} BFD_RELOC_FRV_GPREL32
@deffnx {} BFD_RELOC_FRV_GPRELHI
@deffnx {} BFD_RELOC_FRV_GPRELLO
Fujitsu Frv Relocations.
@end deffn
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
@deffnx {} BFD_RELOC_386_TLS_LE
@deffnx {} BFD_RELOC_386_TLS_GD
@deffnx {} BFD_RELOC_386_TLS_LDM
@deffnx {} BFD_RELOC_386_TLS_LDO_32
@deffnx {} BFD_RELOC_386_TLS_IE_32
@deffnx {} BFD_RELOC_386_TLS_LE_32
@deffnx {} BFD_RELOC_386_TLS_DTPMOD32
@deffnx {} BFD_RELOC_386_TLS_DTPOFF32
@deffnx {} BFD_RELOC_386_TLS_TPOFF32
i386/elf relocations
@end deffn
@deffn {} BFD_RELOC_X86_64_GOT32
@deffnx {} BFD_RELOC_X86_64_PLT32
@deffnx {} BFD_RELOC_X86_64_COPY
@deffnx {} BFD_RELOC_X86_64_GLOB_DAT
@deffnx {} BFD_RELOC_X86_64_JUMP_SLOT
@deffnx {} BFD_RELOC_X86_64_RELATIVE
@deffnx {} BFD_RELOC_X86_64_GOTPCREL
@deffnx {} BFD_RELOC_X86_64_32S
x86-64/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_PDP11_DISP_8_PCREL
@deffnx {} BFD_RELOC_PDP11_DISP_6_PCREL
PDP11 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
@deffnx {} BFD_RELOC_PPC64_HIGHER
@deffnx {} BFD_RELOC_PPC64_HIGHER_S
@deffnx {} BFD_RELOC_PPC64_HIGHEST
@deffnx {} BFD_RELOC_PPC64_HIGHEST_S
@deffnx {} BFD_RELOC_PPC64_TOC16_LO
@deffnx {} BFD_RELOC_PPC64_TOC16_HI
@deffnx {} BFD_RELOC_PPC64_TOC16_HA
@deffnx {} BFD_RELOC_PPC64_TOC
@deffnx {} BFD_RELOC_PPC64_PLTGOT16
@deffnx {} BFD_RELOC_PPC64_PLTGOT16_LO
@deffnx {} BFD_RELOC_PPC64_PLTGOT16_HI
@deffnx {} BFD_RELOC_PPC64_PLTGOT16_HA
@deffnx {} BFD_RELOC_PPC64_ADDR16_DS
@deffnx {} BFD_RELOC_PPC64_ADDR16_LO_DS
@deffnx {} BFD_RELOC_PPC64_GOT16_DS
@deffnx {} BFD_RELOC_PPC64_GOT16_LO_DS
@deffnx {} BFD_RELOC_PPC64_PLT16_LO_DS
@deffnx {} BFD_RELOC_PPC64_SECTOFF_DS
@deffnx {} BFD_RELOC_PPC64_SECTOFF_LO_DS
@deffnx {} BFD_RELOC_PPC64_TOC16_DS
@deffnx {} BFD_RELOC_PPC64_TOC16_LO_DS
@deffnx {} BFD_RELOC_PPC64_PLTGOT16_DS
@deffnx {} BFD_RELOC_PPC64_PLTGOT16_LO_DS
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
@deffnx {} BFD_RELOC_SH_COPY
@deffnx {} BFD_RELOC_SH_GLOB_DAT
@deffnx {} BFD_RELOC_SH_JMP_SLOT
@deffnx {} BFD_RELOC_SH_RELATIVE
@deffnx {} BFD_RELOC_SH_GOTPC
@deffnx {} BFD_RELOC_SH_GOT_LOW16
@deffnx {} BFD_RELOC_SH_GOT_MEDLOW16
@deffnx {} BFD_RELOC_SH_GOT_MEDHI16
@deffnx {} BFD_RELOC_SH_GOT_HI16
@deffnx {} BFD_RELOC_SH_GOTPLT_LOW16
@deffnx {} BFD_RELOC_SH_GOTPLT_MEDLOW16
@deffnx {} BFD_RELOC_SH_GOTPLT_MEDHI16
@deffnx {} BFD_RELOC_SH_GOTPLT_HI16
@deffnx {} BFD_RELOC_SH_PLT_LOW16
@deffnx {} BFD_RELOC_SH_PLT_MEDLOW16
@deffnx {} BFD_RELOC_SH_PLT_MEDHI16
@deffnx {} BFD_RELOC_SH_PLT_HI16
@deffnx {} BFD_RELOC_SH_GOTOFF_LOW16
@deffnx {} BFD_RELOC_SH_GOTOFF_MEDLOW16
@deffnx {} BFD_RELOC_SH_GOTOFF_MEDHI16
@deffnx {} BFD_RELOC_SH_GOTOFF_HI16
@deffnx {} BFD_RELOC_SH_GOTPC_LOW16
@deffnx {} BFD_RELOC_SH_GOTPC_MEDLOW16
@deffnx {} BFD_RELOC_SH_GOTPC_MEDHI16
@deffnx {} BFD_RELOC_SH_GOTPC_HI16
@deffnx {} BFD_RELOC_SH_COPY64
@deffnx {} BFD_RELOC_SH_GLOB_DAT64
@deffnx {} BFD_RELOC_SH_JMP_SLOT64
@deffnx {} BFD_RELOC_SH_RELATIVE64
@deffnx {} BFD_RELOC_SH_GOT10BY4
@deffnx {} BFD_RELOC_SH_GOT10BY8
@deffnx {} BFD_RELOC_SH_GOTPLT10BY4
@deffnx {} BFD_RELOC_SH_GOTPLT10BY8
@deffnx {} BFD_RELOC_SH_GOTPLT32
@deffnx {} BFD_RELOC_SH_SHMEDIA_CODE
@deffnx {} BFD_RELOC_SH_IMMU5
@deffnx {} BFD_RELOC_SH_IMMS6
@deffnx {} BFD_RELOC_SH_IMMS6BY32
@deffnx {} BFD_RELOC_SH_IMMU6
@deffnx {} BFD_RELOC_SH_IMMS10
@deffnx {} BFD_RELOC_SH_IMMS10BY2
@deffnx {} BFD_RELOC_SH_IMMS10BY4
@deffnx {} BFD_RELOC_SH_IMMS10BY8
@deffnx {} BFD_RELOC_SH_IMMS16
@deffnx {} BFD_RELOC_SH_IMMU16
@deffnx {} BFD_RELOC_SH_IMM_LOW16
@deffnx {} BFD_RELOC_SH_IMM_LOW16_PCREL
@deffnx {} BFD_RELOC_SH_IMM_MEDLOW16
@deffnx {} BFD_RELOC_SH_IMM_MEDLOW16_PCREL
@deffnx {} BFD_RELOC_SH_IMM_MEDHI16
@deffnx {} BFD_RELOC_SH_IMM_MEDHI16_PCREL
@deffnx {} BFD_RELOC_SH_IMM_HI16
@deffnx {} BFD_RELOC_SH_IMM_HI16_PCREL
@deffnx {} BFD_RELOC_SH_PT_16
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
ARC Cores 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_DLX_HI16_S
DLX relocs
@end deffn
@deffn {} BFD_RELOC_DLX_LO16
DLX relocs
@end deffn
@deffn {} BFD_RELOC_DLX_JMP26
DLX relocs
@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_V850_LONGCALL
Used for relaxing indirect function calls.
@end deffn
@deffn {} BFD_RELOC_V850_LONGJUMP
Used for relaxing indirect jumps.
@end deffn
@deffn {} BFD_RELOC_V850_ALIGN
Used to maintain alignment whilst relaxing.
@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_MMIX_GETA
@deffnx {} BFD_RELOC_MMIX_GETA_1
@deffnx {} BFD_RELOC_MMIX_GETA_2
@deffnx {} BFD_RELOC_MMIX_GETA_3
These are relocations for the GETA instruction.
@end deffn
@deffn {} BFD_RELOC_MMIX_CBRANCH
@deffnx {} BFD_RELOC_MMIX_CBRANCH_J
@deffnx {} BFD_RELOC_MMIX_CBRANCH_1
@deffnx {} BFD_RELOC_MMIX_CBRANCH_2
@deffnx {} BFD_RELOC_MMIX_CBRANCH_3
These are relocations for a conditional branch instruction.
@end deffn
@deffn {} BFD_RELOC_MMIX_PUSHJ
@deffnx {} BFD_RELOC_MMIX_PUSHJ_1
@deffnx {} BFD_RELOC_MMIX_PUSHJ_2
@deffnx {} BFD_RELOC_MMIX_PUSHJ_3
These are relocations for the PUSHJ instruction.
@end deffn
@deffn {} BFD_RELOC_MMIX_JMP
@deffnx {} BFD_RELOC_MMIX_JMP_1
@deffnx {} BFD_RELOC_MMIX_JMP_2
@deffnx {} BFD_RELOC_MMIX_JMP_3
These are relocations for the JMP instruction.
@end deffn
@deffn {} BFD_RELOC_MMIX_ADDR19
This is a relocation for a relative address as in a GETA instruction or
a branch.
@end deffn
@deffn {} BFD_RELOC_MMIX_ADDR27
This is a relocation for a relative address as in a JMP instruction.
@end deffn
@deffn {} BFD_RELOC_MMIX_REG_OR_BYTE
This is a relocation for an instruction field that may be a general
register or a value 0..255.
@end deffn
@deffn {} BFD_RELOC_MMIX_REG
This is a relocation for an instruction field that may be a general
register.
@end deffn
@deffn {} BFD_RELOC_MMIX_BASE_PLUS_OFFSET
This is a relocation for two instruction fields holding a register and
an offset, the equivalent of the relocation.
@end deffn
@deffn {} BFD_RELOC_MMIX_LOCAL
This relocation is an assertion that the expression is not allocated as
a global register. It does not modify contents.
@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_390_12
Direct 12 bit.
@end deffn
@deffn {} BFD_RELOC_390_GOT12
12 bit GOT offset.
@end deffn
@deffn {} BFD_RELOC_390_PLT32
32 bit PC relative PLT address.
@end deffn
@deffn {} BFD_RELOC_390_COPY
Copy symbol at runtime.
@end deffn
@deffn {} BFD_RELOC_390_GLOB_DAT
Create GOT entry.
@end deffn
@deffn {} BFD_RELOC_390_JMP_SLOT
Create PLT entry.
@end deffn
@deffn {} BFD_RELOC_390_RELATIVE
Adjust by program base.
@end deffn
@deffn {} BFD_RELOC_390_GOTPC
32 bit PC relative offset to GOT.
@end deffn
@deffn {} BFD_RELOC_390_GOT16
16 bit GOT offset.
@end deffn
@deffn {} BFD_RELOC_390_PC16DBL
PC relative 16 bit shifted by 1.
@end deffn
@deffn {} BFD_RELOC_390_PLT16DBL
16 bit PC rel. PLT shifted by 1.
@end deffn
@deffn {} BFD_RELOC_390_PC32DBL
PC relative 32 bit shifted by 1.
@end deffn
@deffn {} BFD_RELOC_390_PLT32DBL
32 bit PC rel. PLT shifted by 1.
@end deffn
@deffn {} BFD_RELOC_390_GOTPCDBL
32 bit PC rel. GOT shifted by 1.
@end deffn
@deffn {} BFD_RELOC_390_GOT64
64 bit GOT offset.
@end deffn
@deffn {} BFD_RELOC_390_PLT64
64 bit PC relative PLT address.
@end deffn
@deffn {} BFD_RELOC_390_GOTENT
32 bit rel. offset to GOT entry.
@end deffn
@deffn {} BFD_RELOC_IP2K_FR9
Scenix IP2K - 9-bit register number / data address
@end deffn
@deffn {} BFD_RELOC_IP2K_BANK
Scenix IP2K - 4-bit register/data bank number
@end deffn
@deffn {} BFD_RELOC_IP2K_ADDR16CJP
Scenix IP2K - low 13 bits of instruction word address
@end deffn
@deffn {} BFD_RELOC_IP2K_PAGE3
Scenix IP2K - high 3 bits of instruction word address
@end deffn
@deffn {} BFD_RELOC_IP2K_LO8DATA
@deffnx {} BFD_RELOC_IP2K_HI8DATA
@deffnx {} BFD_RELOC_IP2K_EX8DATA
Scenix IP2K - ext/low/high 8 bits of data address
@end deffn
@deffn {} BFD_RELOC_IP2K_LO8INSN
@deffnx {} BFD_RELOC_IP2K_HI8INSN
Scenix IP2K - low/high 8 bits of instruction word address
@end deffn
@deffn {} BFD_RELOC_IP2K_PC_SKIP
Scenix IP2K - even/odd PC modifier to modify snb pcl.0
@end deffn
@deffn {} BFD_RELOC_IP2K_TEXT
Scenix IP2K - 16 bit word address in text section.
@end deffn
@deffn {} BFD_RELOC_IP2K_FR_OFFSET
Scenix IP2K - 7-bit sp or dp offset
@end deffn
@deffn {} BFD_RELOC_VPE4KMATH_DATA
@deffnx {} BFD_RELOC_VPE4KMATH_INSN
Scenix VPE4K coprocessor - data/insn-space addressing
@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
@deffn {} BFD_RELOC_IA64_IMM14
@deffnx {} BFD_RELOC_IA64_IMM22
@deffnx {} BFD_RELOC_IA64_IMM64
@deffnx {} BFD_RELOC_IA64_DIR32MSB
@deffnx {} BFD_RELOC_IA64_DIR32LSB
@deffnx {} BFD_RELOC_IA64_DIR64MSB
@deffnx {} BFD_RELOC_IA64_DIR64LSB
@deffnx {} BFD_RELOC_IA64_GPREL22
@deffnx {} BFD_RELOC_IA64_GPREL64I
@deffnx {} BFD_RELOC_IA64_GPREL32MSB
@deffnx {} BFD_RELOC_IA64_GPREL32LSB
@deffnx {} BFD_RELOC_IA64_GPREL64MSB
@deffnx {} BFD_RELOC_IA64_GPREL64LSB
@deffnx {} BFD_RELOC_IA64_LTOFF22
@deffnx {} BFD_RELOC_IA64_LTOFF64I
@deffnx {} BFD_RELOC_IA64_PLTOFF22
@deffnx {} BFD_RELOC_IA64_PLTOFF64I
@deffnx {} BFD_RELOC_IA64_PLTOFF64MSB
@deffnx {} BFD_RELOC_IA64_PLTOFF64LSB
@deffnx {} BFD_RELOC_IA64_FPTR64I
@deffnx {} BFD_RELOC_IA64_FPTR32MSB
@deffnx {} BFD_RELOC_IA64_FPTR32LSB
@deffnx {} BFD_RELOC_IA64_FPTR64MSB
@deffnx {} BFD_RELOC_IA64_FPTR64LSB
@deffnx {} BFD_RELOC_IA64_PCREL21B
@deffnx {} BFD_RELOC_IA64_PCREL21BI
@deffnx {} BFD_RELOC_IA64_PCREL21M
@deffnx {} BFD_RELOC_IA64_PCREL21F
@deffnx {} BFD_RELOC_IA64_PCREL22
@deffnx {} BFD_RELOC_IA64_PCREL60B
@deffnx {} BFD_RELOC_IA64_PCREL64I
@deffnx {} BFD_RELOC_IA64_PCREL32MSB
@deffnx {} BFD_RELOC_IA64_PCREL32LSB
@deffnx {} BFD_RELOC_IA64_PCREL64MSB
@deffnx {} BFD_RELOC_IA64_PCREL64LSB
@deffnx {} BFD_RELOC_IA64_LTOFF_FPTR22
@deffnx {} BFD_RELOC_IA64_LTOFF_FPTR64I
@deffnx {} BFD_RELOC_IA64_LTOFF_FPTR32MSB
@deffnx {} BFD_RELOC_IA64_LTOFF_FPTR32LSB
@deffnx {} BFD_RELOC_IA64_LTOFF_FPTR64MSB
@deffnx {} BFD_RELOC_IA64_LTOFF_FPTR64LSB
@deffnx {} BFD_RELOC_IA64_SEGREL32MSB
@deffnx {} BFD_RELOC_IA64_SEGREL32LSB
@deffnx {} BFD_RELOC_IA64_SEGREL64MSB
@deffnx {} BFD_RELOC_IA64_SEGREL64LSB
@deffnx {} BFD_RELOC_IA64_SECREL32MSB
@deffnx {} BFD_RELOC_IA64_SECREL32LSB
@deffnx {} BFD_RELOC_IA64_SECREL64MSB
@deffnx {} BFD_RELOC_IA64_SECREL64LSB
@deffnx {} BFD_RELOC_IA64_REL32MSB
@deffnx {} BFD_RELOC_IA64_REL32LSB
@deffnx {} BFD_RELOC_IA64_REL64MSB
@deffnx {} BFD_RELOC_IA64_REL64LSB
@deffnx {} BFD_RELOC_IA64_LTV32MSB
@deffnx {} BFD_RELOC_IA64_LTV32LSB
@deffnx {} BFD_RELOC_IA64_LTV64MSB
@deffnx {} BFD_RELOC_IA64_LTV64LSB
@deffnx {} BFD_RELOC_IA64_IPLTMSB
@deffnx {} BFD_RELOC_IA64_IPLTLSB
@deffnx {} BFD_RELOC_IA64_COPY
@deffnx {} BFD_RELOC_IA64_LTOFF22X
@deffnx {} BFD_RELOC_IA64_LDXMOV
@deffnx {} BFD_RELOC_IA64_TPREL14
@deffnx {} BFD_RELOC_IA64_TPREL22
@deffnx {} BFD_RELOC_IA64_TPREL64I
@deffnx {} BFD_RELOC_IA64_TPREL64MSB
@deffnx {} BFD_RELOC_IA64_TPREL64LSB
@deffnx {} BFD_RELOC_IA64_LTOFF_TPREL22
@deffnx {} BFD_RELOC_IA64_DTPMOD64MSB
@deffnx {} BFD_RELOC_IA64_DTPMOD64LSB
@deffnx {} BFD_RELOC_IA64_LTOFF_DTPMOD22
@deffnx {} BFD_RELOC_IA64_DTPREL14
@deffnx {} BFD_RELOC_IA64_DTPREL22
@deffnx {} BFD_RELOC_IA64_DTPREL64I
@deffnx {} BFD_RELOC_IA64_DTPREL32MSB
@deffnx {} BFD_RELOC_IA64_DTPREL32LSB
@deffnx {} BFD_RELOC_IA64_DTPREL64MSB
@deffnx {} BFD_RELOC_IA64_DTPREL64LSB
@deffnx {} BFD_RELOC_IA64_LTOFF_DTPREL22
Intel IA64 Relocations.
@end deffn
@deffn {} BFD_RELOC_M68HC11_HI8
Motorola 68HC11 reloc.
This is the 8 bit high part of an absolute address.
@end deffn
@deffn {} BFD_RELOC_M68HC11_LO8
Motorola 68HC11 reloc.
This is the 8 bit low part of an absolute address.
@end deffn
@deffn {} BFD_RELOC_M68HC11_3B
Motorola 68HC11 reloc.
This is the 3 bit of a value.
@end deffn
@deffn {} BFD_RELOC_M68HC11_RL_JUMP
Motorola 68HC11 reloc.
This reloc marks the beginning of a jump/call instruction.
It is used for linker relaxation to correctly identify beginning
of instruction and change some branchs to use PC-relative
addressing mode.
@end deffn
@deffn {} BFD_RELOC_M68HC11_RL_GROUP
Motorola 68HC11 reloc.
This reloc marks a group of several instructions that gcc generates
and for which the linker relaxation pass can modify and/or remove
some of them.
@end deffn
@deffn {} BFD_RELOC_M68HC11_LO16
Motorola 68HC11 reloc.
This is the 16-bit lower part of an address. It is used for 'call'
instruction to specify the symbol address without any special
transformation (due to memory bank window).
@end deffn
@deffn {} BFD_RELOC_M68HC11_PAGE
Motorola 68HC11 reloc.
This is a 8-bit reloc that specifies the page number of an address.
It is used by 'call' instruction to specify the page number of
the symbol.
@end deffn
@deffn {} BFD_RELOC_M68HC11_24
Motorola 68HC11 reloc.
This is a 24-bit reloc that represents the address with a 16-bit
value and a 8-bit page number. The symbol address is transformed
to follow the 16K memory bank of 68HC12 (seen as mapped in the window).
@end deffn
@deffn {} BFD_RELOC_CRIS_BDISP8
@deffnx {} BFD_RELOC_CRIS_UNSIGNED_5
@deffnx {} BFD_RELOC_CRIS_SIGNED_6
@deffnx {} BFD_RELOC_CRIS_UNSIGNED_6
@deffnx {} BFD_RELOC_CRIS_UNSIGNED_4
These relocs are only used within the CRIS assembler. They are not
(at present) written to any object files.
@end deffn
@deffn {} BFD_RELOC_CRIS_COPY
@deffnx {} BFD_RELOC_CRIS_GLOB_DAT
@deffnx {} BFD_RELOC_CRIS_JUMP_SLOT
@deffnx {} BFD_RELOC_CRIS_RELATIVE
Relocs used in ELF shared libraries for CRIS.
@end deffn
@deffn {} BFD_RELOC_CRIS_32_GOT
32-bit offset to symbol-entry within GOT.
@end deffn
@deffn {} BFD_RELOC_CRIS_16_GOT
16-bit offset to symbol-entry within GOT.
@end deffn
@deffn {} BFD_RELOC_CRIS_32_GOTPLT
32-bit offset to symbol-entry within GOT, with PLT handling.
@end deffn
@deffn {} BFD_RELOC_CRIS_16_GOTPLT
16-bit offset to symbol-entry within GOT, with PLT handling.
@end deffn
@deffn {} BFD_RELOC_CRIS_32_GOTREL
32-bit offset to symbol, relative to GOT.
@end deffn
@deffn {} BFD_RELOC_CRIS_32_PLT_GOTREL
32-bit offset to symbol with PLT entry, relative to GOT.
@end deffn
@deffn {} BFD_RELOC_CRIS_32_PLT_PCREL
32-bit offset to symbol with PLT entry, relative to this relocation.
@end deffn
@deffn {} BFD_RELOC_860_COPY
@deffnx {} BFD_RELOC_860_GLOB_DAT
@deffnx {} BFD_RELOC_860_JUMP_SLOT
@deffnx {} BFD_RELOC_860_RELATIVE
@deffnx {} BFD_RELOC_860_PC26
@deffnx {} BFD_RELOC_860_PLT26
@deffnx {} BFD_RELOC_860_PC16
@deffnx {} BFD_RELOC_860_LOW0
@deffnx {} BFD_RELOC_860_SPLIT0
@deffnx {} BFD_RELOC_860_LOW1
@deffnx {} BFD_RELOC_860_SPLIT1
@deffnx {} BFD_RELOC_860_LOW2
@deffnx {} BFD_RELOC_860_SPLIT2
@deffnx {} BFD_RELOC_860_LOW3
@deffnx {} BFD_RELOC_860_LOGOT0
@deffnx {} BFD_RELOC_860_SPGOT0
@deffnx {} BFD_RELOC_860_LOGOT1
@deffnx {} BFD_RELOC_860_SPGOT1
@deffnx {} BFD_RELOC_860_LOGOTOFF0
@deffnx {} BFD_RELOC_860_SPGOTOFF0
@deffnx {} BFD_RELOC_860_LOGOTOFF1
@deffnx {} BFD_RELOC_860_SPGOTOFF1
@deffnx {} BFD_RELOC_860_LOGOTOFF2
@deffnx {} BFD_RELOC_860_LOGOTOFF3
@deffnx {} BFD_RELOC_860_LOPC
@deffnx {} BFD_RELOC_860_HIGHADJ
@deffnx {} BFD_RELOC_860_HAGOT
@deffnx {} BFD_RELOC_860_HAGOTOFF
@deffnx {} BFD_RELOC_860_HAPC
@deffnx {} BFD_RELOC_860_HIGH
@deffnx {} BFD_RELOC_860_HIGOT
@deffnx {} BFD_RELOC_860_HIGOTOFF
Intel i860 Relocations.
@end deffn
@deffn {} BFD_RELOC_OPENRISC_ABS_26
@deffnx {} BFD_RELOC_OPENRISC_REL_26
OpenRISC Relocations.
@end deffn
@deffn {} BFD_RELOC_H8_DIR16A8
@deffnx {} BFD_RELOC_H8_DIR16R8
@deffnx {} BFD_RELOC_H8_DIR24A8
@deffnx {} BFD_RELOC_H8_DIR24R8
@deffnx {} BFD_RELOC_H8_DIR32A16
H8 elf Relocations.
@end deffn
@deffn {} BFD_RELOC_XSTORMY16_REL_12
@deffnx {} BFD_RELOC_XSTORMY16_24
@deffnx {} BFD_RELOC_XSTORMY16_FPTR16
Sony Xstormy16 Relocations.
@end deffn
@deffn {} BFD_RELOC_VAX_GLOB_DAT
@deffnx {} BFD_RELOC_VAX_JMP_SLOT
@deffnx {} BFD_RELOC_VAX_RELATIVE
Relocations used by VAX ELF.
@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_merge_sections
@subsubsection @code{bfd_generic_merge_sections}
@strong{Synopsis}
@example
boolean bfd_generic_merge_sections
(bfd *, struct bfd_link_info *);
@end example
@strong{Description}@*
Provides default handling for SEC_MERGE section merging for back ends
which don't have SEC_MERGE support -- 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
;
/makefile.vms
0,0 → 1,5
CFLAGS = /noopt/include=([],[-],[-.-.include])
LDFLAGS = /nomap
LDLIBS = ,sys$$library:vaxcrtl.olb/lib
 
all: chew.exe
/targets.texi
0,0 → 1,509
@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_xcoff_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,
bfd_target_mmo_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 @code{BFD_NO_FLAGS}, @code{HAS_RELOC}, ...@code{D_PAGED}. */
flagword object_flags;
 
/* 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}. */
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 @code{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 @code{bfd_close}. */
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. */
@end example
Do not "beautify" the CONCAT* macro args. Traditional C will not
remove whitespace added here, and thus will fail to concatenate
the tokens.
@example
#define BFD_JUMP_TABLE_GENERIC(NAME) \
CONCAT2 (NAME,_close_and_cleanup), \
CONCAT2 (NAME,_bfd_free_cached_info), \
CONCAT2 (NAME,_new_section_hook), \
CONCAT2 (NAME,_get_section_contents), \
CONCAT2 (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) \
CONCAT2 (NAME,_bfd_copy_private_bfd_data), \
CONCAT2 (NAME,_bfd_merge_private_bfd_data), \
CONCAT2 (NAME,_bfd_copy_private_section_data), \
CONCAT2 (NAME,_bfd_copy_private_symbol_data), \
CONCAT2 (NAME,_bfd_set_private_flags), \
CONCAT2 (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) \
CONCAT2 (NAME,_core_file_failing_command), \
CONCAT2 (NAME,_core_file_failing_signal), \
CONCAT2 (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) \
CONCAT2 (NAME,_slurp_armap), \
CONCAT2 (NAME,_slurp_extended_name_table), \
CONCAT2 (NAME,_construct_extended_name_table), \
CONCAT2 (NAME,_truncate_arname), \
CONCAT2 (NAME,_write_armap), \
CONCAT2 (NAME,_read_ar_hdr), \
CONCAT2 (NAME,_openr_next_archived_file), \
CONCAT2 (NAME,_get_elt_at_index), \
CONCAT2 (NAME,_generic_stat_arch_elt), \
CONCAT2 (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 *, unsigned int, struct orl *, unsigned int, int));
PTR (*_bfd_read_ar_hdr_fn) PARAMS ((bfd *));
bfd * (*openr_next_archived_file) PARAMS ((bfd *, bfd *));
#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) \
CONCAT2 (NAME,_get_symtab_upper_bound), \
CONCAT2 (NAME,_get_symtab), \
CONCAT2 (NAME,_make_empty_symbol), \
CONCAT2 (NAME,_print_symbol), \
CONCAT2 (NAME,_get_symbol_info), \
CONCAT2 (NAME,_bfd_is_local_label_name), \
CONCAT2 (NAME,_get_lineno), \
CONCAT2 (NAME,_find_nearest_line), \
CONCAT2 (NAME,_bfd_make_debug_symbol), \
CONCAT2 (NAME,_read_minisymbols), \
CONCAT2 (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 *, struct sec *, struct symbol_cache_entry **, bfd_vma,
const char **, const char **, unsigned int *));
/* 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 *, void *,
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) \
CONCAT2 (NAME,_get_reloc_upper_bound), \
CONCAT2 (NAME,_canonicalize_reloc), \
CONCAT2 (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 *, bfd_reloc_code_real_type));
 
/* Routines used when writing an object file. */
#define BFD_JUMP_TABLE_WRITE(NAME) \
CONCAT2 (NAME,_set_arch_mach), \
CONCAT2 (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) \
CONCAT2 (NAME,_sizeof_headers), \
CONCAT2 (NAME,_bfd_get_relocated_section_contents), \
CONCAT2 (NAME,_bfd_relax_section), \
CONCAT2 (NAME,_bfd_link_hash_table_create), \
CONCAT2 (NAME,_bfd_link_hash_table_free), \
CONCAT2 (NAME,_bfd_link_add_symbols), \
CONCAT2 (NAME,_bfd_link_just_syms), \
CONCAT2 (NAME,_bfd_final_link), \
CONCAT2 (NAME,_bfd_link_split_section), \
CONCAT2 (NAME,_bfd_gc_sections), \
CONCAT2 (NAME,_bfd_merge_sections), \
CONCAT2 (NAME,_bfd_discard_group)
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 *, boolean, struct symbol_cache_entry **));
 
boolean (*_bfd_relax_section)
PARAMS ((bfd *, struct sec *, struct bfd_link_info *, boolean *));
 
/* 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 *));
 
/* Release the memory associated with the linker hash table. */
void (*_bfd_link_hash_table_free) PARAMS ((struct bfd_link_hash_table *));
 
/* Add symbols from this object file into the hash table. */
boolean (*_bfd_link_add_symbols) PARAMS ((bfd *, struct bfd_link_info *));
 
/* Indicate that we are only retrieving symbol values from this section. */
void (*_bfd_link_just_syms) PARAMS ((asection *, 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 *));
 
/* Attempt to merge SEC_MERGE sections. */
boolean (*_bfd_merge_sections) PARAMS ((bfd *, struct bfd_link_info *));
 
/* Discard members of a group. */
boolean (*_bfd_discard_group) PARAMS ((bfd *, struct sec *));
 
/* Routines to handle dynamic symbols and relocs. */
#define BFD_JUMP_TABLE_DYNAMIC(NAME) \
CONCAT2 (NAME,_get_dynamic_symtab_upper_bound), \
CONCAT2 (NAME,_canonicalize_dynamic_symtab), \
CONCAT2 (NAME,_get_dynamic_reloc_upper_bound), \
CONCAT2 (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;
 
/* Data for use by back-end routines, which isn't
generic enough to belong in this structure. */
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.
 
/bfd.info-1
0,0 → 1,1075
This is bfd.info, produced by makeinfo version 4.1 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, 2000, 2001 Free Software Foundation, Inc.
 
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
 

File: 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
* GNU Free Documentation License:: GNU Free Documentation License
* 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 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... */
ufile_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 with which the BFD was opened. */
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. */
ufile_ptr origin;
/* Remember when output has begun, to stop strange things
from happening. */
boolean output_has_begun;
/* A hash table for section names. */
struct bfd_hash_table section_htab;
/* Pointer to linked list of sections. */
struct sec *sections;
/* The place where we add to the section list. */
struct sec **section_tail;
/* 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 mmo_data_struct *mmo_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_wrong_object_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.
 
`bfd_archive_filename'
......................
 
*Synopsis*
const char *bfd_archive_filename (bfd *);
*Description*
For a BFD that is a component of an archive, returns a string with both
the archive name and file name. For other BFDs, just returns the file
name.
 
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_get_arch_size'
...................
 
*Synopsis*
int bfd_get_arch_size (bfd *abfd);
*Description*
Returns the architecture address size, in bits, as determined by the
object file's format. For ELF, this information is included in the
header.
 
*Returns*
Returns the arch size in bits if known, `-1' otherwise.
 
`bfd_get_sign_extend_vma'
.........................
 
*Synopsis*
int bfd_get_sign_extend_vma (bfd *abfd);
*Description*
Indicates if the target architecture "naturally" sign extends an
address. Some architectures implicitly sign extend address values when
they are converted to types larger than the size of an address. For
instance, bfd_get_start_address() will return an address sign extended
to fill a bfd_vma when this is the case.
 
*Returns*
Returns `1' if the target architecture is known to sign extend
addresses, `0' if the target architecture is known to not sign extend
addresses, and `-1' otherwise.
 
`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*
unsigned 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, unsigned 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.
 
If the value would overflow, the maximum `bfd_vma' value is returned.
 
`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_merge_sections(abfd, link_info) \
BFD_SEND (abfd, _bfd_merge_sections, (abfd, link_info))
#define bfd_discard_group(abfd, sec) \
BFD_SEND (abfd, _bfd_discard_group, (abfd, sec))
#define bfd_link_hash_table_create(abfd) \
BFD_SEND (abfd, _bfd_link_hash_table_create, (abfd))
#define bfd_link_hash_table_free(abfd, hash) \
BFD_SEND (abfd, _bfd_link_hash_table_free, (hash))
#define bfd_link_add_symbols(abfd, info) \
BFD_SEND (abfd, _bfd_link_add_symbols, (abfd, info))
#define bfd_link_just_syms(sec, info) \
BFD_SEND (abfd, _bfd_link_just_syms, (sec, 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 **));
 
`bfd_alt_mach_code'
...................
 
*Synopsis*
boolean bfd_alt_mach_code(bfd *abfd, int alternative);
*Description*
When more than one machine code number is available for the same
machine type, this function can be used to switch between the preferred
one (alternative == 0) and any others. Currently, only ELF supports
this feature, with up to two alternate machine codes.
 
* 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.
 
/archures.texi
0,0 → 1,488
@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
#define bfd_mach_mcf5200 9
#define bfd_mach_mcf5206e 10
#define bfd_mach_mcf5307 11
#define bfd_mach_mcf5407 12
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_or32, /* OpenRISC 32 */
 
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. */
#define bfd_mach_sparc_v8plusb 9 /* with cheetah add'ns. */
#define bfd_mach_sparc_v9b 10 /* with cheetah 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_v9b \
&& (mach) != bfd_mach_sparc_sparclite_le)
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_mips12000 12000
#define bfd_mach_mips16 16
#define bfd_mach_mips5 5
#define bfd_mach_mips_sb1 12310201 /* octal 'SB', 01 */
#define bfd_mach_mipsisa32 32
#define bfd_mach_mipsisa64 64
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
#define bfd_mach_x86_64 3
#define bfd_mach_x86_64_intel_syntax 4
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_pdp11, /* DEC PDP-11 */
bfd_arch_powerpc, /* PowerPC */
#define bfd_mach_ppc 0
#define bfd_mach_ppc64 1
#define bfd_mach_ppc_403 403
#define bfd_mach_ppc_403gc 4030
#define bfd_mach_ppc_505 505
#define bfd_mach_ppc_601 601
#define bfd_mach_ppc_602 602
#define bfd_mach_ppc_603 603
#define bfd_mach_ppc_ec603e 6031
#define bfd_mach_ppc_604 604
#define bfd_mach_ppc_620 620
#define bfd_mach_ppc_630 630
#define bfd_mach_ppc_750 750
#define bfd_mach_ppc_860 860
#define bfd_mach_ppc_a35 35
#define bfd_mach_ppc_rs64ii 642
#define bfd_mach_ppc_rs64iii 643
#define bfd_mach_ppc_7400 7400
#define bfd_mach_ppc_e500 500
bfd_arch_rs6000, /* IBM RS/6000 */
#define bfd_mach_rs6k 0
#define bfd_mach_rs6k_rs1 6001
#define bfd_mach_rs6k_rsc 6003
#define bfd_mach_rs6k_rs2 6002
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_dlx, /* DLX */
bfd_arch_m68hc11, /* Motorola 68HC11 */
bfd_arch_m68hc12, /* Motorola 68HC12 */
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
#define bfd_mach_sh5 0x50
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
#define bfd_mach_arm_5TE 9
#define bfd_mach_arm_XScale 10
bfd_arch_ns32k, /* National Semiconductors ns32000 */
bfd_arch_w65, /* WDC 65816 */
bfd_arch_tic30, /* Texas Instruments TMS320C30 */
bfd_arch_tic4x, /* Texas Instruments TMS320C3X/4X */
#define bfd_mach_c3x 30
#define bfd_mach_c4x 40
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'
bfd_arch_arc, /* ARC Cores */
#define bfd_mach_arc_5 0
#define bfd_mach_arc_6 1
#define bfd_mach_arc_7 2
#define bfd_mach_arc_8 3
bfd_arch_m32r, /* Mitsubishi M32R/D */
#define bfd_mach_m32r 0 /* For 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_frv,
#define bfd_mach_frv 0
#define bfd_mach_frvsimple 1
#define bfd_mach_fr300 300
#define bfd_mach_fr400 400
#define bfd_mach_frvtomcat 499 /* fr500 prototype */
#define bfd_mach_fr500 500
bfd_arch_mcore,
bfd_arch_ia64, /* HP/Intel ia64 */
#define bfd_mach_ia64_elf64 0
#define bfd_mach_ia64_elf32 1
bfd_arch_ip2k, /* Ubicom IP2K microcontrollers. */
#define bfd_mach_ip2022 0
#define bfd_mach_ip2022ext 1
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
#define bfd_mach_avr5 5
bfd_arch_cris, /* Axis CRIS */
bfd_arch_s390, /* IBM s390 */
#define bfd_mach_s390_31 0
#define bfd_mach_s390_64 1
bfd_arch_openrisc, /* OpenRISC */
bfd_arch_mmix, /* Donald Knuth's educational processor. */
bfd_arch_xstormy16,
#define bfd_mach_xstormy16 0
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.
The default arch should be the first entry for an arch so that
all the entries for that arch can be accessed via @code{next}. */
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
 
/bfd.info-2
0,0 → 1,1265
This is bfd.info, produced by makeinfo version 4.1 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, 2000, 2001 Free Software Foundation, Inc.
 
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
 

File: 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;
};
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;
/* A unique sequence number. */
int id;
/* Which section in the bfd; 0..n-1 as sections are created in a bfd. */
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
/* ELF reserves 4 processor specific bits and 8 operating system
specific bits in sh_flags; at present we can get away with just
one in communicating between the assembler and BFD, but this
isn't a good long-term solution. */
#define SEC_ARCH_BIT_0 0x008
/* 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 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 thread local data. */
#define SEC_THREAD_LOCAL 0x1000
/* The section has GOT references. This flag is only for the
linker, and is currently only used by the elf32-hppa back end.
It will be set if global offset table references were detected
in this section, which indicate to the linker that the section
contains PIC code, and must be handled specially when doing a
static link. */
#define SEC_HAS_GOT_REF 0x4000
/* 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 based on the sum of
the symbol and addend values specified by the associated relocation
entries. Entries without associated relocation entries will be
appended to the end of the section in an unspecified order. */
#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
/* Attempt to merge identical entities in the section.
Entity size is given in the entsize field. */
#define SEC_MERGE 0x20000000
/* If given with SEC_MERGE, entities to merge are zero terminated
strings where entsize specifies character size instead of fixed
size entries. */
#define SEC_STRINGS 0x40000000
/* This section contains data about section groups. */
#define SEC_GROUP 0x80000000
/* 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;
/* Another mark flag used by some of the linker backends. Set for
output sections that have an input section. */
unsigned int linker_has_input : 1;
/* A mark flag used by some linker backends for garbage collection. */
unsigned int gc_mark : 1;
/* Used by the ELF code to mark sections which have been allocated
to segments. */
unsigned int segment_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;
/* Entity size for merging purposes. */
unsigned int entsize;
/* 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)
#define bfd_is_const_section(SEC) \
( ((SEC) == bfd_abs_section_ptr) \
|| ((SEC) == bfd_und_section_ptr) \
|| ((SEC) == bfd_com_section_ptr) \
|| ((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))
/* Macros to handle insertion and deletion of a bfd's sections. These
only handle the list pointers, ie. do not adjust section_count,
target_index etc. */
#define bfd_section_list_remove(ABFD, PS) \
do \
{ \
asection **_ps = PS; \
asection *_s = *_ps; \
*_ps = _s->next; \
if (_s->next == NULL) \
(ABFD)->section_tail = _ps; \
} \
while (0)
#define bfd_section_list_insert(ABFD, PS, S) \
do \
{ \
asection **_ps = PS; \
asection *_s = S; \
_s->next = *_ps; \
*_ps = _s; \
if (_s->next == NULL) \
(ABFD)->section_tail = &_s->next; \
} \
while (0)
 

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_section_list_clear'
........................
 
*Synopsis*
void bfd_section_list_clear (bfd *);
*Description*
Clears the section list, and also resets the section count and hash
table entries.
 
`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_get_unique_section_name'
.............................
 
*Synopsis*
char *bfd_get_unique_section_name(bfd *abfd,
const char *templat,
int *count);
*Description*
Invent a section name that is unique in ABFD by tacking a dot and a
digit suffix onto the original TEMPLAT. If COUNT is non-NULL, then it
specifies the first number tried as a suffix to generate a unique name.
The value pointed to by COUNT will be incremented in this case.
 
`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.
 
This function won't actually do anything except twiddle flags if
called too late in the linking process, when it's not safe to remove
sections.
 
`bfd_generic_discard_group'
...........................
 
*Synopsis*
boolean bfd_generic_discard_group (bfd *abfd, asection *group);
*Description*
Remove all members of GROUP from the output.
 

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
/* This symbol is thread local. Used in ELF. */
#define BSF_THREAD_LOCAL 0x40000
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(bfd *abfd, 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_generic_make_empty_symbol'
................................
 
*Synopsis*
asymbol *_bfd_generic_make_empty_symbol (bfd *);
*Description*
Create a new `asymbol' structure for the BFD ABFD and return a pointer
to it. Used by core file routines, binary back-end and anywhere else
where no private info is needed.
 
`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-masse 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::
 
/bfd.info
0,0 → 1,95
This is bfd.info, produced by makeinfo version 4.1 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, 2000, 2001 Free Software Foundation, Inc.
 
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
 

Indirect:
bfd.info-1: 686
bfd.info-2: 39793
bfd.info-3: 87250
bfd.info-4: 103047
bfd.info-5: 147149
bfd.info-6: 195669
bfd.info-7: 232715
bfd.info-8: 272284
bfd.info-9: 290706

Tag Table:
(Indirect)
Node: Top686
Node: Overview1018
Node: History2068
Node: How It Works3009
Node: What BFD Version 2 Can Do4547
Node: BFD information loss5857
Node: Canonical format8380
Node: BFD front end12741
Node: Memory Usage33891
Node: Initialization35114
Node: Sections35491
Node: Section Input35969
Node: Section Output37325
Node: typedef asection39793
Node: section prototypes57838
Node: Symbols64976
Node: Reading Symbols66566
Node: Writing Symbols67740
Node: Mini Symbols69430
Node: typedef asymbol70395
Node: symbol handling functions75437
Node: Archives80102
Node: Formats83720
Node: Relocations86530
Node: typedef arelent87250
Node: howto manager103047
Node: Core Files144165
Node: Targets145186
Node: bfd_target147149
Node: Architectures167223
Node: Opening and Closing183792
Node: Internal188189
Node: File Caching195669
Node: Linker Functions198448
Node: Creating a Linker Hash Table200114
Node: Adding Symbols to the Hash Table201842
Node: Differing file formats202732
Node: Adding symbols from an object file204465
Node: Adding symbols from an archive206601
Node: Performing the Final Link209000
Node: Information provided by the linker210231
Node: Relocating the section contents211367
Node: Writing the symbol table213104
Node: Hash Tables215698
Node: Creating and Freeing a Hash Table216889
Node: Looking Up or Entering a String218046
Node: Traversing a Hash Table219288
Node: Deriving a New Hash Table Type220066
Node: Define the Derived Structures221121
Node: Write the Derived Creation Routine222187
Node: Write Other Derived Routines224886
Node: BFD back ends226186
Node: What to Put Where226452
Node: aout226590
Node: coff232715
Node: elf257448
Node: mmo258285
Node: File layout259208
Node: Symbol-table264846
Node: mmo section mapping268641
Node: GNU Free Documentation License272284
Node: Index290706

End Tag Table
/bfd.info-3
0,0 → 1,430
This is bfd.info, produced by makeinfo version 4.1 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, 2000, 2001 Free Software Foundation, Inc.
 
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
 

File: 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 *, arelent *, struct symbol_cache_entry *, PTR, asection *,
bfd *, char **));
/* 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.
 
/bfd.info-4
0,0 → 1,1420
This is bfd.info, produced by makeinfo version 4.1 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, 2000, 2001 Free Software Foundation, Inc.
 
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
 

File: 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_64_PLT_PCREL
- : BFD_RELOC_32_PLT_PCREL
- : BFD_RELOC_24_PLT_PCREL
- : BFD_RELOC_16_PLT_PCREL
- : BFD_RELOC_8_PLT_PCREL
- : BFD_RELOC_64_PLTOFF
- : 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 <<WDISP30>>.) 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_UA16
- : BFD_RELOC_SPARC_UA32
- : BFD_RELOC_SPARC_UA64
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_PLT32
- : 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)
 
- : 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_ALPHA_GPREL_HI16
- : BFD_RELOC_ALPHA_GPREL_LO16
The GPREL_HI/LO relocations together form a 32-bit offset from the
GP register.
 
- : BFD_RELOC_ALPHA_BRSGP
Like BFD_RELOC_23_PCREL_S2, except that the source and target must
share a common GP, and the target address is adjusted for
STO_ALPHA_STD_GPLOAD.
 
- : BFD_RELOC_ALPHA_TLSGD
- : BFD_RELOC_ALPHA_TLSLDM
- : BFD_RELOC_ALPHA_DTPMOD64
- : BFD_RELOC_ALPHA_GOTDTPREL16
- : BFD_RELOC_ALPHA_DTPREL64
- : BFD_RELOC_ALPHA_DTPREL_HI16
- : BFD_RELOC_ALPHA_DTPREL_LO16
- : BFD_RELOC_ALPHA_DTPREL16
- : BFD_RELOC_ALPHA_GOTTPREL16
- : BFD_RELOC_ALPHA_TPREL64
- : BFD_RELOC_ALPHA_TPREL_HI16
- : BFD_RELOC_ALPHA_TPREL_LO16
- : BFD_RELOC_ALPHA_TPREL16
Alpha thread-local storage relocations.
 
- : 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_LITERAL
Relocation against a MIPS literal section.
 
- : BFD_RELOC_MIPS_GOT16
- : BFD_RELOC_MIPS_CALL16
- : 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
- : BFD_RELOC_MIPS_SHIFT5
- : BFD_RELOC_MIPS_SHIFT6
- : BFD_RELOC_MIPS_INSERT_A
- : BFD_RELOC_MIPS_INSERT_B
- : BFD_RELOC_MIPS_DELETE
- : BFD_RELOC_MIPS_HIGHEST
- : BFD_RELOC_MIPS_HIGHER
- : BFD_RELOC_MIPS_SCN_DISP
- : BFD_RELOC_MIPS_REL16
- : BFD_RELOC_MIPS_RELGOT
- : BFD_RELOC_MIPS_JALR
- : BFD_RELOC_FRV_LABEL16
- : BFD_RELOC_FRV_LABEL24
- : BFD_RELOC_FRV_LO16
- : BFD_RELOC_FRV_HI16
- : BFD_RELOC_FRV_GPREL12
- : BFD_RELOC_FRV_GPRELU12
- : BFD_RELOC_FRV_GPREL32
- : BFD_RELOC_FRV_GPRELHI
- : BFD_RELOC_FRV_GPRELLO
Fujitsu Frv Relocations.
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
- : BFD_RELOC_386_TLS_LE
- : BFD_RELOC_386_TLS_GD
- : BFD_RELOC_386_TLS_LDM
- : BFD_RELOC_386_TLS_LDO_32
- : BFD_RELOC_386_TLS_IE_32
- : BFD_RELOC_386_TLS_LE_32
- : BFD_RELOC_386_TLS_DTPMOD32
- : BFD_RELOC_386_TLS_DTPOFF32
- : BFD_RELOC_386_TLS_TPOFF32
i386/elf relocations
 
- : BFD_RELOC_X86_64_GOT32
- : BFD_RELOC_X86_64_PLT32
- : BFD_RELOC_X86_64_COPY
- : BFD_RELOC_X86_64_GLOB_DAT
- : BFD_RELOC_X86_64_JUMP_SLOT
- : BFD_RELOC_X86_64_RELATIVE
- : BFD_RELOC_X86_64_GOTPCREL
- : BFD_RELOC_X86_64_32S
x86-64/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_PDP11_DISP_8_PCREL
- : BFD_RELOC_PDP11_DISP_6_PCREL
PDP11 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
- : BFD_RELOC_PPC64_HIGHER
- : BFD_RELOC_PPC64_HIGHER_S
- : BFD_RELOC_PPC64_HIGHEST
- : BFD_RELOC_PPC64_HIGHEST_S
- : BFD_RELOC_PPC64_TOC16_LO
- : BFD_RELOC_PPC64_TOC16_HI
- : BFD_RELOC_PPC64_TOC16_HA
- : BFD_RELOC_PPC64_TOC
- : BFD_RELOC_PPC64_PLTGOT16
- : BFD_RELOC_PPC64_PLTGOT16_LO
- : BFD_RELOC_PPC64_PLTGOT16_HI
- : BFD_RELOC_PPC64_PLTGOT16_HA
- : BFD_RELOC_PPC64_ADDR16_DS
- : BFD_RELOC_PPC64_ADDR16_LO_DS
- : BFD_RELOC_PPC64_GOT16_DS
- : BFD_RELOC_PPC64_GOT16_LO_DS
- : BFD_RELOC_PPC64_PLT16_LO_DS
- : BFD_RELOC_PPC64_SECTOFF_DS
- : BFD_RELOC_PPC64_SECTOFF_LO_DS
- : BFD_RELOC_PPC64_TOC16_DS
- : BFD_RELOC_PPC64_TOC16_LO_DS
- : BFD_RELOC_PPC64_PLTGOT16_DS
- : BFD_RELOC_PPC64_PLTGOT16_LO_DS
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
- : BFD_RELOC_SH_COPY
- : BFD_RELOC_SH_GLOB_DAT
- : BFD_RELOC_SH_JMP_SLOT
- : BFD_RELOC_SH_RELATIVE
- : BFD_RELOC_SH_GOTPC
- : BFD_RELOC_SH_GOT_LOW16
- : BFD_RELOC_SH_GOT_MEDLOW16
- : BFD_RELOC_SH_GOT_MEDHI16
- : BFD_RELOC_SH_GOT_HI16
- : BFD_RELOC_SH_GOTPLT_LOW16
- : BFD_RELOC_SH_GOTPLT_MEDLOW16
- : BFD_RELOC_SH_GOTPLT_MEDHI16
- : BFD_RELOC_SH_GOTPLT_HI16
- : BFD_RELOC_SH_PLT_LOW16
- : BFD_RELOC_SH_PLT_MEDLOW16
- : BFD_RELOC_SH_PLT_MEDHI16
- : BFD_RELOC_SH_PLT_HI16
- : BFD_RELOC_SH_GOTOFF_LOW16
- : BFD_RELOC_SH_GOTOFF_MEDLOW16
- : BFD_RELOC_SH_GOTOFF_MEDHI16
- : BFD_RELOC_SH_GOTOFF_HI16
- : BFD_RELOC_SH_GOTPC_LOW16
- : BFD_RELOC_SH_GOTPC_MEDLOW16
- : BFD_RELOC_SH_GOTPC_MEDHI16
- : BFD_RELOC_SH_GOTPC_HI16
- : BFD_RELOC_SH_COPY64
- : BFD_RELOC_SH_GLOB_DAT64
- : BFD_RELOC_SH_JMP_SLOT64
- : BFD_RELOC_SH_RELATIVE64
- : BFD_RELOC_SH_GOT10BY4
- : BFD_RELOC_SH_GOT10BY8
- : BFD_RELOC_SH_GOTPLT10BY4
- : BFD_RELOC_SH_GOTPLT10BY8
- : BFD_RELOC_SH_GOTPLT32
- : BFD_RELOC_SH_SHMEDIA_CODE
- : BFD_RELOC_SH_IMMU5
- : BFD_RELOC_SH_IMMS6
- : BFD_RELOC_SH_IMMS6BY32
- : BFD_RELOC_SH_IMMU6
- : BFD_RELOC_SH_IMMS10
- : BFD_RELOC_SH_IMMS10BY2
- : BFD_RELOC_SH_IMMS10BY4
- : BFD_RELOC_SH_IMMS10BY8
- : BFD_RELOC_SH_IMMS16
- : BFD_RELOC_SH_IMMU16
- : BFD_RELOC_SH_IMM_LOW16
- : BFD_RELOC_SH_IMM_LOW16_PCREL
- : BFD_RELOC_SH_IMM_MEDLOW16
- : BFD_RELOC_SH_IMM_MEDLOW16_PCREL
- : BFD_RELOC_SH_IMM_MEDHI16
- : BFD_RELOC_SH_IMM_MEDHI16_PCREL
- : BFD_RELOC_SH_IMM_HI16
- : BFD_RELOC_SH_IMM_HI16_PCREL
- : BFD_RELOC_SH_PT_16
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
ARC Cores 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_DLX_HI16_S
DLX relocs
 
- : BFD_RELOC_DLX_LO16
DLX relocs
 
- : BFD_RELOC_DLX_JMP26
DLX relocs
 
- : 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_V850_LONGCALL
Used for relaxing indirect function calls.
 
- : BFD_RELOC_V850_LONGJUMP
Used for relaxing indirect jumps.
 
- : BFD_RELOC_V850_ALIGN
Used to maintain alignment whilst relaxing.
 
- : 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_MMIX_GETA
- : BFD_RELOC_MMIX_GETA_1
- : BFD_RELOC_MMIX_GETA_2
- : BFD_RELOC_MMIX_GETA_3
These are relocations for the GETA instruction.
 
- : BFD_RELOC_MMIX_CBRANCH
- : BFD_RELOC_MMIX_CBRANCH_J
- : BFD_RELOC_MMIX_CBRANCH_1
- : BFD_RELOC_MMIX_CBRANCH_2
- : BFD_RELOC_MMIX_CBRANCH_3
These are relocations for a conditional branch instruction.
 
- : BFD_RELOC_MMIX_PUSHJ
- : BFD_RELOC_MMIX_PUSHJ_1
- : BFD_RELOC_MMIX_PUSHJ_2
- : BFD_RELOC_MMIX_PUSHJ_3
These are relocations for the PUSHJ instruction.
 
- : BFD_RELOC_MMIX_JMP
- : BFD_RELOC_MMIX_JMP_1
- : BFD_RELOC_MMIX_JMP_2
- : BFD_RELOC_MMIX_JMP_3
These are relocations for the JMP instruction.
 
- : BFD_RELOC_MMIX_ADDR19
This is a relocation for a relative address as in a GETA
instruction or a branch.
 
- : BFD_RELOC_MMIX_ADDR27
This is a relocation for a relative address as in a JMP
instruction.
 
- : BFD_RELOC_MMIX_REG_OR_BYTE
This is a relocation for an instruction field that may be a general
register or a value 0..255.
 
- : BFD_RELOC_MMIX_REG
This is a relocation for an instruction field that may be a general
register.
 
- : BFD_RELOC_MMIX_BASE_PLUS_OFFSET
This is a relocation for two instruction fields holding a register
and an offset, the equivalent of the relocation.
 
- : BFD_RELOC_MMIX_LOCAL
This relocation is an assertion that the expression is not
allocated as a global register. It does not modify contents.
 
- : 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_390_12
Direct 12 bit.
 
- : BFD_RELOC_390_GOT12
12 bit GOT offset.
 
- : BFD_RELOC_390_PLT32
32 bit PC relative PLT address.
 
- : BFD_RELOC_390_COPY
Copy symbol at runtime.
 
- : BFD_RELOC_390_GLOB_DAT
Create GOT entry.
 
- : BFD_RELOC_390_JMP_SLOT
Create PLT entry.
 
- : BFD_RELOC_390_RELATIVE
Adjust by program base.
 
- : BFD_RELOC_390_GOTPC
32 bit PC relative offset to GOT.
 
- : BFD_RELOC_390_GOT16
16 bit GOT offset.
 
- : BFD_RELOC_390_PC16DBL
PC relative 16 bit shifted by 1.
 
- : BFD_RELOC_390_PLT16DBL
16 bit PC rel. PLT shifted by 1.
 
- : BFD_RELOC_390_PC32DBL
PC relative 32 bit shifted by 1.
 
- : BFD_RELOC_390_PLT32DBL
32 bit PC rel. PLT shifted by 1.
 
- : BFD_RELOC_390_GOTPCDBL
32 bit PC rel. GOT shifted by 1.
 
- : BFD_RELOC_390_GOT64
64 bit GOT offset.
 
- : BFD_RELOC_390_PLT64
64 bit PC relative PLT address.
 
- : BFD_RELOC_390_GOTENT
32 bit rel. offset to GOT entry.
 
- : BFD_RELOC_IP2K_FR9
Scenix IP2K - 9-bit register number / data address
 
- : BFD_RELOC_IP2K_BANK
Scenix IP2K - 4-bit register/data bank number
 
- : BFD_RELOC_IP2K_ADDR16CJP
Scenix IP2K - low 13 bits of instruction word address
 
- : BFD_RELOC_IP2K_PAGE3
Scenix IP2K - high 3 bits of instruction word address
 
- : BFD_RELOC_IP2K_LO8DATA
- : BFD_RELOC_IP2K_HI8DATA
- : BFD_RELOC_IP2K_EX8DATA
Scenix IP2K - ext/low/high 8 bits of data address
 
- : BFD_RELOC_IP2K_LO8INSN
- : BFD_RELOC_IP2K_HI8INSN
Scenix IP2K - low/high 8 bits of instruction word address
 
- : BFD_RELOC_IP2K_PC_SKIP
Scenix IP2K - even/odd PC modifier to modify snb pcl.0
 
- : BFD_RELOC_IP2K_TEXT
Scenix IP2K - 16 bit word address in text section.
 
- : BFD_RELOC_IP2K_FR_OFFSET
Scenix IP2K - 7-bit sp or dp offset
 
- : BFD_RELOC_VPE4KMATH_DATA
- : BFD_RELOC_VPE4KMATH_INSN
Scenix VPE4K coprocessor - data/insn-space addressing
 
- : 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.
 
- : BFD_RELOC_IA64_IMM14
- : BFD_RELOC_IA64_IMM22
- : BFD_RELOC_IA64_IMM64
- : BFD_RELOC_IA64_DIR32MSB
- : BFD_RELOC_IA64_DIR32LSB
- : BFD_RELOC_IA64_DIR64MSB
- : BFD_RELOC_IA64_DIR64LSB
- : BFD_RELOC_IA64_GPREL22
- : BFD_RELOC_IA64_GPREL64I
- : BFD_RELOC_IA64_GPREL32MSB
- : BFD_RELOC_IA64_GPREL32LSB
- : BFD_RELOC_IA64_GPREL64MSB
- : BFD_RELOC_IA64_GPREL64LSB
- : BFD_RELOC_IA64_LTOFF22
- : BFD_RELOC_IA64_LTOFF64I
- : BFD_RELOC_IA64_PLTOFF22
- : BFD_RELOC_IA64_PLTOFF64I
- : BFD_RELOC_IA64_PLTOFF64MSB
- : BFD_RELOC_IA64_PLTOFF64LSB
- : BFD_RELOC_IA64_FPTR64I
- : BFD_RELOC_IA64_FPTR32MSB
- : BFD_RELOC_IA64_FPTR32LSB
- : BFD_RELOC_IA64_FPTR64MSB
- : BFD_RELOC_IA64_FPTR64LSB
- : BFD_RELOC_IA64_PCREL21B
- : BFD_RELOC_IA64_PCREL21BI
- : BFD_RELOC_IA64_PCREL21M
- : BFD_RELOC_IA64_PCREL21F
- : BFD_RELOC_IA64_PCREL22
- : BFD_RELOC_IA64_PCREL60B
- : BFD_RELOC_IA64_PCREL64I
- : BFD_RELOC_IA64_PCREL32MSB
- : BFD_RELOC_IA64_PCREL32LSB
- : BFD_RELOC_IA64_PCREL64MSB
- : BFD_RELOC_IA64_PCREL64LSB
- : BFD_RELOC_IA64_LTOFF_FPTR22
- : BFD_RELOC_IA64_LTOFF_FPTR64I
- : BFD_RELOC_IA64_LTOFF_FPTR32MSB
- : BFD_RELOC_IA64_LTOFF_FPTR32LSB
- : BFD_RELOC_IA64_LTOFF_FPTR64MSB
- : BFD_RELOC_IA64_LTOFF_FPTR64LSB
- : BFD_RELOC_IA64_SEGREL32MSB
- : BFD_RELOC_IA64_SEGREL32LSB
- : BFD_RELOC_IA64_SEGREL64MSB
- : BFD_RELOC_IA64_SEGREL64LSB
- : BFD_RELOC_IA64_SECREL32MSB
- : BFD_RELOC_IA64_SECREL32LSB
- : BFD_RELOC_IA64_SECREL64MSB
- : BFD_RELOC_IA64_SECREL64LSB
- : BFD_RELOC_IA64_REL32MSB
- : BFD_RELOC_IA64_REL32LSB
- : BFD_RELOC_IA64_REL64MSB
- : BFD_RELOC_IA64_REL64LSB
- : BFD_RELOC_IA64_LTV32MSB
- : BFD_RELOC_IA64_LTV32LSB
- : BFD_RELOC_IA64_LTV64MSB
- : BFD_RELOC_IA64_LTV64LSB
- : BFD_RELOC_IA64_IPLTMSB
- : BFD_RELOC_IA64_IPLTLSB
- : BFD_RELOC_IA64_COPY
- : BFD_RELOC_IA64_LTOFF22X
- : BFD_RELOC_IA64_LDXMOV
- : BFD_RELOC_IA64_TPREL14
- : BFD_RELOC_IA64_TPREL22
- : BFD_RELOC_IA64_TPREL64I
- : BFD_RELOC_IA64_TPREL64MSB
- : BFD_RELOC_IA64_TPREL64LSB
- : BFD_RELOC_IA64_LTOFF_TPREL22
- : BFD_RELOC_IA64_DTPMOD64MSB
- : BFD_RELOC_IA64_DTPMOD64LSB
- : BFD_RELOC_IA64_LTOFF_DTPMOD22
- : BFD_RELOC_IA64_DTPREL14
- : BFD_RELOC_IA64_DTPREL22
- : BFD_RELOC_IA64_DTPREL64I
- : BFD_RELOC_IA64_DTPREL32MSB
- : BFD_RELOC_IA64_DTPREL32LSB
- : BFD_RELOC_IA64_DTPREL64MSB
- : BFD_RELOC_IA64_DTPREL64LSB
- : BFD_RELOC_IA64_LTOFF_DTPREL22
Intel IA64 Relocations.
 
- : BFD_RELOC_M68HC11_HI8
Motorola 68HC11 reloc. This is the 8 bit high part of an absolute
address.
 
- : BFD_RELOC_M68HC11_LO8
Motorola 68HC11 reloc. This is the 8 bit low part of an absolute
address.
 
- : BFD_RELOC_M68HC11_3B
Motorola 68HC11 reloc. This is the 3 bit of a value.
 
- : BFD_RELOC_M68HC11_RL_JUMP
Motorola 68HC11 reloc. This reloc marks the beginning of a
jump/call instruction. It is used for linker relaxation to
correctly identify beginning of instruction and change some
branchs to use PC-relative addressing mode.
 
- : BFD_RELOC_M68HC11_RL_GROUP
Motorola 68HC11 reloc. This reloc marks a group of several
instructions that gcc generates and for which the linker
relaxation pass can modify and/or remove some of them.
 
- : BFD_RELOC_M68HC11_LO16
Motorola 68HC11 reloc. This is the 16-bit lower part of an
address. It is used for 'call' instruction to specify the symbol
address without any special transformation (due to memory bank
window).
 
- : BFD_RELOC_M68HC11_PAGE
Motorola 68HC11 reloc. This is a 8-bit reloc that specifies the
page number of an address. It is used by 'call' instruction to
specify the page number of the symbol.
 
- : BFD_RELOC_M68HC11_24
Motorola 68HC11 reloc. This is a 24-bit reloc that represents the
address with a 16-bit value and a 8-bit page number. The symbol
address is transformed to follow the 16K memory bank of 68HC12
(seen as mapped in the window).
 
- : BFD_RELOC_CRIS_BDISP8
- : BFD_RELOC_CRIS_UNSIGNED_5
- : BFD_RELOC_CRIS_SIGNED_6
- : BFD_RELOC_CRIS_UNSIGNED_6
- : BFD_RELOC_CRIS_UNSIGNED_4
These relocs are only used within the CRIS assembler. They are not
(at present) written to any object files.
 
- : BFD_RELOC_CRIS_COPY
- : BFD_RELOC_CRIS_GLOB_DAT
- : BFD_RELOC_CRIS_JUMP_SLOT
- : BFD_RELOC_CRIS_RELATIVE
Relocs used in ELF shared libraries for CRIS.
 
- : BFD_RELOC_CRIS_32_GOT
32-bit offset to symbol-entry within GOT.
 
- : BFD_RELOC_CRIS_16_GOT
16-bit offset to symbol-entry within GOT.
 
- : BFD_RELOC_CRIS_32_GOTPLT
32-bit offset to symbol-entry within GOT, with PLT handling.
 
- : BFD_RELOC_CRIS_16_GOTPLT
16-bit offset to symbol-entry within GOT, with PLT handling.
 
- : BFD_RELOC_CRIS_32_GOTREL
32-bit offset to symbol, relative to GOT.
 
- : BFD_RELOC_CRIS_32_PLT_GOTREL
32-bit offset to symbol with PLT entry, relative to GOT.
 
- : BFD_RELOC_CRIS_32_PLT_PCREL
32-bit offset to symbol with PLT entry, relative to this
relocation.
 
- : BFD_RELOC_860_COPY
- : BFD_RELOC_860_GLOB_DAT
- : BFD_RELOC_860_JUMP_SLOT
- : BFD_RELOC_860_RELATIVE
- : BFD_RELOC_860_PC26
- : BFD_RELOC_860_PLT26
- : BFD_RELOC_860_PC16
- : BFD_RELOC_860_LOW0
- : BFD_RELOC_860_SPLIT0
- : BFD_RELOC_860_LOW1
- : BFD_RELOC_860_SPLIT1
- : BFD_RELOC_860_LOW2
- : BFD_RELOC_860_SPLIT2
- : BFD_RELOC_860_LOW3
- : BFD_RELOC_860_LOGOT0
- : BFD_RELOC_860_SPGOT0
- : BFD_RELOC_860_LOGOT1
- : BFD_RELOC_860_SPGOT1
- : BFD_RELOC_860_LOGOTOFF0
- : BFD_RELOC_860_SPGOTOFF0
- : BFD_RELOC_860_LOGOTOFF1
- : BFD_RELOC_860_SPGOTOFF1
- : BFD_RELOC_860_LOGOTOFF2
- : BFD_RELOC_860_LOGOTOFF3
- : BFD_RELOC_860_LOPC
- : BFD_RELOC_860_HIGHADJ
- : BFD_RELOC_860_HAGOT
- : BFD_RELOC_860_HAGOTOFF
- : BFD_RELOC_860_HAPC
- : BFD_RELOC_860_HIGH
- : BFD_RELOC_860_HIGOT
- : BFD_RELOC_860_HIGOTOFF
Intel i860 Relocations.
 
- : BFD_RELOC_OPENRISC_ABS_26
- : BFD_RELOC_OPENRISC_REL_26
OpenRISC Relocations.
 
- : BFD_RELOC_H8_DIR16A8
- : BFD_RELOC_H8_DIR16R8
- : BFD_RELOC_H8_DIR24A8
- : BFD_RELOC_H8_DIR24R8
- : BFD_RELOC_H8_DIR32A16
H8 elf Relocations.
 
- : BFD_RELOC_XSTORMY16_REL_12
- : BFD_RELOC_XSTORMY16_24
- : BFD_RELOC_XSTORMY16_FPTR16
Sony Xstormy16 Relocations.
 
- : BFD_RELOC_VAX_GLOB_DAT
- : BFD_RELOC_VAX_JMP_SLOT
- : BFD_RELOC_VAX_RELATIVE
Relocations used by VAX ELF.
 
 
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_merge_sections'
............................
 
*Synopsis*
boolean bfd_generic_merge_sections
(bfd *, struct bfd_link_info *);
*Description*
Provides default handling for SEC_MERGE section merging for back ends
which don't have SEC_MERGE support - 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::
 
/ChangeLog
0,0 → 1,548
2002-08-29 John David Anglin <dave@hiauly1.hia.nrc.ca>
 
* chew.c (paramstuff, outputdots, perform, bang and usage): Remove
void from function definitions.
 
2002-08-13 Alan Modra <amodra@bigpond.net.au>
 
* header.sed: Strip tabs.
 
2002-06-08 Alan Modra <amodra@bigpond.net.au>
 
* Makefile.am: Fix quote style in last change.
* Makefile.in: Regenerate.
 
2002-06-07 Alan Modra <amodra@bigpond.net.au>
 
* Makefile.am (libbfd.h): Don't use "echo -n".
(libcoff.h, bfd.h): Likewise.
* Makefile.in: Regenerate.
 
2002-06-06 Lars Brinkhoff <lars@nocrew.org>
 
* bfdint.texi: Change registry@sco.com to registry@caldera.com.
 
2002-06-05 Alan Modra <amodra@bigpond.net.au>
 
* Makefile.am (libbfd.h): Add "Extracted from.." comment.
(libcoff.h, bfd.h): Likewise.
* Makefile.in: Regenerate.
 
2002-05-25 Alan Modra <amodra@bigpond.net.au>
 
* chew.c: Use #include "" instead of <> for local header files.
 
2002-04-20 Alan Modra <amodra@bigpond.net.au>
 
* Makefile.in: Regenerate.
 
2002-02-11 Alan Modra <amodra@bigpond.net.au>
 
* Makefile.in: Regenerate.
 
2002-02-01 Alan Modra <amodra@bigpond.net.au>
 
* chew.c (WORD): Eliminate.
 
2002-01-31 Ivan Guzvinec <ivang@opencores.org>
 
* Makefile.in: Regenerate.
 
2002-01-31 Alan Modra <amodra@bigpond.net.au>
 
* chew.c (courierize): Don't modify @command params.
 
2002-01-30 Nick Clifton <nickc@cambridge.redhat.com>
 
* proto.str (ENUMDOC): Place two spaces between the end of
the text and the closing comment marker.
 
2001-10-30 Hans-Peter Nilsson <hp@bitrange.com>
 
* bfdint.texi (BFD target vector miscellaneous): Add
bfd_target_mmo_flavour.
* bfd.texinfo (BFD back ends): Add entry for mmo.
* Makefile.am (DOCFILES): Add mmo.texi.
(SRCDOC): Add mmo.c.
(s-mmo, mmo.texi): New rules.
 
2001-10-29 Kazu Hirata <kazu@hxi.com>
 
* bfdsumm.texi: Fix a typo.
 
2001-10-26 Nick Clifton <nickc@cambridge.redhat.com>
 
* bfd.texinfo: Change footer to refer to FSF. Change subtitle
to refer to original creation date.
 
2002-01-26 Hans-Peter Nilsson <hp@bitrange.com>
 
* Makefile.am (install): Depend on install-info.
* Makefile.in: Regenerate.
 
2001-10-03 Alan Modra <amodra@bigpond.net.au>
 
* Makefile.am (BFD_H_DEP): Add ../version.h.
* Makefile.in: Regenerate.
 
2001-10-02 Alan Modra <amodra@bigpond.net.au>
 
* Makefile.in: Regenerate.
 
2001-10-01 Alan Modra <amodra@bigpond.net.au>
 
* header.sed: New file, adds header to generated files.
* Makefile.am: Rewrite rules generating libbfd.h, libcoff.h and
bfd.h, using above. Add missing elf.c dependecy for libbfd.h.
* Makefile.in: Regenerate.
 
2001-09-21 Alan Modra <amodra@bigpond.net.au>
 
* Makefile.in: Regenerate.
 
2001-09-18 Alan Modra <amodra@bigpond.net.au>
 
* bfdint.texi: Replace reference to bfd_read with bfd_bread.
Likewise for bfd_write.
 
2001-07-24 Alan Modra <amodra@bigpond.net.au>
 
* Makefile.in: Regenerate.
 
2001-06-21 Hans-Peter Nilsson <hp@axis.com>
 
* bfdint.texi (BFD relocation functions) <different formats>:
Mention that the GNU linker is aware of input-output format
restrictions when generating relocatable output. Make new
paragraph for final-link case.
(BFD target vector swap): Fix typo.
 
2001-01-25 Kazu Hirata <kazu@hxi.com>
 
* chew.c: Do not output trailing whitespaces in type and
functionname. Update copyright.
 
2001-01-24 Kazu Hirata <kazu@hxi.com>
 
* chew.c: Do not output a trailing whitespace.
 
2000-11-06 Nick Clifton <nickc@redhat.com>
 
* bfd.texinfo: Add GNU Free Documentation License.
 
2000-07-09 Alan Modra <alan@linuxcare.com.au>
 
* Makefile.in: Regenerate.
 
2000-07-08 Alan Modra <alan@linuxcare.com.au>
 
* chew.c (outputdots): Don't add a space before `/*'.
(courierize): Likewise.
 
Wed May 24 12:03:25 2000 Hans-Peter Nilsson <hp@axis.com>
 
* bfdint.texi (BFD ELF processor required): Add paragraph about
target necessities for readelf.
 
2000-04-30 Ben Elliston <bje@redhat.com>
 
* bfdint.texi (BFD generated files): Fix another typo.
 
2000-04-17 Ben Elliston <bje@redhat.com>
 
* bfdint.texi (BFD_JUMP_TABLE macros): Fix typo.
 
Fri Apr 7 17:54:38 2000 Andrew Cagney <cagney@b1.cygnus.com>
 
* Makefile.in: Rebuild with current autoconf/automake.
 
Thu Feb 4 23:21:36 1999 Ian Lance Taylor <ian@cygnus.com>
 
* Makefile.in: Rebuild with current autoconf/automake.
 
Thu Jul 23 09:36:44 1998 Nick Clifton <nickc@cygnus.com>
 
* 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 <ian@cygnus.com>
 
* 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 <ian@cygnus.com>
 
* bfdint.texi: New file.
* Makefile.am (noinst_TEXINFOS): New variable.
* Makefile.in: Rebuild.
 
Mon Apr 13 16:48:56 1998 Ian Lance Taylor <ian@cygnus.com>
 
* Makefile.in: Rebuild.
 
Mon Apr 6 14:06:55 1998 Ian Lance Taylor <ian@cygnus.com>
 
* 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 <ian@cygnus.com>
 
* 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 <ian@cygnus.com>
 
* Makefile.am (AUTOMAKE_OPTIONS): Define.
* Makefile.in: Rebuild.
 
Mon Jan 26 15:38:36 1998 Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>
 
* 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 <ian@cygnus.com>
 
* 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 <dje@canuck.cygnus.com>
 
* Makefile.am (libbfd.h, libcoff.h): Invoke $(MKDOC) as ./$(MKDOC).
* Makefile.in: Rebuild.
 
Fri Aug 1 12:59:58 1997 Ian Lance Taylor <ian@cygnus.com>
 
* Makefile.am (CC_FOR_BUILD): Don't set explicitly.
* Makefile.in: Rebuild.
 
Thu Jul 31 20:00:12 1997 Ian Lance Taylor <ian@cygnus.com>
 
* Makefile.am: New file, based on old Makefile.in.
* Makefile.in: Now built with automake.
 
Tue Jul 22 14:44:00 1997 Robert Hoehne <robert.hoehne@Mathematik.TU-Chemnitz.DE>
 
* 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 <ian@cygnus.com>
 
* Makefile.in (CC, CFLAGS): Substitute from configure script.
From Jeff Makey <jeff@cts.com>.
 
Tue Apr 15 12:37:41 1997 Ian Lance Taylor <ian@cygnus.com>
 
* Makefile.in (install-info): Use mkinstalldirs to build
$(infodir).
 
Tue Apr 8 12:49:46 1997 Ian Lance Taylor <ian@cygnus.com>
 
* 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 <ian@cygnus.com>
 
* 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 <ian@cygnus.com>
 
* chew.c (kill_bogus_lines): Reset sl when not at the start of a
line. From Uwe Ohse <uwe@tirka.gun.de>.
 
Tue Jan 30 14:10:46 1996 Ian Lance Taylor <ian@cygnus.com>
 
From Ronald F. Guilmette <rfg@monkeys.com>:
* Makefile.in (libbfd.h): Depend upon proto.str.
(libcoff.h, bfd.h): Likewise.
 
Fri Nov 3 14:46:48 1995 Fred Fish <fnf@cygnus.com>
 
* 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 <manfred@lts.sel.alcatel.de>
 
* chew.c: Include <ctype.h>.
 
Fri Oct 6 16:23:34 1995 Ken Raeburn <raeburn@cygnus.com>
 
Mon Sep 25 22:49:32 1995 Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>
 
* Makefile.in (Makefile): Only remake this Makefile.
 
Wed Oct 4 15:51:05 1995 Ken Raeburn <raeburn@cygnus.com>
 
* chew.c: Include <stdio.h>.
 
Tue Sep 12 18:14:50 1995 Ian Lance Taylor <ian@cygnus.com>
 
* Makefile.in (maintainer-clean): New target.
 
Thu Aug 31 12:18:43 1995 Ian Lance Taylor <ian@cygnus.com>
 
* 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 <dje@canuck.cygnus.com>
 
* 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.
* 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.
 
* chew.c (exfunstuff): Eliminate.
(paramstuff): Replace exfunstuff with function to generate PARAMS.
* 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:
/bfd.info-5
0,0 → 1,1253
This is bfd.info, produced by makeinfo version 4.1 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, 2000, 2001 Free Software Foundation, Inc.
 
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
 

File: 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_xcoff_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,
bfd_target_mmo_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. */
Do not "beautify" the CONCAT* macro args. Traditional C will not
remove whitespace added here, and thus will fail to concatenate the
tokens.
#define BFD_JUMP_TABLE_GENERIC(NAME) \
CONCAT2 (NAME,_close_and_cleanup), \
CONCAT2 (NAME,_bfd_free_cached_info), \
CONCAT2 (NAME,_new_section_hook), \
CONCAT2 (NAME,_get_section_contents), \
CONCAT2 (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) \
CONCAT2 (NAME,_bfd_copy_private_bfd_data), \
CONCAT2 (NAME,_bfd_merge_private_bfd_data), \
CONCAT2 (NAME,_bfd_copy_private_section_data), \
CONCAT2 (NAME,_bfd_copy_private_symbol_data), \
CONCAT2 (NAME,_bfd_set_private_flags), \
CONCAT2 (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) \
CONCAT2 (NAME,_core_file_failing_command), \
CONCAT2 (NAME,_core_file_failing_signal), \
CONCAT2 (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) \
CONCAT2 (NAME,_slurp_armap), \
CONCAT2 (NAME,_slurp_extended_name_table), \
CONCAT2 (NAME,_construct_extended_name_table), \
CONCAT2 (NAME,_truncate_arname), \
CONCAT2 (NAME,_write_armap), \
CONCAT2 (NAME,_read_ar_hdr), \
CONCAT2 (NAME,_openr_next_archived_file), \
CONCAT2 (NAME,_get_elt_at_index), \
CONCAT2 (NAME,_generic_stat_arch_elt), \
CONCAT2 (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 *, unsigned int, struct orl *, unsigned int, int));
PTR (*_bfd_read_ar_hdr_fn) PARAMS ((bfd *));
bfd * (*openr_next_archived_file) PARAMS ((bfd *, bfd *));
#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) \
CONCAT2 (NAME,_get_symtab_upper_bound), \
CONCAT2 (NAME,_get_symtab), \
CONCAT2 (NAME,_make_empty_symbol), \
CONCAT2 (NAME,_print_symbol), \
CONCAT2 (NAME,_get_symbol_info), \
CONCAT2 (NAME,_bfd_is_local_label_name), \
CONCAT2 (NAME,_get_lineno), \
CONCAT2 (NAME,_find_nearest_line), \
CONCAT2 (NAME,_bfd_make_debug_symbol), \
CONCAT2 (NAME,_read_minisymbols), \
CONCAT2 (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 *, struct sec *, struct symbol_cache_entry **, bfd_vma,
const char **, const char **, unsigned int *));
/* 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 *, void *,
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) \
CONCAT2 (NAME,_get_reloc_upper_bound), \
CONCAT2 (NAME,_canonicalize_reloc), \
CONCAT2 (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 *, bfd_reloc_code_real_type));
/* Routines used when writing an object file. */
#define BFD_JUMP_TABLE_WRITE(NAME) \
CONCAT2 (NAME,_set_arch_mach), \
CONCAT2 (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) \
CONCAT2 (NAME,_sizeof_headers), \
CONCAT2 (NAME,_bfd_get_relocated_section_contents), \
CONCAT2 (NAME,_bfd_relax_section), \
CONCAT2 (NAME,_bfd_link_hash_table_create), \
CONCAT2 (NAME,_bfd_link_hash_table_free), \
CONCAT2 (NAME,_bfd_link_add_symbols), \
CONCAT2 (NAME,_bfd_link_just_syms), \
CONCAT2 (NAME,_bfd_final_link), \
CONCAT2 (NAME,_bfd_link_split_section), \
CONCAT2 (NAME,_bfd_gc_sections), \
CONCAT2 (NAME,_bfd_merge_sections), \
CONCAT2 (NAME,_bfd_discard_group)
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 *, boolean, struct symbol_cache_entry **));
boolean (*_bfd_relax_section)
PARAMS ((bfd *, struct sec *, struct bfd_link_info *, boolean *));
/* 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 *));
/* Release the memory associated with the linker hash table. */
void (*_bfd_link_hash_table_free) PARAMS ((struct bfd_link_hash_table *));
/* Add symbols from this object file into the hash table. */
boolean (*_bfd_link_add_symbols) PARAMS ((bfd *, struct bfd_link_info *));
/* Indicate that we are only retrieving symbol values from this section. */
void (*_bfd_link_just_syms) PARAMS ((asection *, 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 *));
/* Attempt to merge SEC_MERGE sections. */
boolean (*_bfd_merge_sections) PARAMS ((bfd *, struct bfd_link_info *));
/* Discard members of a group. */
boolean (*_bfd_discard_group) PARAMS ((bfd *, struct sec *));
/* Routines to handle dynamic symbols and relocs. */
#define BFD_JUMP_TABLE_DYNAMIC(NAME) \
CONCAT2 (NAME,_get_dynamic_symtab_upper_bound), \
CONCAT2 (NAME,_canonicalize_dynamic_symtab), \
CONCAT2 (NAME,_get_dynamic_reloc_upper_bound), \
CONCAT2 (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
#define bfd_mach_mcf5200 9
#define bfd_mach_mcf5206e 10
#define bfd_mach_mcf5307 11
#define bfd_mach_mcf5407 12
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_or32, /* OpenRISC 32 */
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. */
#define bfd_mach_sparc_v8plusb 9 /* with cheetah add'ns. */
#define bfd_mach_sparc_v9b 10 /* with cheetah 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_v9b \
&& (mach) != bfd_mach_sparc_sparclite_le)
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_mips12000 12000
#define bfd_mach_mips16 16
#define bfd_mach_mips5 5
#define bfd_mach_mips_sb1 12310201 /* octal 'SB', 01 */
#define bfd_mach_mipsisa32 32
#define bfd_mach_mipsisa64 64
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
#define bfd_mach_x86_64 3
#define bfd_mach_x86_64_intel_syntax 4
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_pdp11, /* DEC PDP-11 */
bfd_arch_powerpc, /* PowerPC */
#define bfd_mach_ppc 0
#define bfd_mach_ppc64 1
#define bfd_mach_ppc_403 403
#define bfd_mach_ppc_403gc 4030
#define bfd_mach_ppc_505 505
#define bfd_mach_ppc_601 601
#define bfd_mach_ppc_602 602
#define bfd_mach_ppc_603 603
#define bfd_mach_ppc_ec603e 6031
#define bfd_mach_ppc_604 604
#define bfd_mach_ppc_620 620
#define bfd_mach_ppc_630 630
#define bfd_mach_ppc_750 750
#define bfd_mach_ppc_860 860
#define bfd_mach_ppc_a35 35
#define bfd_mach_ppc_rs64ii 642
#define bfd_mach_ppc_rs64iii 643
#define bfd_mach_ppc_7400 7400
#define bfd_mach_ppc_e500 500
bfd_arch_rs6000, /* IBM RS/6000 */
#define bfd_mach_rs6k 0
#define bfd_mach_rs6k_rs1 6001
#define bfd_mach_rs6k_rsc 6003
#define bfd_mach_rs6k_rs2 6002
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_dlx, /* DLX */
bfd_arch_m68hc11, /* Motorola 68HC11 */
bfd_arch_m68hc12, /* Motorola 68HC12 */
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
#define bfd_mach_sh5 0x50
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
#define bfd_mach_arm_5TE 9
#define bfd_mach_arm_XScale 10
bfd_arch_ns32k, /* National Semiconductors ns32000 */
bfd_arch_w65, /* WDC 65816 */
bfd_arch_tic30, /* Texas Instruments TMS320C30 */
bfd_arch_tic4x, /* Texas Instruments TMS320C3X/4X */
#define bfd_mach_c3x 30
#define bfd_mach_c4x 40
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'
bfd_arch_arc, /* ARC Cores */
#define bfd_mach_arc_5 0
#define bfd_mach_arc_6 1
#define bfd_mach_arc_7 2
#define bfd_mach_arc_8 3
bfd_arch_m32r, /* Mitsubishi M32R/D */
#define bfd_mach_m32r 0 /* For 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_frv,
#define bfd_mach_frv 0
#define bfd_mach_frvsimple 1
#define bfd_mach_fr300 300
#define bfd_mach_fr400 400
#define bfd_mach_frvtomcat 499 /* fr500 prototype */
#define bfd_mach_fr500 500
bfd_arch_mcore,
bfd_arch_ia64, /* HP/Intel ia64 */
#define bfd_mach_ia64_elf64 0
#define bfd_mach_ia64_elf32 1
bfd_arch_ip2k, /* Ubicom IP2K microcontrollers. */
#define bfd_mach_ip2022 0
#define bfd_mach_ip2022ext 1
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
#define bfd_mach_avr5 5
bfd_arch_cris, /* Axis CRIS */
bfd_arch_s390, /* IBM s390 */
#define bfd_mach_s390_31 0
#define bfd_mach_s390_64 1
bfd_arch_openrisc, /* OpenRISC */
bfd_arch_mmix, /* Donald Knuth's educational processor. */
bfd_arch_xstormy16,
#define bfd_mach_xstormy16 0
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.
The default arch should be the first entry for an arch so that
all the entries for that arch can be accessed via `next'. */
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*
boolean bfd_write_bigendian_4byte_int (bfd *, unsigned int);
*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) & 0xff)
#define bfd_get_signed_8(abfd, ptr) \
(((*(unsigned char *) (ptr) & 0xff) ^ 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_vma) 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' brethren,
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))
/* Refinements on the above, which should eventually go away. Save
cluttering the source with (bfd_vma) and (bfd_byte *) casts. */
#define H_PUT_64(abfd, val, where) \
bfd_h_put_64 ((abfd), (bfd_vma) (val), (bfd_byte *) (where))
#define H_PUT_32(abfd, val, where) \
bfd_h_put_32 ((abfd), (bfd_vma) (val), (bfd_byte *) (where))
#define H_PUT_16(abfd, val, where) \
bfd_h_put_16 ((abfd), (bfd_vma) (val), (bfd_byte *) (where))
#define H_PUT_8 bfd_h_put_8
#define H_PUT_S64(abfd, val, where) \
bfd_h_put_signed_64 ((abfd), (bfd_vma) (val), (bfd_byte *) (where))
#define H_PUT_S32(abfd, val, where) \
bfd_h_put_signed_32 ((abfd), (bfd_vma) (val), (bfd_byte *) (where))
#define H_PUT_S16(abfd, val, where) \
bfd_h_put_signed_16 ((abfd), (bfd_vma) (val), (bfd_byte *) (where))
#define H_PUT_S8 bfd_h_put_signed_8
#define H_GET_64(abfd, where) \
bfd_h_get_64 ((abfd), (bfd_byte *) (where))
#define H_GET_32(abfd, where) \
bfd_h_get_32 ((abfd), (bfd_byte *) (where))
#define H_GET_16(abfd, where) \
bfd_h_get_16 ((abfd), (bfd_byte *) (where))
#define H_GET_8 bfd_h_get_8
#define H_GET_S64(abfd, where) \
bfd_h_get_signed_64 ((abfd), (bfd_byte *) (where))
#define H_GET_S32(abfd, where) \
bfd_h_get_signed_32 ((abfd), (bfd_byte *) (where))
#define H_GET_S16(abfd, where) \
bfd_h_get_signed_16 ((abfd), (bfd_byte *) (where))
#define H_GET_S8 bfd_h_get_signed_8
 
`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. A X of 0 returns 0.
 
/bfd.info-6
0,0 → 1,914
This is bfd.info, produced by makeinfo version 4.1 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, 2000, 2001 Free Software Foundation, Inc.
 
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
 

File: 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::
 

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: GNU Free Documentation License, Prev: BFD front end, Up: Top
 
BFD back ends
*************
 
* Menu:
 
* What to Put Where::
* aout :: a.out backends
* coff :: coff backends
* elf :: elf backends
* mmo :: mmo backend
 

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.
 
/bfd.info-7
0,0 → 1,970
This is bfd.info, produced by makeinfo version 4.1 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, 2000, 2001 Free Software Foundation, Inc.
 
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
 

File: 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 *, PTR, int, int, int, int, PTR));
void (*_bfd_coff_swap_sym_in)
PARAMS ((bfd *, PTR, PTR));
void (*_bfd_coff_swap_lineno_in)
PARAMS ((bfd *, PTR, PTR));
unsigned int (*_bfd_coff_swap_aux_out)
PARAMS ((bfd *, PTR, int, int, int, int, PTR));
unsigned int (*_bfd_coff_swap_sym_out)
PARAMS ((bfd *, PTR, PTR));
unsigned int (*_bfd_coff_swap_lineno_out)
PARAMS ((bfd *, PTR, PTR));
unsigned int (*_bfd_coff_swap_reloc_out)
PARAMS ((bfd *, PTR, PTR));
unsigned int (*_bfd_coff_swap_filehdr_out)
PARAMS ((bfd *, PTR, PTR));
unsigned int (*_bfd_coff_swap_aouthdr_out)
PARAMS ((bfd *, PTR, PTR));
unsigned int (*_bfd_coff_swap_scnhdr_out)
PARAMS ((bfd *, PTR, PTR));
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;
boolean _bfd_coff_force_symnames_in_strings;
unsigned int _bfd_coff_debug_string_prefix_length;
void (*_bfd_coff_swap_filehdr_in)
PARAMS ((bfd *, PTR, PTR));
void (*_bfd_coff_swap_aouthdr_in)
PARAMS ((bfd *, PTR, PTR));
void (*_bfd_coff_swap_scnhdr_in)
PARAMS ((bfd *, PTR, PTR));
void (*_bfd_coff_swap_reloc_in)
PARAMS ((bfd *abfd, PTR, PTR));
boolean (*_bfd_coff_bad_format_hook)
PARAMS ((bfd *, PTR));
boolean (*_bfd_coff_set_arch_mach_hook)
PARAMS ((bfd *, PTR));
PTR (*_bfd_coff_mkobject_hook)
PARAMS ((bfd *, PTR, PTR));
boolean (*_bfd_styp_to_sec_flags_hook)
PARAMS ((bfd *, PTR, const char *, asection *, flagword *));
void (*_bfd_set_alignment_hook)
PARAMS ((bfd *, asection *, PTR));
boolean (*_bfd_coff_slurp_symbol_table)
PARAMS ((bfd *));
boolean (*_bfd_coff_symname_in_debug)
PARAMS ((bfd *, struct internal_syment *));
boolean (*_bfd_coff_pointerize_aux_hook)
PARAMS ((bfd *, combined_entry_type *, combined_entry_type *,
unsigned int, combined_entry_type *));
boolean (*_bfd_coff_print_aux)
PARAMS ((bfd *, FILE *, combined_entry_type *, combined_entry_type *,
combined_entry_type *, unsigned int));
void (*_bfd_coff_reloc16_extra_cases)
PARAMS ((bfd *, struct bfd_link_info *, struct bfd_link_order *, arelent *,
bfd_byte *, unsigned int *, unsigned int *));
int (*_bfd_coff_reloc16_estimate)
PARAMS ((bfd *, asection *, arelent *, unsigned int,
struct bfd_link_info *));
enum coff_symbol_classification (*_bfd_coff_classify_symbol)
PARAMS ((bfd *, struct internal_syment *));
boolean (*_bfd_coff_compute_section_file_positions)
PARAMS ((bfd *));
boolean (*_bfd_coff_start_final_link)
PARAMS ((bfd *, struct bfd_link_info *));
boolean (*_bfd_coff_relocate_section)
PARAMS ((bfd *, struct bfd_link_info *, bfd *, asection *, bfd_byte *,
struct internal_reloc *, struct internal_syment *, asection **));
reloc_howto_type *(*_bfd_coff_rtype_to_howto)
PARAMS ((bfd *, asection *, struct internal_reloc *,
struct coff_link_hash_entry *, struct internal_syment *,
bfd_vma *));
boolean (*_bfd_coff_adjust_symndx)\
PARAMS ((bfd *, struct bfd_link_info *, bfd *, asection *,
struct internal_reloc *, boolean *));
boolean (*_bfd_coff_link_add_one_symbol)
PARAMS ((struct bfd_link_info *, bfd *, const char *, flagword,
asection *, bfd_vma, const char *, boolean, boolean,
struct bfd_link_hash_entry **));
boolean (*_bfd_coff_link_output_has_begun)
PARAMS ((bfd *, struct coff_final_link_info *));
boolean (*_bfd_coff_final_link_postscript)
PARAMS ((bfd *, struct coff_final_link_info *));
} 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, flags_ptr)\
((coff_backend_info (abfd)->_bfd_styp_to_sec_flags_hook)\
(abfd, scnhdr, name, section, flags_ptr))
#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_force_symnames_in_strings(abfd)\
(coff_backend_info (abfd)->_bfd_coff_force_symnames_in_strings)
#define bfd_coff_debug_string_prefix_length(abfd)\
(coff_backend_info (abfd)->_bfd_coff_debug_string_prefix_length)
#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, Next: mmo, 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.
 

File: bfd.info, Node: mmo, Prev: elf, Up: BFD back ends
 
mmo backend
===========
 
The mmo object format is used exclusively together with Professor
Donald E. Knuth's educational 64-bit processor MMIX. The simulator
`mmix' which is available at
<http://www-cs-faculty.stanford.edu/~knuth/programs/mmix.tar.gz>
understands this format. That package also includes a combined
assembler and linker called `mmixal'. The mmo format has no advantages
feature-wise compared to e.g. ELF. It is a simple non-relocatable
object format with no support for archives or debugging information,
except for symbol value information and line numbers (which is not yet
implemented in BFD). See
<http://www-cs-faculty.stanford.edu/~knuth/mmix.html> for more
information about MMIX. The ELF format is used for intermediate object
files in the BFD implementation.
 
* Menu:
 
* File layout::
* Symbol-table::
* mmo section mapping::
 

File: bfd.info, Node: File layout, Next: Symbol-table, Prev: mmo, Up: mmo
 
File layout
-----------
 
The mmo file contents is not partitioned into named sections as with
e.g. ELF. Memory areas is formed by specifying the location of the
data that follows. Only the memory area `0x0000...00' to `0x01ff...ff'
is executable, so it is used for code (and constants) and the area
`0x2000...00' to `0x20ff...ff' is used for writable data. *Note mmo
section mapping::.
 
Contents is entered as 32-bit words, xor:ed over previous contents,
always zero-initialized. A word that starts with the byte `0x98' forms
a command called a `lopcode', where the next byte distinguished between
the thirteen lopcodes. The two remaining bytes, called the `Y' and `Z'
fields, or the `YZ' field (a 16-bit big-endian number), are used for
various purposes different for each lopcode. As documented in
<http://www-cs-faculty.stanford.edu/~knuth/mmixal-intro.ps.gz>, the
lopcodes are:
 
There is provision for specifying "special data" of 65536 different
types. We use type 80 (decimal), arbitrarily chosen the same as the
ELF `e_machine' number for MMIX, filling it with section information
normally found in ELF objects. *Note mmo section mapping::.
 
`lop_quote'
0x98000001. The next word is contents, regardless of whether it
starts with 0x98 or not.
 
`lop_loc'
0x9801YYZZ, where `Z' is 1 or 2. This is a location directive,
setting the location for the next data to the next 32-bit word
(for Z = 1) or 64-bit word (for Z = 2), plus Y * 2^56. Normally
`Y' is 0 for the text segment and 2 for the data segment.
 
`lop_skip'
0x9802YYZZ. Increase the current location by `YZ' bytes.
 
`lop_fixo'
0x9803YYZZ, where `Z' is 1 or 2. Store the current location as 64
bits into the location pointed to by the next 32-bit (Z = 1) or
64-bit (Z = 2) word, plus Y * 2^56.
 
`lop_fixr'
0x9804YYZZ. `YZ' is stored into the current location plus 2 - 4 *
YZ.
 
`lop_fixrx'
0x980500ZZ. `Z' is 16 or 24. A value `L' derived from the
following 32-bit word are used in a manner similar to `YZ' in
lop_fixr: it is xor:ed into the current location minus 4 * L. The
first byte of the word is 0 or 1. If it is 1, then L = (LOWEST 24
BITS OF WORD) - 2^Z, if 0, then L = (LOWEST 24 BITS OF WORD).
 
`lop_file'
0x9806YYZZ. `Y' is the file number, `Z' is count of 32-bit words.
Set the file number to `Y' and the line counter to 0. The next Z
* 4 bytes contain the file name, padded with zeros if the count is
not a multiple of four. The same `Y' may occur multiple times,
but `Z' must be 0 for all but the first occurrence.
 
`lop_line'
0x9807YYZZ. `YZ' is the line number. Together with lop_file, it
forms the source location for the next 32-bit word. Note that for
each non-lopcode 32-bit word, line numbers are assumed incremented
by one.
 
`lop_spec'
0x9808YYZZ. `YZ' is the type number. Data until the next lopcode
other than lop_quote forms special data of type `YZ'. *Note mmo
section mapping::.
 
Other types than 80, (or type 80 with a content that does not
parse) is stored in sections named `.MMIX.spec_data.N' where N is
the `YZ'-type. The flags for such a sections say not to allocate
or load the data. The vma is 0. Contents of multiple occurrences
of special data N is concatenated to the data of the previous
lop_spec Ns. The location in data or code at which the lop_spec
occurred is lost.
 
`lop_pre'
0x980901ZZ. The first lopcode in a file. The `Z' field forms the
length of header information in 32-bit words, where the first word
tells the time in seconds since `00:00:00 GMT Jan 1 1970'.
 
`lop_post'
0x980a00ZZ. Z > 32. This lopcode follows after all
content-generating lopcodes in a program. The `Z' field denotes
the value of `rG' at the beginning of the program. The following
256 - Z big-endian 64-bit words are loaded into global registers
`$G' ... `$255'.
 
`lop_stab'
0x980b0000. The next-to-last lopcode in a program. Must follow
immediately after the lop_post lopcode and its data. After this
lopcode follows all symbols in a compressed format (*note
Symbol-table::).
 
`lop_end'
0x980cYYZZ. The last lopcode in a program. It must follow the
lop_stab lopcode and its data. The `YZ' field contains the number
of 32-bit words of symbol table information after the preceding
lop_stab lopcode.
 
Note that the lopcode "fixups"; `lop_fixr', `lop_fixrx' and
`lop_fixo' are not generated by BFD, but are handled. They are
generated by `mmixal'.
 
This trivial one-label, one-instruction file:
 
:Main TRAP 1,2,3
 
can be represented this way in mmo:
 
0x98090101 - lop_pre, one 32-bit word with timestamp.
<timestamp>
0x98010002 - lop_loc, text segment, using a 64-bit address.
Note that mmixal does not emit this for the file above.
0x00000000 - Address, high 32 bits.
0x00000000 - Address, low 32 bits.
0x98060002 - lop_file, 2 32-bit words for file-name.
0x74657374 - "test"
0x2e730000 - ".s\0\0"
0x98070001 - lop_line, line 1.
0x00010203 - TRAP 1,2,3
0x980a00ff - lop_post, setting $255 to 0.
0x00000000
0x00000000
0x980b0000 - lop_stab for ":Main" = 0, serial 1.
0x203a4040 *Note Symbol-table::.
0x10404020
0x4d206120
0x69016e00
0x81000000
0x980c0005 - lop_end; symbol table contained five 32-bit words.
 

File: bfd.info, Node: Symbol-table, Next: mmo section mapping, Prev: File layout, Up: mmo
 
Symbol table format
-------------------
 
From mmixal.w (or really, the generated mmixal.tex) in
<http://www-cs-faculty.stanford.edu/~knuth/programs/mmix.tar.gz>):
"Symbols are stored and retrieved by means of a `ternary search trie',
following ideas of Bentley and Sedgewick. (See ACM-SIAM Symp. on
Discrete Algorithms `8' (1997), 360-369; R.Sedgewick, `Algorithms in C'
(Reading, Mass. Addison-Wesley, 1998), `15.4'.) Each trie node stores
a character, and there are branches to subtries for the cases where a
given character is less than, equal to, or greater than the character
in the trie. There also is a pointer to a symbol table entry if a
symbol ends at the current node."
 
So it's a tree encoded as a stream of bytes. The stream of bytes
acts on a single virtual global symbol, adding and removing characters
and signalling complete symbol points. Here, we read the stream and
create symbols at the completion points.
 
First, there's a control byte `m'. If any of the listed bits in `m'
is nonzero, we execute what stands at the right, in the listed order:
 
(MMO3_LEFT)
0x40 - Traverse left trie.
(Read a new command byte and recurse.)
(MMO3_SYMBITS)
0x2f - Read the next byte as a character and store it in the
current character position; increment character position.
Test the bits of `m':
(MMO3_WCHAR)
0x80 - The character is 16-bit (so read another byte,
merge into current character.
(MMO3_TYPEBITS)
0xf - We have a complete symbol; parse the type, value
and serial number and do what should be done
with a symbol. The type and length information
is in j = (m & 0xf).
(MMO3_REGQUAL_BITS)
j == 0xf: A register variable. The following
byte tells which register.
j <= 8: An absolute symbol. Read j bytes as the
big-endian number the symbol equals.
A j = 2 with two zero bytes denotes an
unknown symbol.
j > 8: As with j <= 8, but add (0x20 << 56)
to the value in the following j - 8
bytes.
Then comes the serial number, as a variant of
uleb128, but better named ubeb128:
Read bytes and shift the previous value left 7
(multiply by 128). Add in the new byte, repeat
until a byte has bit 7 set. The serial number
is the computed value minus 128.
(MMO3_MIDDLE)
0x20 - Traverse middle trie. (Read a new command byte
and recurse.) Decrement character position.
(MMO3_RIGHT)
0x10 - Traverse right trie. (Read a new command byte and
recurse.)
 
Let's look again at the `lop_stab' for the trivial file (*note File
layout::).
 
0x980b0000 - lop_stab for ":Main" = 0, serial 1.
0x203a4040
0x10404020
0x4d206120
0x69016e00
0x81000000
 
This forms the trivial trie (note that the path between ":" and "M"
is redundant):
 
203a ":"
40 /
40 /
10 \
40 /
40 /
204d "M"
2061 "a"
2069 "i"
016e "n" is the last character in a full symbol, and
with a value represented in one byte.
00 The value is 0.
81 The serial number is 1.
 

File: bfd.info, Node: mmo section mapping, Prev: Symbol-table, Up: mmo
 
mmo section mapping
-------------------
 
The implementation in BFD uses special data type 80 (decimal) to
encapsulate and describe named sections, containing e.g. debug
information. If needed, any datum in the encapsulation will be quoted
using lop_quote. First comes a 32-bit word holding the number of
32-bit words containing the zero-terminated zero-padded segment name.
After the name there's a 32-bit word holding flags describing the
section type. Then comes a 64-bit big-endian word with the section
length (in bytes), then another with the section start address.
Depending on the type of section, the contents might follow,
zero-padded to 32-bit boundary. For a loadable section (such as data
or code), the contents might follow at some later point, not
necessarily immediately, as a lop_loc with the same start address as in
the section description, followed by the contents. This in effect
forms a descriptor that must be emitted before the actual contents.
Sections described this way must not overlap.
 
For areas that don't have such descriptors, synthetic sections are
formed by BFD. Consecutive contents in the two memory areas
`0x0000...00' to `0x01ff...ff' and `0x2000...00' to `0x20ff...ff' are
entered in sections named `.text' and `.data' respectively. If an area
is not otherwise described, but would together with a neighboring lower
area be less than `0x40000000' bytes long, it is joined with the lower
area and the gap is zero-filled. For other cases, a new section is
formed, named `.MMIX.sec.N'. Here, N is a number, a running count
through the mmo file, starting at 0.
 
A loadable section specified as:
 
.section secname,"ax"
TETRA 1,2,3,4,-1,-2009
BYTE 80
 
and linked to address `0x4', is represented by the sequence:
 
0x98080050 - lop_spec 80
0x00000002 - two 32-bit words for the section name
0x7365636e - "secn"
0x616d6500 - "ame\0"
0x00000033 - flags CODE, READONLY, LOAD, ALLOC
0x00000000 - high 32 bits of section length
0x0000001c - section length is 28 bytes; 6 * 4 + 1 + alignment to 32 bits
0x00000000 - high 32 bits of section address
0x00000004 - section address is 4
0x98010002 - 64 bits with address of following data
0x00000000 - high 32 bits of address
0x00000004 - low 32 bits: data starts at address 4
0x00000001 - 1
0x00000002 - 2
0x00000003 - 3
0x00000004 - 4
0xffffffff - -1
0xfffff827 - -2009
0x50000000 - 80 as a byte, padded with zeros.
 
Note that the lop_spec wrapping does not include the section
contents. Compare this to a non-loaded section specified as:
 
.section thirdsec
TETRA 200001,100002
BYTE 38,40
 
This, when linked to address `0x200000000000001c', is represented by:
 
0x98080050 - lop_spec 80
0x00000002 - two 32-bit words for the section name
0x7365636e - "thir"
0x616d6500 - "dsec"
0x00000010 - flag READONLY
0x00000000 - high 32 bits of section length
0x0000000c - section length is 12 bytes; 2 * 4 + 2 + alignment to 32 bits
0x20000000 - high 32 bits of address
0x0000001c - low 32 bits of address 0x200000000000001c
0x00030d41 - 200001
0x000186a2 - 100002
0x26280000 - 38, 40 as bytes, padded with zeros
 
For the latter example, the section contents must not be loaded in
memory, and is therefore specified as part of the special data. The
address is usually unimportant but might provide information for e.g.
the DWARF 2 debugging format.
 
/libbfd.texi
0,0 → 1,204
@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
boolean bfd_write_bigendian_4byte_int (bfd *, unsigned int);
@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) & 0xff)
#define bfd_get_signed_8(abfd, ptr) \
(((*(unsigned char *) (ptr) & 0xff) ^ 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_vma) 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}
brethren, 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))
 
/* Refinements on the above, which should eventually go away. Save
cluttering the source with (bfd_vma) and (bfd_byte *) casts. */
 
#define H_PUT_64(abfd, val, where) \
bfd_h_put_64 ((abfd), (bfd_vma) (val), (bfd_byte *) (where))
 
#define H_PUT_32(abfd, val, where) \
bfd_h_put_32 ((abfd), (bfd_vma) (val), (bfd_byte *) (where))
 
#define H_PUT_16(abfd, val, where) \
bfd_h_put_16 ((abfd), (bfd_vma) (val), (bfd_byte *) (where))
 
#define H_PUT_8 bfd_h_put_8
 
#define H_PUT_S64(abfd, val, where) \
bfd_h_put_signed_64 ((abfd), (bfd_vma) (val), (bfd_byte *) (where))
 
#define H_PUT_S32(abfd, val, where) \
bfd_h_put_signed_32 ((abfd), (bfd_vma) (val), (bfd_byte *) (where))
 
#define H_PUT_S16(abfd, val, where) \
bfd_h_put_signed_16 ((abfd), (bfd_vma) (val), (bfd_byte *) (where))
 
#define H_PUT_S8 bfd_h_put_signed_8
 
#define H_GET_64(abfd, where) \
bfd_h_get_64 ((abfd), (bfd_byte *) (where))
 
#define H_GET_32(abfd, where) \
bfd_h_get_32 ((abfd), (bfd_byte *) (where))
 
#define H_GET_16(abfd, where) \
bfd_h_get_16 ((abfd), (bfd_byte *) (where))
 
#define H_GET_8 bfd_h_get_8
 
#define H_GET_S64(abfd, where) \
bfd_h_get_signed_64 ((abfd), (bfd_byte *) (where))
 
#define H_GET_S32(abfd, where) \
bfd_h_get_signed_32 ((abfd), (bfd_byte *) (where))
 
#define H_GET_S16(abfd, where) \
bfd_h_get_signed_16 ((abfd), (bfd_byte *) (where))
 
#define H_GET_S8 bfd_h_get_signed_8
 
 
@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. A @var{x} of 0 returns 0.
 
/bfd.info-8
0,0 → 1,367
This is bfd.info, produced by makeinfo version 4.1 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, 2000, 2001 Free Software Foundation, Inc.
 
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
 

File: bfd.info, Node: GNU Free Documentation License, Next: Index, Prev: BFD back ends, Up: Top
 
GNU Free Documentation License
******************************
 
GNU Free Documentation License
 
Version 1.1, March 2000
 
Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple
Place, Suite 330, Boston, MA 02111-1307 USA
 
Everyone is permitted to copy and distribute verbatim copies of
this license document, but changing it is not allowed.
 
0. PREAMBLE
 
The purpose of this License is to make a manual, textbook, or other
written document "free" in the sense of freedom: to assure everyone the
effective freedom to copy and redistribute it, with or without
modifying it, either commercially or noncommercially. Secondarily,
this License preserves for the author and publisher a way to get credit
for their work, while not being considered responsible for
modifications made by others.
 
This License is a kind of "copyleft", which means that derivative
works of the document must themselves be free in the same sense. It
complements the GNU General Public License, which is a copyleft license
designed for free software.
 
We have designed this License in order to use it for manuals for free
software, because free software needs free documentation: a free
program should come with manuals providing the same freedoms that the
software does. But this License is not limited to software manuals; it
can be used for any textual work, regardless of subject matter or
whether it is published as a printed book. We recommend this License
principally for works whose purpose is instruction or reference.
 
1. APPLICABILITY AND DEFINITIONS
 
This License applies to any manual or other work that contains a
notice placed by the copyright holder saying it can be distributed
under the terms of this License. The "Document", below, refers to any
such manual or work. Any member of the public is a licensee, and is
addressed as "you".
 
A "Modified Version" of the Document means any work containing the
Document or a portion of it, either copied verbatim, or with
modifications and/or translated into another language.
 
A "Secondary Section" is a named appendix or a front-matter section
of the Document that deals exclusively with the relationship of the
publishers or authors of the Document to the Document's overall subject
(or to related matters) and contains nothing that could fall directly
within that overall subject. (For example, if the Document is in part a
textbook of mathematics, a Secondary Section may not explain any
mathematics.) The relationship could be a matter of historical
connection with the subject or with related matters, or of legal,
commercial, philosophical, ethical or political position regarding them.
 
The "Invariant Sections" are certain Secondary Sections whose titles
are designated, as being those of Invariant Sections, in the notice
that says that the Document is released under this License.
 
The "Cover Texts" are certain short passages of text that are listed,
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
the Document is released under this License.
 
A "Transparent" copy of the Document means a machine-readable copy,
represented in a format whose specification is available to the general
public, whose contents can be viewed and edited directly and
straightforwardly with generic text editors or (for images composed of
pixels) generic paint programs or (for drawings) some widely available
drawing editor, and that is suitable for input to text formatters or
for automatic translation to a variety of formats suitable for input to
text formatters. A copy made in an otherwise Transparent file format
whose markup has been designed to thwart or discourage subsequent
modification by readers is not Transparent. A copy that is not
"Transparent" is called "Opaque".
 
Examples of suitable formats for Transparent copies include plain
ASCII without markup, Texinfo input format, LaTeX input format, SGML or
XML using a publicly available DTD, and standard-conforming simple HTML
designed for human modification. Opaque formats include PostScript,
PDF, proprietary formats that can be read and edited only by
proprietary word processors, SGML or XML for which the DTD and/or
processing tools are not generally available, and the machine-generated
HTML produced by some word processors for output purposes only.
 
The "Title Page" means, for a printed book, the title page itself,
plus such following pages as are needed to hold, legibly, the material
this License requires to appear in the title page. For works in
formats which do not have any title page as such, "Title Page" means
the text near the most prominent appearance of the work's title,
preceding the beginning of the body of the text.
 
2. VERBATIM COPYING
 
You may copy and distribute the Document in any medium, either
commercially or noncommercially, provided that this License, the
copyright notices, and the license notice saying this License applies
to the Document are reproduced in all copies, and that you add no other
conditions whatsoever to those of this License. You may not use
technical measures to obstruct or control the reading or further
copying of the copies you make or distribute. However, you may accept
compensation in exchange for copies. If you distribute a large enough
number of copies you must also follow the conditions in section 3.
 
You may also lend copies, under the same conditions stated above, and
you may publicly display copies.
 
3. COPYING IN QUANTITY
 
If you publish printed copies of the Document numbering more than
100, and the Document's license notice requires Cover Texts, you must
enclose the copies in covers that carry, clearly and legibly, all these
Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts
on the back cover. Both covers must also clearly and legibly identify
you as the publisher of these copies. The front cover must present the
full title with all words of the title equally prominent and visible.
You may add other material on the covers in addition. Copying with
changes limited to the covers, as long as they preserve the title of
the Document and satisfy these conditions, can be treated as verbatim
copying in other respects.
 
If the required texts for either cover are too voluminous to fit
legibly, you should put the first ones listed (as many as fit
reasonably) on the actual cover, and continue the rest onto adjacent
pages.
 
If you publish or distribute Opaque copies of the Document numbering
more than 100, you must either include a machine-readable Transparent
copy along with each Opaque copy, or state in or with each Opaque copy
a publicly-accessible computer-network location containing a complete
Transparent copy of the Document, free of added material, which the
general network-using public has access to download anonymously at no
charge using public-standard network protocols. If you use the latter
option, you must take reasonably prudent steps, when you begin
distribution of Opaque copies in quantity, to ensure that this
Transparent copy will remain thus accessible at the stated location
until at least one year after the last time you distribute an Opaque
copy (directly or through your agents or retailers) of that edition to
the public.
 
It is requested, but not required, that you contact the authors of
the Document well before redistributing any large number of copies, to
give them a chance to provide you with an updated version of the
Document.
 
4. MODIFICATIONS
 
You may copy and distribute a Modified Version of the Document under
the conditions of sections 2 and 3 above, provided that you release the
Modified Version under precisely this License, with the Modified
Version filling the role of the Document, thus licensing distribution
and modification of the Modified Version to whoever possesses a copy of
it. In addition, you must do these things in the Modified Version:
 
A. Use in the Title Page (and on the covers, if any) a title distinct
from that of the Document, and from those of previous versions
(which should, if there were any, be listed in the History section
of the Document). You may use the same title as a previous version
if the original publisher of that version gives permission. B. List on
the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has less than five). C.
State on the Title page the name of the publisher of the Modified
Version, as the publisher. D. Preserve all the copyright notices of
the Document. E. Add an appropriate copyright notice for your
modifications adjacent to the other copyright notices. F. Include,
immediately after the copyright notices, a license notice giving the
public permission to use the Modified Version under the terms of
this License, in the form shown in the Addendum below. G. Preserve in
that license notice the full lists of Invariant Sections and
required Cover Texts given in the Document's license notice. H.
Include an unaltered copy of this License. I. Preserve the section
entitled "History", and its title, and add to it an item stating at
least the title, year, new authors, and publisher of the Modified
Version as given on the Title Page. If there is no section entitled
"History" in the Document, create one stating the title, year,
authors, and publisher of the Document as given on its Title Page,
then add an item describing the Modified Version as stated in the
previous sentence. J. Preserve the network location, if any, given in
the Document for public access to a Transparent copy of the
Document, and likewise the network locations given in the Document
for previous versions it was based on. These may be placed in the
"History" section. You may omit a network location for a work that
was published at least four years before the Document itself, or if
the original publisher of the version it refers to gives permission.
K. In any section entitled "Acknowledgements" or "Dedications",
preserve the section's title, and preserve in the section all the
substance and tone of each of the contributor acknowledgements
and/or dedications given therein. L. Preserve all the Invariant
Sections of the Document, unaltered in their text and in their
titles. Section numbers or the equivalent are not considered part
of the section titles. M. Delete any section entitled "Endorsements".
Such a section may not be included in the Modified Version. N. Do
not retitle any existing section as "Endorsements" or to conflict in
title with any Invariant Section.
 
If the Modified Version includes new front-matter sections or
appendices that qualify as Secondary Sections and contain no material
copied from the Document, you may at your option designate some or all
of these sections as invariant. To do this, add their titles to the
list of Invariant Sections in the Modified Version's license notice.
These titles must be distinct from any other section titles.
 
You may add a section entitled "Endorsements", provided it contains
nothing but endorsements of your Modified Version by various
parties-for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a
standard.
 
You may add a passage of up to five words as a Front-Cover Text, and
a passage of up to 25 words as a Back-Cover Text, to the end of the list
of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or through
arrangements made by) any one entity. If the Document already includes
a cover text for the same cover, previously added by you or by
arrangement made by the same entity you are acting on behalf of, you
may not add another; but you may replace the old one, on explicit
permission from the previous publisher that added the old one.
 
The author(s) and publisher(s) of the Document do not by this License
give permission to use their names for publicity for or to assert or
imply endorsement of any Modified Version.
 
5. COMBINING DOCUMENTS
 
You may combine the Document with other documents released under this
License, under the terms defined in section 4 above for modified
versions, provided that you include in the combination all of the
Invariant Sections of all of the original documents, unmodified, and
list them all as Invariant Sections of your combined work in its
license notice.
 
The combined work need only contain one copy of this License, and
multiple identical Invariant Sections may be replaced with a single
copy. If there are multiple Invariant Sections with the same name but
different contents, make the title of each such section unique by
adding at the end of it, in parentheses, the name of the original
author or publisher of that section if known, or else a unique number.
Make the same adjustment to the section titles in the list of Invariant
Sections in the license notice of the combined work.
 
In the combination, you must combine any sections entitled "History"
in the various original documents, forming one section entitled
"History"; likewise combine any sections entitled "Acknowledgements",
and any sections entitled "Dedications". You must delete all sections
entitled "Endorsements."
 
6. COLLECTIONS OF DOCUMENTS
 
You may make a collection consisting of the Document and other
documents released under this License, and replace the individual
copies of this License in the various documents with a single copy that
is included in the collection, provided that you follow the rules of
this License for verbatim copying of each of the documents in all other
respects.
 
You may extract a single document from such a collection, and
distribute it individually under this License, provided you insert a
copy of this License into the extracted document, and follow this
License in all other respects regarding verbatim copying of that
document.
 
7. AGGREGATION WITH INDEPENDENT WORKS
 
A compilation of the Document or its derivatives with other separate
and independent documents or works, in or on a volume of a storage or
distribution medium, does not as a whole count as a Modified Version of
the Document, provided no compilation copyright is claimed for the
compilation. Such a compilation is called an "aggregate", and this
License does not apply to the other self-contained works thus compiled
with the Document, on account of their being thus compiled, if they are
not themselves derivative works of the Document.
 
If the Cover Text requirement of section 3 is applicable to these
copies of the Document, then if the Document is less than one quarter
of the entire aggregate, the Document's Cover Texts may be placed on
covers that surround only the Document within the aggregate. Otherwise
they must appear on covers around the whole aggregate.
 
8. TRANSLATION
 
Translation is considered a kind of modification, so you may
distribute translations of the Document under the terms of section 4.
Replacing Invariant Sections with translations requires special
permission from their copyright holders, but you may include
translations of some or all Invariant Sections in addition to the
original versions of these Invariant Sections. You may include a
translation of this License provided that you also include the original
English version of this License. In case of a disagreement between the
translation and the original English version of this License, the
original English version will prevail.
 
9. TERMINATION
 
You may not copy, modify, sublicense, or distribute the Document
except as expressly provided for under this License. Any other attempt
to copy, modify, sublicense or distribute the Document is void, and will
automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such parties
remain in full compliance.
 
10. FUTURE REVISIONS OF THIS LICENSE
 
The Free Software Foundation may publish new, revised versions of
the GNU Free Documentation License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns. See
http://www.gnu.org/copyleft/.
 
Each version of the License is given a distinguishing version number.
If the Document specifies that a particular numbered version of this
License "or any later version" applies to it, you have the option of
following the terms and conditions either of that specified version or
of any later version that has been published (not as a draft) by the
Free Software Foundation. If the Document does not specify a version
number of this License, you may choose any version ever published (not
as a draft) by the Free Software Foundation.
 
ADDENDUM: How to use this License for your documents
 
To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and license
notices just after the title page:
 
Copyright (c) YEAR YOUR NAME.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with the Invariant Sections being LIST THEIR TITLES, with the
Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
A copy of the license is included in the section entitled "GNU
Free Documentation License".
 
If you have no Invariant Sections, write "with no Invariant Sections"
instead of saying which ones are invariant. If you have no Front-Cover
Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being
LIST"; likewise for Back-Cover Texts.
 
If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License, to
permit their use in free software.
 
/hash.texi
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.
 
/bfd.info-9
0,0 → 1,839
This is bfd.info, produced by makeinfo version 4.1 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, 2000, 2001 Free Software Foundation, Inc.
 
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with no
Back-Cover Texts. A copy of the license is included in the
section entitled "GNU Free Documentation License".
 

File: bfd.info, Node: Index, Prev: GNU Free Documentation License, Up: Top
 
Index
*****
 
* Menu:
 
* _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_generic_make_empty_symbol: symbol handling functions.
* _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: Overview.
* BFD canonical format: Canonical format.
* bfd_alloc: Opening and Closing.
* bfd_alt_mach_code: BFD front end.
* 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_archive_filename: BFD front end.
* bfd_cache_close: File Caching.
* bfd_cache_init: File Caching.
* bfd_cache_lookup: File Caching.
* bfd_cache_lookup_worker: File Caching.
* BFD_CACHE_MAX_OPEN macro: 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_discard_group: section prototypes.
* bfd_generic_gc_sections: howto manager.
* bfd_generic_get_relocated_section_contents: howto manager.
* bfd_generic_merge_sections: howto manager.
* bfd_generic_relax_section: howto manager.
* bfd_get_arch: Architectures.
* bfd_get_arch_info: Architectures.
* bfd_get_arch_size: BFD front end.
* 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_sign_extend_vma: BFD front end.
* bfd_get_size <1>: Internal.
* bfd_get_size: BFD front end.
* bfd_get_symtab_upper_bound: symbol handling functions.
* bfd_get_unique_section_name: section prototypes.
* 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_12_PCREL: howto manager.
* BFD_RELOC_14: howto manager.
* BFD_RELOC_16: howto manager.
* BFD_RELOC_16_BASEREL: howto manager.
* BFD_RELOC_16_GOT_PCREL: howto manager.
* BFD_RELOC_16_GOTOFF: howto manager.
* BFD_RELOC_16_PCREL: howto manager.
* BFD_RELOC_16_PCREL_S2: howto manager.
* BFD_RELOC_16_PLT_PCREL: howto manager.
* BFD_RELOC_16_PLTOFF: 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_GOT_PCREL: howto manager.
* BFD_RELOC_32_GOTOFF: howto manager.
* BFD_RELOC_32_PCREL: howto manager.
* BFD_RELOC_32_PCREL_S2: howto manager.
* BFD_RELOC_32_PLT_PCREL: howto manager.
* BFD_RELOC_32_PLTOFF: 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_386_TLS_DTPMOD32: howto manager.
* BFD_RELOC_386_TLS_DTPOFF32: howto manager.
* BFD_RELOC_386_TLS_GD: howto manager.
* BFD_RELOC_386_TLS_IE_32: howto manager.
* BFD_RELOC_386_TLS_LDM: howto manager.
* BFD_RELOC_386_TLS_LDO_32: howto manager.
* BFD_RELOC_386_TLS_LE: howto manager.
* BFD_RELOC_386_TLS_LE_32: howto manager.
* BFD_RELOC_386_TLS_TPOFF32: howto manager.
* BFD_RELOC_390_12: howto manager.
* BFD_RELOC_390_COPY: howto manager.
* BFD_RELOC_390_GLOB_DAT: howto manager.
* BFD_RELOC_390_GOT12: howto manager.
* BFD_RELOC_390_GOT16: howto manager.
* BFD_RELOC_390_GOT64: howto manager.
* BFD_RELOC_390_GOTENT: howto manager.
* BFD_RELOC_390_GOTPC: howto manager.
* BFD_RELOC_390_GOTPCDBL: howto manager.
* BFD_RELOC_390_JMP_SLOT: howto manager.
* BFD_RELOC_390_PC16DBL: howto manager.
* BFD_RELOC_390_PC32DBL: howto manager.
* BFD_RELOC_390_PLT16DBL: howto manager.
* BFD_RELOC_390_PLT32: howto manager.
* BFD_RELOC_390_PLT32DBL: howto manager.
* BFD_RELOC_390_PLT64: howto manager.
* BFD_RELOC_390_RELATIVE: howto manager.
* BFD_RELOC_64: howto manager.
* BFD_RELOC_64_PCREL: howto manager.
* BFD_RELOC_64_PLT_PCREL: howto manager.
* BFD_RELOC_64_PLTOFF: 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_860_COPY: howto manager.
* BFD_RELOC_860_GLOB_DAT: howto manager.
* BFD_RELOC_860_HAGOT: howto manager.
* BFD_RELOC_860_HAGOTOFF: howto manager.
* BFD_RELOC_860_HAPC: howto manager.
* BFD_RELOC_860_HIGH: howto manager.
* BFD_RELOC_860_HIGHADJ: howto manager.
* BFD_RELOC_860_HIGOT: howto manager.
* BFD_RELOC_860_HIGOTOFF: howto manager.
* BFD_RELOC_860_JUMP_SLOT: howto manager.
* BFD_RELOC_860_LOGOT0: howto manager.
* BFD_RELOC_860_LOGOT1: howto manager.
* BFD_RELOC_860_LOGOTOFF0: howto manager.
* BFD_RELOC_860_LOGOTOFF1: howto manager.
* BFD_RELOC_860_LOGOTOFF2: howto manager.
* BFD_RELOC_860_LOGOTOFF3: howto manager.
* BFD_RELOC_860_LOPC: howto manager.
* BFD_RELOC_860_LOW0: howto manager.
* BFD_RELOC_860_LOW1: howto manager.
* BFD_RELOC_860_LOW2: howto manager.
* BFD_RELOC_860_LOW3: howto manager.
* BFD_RELOC_860_PC16: howto manager.
* BFD_RELOC_860_PC26: howto manager.
* BFD_RELOC_860_PLT26: howto manager.
* BFD_RELOC_860_RELATIVE: howto manager.
* BFD_RELOC_860_SPGOT0: howto manager.
* BFD_RELOC_860_SPGOT1: howto manager.
* BFD_RELOC_860_SPGOTOFF0: howto manager.
* BFD_RELOC_860_SPGOTOFF1: howto manager.
* BFD_RELOC_860_SPLIT0: howto manager.
* BFD_RELOC_860_SPLIT1: howto manager.
* BFD_RELOC_860_SPLIT2: howto manager.
* BFD_RELOC_8_BASEREL: howto manager.
* BFD_RELOC_8_FFnn: howto manager.
* BFD_RELOC_8_GOT_PCREL: howto manager.
* BFD_RELOC_8_GOTOFF: howto manager.
* BFD_RELOC_8_PCREL: howto manager.
* BFD_RELOC_8_PLT_PCREL: howto manager.
* BFD_RELOC_8_PLTOFF: howto manager.
* BFD_RELOC_ALPHA_BRSGP: howto manager.
* BFD_RELOC_ALPHA_CODEADDR: howto manager.
* BFD_RELOC_ALPHA_DTPMOD64: howto manager.
* BFD_RELOC_ALPHA_DTPREL16: howto manager.
* BFD_RELOC_ALPHA_DTPREL64: howto manager.
* BFD_RELOC_ALPHA_DTPREL_HI16: howto manager.
* BFD_RELOC_ALPHA_DTPREL_LO16: howto manager.
* BFD_RELOC_ALPHA_ELF_LITERAL: howto manager.
* BFD_RELOC_ALPHA_GOTDTPREL16: howto manager.
* BFD_RELOC_ALPHA_GOTTPREL16: 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_GPREL_HI16: howto manager.
* BFD_RELOC_ALPHA_GPREL_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_TLSGD: howto manager.
* BFD_RELOC_ALPHA_TLSLDM: howto manager.
* BFD_RELOC_ALPHA_TPREL16: howto manager.
* BFD_RELOC_ALPHA_TPREL64: howto manager.
* BFD_RELOC_ALPHA_TPREL_HI16: howto manager.
* BFD_RELOC_ALPHA_TPREL_LO16: howto manager.
* BFD_RELOC_ARC_B22_PCREL: howto manager.
* BFD_RELOC_ARC_B26: howto manager.
* BFD_RELOC_ARM_ADR_IMM: howto manager.
* BFD_RELOC_ARM_ADRL_IMMEDIATE: 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_code_type: howto manager.
* BFD_RELOC_CRIS_16_GOT: howto manager.
* BFD_RELOC_CRIS_16_GOTPLT: howto manager.
* BFD_RELOC_CRIS_32_GOT: howto manager.
* BFD_RELOC_CRIS_32_GOTPLT: howto manager.
* BFD_RELOC_CRIS_32_GOTREL: howto manager.
* BFD_RELOC_CRIS_32_PLT_GOTREL: howto manager.
* BFD_RELOC_CRIS_32_PLT_PCREL: howto manager.
* BFD_RELOC_CRIS_BDISP8: howto manager.
* BFD_RELOC_CRIS_COPY: howto manager.
* BFD_RELOC_CRIS_GLOB_DAT: howto manager.
* BFD_RELOC_CRIS_JUMP_SLOT: howto manager.
* BFD_RELOC_CRIS_RELATIVE: howto manager.
* BFD_RELOC_CRIS_SIGNED_6: howto manager.
* BFD_RELOC_CRIS_UNSIGNED_4: howto manager.
* BFD_RELOC_CRIS_UNSIGNED_5: howto manager.
* BFD_RELOC_CRIS_UNSIGNED_6: 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_DLX_HI16_S: howto manager.
* BFD_RELOC_DLX_JMP26: howto manager.
* BFD_RELOC_DLX_LO16: 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_FRV_GPREL12: howto manager.
* BFD_RELOC_FRV_GPREL32: howto manager.
* BFD_RELOC_FRV_GPRELHI: howto manager.
* BFD_RELOC_FRV_GPRELLO: howto manager.
* BFD_RELOC_FRV_GPRELU12: howto manager.
* BFD_RELOC_FRV_HI16: howto manager.
* BFD_RELOC_FRV_LABEL16: howto manager.
* BFD_RELOC_FRV_LABEL24: howto manager.
* BFD_RELOC_FRV_LO16: howto manager.
* BFD_RELOC_GPREL16: howto manager.
* BFD_RELOC_GPREL32: howto manager.
* BFD_RELOC_H8_DIR16A8: howto manager.
* BFD_RELOC_H8_DIR16R8: howto manager.
* BFD_RELOC_H8_DIR24A8: howto manager.
* BFD_RELOC_H8_DIR24R8: howto manager.
* BFD_RELOC_H8_DIR32A16: 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_IA64_COPY: howto manager.
* BFD_RELOC_IA64_DIR32LSB: howto manager.
* BFD_RELOC_IA64_DIR32MSB: howto manager.
* BFD_RELOC_IA64_DIR64LSB: howto manager.
* BFD_RELOC_IA64_DIR64MSB: howto manager.
* BFD_RELOC_IA64_DTPMOD64LSB: howto manager.
* BFD_RELOC_IA64_DTPMOD64MSB: howto manager.
* BFD_RELOC_IA64_DTPREL14: howto manager.
* BFD_RELOC_IA64_DTPREL22: howto manager.
* BFD_RELOC_IA64_DTPREL32LSB: howto manager.
* BFD_RELOC_IA64_DTPREL32MSB: howto manager.
* BFD_RELOC_IA64_DTPREL64I: howto manager.
* BFD_RELOC_IA64_DTPREL64LSB: howto manager.
* BFD_RELOC_IA64_DTPREL64MSB: howto manager.
* BFD_RELOC_IA64_FPTR32LSB: howto manager.
* BFD_RELOC_IA64_FPTR32MSB: howto manager.
* BFD_RELOC_IA64_FPTR64I: howto manager.
* BFD_RELOC_IA64_FPTR64LSB: howto manager.
* BFD_RELOC_IA64_FPTR64MSB: howto manager.
* BFD_RELOC_IA64_GPREL22: howto manager.
* BFD_RELOC_IA64_GPREL32LSB: howto manager.
* BFD_RELOC_IA64_GPREL32MSB: howto manager.
* BFD_RELOC_IA64_GPREL64I: howto manager.
* BFD_RELOC_IA64_GPREL64LSB: howto manager.
* BFD_RELOC_IA64_GPREL64MSB: howto manager.
* BFD_RELOC_IA64_IMM14: howto manager.
* BFD_RELOC_IA64_IMM22: howto manager.
* BFD_RELOC_IA64_IMM64: howto manager.
* BFD_RELOC_IA64_IPLTLSB: howto manager.
* BFD_RELOC_IA64_IPLTMSB: howto manager.
* BFD_RELOC_IA64_LDXMOV: howto manager.
* BFD_RELOC_IA64_LTOFF22: howto manager.
* BFD_RELOC_IA64_LTOFF22X: howto manager.
* BFD_RELOC_IA64_LTOFF64I: howto manager.
* BFD_RELOC_IA64_LTOFF_DTPMOD22: howto manager.
* BFD_RELOC_IA64_LTOFF_DTPREL22: howto manager.
* BFD_RELOC_IA64_LTOFF_FPTR22: howto manager.
* BFD_RELOC_IA64_LTOFF_FPTR32LSB: howto manager.
* BFD_RELOC_IA64_LTOFF_FPTR32MSB: howto manager.
* BFD_RELOC_IA64_LTOFF_FPTR64I: howto manager.
* BFD_RELOC_IA64_LTOFF_FPTR64LSB: howto manager.
* BFD_RELOC_IA64_LTOFF_FPTR64MSB: howto manager.
* BFD_RELOC_IA64_LTOFF_TPREL22: howto manager.
* BFD_RELOC_IA64_LTV32LSB: howto manager.
* BFD_RELOC_IA64_LTV32MSB: howto manager.
* BFD_RELOC_IA64_LTV64LSB: howto manager.
* BFD_RELOC_IA64_LTV64MSB: howto manager.
* BFD_RELOC_IA64_PCREL21B: howto manager.
* BFD_RELOC_IA64_PCREL21BI: howto manager.
* BFD_RELOC_IA64_PCREL21F: howto manager.
* BFD_RELOC_IA64_PCREL21M: howto manager.
* BFD_RELOC_IA64_PCREL22: howto manager.
* BFD_RELOC_IA64_PCREL32LSB: howto manager.
* BFD_RELOC_IA64_PCREL32MSB: howto manager.
* BFD_RELOC_IA64_PCREL60B: howto manager.
* BFD_RELOC_IA64_PCREL64I: howto manager.
* BFD_RELOC_IA64_PCREL64LSB: howto manager.
* BFD_RELOC_IA64_PCREL64MSB: howto manager.
* BFD_RELOC_IA64_PLTOFF22: howto manager.
* BFD_RELOC_IA64_PLTOFF64I: howto manager.
* BFD_RELOC_IA64_PLTOFF64LSB: howto manager.
* BFD_RELOC_IA64_PLTOFF64MSB: howto manager.
* BFD_RELOC_IA64_REL32LSB: howto manager.
* BFD_RELOC_IA64_REL32MSB: howto manager.
* BFD_RELOC_IA64_REL64LSB: howto manager.
* BFD_RELOC_IA64_REL64MSB: howto manager.
* BFD_RELOC_IA64_SECREL32LSB: howto manager.
* BFD_RELOC_IA64_SECREL32MSB: howto manager.
* BFD_RELOC_IA64_SECREL64LSB: howto manager.
* BFD_RELOC_IA64_SECREL64MSB: howto manager.
* BFD_RELOC_IA64_SEGREL32LSB: howto manager.
* BFD_RELOC_IA64_SEGREL32MSB: howto manager.
* BFD_RELOC_IA64_SEGREL64LSB: howto manager.
* BFD_RELOC_IA64_SEGREL64MSB: howto manager.
* BFD_RELOC_IA64_TPREL14: howto manager.
* BFD_RELOC_IA64_TPREL22: howto manager.
* BFD_RELOC_IA64_TPREL64I: howto manager.
* BFD_RELOC_IA64_TPREL64LSB: howto manager.
* BFD_RELOC_IA64_TPREL64MSB: howto manager.
* BFD_RELOC_IP2K_ADDR16CJP: howto manager.
* BFD_RELOC_IP2K_BANK: howto manager.
* BFD_RELOC_IP2K_EX8DATA: howto manager.
* BFD_RELOC_IP2K_FR9: howto manager.
* BFD_RELOC_IP2K_FR_OFFSET: howto manager.
* BFD_RELOC_IP2K_HI8DATA: howto manager.
* BFD_RELOC_IP2K_HI8INSN: howto manager.
* BFD_RELOC_IP2K_LO8DATA: howto manager.
* BFD_RELOC_IP2K_LO8INSN: howto manager.
* BFD_RELOC_IP2K_PAGE3: howto manager.
* BFD_RELOC_IP2K_PC_SKIP: howto manager.
* BFD_RELOC_IP2K_TEXT: 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_M68HC11_24: howto manager.
* BFD_RELOC_M68HC11_3B: howto manager.
* BFD_RELOC_M68HC11_HI8: howto manager.
* BFD_RELOC_M68HC11_LO16: howto manager.
* BFD_RELOC_M68HC11_LO8: howto manager.
* BFD_RELOC_M68HC11_PAGE: howto manager.
* BFD_RELOC_M68HC11_RL_GROUP: howto manager.
* BFD_RELOC_M68HC11_RL_JUMP: 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_DELETE: 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_HIGHER: howto manager.
* BFD_RELOC_MIPS_HIGHEST: howto manager.
* BFD_RELOC_MIPS_INSERT_A: howto manager.
* BFD_RELOC_MIPS_INSERT_B: howto manager.
* BFD_RELOC_MIPS_JALR: howto manager.
* BFD_RELOC_MIPS_JMP: howto manager.
* BFD_RELOC_MIPS_LITERAL: howto manager.
* BFD_RELOC_MIPS_REL16: howto manager.
* BFD_RELOC_MIPS_RELGOT: howto manager.
* BFD_RELOC_MIPS_SCN_DISP: howto manager.
* BFD_RELOC_MIPS_SHIFT5: howto manager.
* BFD_RELOC_MIPS_SHIFT6: howto manager.
* BFD_RELOC_MIPS_SUB: howto manager.
* BFD_RELOC_MMIX_ADDR19: howto manager.
* BFD_RELOC_MMIX_ADDR27: howto manager.
* BFD_RELOC_MMIX_BASE_PLUS_OFFSET: howto manager.
* BFD_RELOC_MMIX_CBRANCH: howto manager.
* BFD_RELOC_MMIX_CBRANCH_1: howto manager.
* BFD_RELOC_MMIX_CBRANCH_2: howto manager.
* BFD_RELOC_MMIX_CBRANCH_3: howto manager.
* BFD_RELOC_MMIX_CBRANCH_J: howto manager.
* BFD_RELOC_MMIX_GETA: howto manager.
* BFD_RELOC_MMIX_GETA_1: howto manager.
* BFD_RELOC_MMIX_GETA_2: howto manager.
* BFD_RELOC_MMIX_GETA_3: howto manager.
* BFD_RELOC_MMIX_JMP: howto manager.
* BFD_RELOC_MMIX_JMP_1: howto manager.
* BFD_RELOC_MMIX_JMP_2: howto manager.
* BFD_RELOC_MMIX_JMP_3: howto manager.
* BFD_RELOC_MMIX_LOCAL: howto manager.
* BFD_RELOC_MMIX_PUSHJ: howto manager.
* BFD_RELOC_MMIX_PUSHJ_1: howto manager.
* BFD_RELOC_MMIX_PUSHJ_2: howto manager.
* BFD_RELOC_MMIX_PUSHJ_3: howto manager.
* BFD_RELOC_MMIX_REG: howto manager.
* BFD_RELOC_MMIX_REG_OR_BYTE: 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_OPENRISC_ABS_26: howto manager.
* BFD_RELOC_OPENRISC_REL_26: howto manager.
* BFD_RELOC_PCREL_HI16_S: howto manager.
* BFD_RELOC_PCREL_LO16: howto manager.
* BFD_RELOC_PDP11_DISP_6_PCREL: howto manager.
* BFD_RELOC_PDP11_DISP_8_PCREL: 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_PPC64_ADDR16_DS: howto manager.
* BFD_RELOC_PPC64_ADDR16_LO_DS: howto manager.
* BFD_RELOC_PPC64_GOT16_DS: howto manager.
* BFD_RELOC_PPC64_GOT16_LO_DS: howto manager.
* BFD_RELOC_PPC64_HIGHER: howto manager.
* BFD_RELOC_PPC64_HIGHER_S: howto manager.
* BFD_RELOC_PPC64_HIGHEST: howto manager.
* BFD_RELOC_PPC64_HIGHEST_S: howto manager.
* BFD_RELOC_PPC64_PLT16_LO_DS: howto manager.
* BFD_RELOC_PPC64_PLTGOT16: howto manager.
* BFD_RELOC_PPC64_PLTGOT16_DS: howto manager.
* BFD_RELOC_PPC64_PLTGOT16_HA: howto manager.
* BFD_RELOC_PPC64_PLTGOT16_HI: howto manager.
* BFD_RELOC_PPC64_PLTGOT16_LO: howto manager.
* BFD_RELOC_PPC64_PLTGOT16_LO_DS: howto manager.
* BFD_RELOC_PPC64_SECTOFF_DS: howto manager.
* BFD_RELOC_PPC64_SECTOFF_LO_DS: howto manager.
* BFD_RELOC_PPC64_TOC: howto manager.
* BFD_RELOC_PPC64_TOC16_DS: howto manager.
* BFD_RELOC_PPC64_TOC16_HA: howto manager.
* BFD_RELOC_PPC64_TOC16_HI: howto manager.
* BFD_RELOC_PPC64_TOC16_LO: howto manager.
* BFD_RELOC_PPC64_TOC16_LO_DS: 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_COPY: howto manager.
* BFD_RELOC_SH_COPY64: howto manager.
* BFD_RELOC_SH_COUNT: howto manager.
* BFD_RELOC_SH_DATA: howto manager.
* BFD_RELOC_SH_GLOB_DAT: howto manager.
* BFD_RELOC_SH_GLOB_DAT64: howto manager.
* BFD_RELOC_SH_GOT10BY4: howto manager.
* BFD_RELOC_SH_GOT10BY8: howto manager.
* BFD_RELOC_SH_GOT_HI16: howto manager.
* BFD_RELOC_SH_GOT_LOW16: howto manager.
* BFD_RELOC_SH_GOT_MEDHI16: howto manager.
* BFD_RELOC_SH_GOT_MEDLOW16: howto manager.
* BFD_RELOC_SH_GOTOFF_HI16: howto manager.
* BFD_RELOC_SH_GOTOFF_LOW16: howto manager.
* BFD_RELOC_SH_GOTOFF_MEDHI16: howto manager.
* BFD_RELOC_SH_GOTOFF_MEDLOW16: howto manager.
* BFD_RELOC_SH_GOTPC: howto manager.
* BFD_RELOC_SH_GOTPC_HI16: howto manager.
* BFD_RELOC_SH_GOTPC_LOW16: howto manager.
* BFD_RELOC_SH_GOTPC_MEDHI16: howto manager.
* BFD_RELOC_SH_GOTPC_MEDLOW16: howto manager.
* BFD_RELOC_SH_GOTPLT10BY4: howto manager.
* BFD_RELOC_SH_GOTPLT10BY8: howto manager.
* BFD_RELOC_SH_GOTPLT32: howto manager.
* BFD_RELOC_SH_GOTPLT_HI16: howto manager.
* BFD_RELOC_SH_GOTPLT_LOW16: howto manager.
* BFD_RELOC_SH_GOTPLT_MEDHI16: howto manager.
* BFD_RELOC_SH_GOTPLT_MEDLOW16: 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_IMM_HI16: howto manager.
* BFD_RELOC_SH_IMM_HI16_PCREL: howto manager.
* BFD_RELOC_SH_IMM_LOW16: howto manager.
* BFD_RELOC_SH_IMM_LOW16_PCREL: howto manager.
* BFD_RELOC_SH_IMM_MEDHI16: howto manager.
* BFD_RELOC_SH_IMM_MEDHI16_PCREL: howto manager.
* BFD_RELOC_SH_IMM_MEDLOW16: howto manager.
* BFD_RELOC_SH_IMM_MEDLOW16_PCREL: howto manager.
* BFD_RELOC_SH_IMMS10: howto manager.
* BFD_RELOC_SH_IMMS10BY2: howto manager.
* BFD_RELOC_SH_IMMS10BY4: howto manager.
* BFD_RELOC_SH_IMMS10BY8: howto manager.
* BFD_RELOC_SH_IMMS16: howto manager.
* BFD_RELOC_SH_IMMS6: howto manager.
* BFD_RELOC_SH_IMMS6BY32: howto manager.
* BFD_RELOC_SH_IMMU16: howto manager.
* BFD_RELOC_SH_IMMU5: howto manager.
* BFD_RELOC_SH_IMMU6: howto manager.
* BFD_RELOC_SH_JMP_SLOT: howto manager.
* BFD_RELOC_SH_JMP_SLOT64: 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_PLT_HI16: howto manager.
* BFD_RELOC_SH_PLT_LOW16: howto manager.
* BFD_RELOC_SH_PLT_MEDHI16: howto manager.
* BFD_RELOC_SH_PLT_MEDLOW16: howto manager.
* BFD_RELOC_SH_PT_16: howto manager.
* BFD_RELOC_SH_RELATIVE: howto manager.
* BFD_RELOC_SH_RELATIVE64: howto manager.
* BFD_RELOC_SH_SHMEDIA_CODE: 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_PLT32: 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_UA16: howto manager.
* BFD_RELOC_SPARC_UA32: howto manager.
* BFD_RELOC_SPARC_UA64: 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_type_lookup: howto manager.
* BFD_RELOC_V850_22_PCREL: howto manager.
* BFD_RELOC_V850_9_PCREL: howto manager.
* BFD_RELOC_V850_ALIGN: howto manager.
* BFD_RELOC_V850_CALLT_16_16_OFFSET: howto manager.
* BFD_RELOC_V850_CALLT_6_7_OFFSET: howto manager.
* BFD_RELOC_V850_LONGCALL: howto manager.
* BFD_RELOC_V850_LONGJUMP: 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_VAX_GLOB_DAT: howto manager.
* BFD_RELOC_VAX_JMP_SLOT: howto manager.
* BFD_RELOC_VAX_RELATIVE: howto manager.
* BFD_RELOC_VPE4KMATH_DATA: howto manager.
* BFD_RELOC_VPE4KMATH_INSN: howto manager.
* BFD_RELOC_VTABLE_ENTRY: howto manager.
* BFD_RELOC_VTABLE_INHERIT: howto manager.
* BFD_RELOC_X86_64_32S: howto manager.
* BFD_RELOC_X86_64_COPY: howto manager.
* BFD_RELOC_X86_64_GLOB_DAT: howto manager.
* BFD_RELOC_X86_64_GOT32: howto manager.
* BFD_RELOC_X86_64_GOTPCREL: howto manager.
* BFD_RELOC_X86_64_JUMP_SLOT: howto manager.
* BFD_RELOC_X86_64_PLT32: howto manager.
* BFD_RELOC_X86_64_RELATIVE: howto manager.
* BFD_RELOC_XSTORMY16_24: howto manager.
* BFD_RELOC_XSTORMY16_FPTR16: howto manager.
* BFD_RELOC_XSTORMY16_REL_12: howto manager.
* bfd_scan_arch: Architectures.
* bfd_scan_vma: BFD front end.
* bfd_seach_for_target: bfd_target.
* bfd_section_list_clear: section prototypes.
* 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.
* GNU Free Documentation License: GNU Free Documentation License.
* Hash tables: Hash Tables.
* internal object-file format: Canonical format.
* Linker: Linker Functions.
* 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.
* The HOWTO Macro: typedef arelent.
* what is it?: Overview.
 
 
/linker.texi
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
 
/mmo.texi
0,0 → 1,365
@section mmo backend
The mmo object format is used exclusively together with Professor
Donald E.@: Knuth's educational 64-bit processor MMIX. The simulator
@command{mmix} which is available at
@url{http://www-cs-faculty.stanford.edu/~knuth/programs/mmix.tar.gz}
understands this format. That package also includes a combined
assembler and linker called @command{mmixal}. The mmo format has
no advantages feature-wise compared to e.g. ELF. It is a simple
non-relocatable object format with no support for archives or
debugging information, except for symbol value information and
line numbers (which is not yet implemented in BFD). See
@url{http://www-cs-faculty.stanford.edu/~knuth/mmix.html} for more
information about MMIX. The ELF format is used for intermediate
object files in the BFD implementation.
 
@c We want to xref the symbol table node. A feature in "chew"
@c requires that "commands" do not contain spaces in the
@c arguments. Hence the hyphen in "Symbol-table".
@menu
* File layout::
* Symbol-table::
* mmo section mapping::
@end menu
 
@node File layout, Symbol-table, mmo, mmo
@subsection File layout
The mmo file contents is not partitioned into named sections as
with e.g.@: ELF. Memory areas is formed by specifying the
location of the data that follows. Only the memory area
@samp{0x0000@dots{}00} to @samp{0x01ff@dots{}ff} is executable, so
it is used for code (and constants) and the area
@samp{0x2000@dots{}00} to @samp{0x20ff@dots{}ff} is used for
writable data. @xref{mmo section mapping}.
 
Contents is entered as 32-bit words, xor:ed over previous
contents, always zero-initialized. A word that starts with the
byte @samp{0x98} forms a command called a @samp{lopcode}, where
the next byte distinguished between the thirteen lopcodes. The
two remaining bytes, called the @samp{Y} and @samp{Z} fields, or
the @samp{YZ} field (a 16-bit big-endian number), are used for
various purposes different for each lopcode. As documented in
@url{http://www-cs-faculty.stanford.edu/~knuth/mmixal-intro.ps.gz},
the lopcodes are:
 
There is provision for specifying ``special data'' of 65536
different types. We use type 80 (decimal), arbitrarily chosen the
same as the ELF @code{e_machine} number for MMIX, filling it with
section information normally found in ELF objects. @xref{mmo
section mapping}.
 
@table @code
@item lop_quote
0x98000001. The next word is contents, regardless of whether it
starts with 0x98 or not.
 
@item lop_loc
0x9801YYZZ, where @samp{Z} is 1 or 2. This is a location
directive, setting the location for the next data to the next
32-bit word (for @math{Z = 1}) or 64-bit word (for @math{Z = 2}),
plus @math{Y * 2^56}. Normally @samp{Y} is 0 for the text segment
and 2 for the data segment.
 
@item lop_skip
0x9802YYZZ. Increase the current location by @samp{YZ} bytes.
 
@item lop_fixo
0x9803YYZZ, where @samp{Z} is 1 or 2. Store the current location
as 64 bits into the location pointed to by the next 32-bit
(@math{Z = 1}) or 64-bit (@math{Z = 2}) word, plus @math{Y *
2^56}.
 
@item lop_fixr
0x9804YYZZ. @samp{YZ} is stored into the current location plus
@math{2 - 4 * YZ}.
 
@item lop_fixrx
0x980500ZZ. @samp{Z} is 16 or 24. A value @samp{L} derived from
the following 32-bit word are used in a manner similar to
@samp{YZ} in lop_fixr: it is xor:ed into the current location
minus @math{4 * L}. The first byte of the word is 0 or 1. If it
is 1, then @math{L = (@var{lowest 24 bits of word}) - 2^Z}, if 0,
then @math{L = (@var{lowest 24 bits of word})}.
 
@item lop_file
0x9806YYZZ. @samp{Y} is the file number, @samp{Z} is count of
32-bit words. Set the file number to @samp{Y} and the line
counter to 0. The next @math{Z * 4} bytes contain the file name,
padded with zeros if the count is not a multiple of four. The
same @samp{Y} may occur multiple times, but @samp{Z} must be 0 for
all but the first occurrence.
 
@item lop_line
0x9807YYZZ. @samp{YZ} is the line number. Together with
lop_file, it forms the source location for the next 32-bit word.
Note that for each non-lopcode 32-bit word, line numbers are
assumed incremented by one.
 
@item lop_spec
0x9808YYZZ. @samp{YZ} is the type number. Data until the next
lopcode other than lop_quote forms special data of type @samp{YZ}.
@xref{mmo section mapping}.
 
Other types than 80, (or type 80 with a content that does not
parse) is stored in sections named @code{.MMIX.spec_data.@var{n}}
where @var{n} is the @samp{YZ}-type. The flags for such a
sections say not to allocate or load the data. The vma is 0.
Contents of multiple occurrences of special data @var{n} is
concatenated to the data of the previous lop_spec @var{n}s. The
location in data or code at which the lop_spec occurred is lost.
 
@item lop_pre
0x980901ZZ. The first lopcode in a file. The @samp{Z} field forms the
length of header information in 32-bit words, where the first word
tells the time in seconds since @samp{00:00:00 GMT Jan 1 1970}.
 
@item lop_post
0x980a00ZZ. @math{Z > 32}. This lopcode follows after all
content-generating lopcodes in a program. The @samp{Z} field
denotes the value of @samp{rG} at the beginning of the program.
The following @math{256 - Z} big-endian 64-bit words are loaded
into global registers @samp{$G} @dots{} @samp{$255}.
 
@item lop_stab
0x980b0000. The next-to-last lopcode in a program. Must follow
immediately after the lop_post lopcode and its data. After this
lopcode follows all symbols in a compressed format
(@pxref{Symbol-table}).
 
@item lop_end
0x980cYYZZ. The last lopcode in a program. It must follow the
lop_stab lopcode and its data. The @samp{YZ} field contains the
number of 32-bit words of symbol table information after the
preceding lop_stab lopcode.
@end table
 
Note that the lopcode "fixups"; @code{lop_fixr}, @code{lop_fixrx} and
@code{lop_fixo} are not generated by BFD, but are handled. They are
generated by @code{mmixal}.
 
This trivial one-label, one-instruction file:
 
@example
:Main TRAP 1,2,3
@end example
 
can be represented this way in mmo:
 
@example
0x98090101 - lop_pre, one 32-bit word with timestamp.
<timestamp>
0x98010002 - lop_loc, text segment, using a 64-bit address.
Note that mmixal does not emit this for the file above.
0x00000000 - Address, high 32 bits.
0x00000000 - Address, low 32 bits.
0x98060002 - lop_file, 2 32-bit words for file-name.
0x74657374 - "test"
0x2e730000 - ".s\0\0"
0x98070001 - lop_line, line 1.
0x00010203 - TRAP 1,2,3
0x980a00ff - lop_post, setting $255 to 0.
0x00000000
0x00000000
0x980b0000 - lop_stab for ":Main" = 0, serial 1.
0x203a4040 @xref{Symbol-table}.
0x10404020
0x4d206120
0x69016e00
0x81000000
0x980c0005 - lop_end; symbol table contained five 32-bit words.
@end example
@node Symbol-table, mmo section mapping, File layout, mmo
@subsection Symbol table format
From mmixal.w (or really, the generated mmixal.tex) in
@url{http://www-cs-faculty.stanford.edu/~knuth/programs/mmix.tar.gz}):
``Symbols are stored and retrieved by means of a @samp{ternary
search trie}, following ideas of Bentley and Sedgewick. (See
ACM--SIAM Symp.@: on Discrete Algorithms @samp{8} (1997), 360--369;
R.@:Sedgewick, @samp{Algorithms in C} (Reading, Mass.@:
Addison--Wesley, 1998), @samp{15.4}.) Each trie node stores a
character, and there are branches to subtries for the cases where
a given character is less than, equal to, or greater than the
character in the trie. There also is a pointer to a symbol table
entry if a symbol ends at the current node.''
 
So it's a tree encoded as a stream of bytes. The stream of bytes
acts on a single virtual global symbol, adding and removing
characters and signalling complete symbol points. Here, we read
the stream and create symbols at the completion points.
 
First, there's a control byte @code{m}. If any of the listed bits
in @code{m} is nonzero, we execute what stands at the right, in
the listed order:
 
@example
(MMO3_LEFT)
0x40 - Traverse left trie.
(Read a new command byte and recurse.)
 
(MMO3_SYMBITS)
0x2f - Read the next byte as a character and store it in the
current character position; increment character position.
Test the bits of @code{m}:
 
(MMO3_WCHAR)
0x80 - The character is 16-bit (so read another byte,
merge into current character.
 
(MMO3_TYPEBITS)
0xf - We have a complete symbol; parse the type, value
and serial number and do what should be done
with a symbol. The type and length information
is in j = (m & 0xf).
 
(MMO3_REGQUAL_BITS)
j == 0xf: A register variable. The following
byte tells which register.
j <= 8: An absolute symbol. Read j bytes as the
big-endian number the symbol equals.
A j = 2 with two zero bytes denotes an
unknown symbol.
j > 8: As with j <= 8, but add (0x20 << 56)
to the value in the following j - 8
bytes.
 
Then comes the serial number, as a variant of
uleb128, but better named ubeb128:
Read bytes and shift the previous value left 7
(multiply by 128). Add in the new byte, repeat
until a byte has bit 7 set. The serial number
is the computed value minus 128.
 
(MMO3_MIDDLE)
0x20 - Traverse middle trie. (Read a new command byte
and recurse.) Decrement character position.
 
(MMO3_RIGHT)
0x10 - Traverse right trie. (Read a new command byte and
recurse.)
@end example
 
Let's look again at the @code{lop_stab} for the trivial file
(@pxref{File layout}).
 
@example
0x980b0000 - lop_stab for ":Main" = 0, serial 1.
0x203a4040
0x10404020
0x4d206120
0x69016e00
0x81000000
@end example
 
This forms the trivial trie (note that the path between ``:'' and
``M'' is redundant):
 
@example
203a ":"
40 /
40 /
10 \
40 /
40 /
204d "M"
2061 "a"
2069 "i"
016e "n" is the last character in a full symbol, and
with a value represented in one byte.
00 The value is 0.
81 The serial number is 1.
@end example
 
@node mmo section mapping, , Symbol-table, mmo
@subsection mmo section mapping
The implementation in BFD uses special data type 80 (decimal) to
encapsulate and describe named sections, containing e.g.@: debug
information. If needed, any datum in the encapsulation will be
quoted using lop_quote. First comes a 32-bit word holding the
number of 32-bit words containing the zero-terminated zero-padded
segment name. After the name there's a 32-bit word holding flags
describing the section type. Then comes a 64-bit big-endian word
with the section length (in bytes), then another with the section
start address. Depending on the type of section, the contents
might follow, zero-padded to 32-bit boundary. For a loadable
section (such as data or code), the contents might follow at some
later point, not necessarily immediately, as a lop_loc with the
same start address as in the section description, followed by the
contents. This in effect forms a descriptor that must be emitted
before the actual contents. Sections described this way must not
overlap.
 
For areas that don't have such descriptors, synthetic sections are
formed by BFD. Consecutive contents in the two memory areas
@samp{0x0000@dots{}00} to @samp{0x01ff@dots{}ff} and
@samp{0x2000@dots{}00} to @samp{0x20ff@dots{}ff} are entered in
sections named @code{.text} and @code{.data} respectively. If an area
is not otherwise described, but would together with a neighboring
lower area be less than @samp{0x40000000} bytes long, it is joined
with the lower area and the gap is zero-filled. For other cases,
a new section is formed, named @code{.MMIX.sec.@var{n}}. Here,
@var{n} is a number, a running count through the mmo file,
starting at 0.
 
A loadable section specified as:
 
@example
.section secname,"ax"
TETRA 1,2,3,4,-1,-2009
BYTE 80
@end example
 
and linked to address @samp{0x4}, is represented by the sequence:
 
@example
0x98080050 - lop_spec 80
0x00000002 - two 32-bit words for the section name
0x7365636e - "secn"
0x616d6500 - "ame\0"
0x00000033 - flags CODE, READONLY, LOAD, ALLOC
0x00000000 - high 32 bits of section length
0x0000001c - section length is 28 bytes; 6 * 4 + 1 + alignment to 32 bits
0x00000000 - high 32 bits of section address
0x00000004 - section address is 4
0x98010002 - 64 bits with address of following data
0x00000000 - high 32 bits of address
0x00000004 - low 32 bits: data starts at address 4
0x00000001 - 1
0x00000002 - 2
0x00000003 - 3
0x00000004 - 4
0xffffffff - -1
0xfffff827 - -2009
0x50000000 - 80 as a byte, padded with zeros.
@end example
 
Note that the lop_spec wrapping does not include the section
contents. Compare this to a non-loaded section specified as:
 
@example
.section thirdsec
TETRA 200001,100002
BYTE 38,40
@end example
 
This, when linked to address @samp{0x200000000000001c}, is
represented by:
 
@example
0x98080050 - lop_spec 80
0x00000002 - two 32-bit words for the section name
0x7365636e - "thir"
0x616d6500 - "dsec"
0x00000010 - flag READONLY
0x00000000 - high 32 bits of section length
0x0000000c - section length is 12 bytes; 2 * 4 + 2 + alignment to 32 bits
0x20000000 - high 32 bits of address
0x0000001c - low 32 bits of address 0x200000000000001c
0x00030d41 - 200001
0x000186a2 - 100002
0x26280000 - 38, 40 as bytes, padded with zeros
@end example
 
For the latter example, the section contents must not be
loaded in memory, and is therefore specified as part of the
special data. The address is usually unimportant but might
provide information for e.g.@: the DWARF 2 debugging format.
/format.texi
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}.
 
/header.sed
0,0 → 1,13
s|[ ][ ]*| |g
s|\(.*\) [^ ]*header.sed.*|\1|
s|[^ ]*/||g
s|^ *|"|
s| |", "|g
s|$|"|
s|, \([^ ]*\)$| and \1|
s|^|/* DO NOT EDIT! -*- buffer-read-only: t -*- This file is automatically generated from |
s|\(.\{60\}[^ ]* \)|\1\
|g
s|$|.\
Run "make headers" in your build bfd/ to regenerate. */\
|
/syms.texi
0,0 → 1,444
@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
 
/* This symbol is thread local. Used in ELF. */
#define BSF_THREAD_LOCAL 0x40000
 
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(bfd *abfd, 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_generic_make_empty_symbol
@subsubsection @code{_bfd_generic_make_empty_symbol}
@strong{Synopsis}
@example
asymbol *_bfd_generic_make_empty_symbol (bfd *);
@end example
@strong{Description}@*
Create a new @code{asymbol} structure for the BFD @var{abfd}
and return a pointer to it. Used by core file routines,
binary back-end and anywhere else where no private info
is needed.
 
@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
 
/opncls.texi
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.
 
/chew.c
0,0 → 1,1602
/* chew
Copyright 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1998, 2000, 2001,
2002
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:
: <newword> <oldwords> ;
 
*/
 
/* 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 <<foo>> 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 "ansidecl.h"
#include "sysdep.h"
#include <assert.h>
#include <stdio.h>
#include <ctype.h>
 
#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
init_string_with_size (buffer, size)
string_type *buffer;
unsigned int size;
{
buffer->write_idx = 0;
buffer->size = size;
buffer->ptr = malloc (size);
}
 
static void
init_string (buffer)
string_type *buffer;
{
init_string_with_size (buffer, DEF_SIZE);
}
 
static int
find (str, what)
string_type *str;
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
write_buffer (buffer, f)
string_type *buffer;
FILE *f;
{
fwrite (buffer->ptr, buffer->write_idx, 1, f);
}
 
static void
delete_string (buffer)
string_type *buffer;
{
free (buffer->ptr);
}
 
static char *
addr (buffer, idx)
string_type *buffer;
unsigned int idx;
{
return buffer->ptr + idx;
}
 
static char
at (buffer, pos)
string_type *buffer;
unsigned int pos;
{
if (pos >= buffer->write_idx)
return 0;
return buffer->ptr[pos];
}
 
static void
catchar (buffer, ch)
string_type *buffer;
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
overwrite_string (dst, src)
string_type *dst;
string_type *src;
{
free (dst->ptr);
dst->size = src->size;
dst->write_idx = src->write_idx;
dst->ptr = src->ptr;
}
 
static void
catbuf (buffer, buf, len)
string_type *buffer;
char *buf;
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
cattext (buffer, string)
string_type *buffer;
char *string;
{
catbuf (buffer, string, (unsigned int) strlen (string));
}
 
static void
catstr (dst, src)
string_type *dst;
string_type *src;
{
catbuf (dst, src->ptr, src->write_idx);
}
 
static unsigned int
skip_white_and_stars (src, idx)
string_type *src;
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;
 
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
exec (word)
dict_type *word;
{
pc = word->code;
while (*pc)
(*pc) ();
}
 
static void
call ()
{
stinst_type *oldpc = pc;
dict_type *e;
e = (dict_type *) (pc[1]);
exec (e);
pc = oldpc + 2;
}
 
static void
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++;
}
 
static void
push_number ()
{
isp++;
icheck_range ();
pc++;
*isp = (long) (*pc);
pc++;
}
 
static void
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
remove_noncomments (src, dst)
string_type *src;
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
paramstuff ()
{
unsigned int openp;
unsigned int fname;
unsigned int idx;
unsigned int len;
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++;
 
/* Output type, omitting trailing whitespace character(s), if
any. */
for (len = fname; 0 < len; len--)
{
if (!isspace ((unsigned char) at (tos, len - 1)))
break;
}
for (idx = 0; idx < len; idx++)
catchar (&out, at (tos, idx));
 
cattext (&out, "\n"); /* Insert a newline between type and fnname */
 
/* Output function name, omitting trailing whitespace
character(s), if any. */
for (len = openp; 0 < len; len--)
{
if (!isspace ((unsigned char) at (tos, len - 1)))
break;
}
for (idx = fname; idx < len; idx++)
catchar (&out, at (tos, idx));
 
cattext (&out, " PARAMS (");
 
for (idx = openp; at (tos, idx) && at (tos, idx) != ';'; idx++)
catchar (&out, at (tos, idx));
 
cattext (&out, ");\n\n");
}
overwrite_string (tos, &out);
pc++;
 
}
 
/* turn {*
and *} into comments */
 
static void
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 */
 
static void
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
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 */
static void
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 (command > 1)
{
/* We are inside {} parameters of some command;
Just pass through until matching brace. */
if (at (tos, idx) == '{')
++command;
else if (at (tos, idx) == '}')
--command;
}
else if (command != 0)
{
if (at (tos, idx) == '{')
++command;
else if (!islower ((unsigned char) at (tos, idx)))
--command;
}
else if (at (tos, idx) == '@'
&& islower ((unsigned char) at (tos, idx + 1)))
{
++command;
}
else if (at (tos, idx) == '{' && at (tos, idx + 1) == '*')
{
cattext (&out, "/*");
idx += 2;
continue;
}
else if (at (tos, idx) == '*' && at (tos, idx + 1) == '}')
{
cattext (&out, "*/");
idx += 2;
continue;
}
else if (at (tos, idx) == '{'
|| at (tos, idx) == '}')
{
catchar (&out, '@');
}
 
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*/
 
static void
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 <<foo>> into @code{foo} in place at TOS*/
 
static void
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
iscommand (ptr, idx)
string_type *ptr;
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
copy_past_newline (ptr, idx, dst)
string_type *ptr;
unsigned int idx;
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;
 
}
 
static void
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. */
 
static void
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;
 
}
 
static void
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;
 
}
 
static void
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++;
}
 
static void
swap ()
{
string_type t;
 
t = tos[0];
tos[0] = tos[-1];
tos[-1] = t;
pc++;
}
 
static void
other_dup ()
{
tos++;
check_range ();
init_string (tos);
catstr (tos, tos - 1);
pc++;
}
 
static void
drop ()
{
tos--;
check_range ();
pc++;
}
 
static void
idrop ()
{
isp--;
icheck_range ();
pc++;
}
 
static void
icatstr ()
{
tos--;
check_range ();
catstr (tos, tos + 1);
delete_string (tos + 1);
pc++;
}
 
static void
skip_past_newline ()
{
while (at (ptr, idx)
&& at (ptr, idx) != '\n')
idx++;
idx++;
pc++;
}
 
static void
internalmode ()
{
internal_mode = *(isp);
isp--;
icheck_range ();
pc++;
}
 
static void
maybecatstr ()
{
if (internal_wanted == internal_mode)
{
catstr (tos - 1, tos);
}
delete_string (tos);
tos--;
check_range ();
pc++;
}
 
char *
nextword (string, word)
char *string;
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 *
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
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 *
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
add_to_definition (entry, word)
dict_type *entry;
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
add_intrinsic (name, func)
char *name;
void (*func) ();
{
dict_type *new = newentry (name);
add_to_definition (new, func);
add_to_definition (new, 0);
}
 
void
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
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
bang ()
{
*(long *) ((isp[0])) = isp[-1];
isp -= 2;
icheck_range ();
pc++;
}
 
static void
atsign ()
{
isp[0] = *(long *) (isp[0]);
pc++;
}
 
static void
hello ()
{
printf ("hello\n");
pc++;
}
 
static void
stdout_ ()
{
isp++;
icheck_range ();
*isp = 1;
pc++;
}
 
static void
stderr_ ()
{
isp++;
icheck_range ();
*isp = 2;
pc++;
}
 
static void
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
read_in (str, file)
string_type *str;
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
usage ()
{
fprintf (stderr, "usage: -[d|i|g] <file >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
main (ac, av)
int ac;
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;
}
/Makefile.am
0,0 → 1,284
## 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 \
mmo.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 \
$(srcdir)/../mmo.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-mmo: $(MKDOC) $(srcdir)/../mmo.c $(srcdir)/doc.str
./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../mmo.c >mmo.tmp
$(srcdir)/../../move-if-change mmo.tmp mmo.texi
touch s-mmo
mmo.texi: s-mmo
 
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_DEP = \
$(srcdir)/../libbfd-in.h \
$(srcdir)/../init.c \
$(srcdir)/../libbfd.c \
$(srcdir)/../cache.c \
$(srcdir)/../reloc.c \
$(srcdir)/../archures.c \
$(srcdir)/../elf.c \
$(srcdir)/header.sed \
$(srcdir)/proto.str \
$(MKDOC)
 
libbfd.h: $(LIBBFD_H_DEP)
echo "$(LIBBFD_H_DEP)" | sed -f $(srcdir)/header.sed > $@
for file in $(LIBBFD_H_DEP); do \
case $$file in \
*-in.h) cat $$file >> $@ ;; \
*/header.sed) break ;; \
*) echo $$file | sed -e 's,.*/,,' -e 's,^,/* Extracted from ,' \
-e 's,$$,. */,' >> $@ ; \
./$(MKDOC) -i -f $(srcdir)/proto.str < $$file >> $@ ;; \
esac; \
done
 
LIBCOFF_H_DEP = \
$(srcdir)/../libcoff-in.h \
$(srcdir)/../coffcode.h \
$(srcdir)/header.sed \
$(srcdir)/proto.str \
$(MKDOC)
 
libcoff.h: $(LIBCOFF_H_DEP)
echo "$(LIBCOFF_H_DEP)" | sed -f $(srcdir)/header.sed > $@
for file in $(LIBCOFF_H_DEP); do \
case $$file in \
*-in.h) cat $$file >> $@ ;; \
*/header.sed) break ;; \
*) echo $$file | sed -e 's,.*/,,' -e 's,^,/* Extracted from ,' \
-e 's,$$,. */,' >> $@ ; \
./$(MKDOC) -i -f $(srcdir)/proto.str < $$file >> $@ ;; \
esac; \
done
 
BFD_H_DEP = \
$(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)/header.sed \
$(srcdir)/proto.str \
$(srcdir)/../version.h \
$(MKDOC)
 
bfd.h: $(BFD_H_DEP)
echo "$(BFD_H_DEP)" | sed -f $(srcdir)/header.sed > $@
for file in $(BFD_H_DEP); do \
case $$file in \
*-in.h) cat $$file >> $@ ;; \
*/header.sed) break ;; \
*) echo $$file | sed -e 's,.*/,,' -e 's,^,/* Extracted from ,' \
-e 's,$$,. */,' >> $@ ; \
./$(MKDOC) -f $(srcdir)/proto.str < $$file >> $@ ;; \
esac; \
done
echo "#ifdef __cplusplus" >> $@
echo "}" >> $@
echo "#endif" >> $@
echo "#endif" >> $@
 
noinst_TEXINFOS = bfdint.texi
 
MOSTLYCLEANFILES = $(MKDOC) *.o
 
CLEANFILES = s-* *.p *.ip
 
DISTCLEANFILES = bfd.?? bfd.??? bfd.h libbfd.h libcoff.h texput.log
 
MAINTAINERCLEANFILES = $(DOCFILES)
 
# We want install to imply install-info as per GNU standards, despite the
# cygnus option.
install: install-info
/proto.str
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 ;
/cache.texi
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.
 
/section.texi
0,0 → 1,785
@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;
@};
 
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;
 
/* A unique sequence number. */
int id;
 
/* Which section in the bfd; 0..n-1 as sections are created in a bfd. */
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
 
/* ELF reserves 4 processor specific bits and 8 operating system
specific bits in sh_flags; at present we can get away with just
one in communicating between the assembler and BFD, but this
isn't a good long-term solution. */
#define SEC_ARCH_BIT_0 0x008
 
/* 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 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 thread local data. */
#define SEC_THREAD_LOCAL 0x1000
 
/* The section has GOT references. This flag is only for the
linker, and is currently only used by the elf32-hppa back end.
It will be set if global offset table references were detected
in this section, which indicate to the linker that the section
contains PIC code, and must be handled specially when doing a
static link. */
#define SEC_HAS_GOT_REF 0x4000
 
/* 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 based on the sum of
the symbol and addend values specified by the associated relocation
entries. Entries without associated relocation entries will be
appended to the end of the section in an unspecified order. */
#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
 
/* Attempt to merge identical entities in the section.
Entity size is given in the entsize field. */
#define SEC_MERGE 0x20000000
 
/* If given with SEC_MERGE, entities to merge are zero terminated
strings where entsize specifies character size instead of fixed
size entries. */
#define SEC_STRINGS 0x40000000
 
/* This section contains data about section groups. */
#define SEC_GROUP 0x80000000
 
/* 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;
 
/* Another mark flag used by some of the linker backends. Set for
output sections that have an input section. */
unsigned int linker_has_input : 1;
 
/* A mark flag used by some linker backends for garbage collection. */
unsigned int gc_mark : 1;
 
/* Used by the ELF code to mark sections which have been allocated
to segments. */
unsigned int segment_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;
 
/* Entity size for merging purposes. */
unsigned int entsize;
 
/* 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)
 
#define bfd_is_const_section(SEC) \
( ((SEC) == bfd_abs_section_ptr) \
|| ((SEC) == bfd_und_section_ptr) \
|| ((SEC) == bfd_com_section_ptr) \
|| ((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))
 
/* Macros to handle insertion and deletion of a bfd's sections. These
only handle the list pointers, ie. do not adjust section_count,
target_index etc. */
#define bfd_section_list_remove(ABFD, PS) \
do \
@{ \
asection **_ps = PS; \
asection *_s = *_ps; \
*_ps = _s->next; \
if (_s->next == NULL) \
(ABFD)->section_tail = _ps; \
@} \
while (0)
#define bfd_section_list_insert(ABFD, PS, S) \
do \
@{ \
asection **_ps = PS; \
asection *_s = S; \
_s->next = *_ps; \
*_ps = _s; \
if (_s->next == NULL) \
(ABFD)->section_tail = &_s->next; \
@} \
while (0)
 
@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_section_list_clear
@subsubsection @code{bfd_section_list_clear}
@strong{Synopsis}
@example
void bfd_section_list_clear (bfd *);
@end example
@strong{Description}@*
Clears the section list, and also resets the section count and
hash table entries.
 
@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_get_unique_section_name
@subsubsection @code{bfd_get_unique_section_name}
@strong{Synopsis}
@example
char *bfd_get_unique_section_name(bfd *abfd,
const char *templat,
int *count);
@end example
@strong{Description}@*
Invent a section name that is unique in @var{abfd} by tacking
a dot and a digit suffix onto the original @var{templat}. If
@var{count} is non-NULL, then it specifies the first number
tried as a suffix to generate a unique name. The value
pointed to by @var{count} will be incremented in this case.
 
@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.
 
This function won't actually do anything except twiddle flags
if called too late in the linking process, when it's not safe
to remove sections.
 
@findex bfd_generic_discard_group
@subsubsection @code{bfd_generic_discard_group}
@strong{Synopsis}
@example
boolean bfd_generic_discard_group (bfd *abfd, asection *group);
@end example
@strong{Description}@*
Remove all members of @var{group} from the output.
 
/bfdint.texi
0,0 → 1,1896
\input texinfo
@c Copyright 1988, 1989, 1990, 1991, 1992, 1993, 1994, 1995, 1996, 1998,
@c 2000, 2001
@c Free Software Foundation, Inc.
@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.
 
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.
@item bfd_target_mmo_flavour
Donald Knuth's MMIXware object format.
@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 function 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_bound}, 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_bread}. 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_bwrite}.
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
BFD. 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. The GNU linker makes sure to stop that from
happening when an input file in a different format has relocations.
 
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 Caldera; if you want to get a magic
number for a particular processor, try sending a note to
@email{registry@@caldera.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.
 
While not a BFD component, you probably also want to make the binutils
program @samp{readelf} parse your ELF objects. For this, you need to add
code for @code{EM_@var{cpu}} as appropriate in @file{binutils/readelf.c}.
 
@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
/elf.texi
0,0 → 1,24
@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.
 

powered by: WebSVN 2.1.0

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