Google Git
Sign in
chromium / external / msysgit / msysgit / refs/tags/Git-1.9.4-preview20140611 / . / mingw / info / bfd.info
blob: 9808127fc002eed47065368d274ceb1b6e7b98d5 [file] [log] [blame]
This is bfd.info, produced by makeinfo version 4.8 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, 2003, 2006, 2007 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 the
Invariant Sections being "GNU General Public License" and "Funding Free
Software", the Front-Cover texts being (a) (see below), and with the
Back-Cover Texts being (b) (see below). A copy of the license is
included in the section entitled "GNU Free Documentation License".
(a) The FSF's Front-Cover Text is:
A GNU Manual
(b) The FSF's Back-Cover Text is:
You have freedom to copy and modify this GNU Manual, like GNU
software. Copies published by the Free Software Foundation raise
funds for GNU development.

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
* BFD Index:: BFD Index

File: bfd.info, Node: Overview, Next: BFD front end, Prev: Top, Up: Top
1 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
1.1 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
1.2 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 successfully 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
1.3 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
1.3.1 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
1.3.2 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
2 BFD Front End
***************
2.1 `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
{
/* A unique identifier of the BFD */
unsigned int id;
/* The filename the application opened the BFD with. */
const char *filename;
/* A pointer to the target jump table. */
const struct bfd_target *xvec;
/* The IOSTREAM, and corresponding IO vector that provide access
to the file backing the BFD. */
void *iostream;
const struct bfd_iovec *iovec;
/* Is the file descriptor being cached? That is, can it be closed as
needed, and re-opened when accessed later? */
bfd_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. */
bfd_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). */
bfd_boolean opened_once;
/* Set if we have a locally maintained mtime value, rather than
getting it from the file each time. */
bfd_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. */
bfd_boolean output_has_begun;
/* A hash table for section names. */
struct bfd_hash_table section_htab;
/* Pointer to linked list of sections. */
struct bfd_section *sections;
/* The last section on the section list. */
struct bfd_section *section_last;
/* 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 bfd_symbol **outsymbols;
/* Used for slurped dynamic symbol tables. */
unsigned int dynsymcount;
/* Pointer to structure which contains architecture information. */
const struct bfd_arch_info *arch_info;
/* Flag set if symbols from this BFD should not be exported. */
bfd_boolean no_export;
/* Stuff only useful for archives. */
void *arelt_data;
struct bfd *my_archive; /* The containing archive BFD. */
struct bfd *archive_next; /* The next BFD in the archive. */
struct bfd *archive_head; /* The first BFD in the archive. */
bfd_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;
struct mach_o_data_struct *mach_o_data;
struct mach_o_fat_data_struct *mach_o_fat_data;
struct bfd_pef_data_struct *pef_data;
struct bfd_pef_xlib_data_struct *pef_xlib_data;
struct bfd_sym_data_struct *sym_data;
void *any;
}
tdata;
/* Used by the application to hold private data. */
void *usrdata;
/* Where all the allocated stuff under this BFD goes. This is a
struct objalloc *, but we use void * to avoid requiring the inclusion
of objalloc.h. */
void *memory;
};
2.2 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'.
2.2.1 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_on_input,
bfd_error_invalid_error_code
}
bfd_error_type;
2.2.1.1 `bfd_get_error'
.......................
*Synopsis*
bfd_error_type bfd_get_error (void);
*Description*
Return the current BFD error condition.
2.2.1.2 `bfd_set_error'
.......................
*Synopsis*
void bfd_set_error (bfd_error_type error_tag, ...);
*Description*
Set the BFD error condition to be ERROR_TAG. If ERROR_TAG is
bfd_error_on_input, then this function takes two more parameters, the
input bfd where the error occurred, and the bfd_error_type error.
2.2.1.3 `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'.
2.2.1.4 `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.
2.2.2 BFD error handler
-----------------------
Some BFD functions want to print messages describing the problem. They
call a BFD error handler function. This function may be overridden by
the program.
The BFD error handler acts like printf.
typedef void (*bfd_error_handler_type) (const char *, ...);
2.2.2.1 `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.
2.2.2.2 `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.
2.2.2.3 `bfd_get_error_handler'
...............................
*Synopsis*
bfd_error_handler_type bfd_get_error_handler (void);
*Description*
Return the BFD error handler function.
2.3 Miscellaneous
=================
2.3.1 Miscellaneous functions
-----------------------------
2.3.1.1 `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.
2.3.1.2 `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.
2.3.1.3 `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.
2.3.1.4 `bfd_set_file_flags'
............................
*Synopsis*
bfd_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.
2.3.1.5 `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.
2.3.1.6 `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.
2.3.1.7 `bfd_set_start_address'
...............................
*Synopsis*
bfd_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.
2.3.1.8 `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.
2.3.1.9 `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.
2.3.1.10 `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.
2.3.1.11 `bfd_copy_private_header_data'
.......................................
*Synopsis*
bfd_boolean bfd_copy_private_header_data (bfd *ibfd, bfd *obfd);
*Description*
Copy private BFD header information from the BFD IBFD to the the BFD
OBFD. This copies information that may require sections to exist, but
does not require symbol tables. 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_header_data(ibfd, obfd) \
BFD_SEND (obfd, _bfd_copy_private_header_data, \
(ibfd, obfd))
2.3.1.12 `bfd_copy_private_bfd_data'
....................................
*Synopsis*
bfd_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))
2.3.1.13 `bfd_merge_private_bfd_data'
.....................................
*Synopsis*
bfd_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))
2.3.1.14 `bfd_set_private_flags'
................................
*Synopsis*
bfd_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))
2.3.1.15 `Other functions'
..........................
*Description*
The following functions exist but have not yet been documented.
#define bfd_sizeof_headers(abfd, info) \
BFD_SEND (abfd, _bfd_sizeof_headers, (abfd, info))
#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))
#define bfd_find_line(abfd, syms, sym, file, line) \
BFD_SEND (abfd, _bfd_find_line, \
(abfd, syms, sym, file, line))
#define bfd_find_inliner_info(abfd, file, func, line) \
BFD_SEND (abfd, _bfd_find_inliner_info, \
(abfd, file, func, line))
#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_is_group_section(abfd, sec) \
BFD_SEND (abfd, _bfd_is_group_section, (abfd, sec))
#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(abfd, 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_synthetic_symtab(abfd, count, syms, dyncount, dynsyms, ret) \
BFD_SEND (abfd, _bfd_get_synthetic_symtab, (abfd, count, syms, \
dyncount, dynsyms, ret))
#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
(bfd *, struct bfd_link_info *, struct bfd_link_order *, bfd_byte *,
bfd_boolean, asymbol **);
2.3.1.16 `bfd_alt_mach_code'
............................
*Synopsis*
bfd_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.
struct bfd_preserve
{
void *marker;
void *tdata;
flagword flags;
const struct bfd_arch_info *arch_info;
struct bfd_section *sections;
struct bfd_section *section_last;
unsigned int section_count;
struct bfd_hash_table section_htab;
};
2.3.1.17 `bfd_preserve_save'
............................
*Synopsis*
bfd_boolean bfd_preserve_save (bfd *, struct bfd_preserve *);
*Description*
When testing an object for compatibility with a particular target
back-end, the back-end object_p function needs to set up certain fields
in the bfd on successfully recognizing the object. This typically
happens in a piecemeal fashion, with failures possible at many points.
On failure, the bfd is supposed to be restored to its initial state,
which is virtually impossible. However, restoring a subset of the bfd
state works in practice. This function stores the subset and
reinitializes the bfd.
2.3.1.18 `bfd_preserve_restore'
...............................
*Synopsis*
void bfd_preserve_restore (bfd *, struct bfd_preserve *);
*Description*
This function restores bfd state saved by bfd_preserve_save. If MARKER
is non-NULL in struct bfd_preserve then that block and all subsequently
bfd_alloc'd memory is freed.
2.3.1.19 `bfd_preserve_finish'
..............................
*Synopsis*
void bfd_preserve_finish (bfd *, struct bfd_preserve *);
*Description*
This function should be called when the bfd state saved by
bfd_preserve_save is no longer needed. ie. when the back-end object_p
function returns with success.
2.3.1.20 `bfd_emul_get_maxpagesize'
...................................
*Synopsis*
bfd_vma bfd_emul_get_maxpagesize (const char *);
*Description*
Returns the maximum page size, in bytes, as determined by emulation.
*Returns*
Returns the maximum page size in bytes for ELF, abort otherwise.
2.3.1.21 `bfd_emul_set_maxpagesize'
...................................
*Synopsis*
void bfd_emul_set_maxpagesize (const char *, bfd_vma);
*Description*
For ELF, set the maximum page size for the emulation. It is a no-op
for other formats.
2.3.1.22 `bfd_emul_get_commonpagesize'
......................................
*Synopsis*
bfd_vma bfd_emul_get_commonpagesize (const char *);
*Description*
Returns the common page size, in bytes, as determined by emulation.
*Returns*
Returns the common page size in bytes for ELF, abort otherwise.
2.3.1.23 `bfd_emul_set_commonpagesize'
......................................
*Synopsis*
void bfd_emul_set_commonpagesize (const char *, bfd_vma);
*Description*
For ELF, set the common page size for the emulation. It is a no-op for
other formats.
2.3.1.24 `bfd_demangle'
.......................
*Synopsis*
char *bfd_demangle (bfd *, const char *, int);
*Description*
Wrapper around cplus_demangle. Strips leading underscores and other
such chars that would otherwise confuse the demangler. If passed a g++
v3 ABI mangled name, returns a buffer allocated with malloc holding the
demangled name. Returns NULL otherwise and on memory alloc failure.
2.3.1.25 `struct bfd_iovec'
...........................
*Description*
The `struct bfd_iovec' contains the internal file I/O class. Each
`BFD' has an instance of this class and all file I/O is routed through
it (it is assumed that the instance implements all methods listed
below).
struct bfd_iovec
{
/* To avoid problems with macros, a "b" rather than "f"
prefix is prepended to each method name. */
/* Attempt to read/write NBYTES on ABFD's IOSTREAM storing/fetching
bytes starting at PTR. Return the number of bytes actually
transfered (a read past end-of-file returns less than NBYTES),
or -1 (setting `bfd_error') if an error occurs. */
file_ptr (*bread) (struct bfd *abfd, void *ptr, file_ptr nbytes);
file_ptr (*bwrite) (struct bfd *abfd, const void *ptr,
file_ptr nbytes);
/* Return the current IOSTREAM file offset, or -1 (setting `bfd_error'
if an error occurs. */
file_ptr (*btell) (struct bfd *abfd);
/* For the following, on successful completion a value of 0 is returned.
Otherwise, a value of -1 is returned (and `bfd_error' is set). */
int (*bseek) (struct bfd *abfd, file_ptr offset, int whence);
int (*bclose) (struct bfd *abfd);
int (*bflush) (struct bfd *abfd);
int (*bstat) (struct bfd *abfd, struct stat *sb);
};
2.3.1.26 `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).
2.3.1.27 `bfd_get_size'
.......................
*Synopsis*
file_ptr 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 question, "is
the size reasonable?".
* 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
2.4 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
2.5 Initialization
==================
2.5.1 Initialization functions
------------------------------
These are the functions that handle initializing a BFD.
2.5.1.1 `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
2.6 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
2.6.1 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
2.6.2 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 --------|
2.6.3 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.

File: bfd.info, Node: typedef asection, Next: section prototypes, Prev: Section Output, Up: Sections
2.6.4 typedef asection
----------------------
Here is the section structure:
typedef struct bfd_section
{
/* 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 bfd_section *next;
/* The previous section in the list belonging to the BFD, or NULL. */
struct bfd_section *prev;
/* 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
/* A signal to the OS that the section contains read only data. */
#define SEC_READONLY 0x008
/* The section contains code only. */
#define SEC_CODE 0x010
/* The section contains data only. */
#define SEC_DATA 0x020
/* The section will reside in ROM. */
#define SEC_ROM 0x040
/* 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 0x080
/* 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 0x100
/* An instruction to the linker to not output the section
even if it has information which would normally be written. */
#define SEC_NEVER_LOAD 0x200
/* The section contains thread local data. */
#define SEC_THREAD_LOCAL 0x400
/* 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 0x800
/* The section contains common symbols (symbols may be defined
multiple times, the value of a symbol is the amount of
space it requires, and the largest symbol value is the one
used). Most targets have exactly one of these (which we
translate to bfd_com_section_ptr), but ECOFF has two. */
#define SEC_IS_COMMON 0x1000
/* 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 0x2000
/* 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 0x4000
/* 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 0x8000
/* 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 0x10000
/* 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 0x20000
/* If SEC_LINK_ONCE is set, this bitfield describes how the linker
should handle duplicate sections. */
#define SEC_LINK_DUPLICATES 0xc0000
/* 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 0x40000
/* 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 0x80000
/* 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 \
(SEC_LINK_DUPLICATES_ONE_ONLY | SEC_LINK_DUPLICATES_SAME_SIZE)
/* 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 0x100000
/* This section should not be subject to garbage collection.
Also set to inform the linker that this section should not be
listed in the link map as discarded. */
#define SEC_KEEP 0x200000
/* This section contains "short" data, and should be placed
"near" the GP. */
#define SEC_SMALL_DATA 0x400000
/* Attempt to merge identical entities in the section.
Entity size is given in the entsize field. */
#define SEC_MERGE 0x800000
/* 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 0x1000000
/* This section contains data about section groups. */
#define SEC_GROUP 0x2000000
/* 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 0x4000000
/* This section contains data which may be shared with other
executables or shared objects. This is for COFF only. */
#define SEC_COFF_SHARED 0x8000000
/* 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. This is for TI
TMS320C54X only. */
#define SEC_TIC54X_BLOCK 0x10000000
/* Conditionally link this section; do not link if there are no
references found to any symbol in the section. This is for TI
TMS320C54X only. */
#define SEC_TIC54X_CLINK 0x20000000
/* End of section flags. */
/* Some internal packed boolean fields. */
/* See the vma field. */
unsigned int user_set_vma : 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;
/* Mark flag used by some linker backends for garbage collection. */
unsigned int gc_mark : 1;
/* The following flags are used by the ELF linker. */
/* Mark sections which have been allocated to segments. */
unsigned int segment_mark : 1;
/* Type of sec_info information. */
unsigned int sec_info_type:3;
#define ELF_INFO_TYPE_NONE 0
#define ELF_INFO_TYPE_STABS 1
#define ELF_INFO_TYPE_MERGE 2
#define ELF_INFO_TYPE_EH_FRAME 3
#define ELF_INFO_TYPE_JUST_SYMS 4
/* Nonzero if this section uses RELA relocations, rather than REL. */
unsigned int use_rela_p:1;
/* Bits used by various backends. The generic code doesn't touch
these fields. */
/* Nonzero if this section has TLS related relocations. */
unsigned int has_tls_reloc:1;
/* Nonzero if this section has a gp reloc. */
unsigned int has_gp_reloc:1;
/* Nonzero if this section needs the relax finalize pass. */
unsigned int need_finalize_relax:1;
/* Whether relocations have been processed. */
unsigned int reloc_done : 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'). */
bfd_size_type size;
/* For input sections, the original size on disk of the section, in
octets. This field should be set for any section whose size is
changed by linker relaxation. It is required for sections where
the linker relaxation scheme doesn't cache altered section and
reloc contents (stabs, eh_frame, SEC_MERGE, some coff relaxing
targets), and thus the original size needs to be kept to read the
section multiple times. For output sections, rawsize holds the
section size calculated on a previous linker relaxation pass. */
bfd_size_type rawsize;
/* 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 bfd_section *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. */
void *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;
/* Points to the kept section if this section is a link-once section,
and is discarded. */
struct bfd_section *kept_section;
/* 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;
void *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 bfd_symbol *symbol;
struct bfd_symbol **symbol_ptr_ptr;
/* Early in the link process, map_head and map_tail are used to build
a list of input sections attached to an output section. Later,
output sections use these fields for a list of bfd_link_order
structs. */
union {
struct bfd_link_order *link_order;
struct bfd_section *s;
} map_head, map_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 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 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 asection bfd_com_section;
#define bfd_com_section_ptr ((asection *) &bfd_com_section)
/* Pointer to the indirect section. */
extern 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))
/* 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, S) \
do \
{ \
asection *_s = S; \
asection *_next = _s->next; \
asection *_prev = _s->prev; \
if (_prev) \
_prev->next = _next; \
else \
(ABFD)->sections = _next; \
if (_next) \
_next->prev = _prev; \
else \
(ABFD)->section_last = _prev; \
} \
while (0)
#define bfd_section_list_append(ABFD, S) \
do \
{ \
asection *_s = S; \
bfd *_abfd = ABFD; \
_s->next = NULL; \
if (_abfd->section_last) \
{ \
_s->prev = _abfd->section_last; \
_abfd->section_last->next = _s; \
} \
else \
{ \
_s->prev = NULL; \
_abfd->sections = _s; \
} \
_abfd->section_last = _s; \
} \
while (0)
#define bfd_section_list_prepend(ABFD, S) \
do \
{ \
asection *_s = S; \
bfd *_abfd = ABFD; \
_s->prev = NULL; \
if (_abfd->sections) \
{ \
_s->next = _abfd->sections; \
_abfd->sections->prev = _s; \
} \
else \
{ \
_s->next = NULL; \
_abfd->section_last = _s; \
} \
_abfd->sections = _s; \
} \
while (0)
#define bfd_section_list_insert_after(ABFD, A, S) \
do \
{ \
asection *_a = A; \
asection *_s = S; \
asection *_next = _a->next; \
_s->next = _next; \
_s->prev = _a; \
_a->next = _s; \
if (_next) \
_next->prev = _s; \
else \
(ABFD)->section_last = _s; \
} \
while (0)
#define bfd_section_list_insert_before(ABFD, B, S) \
do \
{ \
asection *_b = B; \
asection *_s = S; \
asection *_prev = _b->prev; \
_s->prev = _prev; \
_s->next = _b; \
_b->prev = _s; \
if (_prev) \
_prev->next = _s; \
else \
(ABFD)->sections = _s; \
} \
while (0)
#define bfd_section_removed_from_list(ABFD, S) \
((S)->next == NULL ? (ABFD)->section_last != (S) : (S)->next->prev != (S))
#define BFD_FAKE_SECTION(SEC, FLAGS, SYM, NAME, IDX) \
/* name, id, index, next, prev, flags, user_set_vma, */ \
{ NAME, IDX, 0, NULL, NULL, FLAGS, 0, \
\
/* linker_mark, linker_has_input, gc_mark, */ \
0, 0, 1, \
\
/* segment_mark, sec_info_type, use_rela_p, has_tls_reloc, */ \
0, 0, 0, 0, \
\
/* has_gp_reloc, need_finalize_relax, reloc_done, */ \
0, 0, 0, \
\
/* vma, lma, size, rawsize */ \
0, 0, 0, 0, \
\
/* output_offset, output_section, alignment_power, */ \
0, (struct bfd_section *) &SEC, 0, \
\
/* relocation, orelocation, reloc_count, filepos, rel_filepos, */ \
NULL, NULL, 0, 0, 0, \
\
/* line_filepos, userdata, contents, lineno, lineno_count, */ \
0, NULL, NULL, NULL, 0, \
\
/* entsize, kept_section, moving_line_filepos, */ \
0, NULL, 0, \
\
/* target_index, used_by_bfd, constructor_chain, owner, */ \
0, NULL, NULL, NULL, \
\
/* symbol, symbol_ptr_ptr, */ \
(struct bfd_symbol *) SYM, &SEC.symbol, \
\
/* map_head, map_tail */ \
{ NULL }, { NULL } \
}

File: bfd.info, Node: section prototypes, Prev: typedef asection, Up: Sections
2.6.5 Section prototypes
------------------------
These are the functions exported by the section handling part of BFD.
2.6.5.1 `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.
2.6.5.2 `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.
2.6.5.3 `bfd_get_section_by_name_if'
....................................
*Synopsis*
asection *bfd_get_section_by_name_if
(bfd *abfd,
const char *name,
bfd_boolean (*func) (bfd *abfd, asection *sect, void *obj),
void *obj);
*Description*
Call the provided function FUNC for each section attached to the BFD
ABFD whose name matches NAME, passing OBJ as an argument. The function
will be called as if by
func (abfd, the_section, obj);
It returns the first section for which FUNC returns true, otherwise
`NULL'.
2.6.5.4 `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.
2.6.5.5 `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.
2.6.5.6 `bfd_make_section_anyway_with_flags'
............................................
*Synopsis*
asection *bfd_make_section_anyway_with_flags
(bfd *abfd, const char *name, flagword flags);
*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. Also set the attributes of the new
section to the value FLAGS.
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.
2.6.5.7 `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.
2.6.5.8 `bfd_make_section_with_flags'
.....................................
*Synopsis*
asection *bfd_make_section_with_flags
(bfd *, const char *name, flagword flags);
*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. Also set the attributes of the new
section to the value FLAGS. If there is an error, return `NULL' and set
`bfd_error'.
2.6.5.9 `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'.
2.6.5.10 `bfd_set_section_flags'
................................
*Synopsis*
bfd_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.
2.6.5.11 `bfd_map_over_sections'
................................
*Synopsis*
void bfd_map_over_sections
(bfd *abfd,
void (*func) (bfd *abfd, asection *sect, void *obj),
void *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 preferred 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, ...)
2.6.5.12 `bfd_sections_find_if'
...............................
*Synopsis*
asection *bfd_sections_find_if
(bfd *abfd,
bfd_boolean (*operation) (bfd *abfd, asection *sect, void *obj),
void *obj);
*Description*
Call the provided function OPERATION for each section attached to the
BFD ABFD, passing OBJ as an argument. The function will be called as if
by
operation (abfd, the_section, obj);
It returns the first section for which OPERATION returns true.
2.6.5.13 `bfd_set_section_size'
...............................
*Synopsis*
bfd_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.
2.6.5.14 `bfd_set_section_contents'
...................................
*Synopsis*
bfd_boolean bfd_set_section_contents
(bfd *abfd, asection *section, const void *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'.
2.6.5.15 `bfd_get_section_contents'
...................................
*Synopsis*
bfd_boolean bfd_get_section_contents
(bfd *abfd, asection *section, void *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'.
2.6.5.16 `bfd_malloc_and_get_section'
.....................................
*Synopsis*
bfd_boolean bfd_malloc_and_get_section
(bfd *abfd, asection *section, bfd_byte **buf);
*Description*
Read all data from SECTION in BFD ABFD into a buffer, *BUF, malloc'd by
this function.
2.6.5.17 `bfd_copy_private_section_data'
........................................
*Synopsis*
bfd_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))
2.6.5.18 `bfd_generic_is_group_section'
.......................................
*Synopsis*
bfd_boolean bfd_generic_is_group_section (bfd *, const asection *sec);
*Description*
Returns TRUE if SEC is a member of a group.
2.6.5.19 `bfd_generic_discard_group'
....................................
*Synopsis*
bfd_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
2.7 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
2.7.1 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 = 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
2.7.2 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"
int main (void)
{
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] = 0;
bfd_set_symtab (abfd, ptrs, 1);
bfd_close (abfd);
return 0;
}
./makesym
nm foo
00012345 A dummy_symbol
Many formats cannot represent arbitrary symbol information; for
instance, the `a.out' object format does not allow an arbitrary 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
2.7.3 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
2.7.4 typedef asymbol
---------------------
An `asymbol' has the form:
typedef struct bfd_symbol
{
/* 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 arbitrary
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
/* This symbol represents a complex relocation expression,
with the expression tree serialized in the symbol name. */
#define BSF_RELC 0x80000
/* This symbol represents a signed complex relocation expression,
with the expression tree serialized in the symbol name. */
#define BSF_SRELC 0x100000
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 bfd_section *section;
/* Back end special data. */
union
{
void *p;
bfd_vma i;
}
udata;
}
asymbol;

File: bfd.info, Node: symbol handling functions, Prev: typedef asymbol, Up: Symbols
2.7.5 Symbol handling functions
-------------------------------
2.7.5.1 `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))
2.7.5.2 `bfd_is_local_label'
............................
*Synopsis*
bfd_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.
2.7.5.3 `bfd_is_local_label_name'
.................................
*Synopsis*
bfd_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))
2.7.5.4 `bfd_is_target_special_symbol'
......................................
*Synopsis*
bfd_boolean bfd_is_target_special_symbol (bfd *abfd, asymbol *sym);
*Description*
Return TRUE iff a symbol SYM in the BFD ABFD is something special to
the particular target represented by the BFD. Such symbols should
normally not be mentioned to the user.
#define bfd_is_target_special_symbol(abfd, sym) \
BFD_SEND (abfd, _bfd_is_target_special_symbol, (abfd, sym))
2.7.5.5 `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))
2.7.5.6 `bfd_set_symtab'
........................
*Synopsis*
bfd_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.
2.7.5.7 `bfd_print_symbol_vandf'
................................
*Synopsis*
void bfd_print_symbol_vandf (bfd *abfd, void *file, asymbol *symbol);
*Description*
Print the value and flags of the SYMBOL supplied to the stream FILE.
2.7.5.8 `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))
2.7.5.9 `_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.
2.7.5.10 `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))
2.7.5.11 `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);
2.7.5.12 `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*
bfd_boolean bfd_is_undefined_symclass (int symclass);
2.7.5.13 `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);
2.7.5.14 `bfd_copy_private_symbol_data'
.......................................
*Synopsis*
bfd_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
2.8 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'.
2.8.1 Archive functions
-----------------------
2.8.1.1 `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.
2.8.1.2 `bfd_set_archive_head'
..............................
*Synopsis*
bfd_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.
2.8.1.3 `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
2.9 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.
2.9.1 File format functions
---------------------------
2.9.1.1 `bfd_check_format'
..........................
*Synopsis*
bfd_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.
2.9.1.2 `bfd_check_format_matches'
..................................
*Synopsis*
bfd_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.
2.9.1.3 `bfd_set_format'
........................
*Synopsis*
bfd_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.
2.9.1.4 `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
2.10 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::

File: bfd.info, Node: typedef arelent, Next: howto manager, Prev: Relocations, Up: Relocations
2.10.1 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 bfd_symbol **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 `canonicalize_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.
2.10.1.1 `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 value overflows when considered as a signed
number one bit larger than the field. ie. A bitfield of N bits
is allowed to represent -2**n to 2**n-1. */
complain_overflow_bitfield,
/* Complain if the value overflows when considered as a signed
number. */
complain_overflow_signed,
/* Complain if the value overflows when considered as an
unsigned number. */
complain_overflow_unsigned
};
2.10.1.2 `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 bfd_symbol; /* 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. */
bfd_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 accommodated (e.g., i960 callj
instructions). */
bfd_reloc_status_type (*special_function)
(bfd *, arelent *, struct bfd_symbol *, void *, 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. */
bfd_boolean partial_inplace;
/* src_mask selects the part of the instruction (or data) to be used
in the relocation sum. If the target relocations don't have an
addend in the reloc, eg. ELF USE_REL, src_mask will normally equal
dst_mask to extract the addend from the section contents. If
relocations do have an addend in the reloc, eg. ELF USE_RELA, this
field should be zero. Non-zero values for ELF USE_RELA targets are
bogus as in those cases the value in the dst_mask part of the
section contents should be treated as garbage. */
bfd_vma src_mask;
/* dst_mask selects which parts of the instruction (or data) are
replaced with a relocated value. */
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. */
bfd_boolean pcrel_offset;
};
2.10.1.3 `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 != NULL) \
{ \
if (bfd_is_com_section (symbol->section)) \
{ \
relocation = 0; \
} \
else \
{ \
relocation = symbol->value; \
} \
} \
}
2.10.1.4 `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.
2.10.1.5 `arelent_chain'
........................
*Description*
How relocs are tied together in an `asection':
typedef struct relent_chain
{
arelent relent;
struct relent_chain *next;
}
arelent_chain;
2.10.1.6 `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'.
2.10.1.7 `bfd_perform_relocation'
.................................
*Synopsis*
bfd_reloc_status_type bfd_perform_relocation
(bfd *abfd,
arelent *reloc_entry,
void *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'.
2.10.1.8 `bfd_install_relocation'
.................................
*Synopsis*
bfd_reloc_status_type bfd_install_relocation
(bfd *abfd,
arelent *reloc_entry,
void *data, bfd_vma data_start,
asection *input_section,
char **error_message);
*Description*
This looks remarkably like `bfd_perform_relocation', except it does not
expect that the section contents have been filled in. I.e., it's
suitable for use when creating, rather than applying a relocation.
For now, this function should be considered reserved for the
assembler.

File: bfd.info, Node: howto manager, Prev: typedef arelent, Up: Relocations
2.10.2 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.
2.10.2.1 `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_SECREL
Section relative relocations. Some targets need this for DWARF2.
-- : 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_SPARC_TLS_GD_HI22
-- : BFD_RELOC_SPARC_TLS_GD_LO10
-- : BFD_RELOC_SPARC_TLS_GD_ADD
-- : BFD_RELOC_SPARC_TLS_GD_CALL
-- : BFD_RELOC_SPARC_TLS_LDM_HI22
-- : BFD_RELOC_SPARC_TLS_LDM_LO10
-- : BFD_RELOC_SPARC_TLS_LDM_ADD
-- : BFD_RELOC_SPARC_TLS_LDM_CALL
-- : BFD_RELOC_SPARC_TLS_LDO_HIX22
-- : BFD_RELOC_SPARC_TLS_LDO_LOX10
-- : BFD_RELOC_SPARC_TLS_LDO_ADD
-- : BFD_RELOC_SPARC_TLS_IE_HI22
-- : BFD_RELOC_SPARC_TLS_IE_LO10
-- : BFD_RELOC_SPARC_TLS_IE_LD
-- : BFD_RELOC_SPARC_TLS_IE_LDX
-- : BFD_RELOC_SPARC_TLS_IE_ADD
-- : BFD_RELOC_SPARC_TLS_LE_HIX22
-- : BFD_RELOC_SPARC_TLS_LE_LOX10
-- : BFD_RELOC_SPARC_TLS_DTPMOD32
-- : BFD_RELOC_SPARC_TLS_DTPMOD64
-- : BFD_RELOC_SPARC_TLS_DTPOFF32
-- : BFD_RELOC_SPARC_TLS_DTPOFF64
-- : BFD_RELOC_SPARC_TLS_TPOFF32
-- : BFD_RELOC_SPARC_TLS_TPOFF64
SPARC TLS relocations
-- : BFD_RELOC_SPU_IMM7
-- : BFD_RELOC_SPU_IMM8
-- : BFD_RELOC_SPU_IMM10
-- : BFD_RELOC_SPU_IMM10W
-- : BFD_RELOC_SPU_IMM16
-- : BFD_RELOC_SPU_IMM16W
-- : BFD_RELOC_SPU_IMM18
-- : BFD_RELOC_SPU_PCREL9a
-- : BFD_RELOC_SPU_PCREL9b
-- : BFD_RELOC_SPU_PCREL16
-- : BFD_RELOC_SPU_LO16
-- : BFD_RELOC_SPU_HI16
-- : BFD_RELOC_SPU_PPU32
-- : BFD_RELOC_SPU_PPU64
SPU Relocations.
-- : 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_HI16_PCREL
High 16 bits of 32-bit pc-relative value
-- : BFD_RELOC_HI16_S_PCREL
High 16 bits of 32-bit pc-relative value, adjusted
-- : BFD_RELOC_LO16_PCREL
Low 16 bits of pc-relative value
-- : BFD_RELOC_MIPS16_HI16
MIPS16 high 16 bits of 32-bit value.
-- : BFD_RELOC_MIPS16_HI16_S
MIPS16 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_MIPS16_LO16
MIPS16 low 16 bits.
-- : 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_MIPS_TLS_DTPMOD32
-- : BFD_RELOC_MIPS_TLS_DTPREL32
-- : BFD_RELOC_MIPS_TLS_DTPMOD64
-- : BFD_RELOC_MIPS_TLS_DTPREL64
-- : BFD_RELOC_MIPS_TLS_GD
-- : BFD_RELOC_MIPS_TLS_LDM
-- : BFD_RELOC_MIPS_TLS_DTPREL_HI16
-- : BFD_RELOC_MIPS_TLS_DTPREL_LO16
-- : BFD_RELOC_MIPS_TLS_GOTTPREL
-- : BFD_RELOC_MIPS_TLS_TPREL32
-- : BFD_RELOC_MIPS_TLS_TPREL64
-- : BFD_RELOC_MIPS_TLS_TPREL_HI16
-- : BFD_RELOC_MIPS_TLS_TPREL_LO16
MIPS ELF relocations.
-- : BFD_RELOC_MIPS_COPY
-- : BFD_RELOC_MIPS_JUMP_SLOT
MIPS ELF relocations (VxWorks extensions).
-- : 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
-- : BFD_RELOC_FRV_GOT12
-- : BFD_RELOC_FRV_GOTHI
-- : BFD_RELOC_FRV_GOTLO
-- : BFD_RELOC_FRV_FUNCDESC
-- : BFD_RELOC_FRV_FUNCDESC_GOT12
-- : BFD_RELOC_FRV_FUNCDESC_GOTHI
-- : BFD_RELOC_FRV_FUNCDESC_GOTLO
-- : BFD_RELOC_FRV_FUNCDESC_VALUE
-- : BFD_RELOC_FRV_FUNCDESC_GOTOFF12
-- : BFD_RELOC_FRV_FUNCDESC_GOTOFFHI
-- : BFD_RELOC_FRV_FUNCDESC_GOTOFFLO
-- : BFD_RELOC_FRV_GOTOFF12
-- : BFD_RELOC_FRV_GOTOFFHI
-- : BFD_RELOC_FRV_GOTOFFLO
-- : BFD_RELOC_FRV_GETTLSOFF
-- : BFD_RELOC_FRV_TLSDESC_VALUE
-- : BFD_RELOC_FRV_GOTTLSDESC12
-- : BFD_RELOC_FRV_GOTTLSDESCHI
-- : BFD_RELOC_FRV_GOTTLSDESCLO
-- : BFD_RELOC_FRV_TLSMOFF12
-- : BFD_RELOC_FRV_TLSMOFFHI
-- : BFD_RELOC_FRV_TLSMOFFLO
-- : BFD_RELOC_FRV_GOTTLSOFF12
-- : BFD_RELOC_FRV_GOTTLSOFFHI
-- : BFD_RELOC_FRV_GOTTLSOFFLO
-- : BFD_RELOC_FRV_TLSOFF
-- : BFD_RELOC_FRV_TLSDESC_RELAX
-- : BFD_RELOC_FRV_GETTLSOFF_RELAX
-- : BFD_RELOC_FRV_TLSOFF_RELAX
-- : BFD_RELOC_FRV_TLSMOFF
Fujitsu Frv Relocations.
-- : BFD_RELOC_MN10300_GOTOFF24
This is a 24bit GOT-relative reloc for the mn10300.
-- : BFD_RELOC_MN10300_GOT32
This is a 32bit GOT-relative reloc for the mn10300, offset by two
bytes in the instruction.
-- : BFD_RELOC_MN10300_GOT24
This is a 24bit GOT-relative reloc for the mn10300, offset by two
bytes in the instruction.
-- : BFD_RELOC_MN10300_GOT16
This is a 16bit GOT-relative reloc for the mn10300, offset by two
bytes in the instruction.
-- : BFD_RELOC_MN10300_COPY
Copy symbol at runtime.
-- : BFD_RELOC_MN10300_GLOB_DAT
Create GOT entry.
-- : BFD_RELOC_MN10300_JMP_SLOT
Create PLT entry.
-- : BFD_RELOC_MN10300_RELATIVE
Adjust by program base.
-- : BFD_RELOC_MN10300_SYM_DIFF
Together with another reloc targeted at the same location, allows
for a value that is the difference of two symbols in the same
section.
-- : BFD_RELOC_MN10300_ALIGN
The addend of this reloc is an alignment power that must be
honoured at the offset's location, regardless of linker relaxation.
-- : 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_TPOFF
-- : BFD_RELOC_386_TLS_IE
-- : BFD_RELOC_386_TLS_GOTIE
-- : 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
-- : BFD_RELOC_386_TLS_GOTDESC
-- : BFD_RELOC_386_TLS_DESC_CALL
-- : BFD_RELOC_386_TLS_DESC
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
-- : BFD_RELOC_X86_64_DTPMOD64
-- : BFD_RELOC_X86_64_DTPOFF64
-- : BFD_RELOC_X86_64_TPOFF64
-- : BFD_RELOC_X86_64_TLSGD
-- : BFD_RELOC_X86_64_TLSLD
-- : BFD_RELOC_X86_64_DTPOFF32
-- : BFD_RELOC_X86_64_GOTTPOFF
-- : BFD_RELOC_X86_64_TPOFF32
-- : BFD_RELOC_X86_64_GOTOFF64
-- : BFD_RELOC_X86_64_GOTPC32
-- : BFD_RELOC_X86_64_GOT64
-- : BFD_RELOC_X86_64_GOTPCREL64
-- : BFD_RELOC_X86_64_GOTPC64
-- : BFD_RELOC_X86_64_GOTPLT64
-- : BFD_RELOC_X86_64_PLTOFF64
-- : BFD_RELOC_X86_64_GOTPC32_TLSDESC
-- : BFD_RELOC_X86_64_TLSDESC_CALL
-- : BFD_RELOC_X86_64_TLSDESC
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_PPC_TLS
-- : BFD_RELOC_PPC_DTPMOD
-- : BFD_RELOC_PPC_TPREL16
-- : BFD_RELOC_PPC_TPREL16_LO
-- : BFD_RELOC_PPC_TPREL16_HI
-- : BFD_RELOC_PPC_TPREL16_HA
-- : BFD_RELOC_PPC_TPREL
-- : BFD_RELOC_PPC_DTPREL16
-- : BFD_RELOC_PPC_DTPREL16_LO
-- : BFD_RELOC_PPC_DTPREL16_HI
-- : BFD_RELOC_PPC_DTPREL16_HA
-- : BFD_RELOC_PPC_DTPREL
-- : BFD_RELOC_PPC_GOT_TLSGD16
-- : BFD_RELOC_PPC_GOT_TLSGD16_LO
-- : BFD_RELOC_PPC_GOT_TLSGD16_HI
-- : BFD_RELOC_PPC_GOT_TLSGD16_HA
-- : BFD_RELOC_PPC_GOT_TLSLD16
-- : BFD_RELOC_PPC_GOT_TLSLD16_LO
-- : BFD_RELOC_PPC_GOT_TLSLD16_HI
-- : BFD_RELOC_PPC_GOT_TLSLD16_HA
-- : BFD_RELOC_PPC_GOT_TPREL16
-- : BFD_RELOC_PPC_GOT_TPREL16_LO
-- : BFD_RELOC_PPC_GOT_TPREL16_HI
-- : BFD_RELOC_PPC_GOT_TPREL16_HA
-- : BFD_RELOC_PPC_GOT_DTPREL16
-- : BFD_RELOC_PPC_GOT_DTPREL16_LO
-- : BFD_RELOC_PPC_GOT_DTPREL16_HI
-- : BFD_RELOC_PPC_GOT_DTPREL16_HA
-- : BFD_RELOC_PPC64_TPREL16_DS
-- : BFD_RELOC_PPC64_TPREL16_LO_DS
-- : BFD_RELOC_PPC64_TPREL16_HIGHER
-- : BFD_RELOC_PPC64_TPREL16_HIGHERA
-- : BFD_RELOC_PPC64_TPREL16_HIGHEST
-- : BFD_RELOC_PPC64_TPREL16_HIGHESTA
-- : BFD_RELOC_PPC64_DTPREL16_DS
-- : BFD_RELOC_PPC64_DTPREL16_LO_DS
-- : BFD_RELOC_PPC64_DTPREL16_HIGHER
-- : BFD_RELOC_PPC64_DTPREL16_HIGHERA
-- : BFD_RELOC_PPC64_DTPREL16_HIGHEST
-- : BFD_RELOC_PPC64_DTPREL16_HIGHESTA
PowerPC and PowerPC64 thread-local storage relocations.
-- : BFD_RELOC_I370_D12
IBM 370/390 relocations
-- : BFD_RELOC_CTOR
The type of reloc used to build a constructor 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_PCREL_CALL
ARM 26-bit pc-relative branch for an unconditional BL or BLX
instruction.
-- : BFD_RELOC_ARM_PCREL_JUMP
ARM 26-bit pc-relative branch for B or conditional BL instruction.
-- : BFD_RELOC_THUMB_PCREL_BRANCH7
-- : BFD_RELOC_THUMB_PCREL_BRANCH9
-- : BFD_RELOC_THUMB_PCREL_BRANCH12
-- : BFD_RELOC_THUMB_PCREL_BRANCH20
-- : BFD_RELOC_THUMB_PCREL_BRANCH23
-- : BFD_RELOC_THUMB_PCREL_BRANCH25
Thumb 7-, 9-, 12-, 20-, 23-, and 25-bit pc-relative branches. The
lowest bit must be zero and is not stored in the instruction.
Note that the corresponding ELF R_ARM_THM_JUMPnn constant has an
"nn" one smaller in all cases. Note further that BRANCH23
corresponds to R_ARM_THM_CALL.
-- : BFD_RELOC_ARM_OFFSET_IMM
12-bit immediate offset, used in ARM-format ldr and str
instructions.
-- : BFD_RELOC_ARM_THUMB_OFFSET
5-bit immediate offset, used in Thumb-format ldr and str
instructions.
-- : BFD_RELOC_ARM_TARGET1
Pc-relative or absolute relocation depending on target. Used for
entries in .init_array sections.
-- : BFD_RELOC_ARM_ROSEGREL32
Read-only segment base relative address.
-- : BFD_RELOC_ARM_SBREL32
Data segment base relative address.
-- : BFD_RELOC_ARM_TARGET2
This reloc is used for references to RTTI data from exception
handling tables. The actual definition depends on the target. It
may be a pc-relative or some form of GOT-indirect relocation.
-- : BFD_RELOC_ARM_PREL31
31-bit PC relative address.
-- : BFD_RELOC_ARM_MOVW
-- : BFD_RELOC_ARM_MOVT
-- : BFD_RELOC_ARM_MOVW_PCREL
-- : BFD_RELOC_ARM_MOVT_PCREL
-- : BFD_RELOC_ARM_THUMB_MOVW
-- : BFD_RELOC_ARM_THUMB_MOVT
-- : BFD_RELOC_ARM_THUMB_MOVW_PCREL
-- : BFD_RELOC_ARM_THUMB_MOVT_PCREL
Low and High halfword relocations for MOVW and MOVT instructions.
-- : BFD_RELOC_ARM_JUMP_SLOT
-- : BFD_RELOC_ARM_GLOB_DAT
-- : BFD_RELOC_ARM_GOT32
-- : BFD_RELOC_ARM_PLT32
-- : BFD_RELOC_ARM_RELATIVE
-- : BFD_RELOC_ARM_GOTOFF
-- : BFD_RELOC_ARM_GOTPC
Relocations for setting up GOTs and PLTs for shared libraries.
-- : BFD_RELOC_ARM_TLS_GD32
-- : BFD_RELOC_ARM_TLS_LDO32
-- : BFD_RELOC_ARM_TLS_LDM32
-- : BFD_RELOC_ARM_TLS_DTPOFF32
-- : BFD_RELOC_ARM_TLS_DTPMOD32
-- : BFD_RELOC_ARM_TLS_TPOFF32
-- : BFD_RELOC_ARM_TLS_IE32
-- : BFD_RELOC_ARM_TLS_LE32
ARM thread-local storage relocations.
-- : BFD_RELOC_ARM_ALU_PC_G0_NC
-- : BFD_RELOC_ARM_ALU_PC_G0
-- : BFD_RELOC_ARM_ALU_PC_G1_NC
-- : BFD_RELOC_ARM_ALU_PC_G1
-- : BFD_RELOC_ARM_ALU_PC_G2
-- : BFD_RELOC_ARM_LDR_PC_G0
-- : BFD_RELOC_ARM_LDR_PC_G1
-- : BFD_RELOC_ARM_LDR_PC_G2
-- : BFD_RELOC_ARM_LDRS_PC_G0
-- : BFD_RELOC_ARM_LDRS_PC_G1
-- : BFD_RELOC_ARM_LDRS_PC_G2
-- : BFD_RELOC_ARM_LDC_PC_G0
-- : BFD_RELOC_ARM_LDC_PC_G1
-- : BFD_RELOC_ARM_LDC_PC_G2
-- : BFD_RELOC_ARM_ALU_SB_G0_NC
-- : BFD_RELOC_ARM_ALU_SB_G0
-- : BFD_RELOC_ARM_ALU_SB_G1_NC
-- : BFD_RELOC_ARM_ALU_SB_G1
-- : BFD_RELOC_ARM_ALU_SB_G2
-- : BFD_RELOC_ARM_LDR_SB_G0
-- : BFD_RELOC_ARM_LDR_SB_G1
-- : BFD_RELOC_ARM_LDR_SB_G2
-- : BFD_RELOC_ARM_LDRS_SB_G0
-- : BFD_RELOC_ARM_LDRS_SB_G1
-- : BFD_RELOC_ARM_LDRS_SB_G2
-- : BFD_RELOC_ARM_LDC_SB_G0
-- : BFD_RELOC_ARM_LDC_SB_G1
-- : BFD_RELOC_ARM_LDC_SB_G2
ARM group relocations.
-- : BFD_RELOC_ARM_V4BX
Annotation of BX instructions.
-- : BFD_RELOC_ARM_IMMEDIATE
-- : BFD_RELOC_ARM_ADRL_IMMEDIATE
-- : BFD_RELOC_ARM_T32_IMMEDIATE
-- : BFD_RELOC_ARM_T32_ADD_IMM
-- : BFD_RELOC_ARM_T32_IMM12
-- : BFD_RELOC_ARM_T32_ADD_PC12
-- : BFD_RELOC_ARM_SHIFT_IMM
-- : BFD_RELOC_ARM_SMC
-- : BFD_RELOC_ARM_SWI
-- : BFD_RELOC_ARM_MULTI
-- : BFD_RELOC_ARM_CP_OFF_IMM
-- : BFD_RELOC_ARM_CP_OFF_IMM_S2
-- : BFD_RELOC_ARM_T32_CP_OFF_IMM
-- : BFD_RELOC_ARM_T32_CP_OFF_IMM_S2
-- : 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_T32_OFFSET_U8
-- : BFD_RELOC_ARM_T32_OFFSET_IMM
-- : BFD_RELOC_ARM_HWLITERAL
-- : BFD_RELOC_ARM_THUMB_ADD
-- : BFD_RELOC_ARM_THUMB_IMM
-- : BFD_RELOC_ARM_THUMB_SHIFT
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_IMM3
-- : BFD_RELOC_SH_IMM3U
-- : BFD_RELOC_SH_DISP12
-- : BFD_RELOC_SH_DISP12BY2
-- : BFD_RELOC_SH_DISP12BY4
-- : BFD_RELOC_SH_DISP12BY8
-- : BFD_RELOC_SH_DISP20
-- : BFD_RELOC_SH_DISP20BY8
-- : 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
-- : BFD_RELOC_SH_TLS_GD_32
-- : BFD_RELOC_SH_TLS_LD_32
-- : BFD_RELOC_SH_TLS_LDO_32
-- : BFD_RELOC_SH_TLS_IE_32
-- : BFD_RELOC_SH_TLS_LE_32
-- : BFD_RELOC_SH_TLS_DTPMOD32
-- : BFD_RELOC_SH_TLS_DTPOFF32
-- : BFD_RELOC_SH_TLS_TPOFF32
Renesas / SuperH SH relocs. Not all of these appear in object
files.
-- : 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_BFIN_16_IMM
ADI Blackfin 16 bit immediate absolute reloc.
-- : BFD_RELOC_BFIN_16_HIGH
ADI Blackfin 16 bit immediate absolute reloc higher 16 bits.
-- : BFD_RELOC_BFIN_4_PCREL
ADI Blackfin 'a' part of LSETUP.
-- : BFD_RELOC_BFIN_5_PCREL
ADI Blackfin.
-- : BFD_RELOC_BFIN_16_LOW
ADI Blackfin 16 bit immediate absolute reloc lower 16 bits.
-- : BFD_RELOC_BFIN_10_PCREL
ADI Blackfin.
-- : BFD_RELOC_BFIN_11_PCREL
ADI Blackfin 'b' part of LSETUP.
-- : BFD_RELOC_BFIN_12_PCREL_JUMP
ADI Blackfin.
-- : BFD_RELOC_BFIN_12_PCREL_JUMP_S
ADI Blackfin Short jump, pcrel.
-- : BFD_RELOC_BFIN_24_PCREL_CALL_X
ADI Blackfin Call.x not implemented.
-- : BFD_RELOC_BFIN_24_PCREL_JUMP_L
ADI Blackfin Long Jump pcrel.
-- : BFD_RELOC_BFIN_GOT17M4
-- : BFD_RELOC_BFIN_GOTHI
-- : BFD_RELOC_BFIN_GOTLO
-- : BFD_RELOC_BFIN_FUNCDESC
-- : BFD_RELOC_BFIN_FUNCDESC_GOT17M4
-- : BFD_RELOC_BFIN_FUNCDESC_GOTHI
-- : BFD_RELOC_BFIN_FUNCDESC_GOTLO
-- : BFD_RELOC_BFIN_FUNCDESC_VALUE
-- : BFD_RELOC_BFIN_FUNCDESC_GOTOFF17M4
-- : BFD_RELOC_BFIN_FUNCDESC_GOTOFFHI
-- : BFD_RELOC_BFIN_FUNCDESC_GOTOFFLO
-- : BFD_RELOC_BFIN_GOTOFF17M4
-- : BFD_RELOC_BFIN_GOTOFFHI
-- : BFD_RELOC_BFIN_GOTOFFLO
ADI Blackfin FD-PIC relocations.
-- : BFD_RELOC_BFIN_GOT
ADI Blackfin GOT relocation.
-- : BFD_RELOC_BFIN_PLTPC
ADI Blackfin PLTPC relocation.
-- : BFD_ARELOC_BFIN_PUSH
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_CONST
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_ADD
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_SUB
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_MULT
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_DIV
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_MOD
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_LSHIFT
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_RSHIFT
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_AND
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_OR
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_XOR
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_LAND
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_LOR
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_LEN
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_NEG
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_COMP
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_PAGE
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_HWPAGE
ADI Blackfin arithmetic relocation.
-- : BFD_ARELOC_BFIN_ADDR
ADI Blackfin arithmetic relocation.
-- : 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_M32C_HI8
-- : BFD_RELOC_M32C_RL_JUMP
-- : BFD_RELOC_M32C_RL_1ADDR
-- : BFD_RELOC_M32C_RL_2ADDR
Renesas M16C/M32C Relocations.
-- : BFD_RELOC_M32R_24
Renesas M32R (formerly 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_M32R_GOT24
-- : BFD_RELOC_M32R_26_PLTREL
-- : BFD_RELOC_M32R_COPY
-- : BFD_RELOC_M32R_GLOB_DAT
-- : BFD_RELOC_M32R_JMP_SLOT
-- : BFD_RELOC_M32R_RELATIVE
-- : BFD_RELOC_M32R_GOTOFF
-- : BFD_RELOC_M32R_GOTOFF_HI_ULO
-- : BFD_RELOC_M32R_GOTOFF_HI_SLO
-- : BFD_RELOC_M32R_GOTOFF_LO
-- : BFD_RELOC_M32R_GOTPC24
-- : BFD_RELOC_M32R_GOT16_HI_ULO
-- : BFD_RELOC_M32R_GOT16_HI_SLO
-- : BFD_RELOC_M32R_GOT16_LO
-- : BFD_RELOC_M32R_GOTPC_HI_ULO
-- : BFD_RELOC_M32R_GOTPC_HI_SLO
-- : BFD_RELOC_M32R_GOTPC_LO
For PIC.
-- : 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.
-- : B