bfdint.texi

这个是LINUX下的GDB调度工具的源码

@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