| This is bfd.info, produced by makeinfo version 4.8 from bfd.texinfo. |
| |
| INFO-DIR-SECTION Software development |
| START-INFO-DIR-ENTRY |
| * Bfd: (bfd). The Binary File Descriptor library. |
| END-INFO-DIR-ENTRY |
| |
| This file documents the BFD library. |
| |
| Copyright (C) 1991 - 2013 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.3 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 |
| *************** |
| |
| * Menu: |
| |
| * typedef bfd:: |
| * Error reporting:: |
| * Miscellaneous:: |
| * 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: typedef bfd, Next: Error reporting, Prev: BFD front end, Up: 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. |
| |
| |
| enum bfd_direction |
| { |
| no_direction = 0, |
| read_direction = 1, |
| write_direction = 2, |
| both_direction = 3 |
| }; |
| |
| 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; |
| |
| /* 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; |
| |
| /* 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 direction; |
| |
| /* Format_specific flags. */ |
| flagword flags; |
| |
| /* Values that may appear in the flags field of a BFD. These also |
| appear in the object_flags field of the bfd_target structure, where |
| they indicate the set of flags used by that backend (not all flags |
| are meaningful for all object file formats) (FIXME: at the moment, |
| the object_flags values have mostly just been copied from backend |
| to another, and are not necessarily correct). */ |
| |
| #define BFD_NO_FLAGS 0x00 |
| |
| /* BFD contains relocation entries. */ |
| #define HAS_RELOC 0x01 |
| |
| /* BFD is directly executable. */ |
| #define EXEC_P 0x02 |
| |
| /* BFD has line number information (basically used for F_LNNO in a |
| COFF header). */ |
| #define HAS_LINENO 0x04 |
| |
| /* BFD has debugging information. */ |
| #define HAS_DEBUG 0x08 |
| |
| /* BFD has symbols. */ |
| #define HAS_SYMS 0x10 |
| |
| /* BFD has local symbols (basically used for F_LSYMS in a COFF |
| header). */ |
| #define HAS_LOCALS 0x20 |
| |
| /* BFD is a dynamic object. */ |
| #define DYNAMIC 0x40 |
| |
| /* Text section is write protected (if D_PAGED is not set, this is |
| like an a.out NMAGIC file) (the linker sets this by default, but |
| clears it for -r or -N). */ |
| #define WP_TEXT 0x80 |
| |
| /* BFD is dynamically paged (this is like an a.out ZMAGIC file) (the |
| linker sets this by default, but clears it for -r or -n or -N). */ |
| #define D_PAGED 0x100 |
| |
| /* BFD is relaxable (this means that bfd_relax_section may be able to |
| do something) (sometimes bfd_relax_section can do something even if |
| this is not set). */ |
| #define BFD_IS_RELAXABLE 0x200 |
| |
| /* This may be set before writing out a BFD to request using a |
| traditional format. For example, this is used to request that when |
| writing out an a.out object the symbols not be hashed to eliminate |
| duplicates. */ |
| #define BFD_TRADITIONAL_FORMAT 0x400 |
| |
| /* This flag indicates that the BFD contents are actually cached |
| in memory. If this is set, iostream points to a bfd_in_memory |
| struct. */ |
| #define BFD_IN_MEMORY 0x800 |
| |
| /* The sections in this BFD specify a memory page. */ |
| #define HAS_LOAD_PAGE 0x1000 |
| |
| /* This BFD has been created by the linker and doesn't correspond |
| to any input file. */ |
| #define BFD_LINKER_CREATED 0x2000 |
| |
| /* This may be set before writing out a BFD to request that it |
| be written using values for UIDs, GIDs, timestamps, etc. that |
| will be consistent from run to run. */ |
| #define BFD_DETERMINISTIC_OUTPUT 0x4000 |
| |
| /* Compress sections in this BFD. */ |
| #define BFD_COMPRESS 0x8000 |
| |
| /* Decompress sections in this BFD. */ |
| #define BFD_DECOMPRESS 0x10000 |
| |
| /* BFD is a dummy, for plugins. */ |
| #define BFD_PLUGIN 0x20000 |
| |
| /* Flags bits to be saved in bfd_preserve_save. */ |
| #define BFD_FLAGS_SAVED \ |
| (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS | BFD_PLUGIN) |
| |
| /* Flags bits which are for BFD use only. */ |
| #define BFD_FLAGS_FOR_BFD_USE_MASK \ |
| (BFD_IN_MEMORY | BFD_COMPRESS | BFD_DECOMPRESS | BFD_LINKER_CREATED \ |
| | BFD_PLUGIN | BFD_TRADITIONAL_FORMAT | BFD_DETERMINISTIC_OUTPUT) |
| |
| /* 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; |
| |
| /* The origin in the archive of the proxy entry. This will |
| normally be the same as origin, except for thin archives, |
| when it will contain the current offset of the proxy in the |
| thin archive rather than the offset of the bfd in its actual |
| container. */ |
| ufile_ptr proxy_origin; |
| |
| /* 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). |
| Also used by the linker to cache input BFD symbols. */ |
| 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; |
| |
| /* 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. */ |
| struct bfd *nested_archives; /* List of nested archive in a flattened |
| thin archive. */ |
| |
| /* 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 verilog_data_struct *verilog_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 plugin_data_struct *plugin_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; |
| |
| /* Is the file descriptor being cached? That is, can it be closed as |
| needed, and re-opened when accessed later? */ |
| unsigned int cacheable : 1; |
| |
| /* 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. */ |
| unsigned int target_defaulted : 1; |
| |
| /* ... and here: (``once'' means at least once). */ |
| unsigned int opened_once : 1; |
| |
| /* Set if we have a locally maintained mtime value, rather than |
| getting it from the file each time. */ |
| unsigned int mtime_set : 1; |
| |
| /* Flag set if symbols from this BFD should not be exported. */ |
| unsigned int no_export : 1; |
| |
| /* Remember when output has begun, to stop strange things |
| from happening. */ |
| unsigned int output_has_begun : 1; |
| |
| /* Have archive map. */ |
| unsigned int has_armap : 1; |
| |
| /* Set if this is a thin archive. */ |
| unsigned int is_thin_archive : 1; |
| |
| /* Set if only required symbols should be added in the link hash table for |
| this object. Used by VMS linkers. */ |
| unsigned int selective_search : 1; |
| }; |
| |
| |
| File: bfd.info, Node: Error reporting, Next: Miscellaneous, Prev: typedef bfd, Up: BFD front end |
| |
| 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_missing_dso, |
| 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.2.3 BFD assert handler |
| ------------------------ |
| |
| If BFD finds an internal inconsistency, the bfd assert handler is |
| called with information on the BFD version, BFD source file and line. |
| If this happens, most programs linked against BFD are expected to want |
| to exit with an error, or mark the current BFD operation as failed, so |
| it is recommended to override the default handler, which just calls |
| _bfd_error_handler and continues. |
| |
| |
| typedef void (*bfd_assert_handler_type) (const char *bfd_formatmsg, |
| const char *bfd_version, |
| const char *bfd_file, |
| int bfd_line); |
| |
| 2.2.3.1 `bfd_set_assert_handler' |
| ................................ |
| |
| *Synopsis* |
| bfd_assert_handler_type bfd_set_assert_handler (bfd_assert_handler_type); |
| *Description* |
| Set the BFD assert handler function. Returns the previous function. |
| |
| 2.2.3.2 `bfd_get_assert_handler' |
| ................................ |
| |
| *Synopsis* |
| bfd_assert_handler_type bfd_get_assert_handler (void); |
| *Description* |
| Return the BFD assert handler function. |
| |
| |
| File: bfd.info, Node: Miscellaneous, Next: Memory Usage, Prev: Error reporting, Up: BFD front end |
| |
| 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_nearest_line_discriminator(abfd, sec, syms, off, file, func, \ |
| line, disc) \ |
| BFD_SEND (abfd, _bfd_find_nearest_line_discriminator, \ |
| (abfd, sec, syms, off, file, func, line, disc)) |
| |
| #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_lookup_section_flags(link_info, flag_info, section) \ |
| BFD_SEND (abfd, _bfd_lookup_section_flags, (link_info, flag_info, section)) |
| |
| #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. |
| |
| 2.3.1.17 `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, 0 otherwise. |
| |
| 2.3.1.18 `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.19 `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, 0 otherwise. |
| |
| 2.3.1.20 `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.21 `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.22 `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); |
| /* Mmap a part of the files. ADDR, LEN, PROT, FLAGS and OFFSET are the usual |
| mmap parameter, except that LEN and OFFSET do not need to be page |
| aligned. Returns (void *)-1 on failure, mmapped address on success. |
| Also write in MAP_ADDR the address of the page aligned buffer and in |
| MAP_LEN the size mapped (a page multiple). Use unmap with MAP_ADDR and |
| MAP_LEN to unmap. */ |
| void *(*bmmap) (struct bfd *abfd, void *addr, bfd_size_type len, |
| int prot, int flags, file_ptr offset, |
| void **map_addr, bfd_size_type *map_len); |
| }; |
| extern const struct bfd_iovec _bfd_memory_iovec; |
| |
| 2.3.1.23 `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.24 `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?". |
| |
| 2.3.1.25 `bfd_mmap' |
| ................... |
| |
| *Synopsis* |
| void *bfd_mmap (bfd *abfd, void *addr, bfd_size_type len, |
| int prot, int flags, file_ptr offset, |
| void **map_addr, bfd_size_type *map_len); |
| *Description* |
| Return mmap()ed region of the file, if possible and implemented. LEN |
| and OFFSET do not need to be page aligned. The page aligned address |
| and length are written to MAP_ADDR and MAP_LEN. |
| |
| |
| File: bfd.info, Node: Memory Usage, Next: Initialization, Prev: Miscellaneous, 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 input section should be copied to output in reverse order |
| as an array of pointers. This is for ELF linker internal use |
| only. */ |
| #define SEC_ELF_REVERSE_COPY 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 |
| |
| /* Indicate that section has the no read flag set. This happens |
| when memory read flag isn't set. */ |
| #define SEC_COFF_NOREAD 0x40000000 |
| |
| /* 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; |
| |
| /* Section compression status. */ |
| unsigned int compress_status : 2; |
| #define COMPRESS_SECTION_NONE 0 |
| #define COMPRESS_SECTION_DONE 1 |
| #define DECOMPRESS_SECTION_SIZED 2 |
| |
| /* 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 SEC_INFO_TYPE_NONE 0 |
| #define SEC_INFO_TYPE_STABS 1 |
| #define SEC_INFO_TYPE_MERGE 2 |
| #define SEC_INFO_TYPE_EH_FRAME 3 |
| #define SEC_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. */ |
| |
| unsigned int sec_flg0:1; |
| unsigned int sec_flg1:1; |
| unsigned int sec_flg2:1; |
| unsigned int sec_flg3:1; |
| unsigned int sec_flg4:1; |
| unsigned int sec_flg5: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; |
| |
| /* The compressed size of the section in octets. */ |
| bfd_size_type compressed_size; |
| |
| /* Relaxation table. */ |
| struct relax_table *relax; |
| |
| /* Count of used relaxation table entries. */ |
| int relax_count; |
| |
| |
| /* 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; |
| |
| /* Relax table contains information about instructions which can |
| be removed by relaxation -- replacing a long address with a |
| short address. */ |
| struct relax_table { |
| /* Address where bytes may be deleted. */ |
| bfd_vma addr; |
| |
| /* Number of bytes to be deleted. */ |
| int size; |
| }; |
| |
| /* 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. */ |
| extern asection _bfd_std_section[4]; |
| |
| #define BFD_ABS_SECTION_NAME "*ABS*" |
| #define BFD_UND_SECTION_NAME "*UND*" |
| #define BFD_COM_SECTION_NAME "*COM*" |
| #define BFD_IND_SECTION_NAME "*IND*" |
| |
| /* Pointer to the common section. */ |
| #define bfd_com_section_ptr (&_bfd_std_section[0]) |
| /* Pointer to the undefined section. */ |
| #define bfd_und_section_ptr (&_bfd_std_section[1]) |
| /* Pointer to the absolute section. */ |
| #define bfd_abs_section_ptr (&_bfd_std_section[2]) |
| /* Pointer to the indirect section. */ |
| #define bfd_ind_section_ptr (&_bfd_std_section[3]) |
| |
| #define bfd_is_und_section(sec) ((sec) == bfd_und_section_ptr) |
| #define bfd_is_abs_section(sec) ((sec) == bfd_abs_section_ptr) |
| #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, decompress_status, */ \ |
| 0, 0, 1, 0, \ |
| \ |
| /* segment_mark, sec_info_type, use_rela_p, */ \ |
| 0, 0, 0, \ |
| \ |
| /* sec_flg0, sec_flg1, sec_flg2, sec_flg3, sec_flg4, sec_flg5, */ \ |
| 0, 0, 0, 0, 0, 0, \ |
| \ |
| /* vma, lma, size, rawsize, compressed_size, relax, relax_count, */ \ |
| 0, 0, 0, 0, 0, 0, 0, \ |
| \ |
| /* output_offset, output_section, alignment_power, */ \ |
| 0, &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* |
| Return the most recently created section attached to ABFD named NAME. |
| Return NULL if no such section exists. |
| |
| 2.6.5.3 `bfd_get_next_section_by_name' |
| ...................................... |
| |
| *Synopsis* |
| asection *bfd_get_next_section_by_name (asection *sec); |
| *Description* |
| Given SEC is a section returned by `bfd_get_section_by_name', return |
| the next most recently created section attached to the same BFD with |
| the same name. Return NULL if no such section exists. |
| |
| 2.6.5.4 `bfd_get_linker_section' |
| ................................ |
| |
| *Synopsis* |
| asection *bfd_get_linker_section (bfd *abfd, const char *name); |
| *Description* |
| Return the linker created section attached to ABFD named NAME. Return |
| NULL if no such section exists. |
| |
| 2.6.5.5 `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.6 `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.7 `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.8 `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.9 `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.10 `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.11 `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.12 `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.13 `bfd_rename_section' |
| ............................. |
| |
| *Synopsis* |
| void bfd_rename_section |
| (bfd *abfd, asection *sec, const char *newname); |
| *Description* |
| Rename section SEC in ABFD to NEWNAME. |
| |
| 2.6.5.14 `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: |
| |
| asection *p; |
| for (p = abfd->sections; p != NULL; p = p->next) |
| func (abfd, p, ...) |
| |
| 2.6.5.15 `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.16 `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.17 `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.18 `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.19 `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.20 `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.21 `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.22 `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 "sysdep.h" |
| #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 (1 << 0) |
| |
| /* The symbol has global scope; initialized data in `C'. The |
| value is the offset into the section of the data. */ |
| #define BSF_GLOBAL (1 << 1) |
| |
| /* 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_COMMON', `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 (1 << 2) |
| |
| /* The symbol denotes a function entry point. Used in ELF, |
| perhaps others someday. */ |
| #define BSF_FUNCTION (1 << 3) |
| |
| /* Used by the linker. */ |
| #define BSF_KEEP (1 << 5) |
| #define BSF_KEEP_G (1 << 6) |
| |
| /* A weak global symbol, overridable without warnings by |
| a regular global symbol of the same name. */ |
| #define BSF_WEAK (1 << 7) |
| |
| /* This symbol was created to point to a section, e.g. ELF's |
| STT_SECTION symbols. */ |
| #define BSF_SECTION_SYM (1 << 8) |
| |
| /* The symbol used to be a common symbol, but now it is |
| allocated. */ |
| #define BSF_OLD_COMMON (1 << 9) |
| |
| /* 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 (1 << 10) |
| |
| /* Signal that the symbol is the label of constructor section. */ |
| #define BSF_CONSTRUCTOR (1 << 11) |
| |
| /* 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 (1 << 12) |
| |
| /* 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 (1 << 13) |
| |
| /* BSF_FILE marks symbols that contain a file name. This is used |
| for ELF STT_FILE symbols. */ |
| #define BSF_FILE (1 << 14) |
| |
| /* Symbol is from dynamic linking information. */ |
| #define BSF_DYNAMIC (1 << 15) |
| |
| /* The symbol denotes a data object. Used in ELF, and perhaps |
| others someday. */ |
| #define BSF_OBJECT (1 << 16) |
| |
| /* 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 (1 << 17) |
| |
| /* This symbol is thread local. Used in ELF. */ |
| #define BSF_THREAD_LOCAL (1 << 18) |
| |
| /* This symbol represents a complex relocation expression, |
| with the expression tree serialized in the symbol name. */ |
| #define BSF_RELC (1 << 19) |
| |
| /* This symbol represents a signed complex relocation expression, |
| with the expression tree serialized in the symbol name. */ |
| #define BSF_SRELC (1 << 20) |
| |
| /* This symbol was created by bfd_get_synthetic_symtab. */ |
| #define BSF_SYNTHETIC (1 << 21) |
| |
| /* This symbol is an indirect code object. Unrelated to BSF_INDIRECT. |
| The dynamic linker will compute the value of this symbol by |
| calling the function that it points to. BSF_FUNCTION must |
| also be also set. */ |
| #define BSF_GNU_INDIRECT_FUNCTION (1 << 22) |
| /* This symbol is a globally unique data object. The dynamic linker |
| will make sure that in the entire process there is just one symbol |
| with this name and type in use. BSF_OBJECT must also be set. */ |
| #define BSF_GNU_UNIQUE (1 << 23) |
| |
| 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. |
| |
| A BFD returned by `bfd_openr_next_archived_file' can be closed |
| manually with `bfd_close'. If you do not close it, then a second |
| iteration through the members of an archive may return the same BFD. |
| If you close the archive BFD, then all the member BFDs will |
| automatically be closed as well. |
| |
| Archive contents of output BFDs are chained through the |
| `archive_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; |
| |
| /* The relocation is relative to the field 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_SIZE32 |
| -- : BFD_RELOC_SIZE64 |
| Size relocations. |
| |
| -- : BFD_RELOC_68K_GLOB_DAT |
| -- : BFD_RELOC_68K_JMP_SLOT |
| -- : BFD_RELOC_68K_RELATIVE |
| -- : BFD_RELOC_68K_TLS_GD32 |
| -- : BFD_RELOC_68K_TLS_GD16 |
| -- : BFD_RELOC_68K_TLS_GD8 |
| -- : BFD_RELOC_68K_TLS_LDM32 |
| -- : BFD_RELOC_68K_TLS_LDM16 |
| -- : BFD_RELOC_68K_TLS_LDM8 |
| -- : BFD_RELOC_68K_TLS_LDO32 |
| -- : BFD_RELOC_68K_TLS_LDO16 |
| -- : BFD_RELOC_68K_TLS_LDO8 |
| -- : BFD_RELOC_68K_TLS_IE32 |
| -- : BFD_RELOC_68K_TLS_IE16 |
| -- : BFD_RELOC_68K_TLS_IE8 |
| -- : BFD_RELOC_68K_TLS_LE32 |
| -- : BFD_RELOC_68K_TLS_LE16 |
| -- : BFD_RELOC_68K_TLS_LE8 |
| 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 |
| -- : BFD_RELOC_SPARC_GOTDATA_HIX22 |
| -- : BFD_RELOC_SPARC_GOTDATA_LOX10 |
| -- : BFD_RELOC_SPARC_GOTDATA_OP_HIX22 |
| -- : BFD_RELOC_SPARC_GOTDATA_OP_LOX10 |
| -- : BFD_RELOC_SPARC_GOTDATA_OP |
| -- : BFD_RELOC_SPARC_JMP_IREL |
| -- : BFD_RELOC_SPARC_IRELATIVE |
| 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 |
| -- : BFD_RELOC_SPARC_H34 |
| -- : BFD_RELOC_SPARC_SIZE32 |
| -- : BFD_RELOC_SPARC_SIZE64 |
| -- : BFD_RELOC_SPARC_WDISP10 |
| 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 |
| -- : BFD_RELOC_SPU_ADD_PIC |
| 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_NOP |
| The NOP relocation outputs a NOP if the longword displacement |
| between two procedure entry points is < 2^21. |
| |
| -- : BFD_RELOC_ALPHA_BSR |
| The BSR relocation outputs a BSR if the longword displacement |
| between two procedure entry points is < 2^21. |
| |
| -- : BFD_RELOC_ALPHA_LDA |
| The LDA relocation outputs a LDA if the longword displacement |
| between two procedure entry points is < 2^16. |
| |
| -- : BFD_RELOC_ALPHA_BOH |
| The BOH relocation outputs a BSR if the longword displacement |
| between two procedure entry points is < 2^21, or else a hint. |
| |
| -- : 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 |
| -- : BFD_RELOC_MICROMIPS_JMP |
| The MIPS jump instruction. |
| |
| -- : 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_GOT16 |
| -- : BFD_RELOC_MIPS16_CALL16 |
| Equivalent of BFD_RELOC_MIPS_*, but with the MIPS16 layout of |
| 16-bit immediate fields |
| |
| -- : 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_MIPS16_TLS_GD |
| -- : BFD_RELOC_MIPS16_TLS_LDM |
| -- : BFD_RELOC_MIPS16_TLS_DTPREL_HI16 |
| -- : BFD_RELOC_MIPS16_TLS_DTPREL_LO16 |
| -- : BFD_RELOC_MIPS16_TLS_GOTTPREL |
| -- : BFD_RELOC_MIPS16_TLS_TPREL_HI16 |
| -- : BFD_RELOC_MIPS16_TLS_TPREL_LO16 |
| MIPS16 TLS relocations |
| |
| -- : BFD_RELOC_MIPS_LITERAL |
| -- : BFD_RELOC_MICROMIPS_LITERAL |
| Relocation against a MIPS literal section. |
| |
| -- : BFD_RELOC_MICROMIPS_7_PCREL_S1 |
| -- : BFD_RELOC_MICROMIPS_10_PCREL_S1 |
| -- : BFD_RELOC_MICROMIPS_16_PCREL_S1 |
| microMIPS PC-relative relocations. |
| |
| -- : BFD_RELOC_MICROMIPS_GPREL16 |
| -- : BFD_RELOC_MICROMIPS_HI16 |
| -- : BFD_RELOC_MICROMIPS_HI16_S |
| -- : BFD_RELOC_MICROMIPS_LO16 |
| microMIPS versions of generic BFD relocs. |
| |
| -- : BFD_RELOC_MIPS_GOT16 |
| -- : BFD_RELOC_MICROMIPS_GOT16 |
| -- : BFD_RELOC_MIPS_CALL16 |
| -- : BFD_RELOC_MICROMIPS_CALL16 |
| -- : BFD_RELOC_MIPS_GOT_HI16 |
| -- : BFD_RELOC_MICROMIPS_GOT_HI16 |
| -- : BFD_RELOC_MIPS_GOT_LO16 |
| -- : BFD_RELOC_MICROMIPS_GOT_LO16 |
| -- : BFD_RELOC_MIPS_CALL_HI16 |
| -- : BFD_RELOC_MICROMIPS_CALL_HI16 |
| -- : BFD_RELOC_MIPS_CALL_LO16 |
| -- : BFD_RELOC_MICROMIPS_CALL_LO16 |
| -- : BFD_RELOC_MIPS_SUB |
| -- : BFD_RELOC_MICROMIPS_SUB |
| -- : BFD_RELOC_MIPS_GOT_PAGE |
| -- : BFD_RELOC_MICROMIPS_GOT_PAGE |
| -- : BFD_RELOC_MIPS_GOT_OFST |
| -- : BFD_RELOC_MICROMIPS_GOT_OFST |
| -- : BFD_RELOC_MIPS_GOT_DISP |
| -- : BFD_RELOC_MICROMIPS_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_MICROMIPS_HIGHEST |
| -- : BFD_RELOC_MIPS_HIGHER |
| -- : BFD_RELOC_MICROMIPS_HIGHER |
| -- : BFD_RELOC_MIPS_SCN_DISP |
| -- : BFD_RELOC_MICROMIPS_SCN_DISP |
| -- : BFD_RELOC_MIPS_REL16 |
| -- : BFD_RELOC_MIPS_RELGOT |
| -- : BFD_RELOC_MIPS_JALR |
| -- : BFD_RELOC_MICROMIPS_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_MICROMIPS_TLS_GD |
| -- : BFD_RELOC_MIPS_TLS_LDM |
| -- : BFD_RELOC_MICROMIPS_TLS_LDM |
| -- : BFD_RELOC_MIPS_TLS_DTPREL_HI16 |
| -- : BFD_RELOC_MICROMIPS_TLS_DTPREL_HI16 |
| -- : BFD_RELOC_MIPS_TLS_DTPREL_LO16 |
| -- : BFD_RELOC_MICROMIPS_TLS_DTPREL_LO16 |
| -- : BFD_RELOC_MIPS_TLS_GOTTPREL |
| -- : BFD_RELOC_MICROMIPS_TLS_GOTTPREL |
| -- : BFD_RELOC_MIPS_TLS_TPREL32 |
| -- : BFD_RELOC_MIPS_TLS_TPREL64 |
| -- : BFD_RELOC_MIPS_TLS_TPREL_HI16 |
| -- : BFD_RELOC_MICROMIPS_TLS_TPREL_HI16 |
| -- : BFD_RELOC_MIPS_TLS_TPREL_LO16 |
| -- : BFD_RELOC_MICROMIPS_TLS_TPREL_LO16 |
| -- : BFD_RELOC_MIPS_EH |
| MIPS ELF relocations. |
| |
| -- : BFD_RELOC_MIPS_COPY |
| -- : BFD_RELOC_MIPS_JUMP_SLOT |
| MIPS ELF relocations (VxWorks and PLT extensions). |
| |
| -- : BFD_RELOC_MOXIE_10_PCREL |
| Moxie ELF relocations. |
| |
| -- : 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_MN10300_TLS_GD |
| -- : BFD_RELOC_MN10300_TLS_LD |
| -- : BFD_RELOC_MN10300_TLS_LDO |
| -- : BFD_RELOC_MN10300_TLS_GOTIE |
| -- : BFD_RELOC_MN10300_TLS_IE |
| -- : BFD_RELOC_MN10300_TLS_LE |
| -- : BFD_RELOC_MN10300_TLS_DTPMOD |
| -- : BFD_RELOC_MN10300_TLS_DTPOFF |
| -- : BFD_RELOC_MN10300_TLS_TPOFF |
| Various TLS-related relocations. |
| |
| -- : BFD_RELOC_MN10300_32_PCREL |
| This is a 32bit pcrel reloc for the mn10300, offset by two bytes |
| in the instruction. |
| |
| -- : BFD_RELOC_MN10300_16_PCREL |
| This is a 16bit pcrel reloc for the mn10300, offset by two bytes |
| in the instruction. |
| |
| -- : BFD_RELOC_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 |
| -- : BFD_RELOC_386_IRELATIVE |
| 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 |
| -- : BFD_RELOC_X86_64_IRELATIVE |
| -- : BFD_RELOC_X86_64_PC32_BND |
| -- : BFD_RELOC_X86_64_PLT32_BND |
| 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_PPC_VLE_REL8 |
| -- : BFD_RELOC_PPC_VLE_REL15 |
| -- : BFD_RELOC_PPC_VLE_REL24 |
| -- : BFD_RELOC_PPC_VLE_LO16A |
| -- : BFD_RELOC_PPC_VLE_LO16D |
| -- : BFD_RELOC_PPC_VLE_HI16A |
| -- : BFD_RELOC_PPC_VLE_HI16D |
| -- : BFD_RELOC_PPC_VLE_HA16A |
| -- : BFD_RELOC_PPC_VLE_HA16D |
| -- : BFD_RELOC_PPC_VLE_SDA21 |
| -- : BFD_RELOC_PPC_VLE_SDA21_LO |
| -- : BFD_RELOC_PPC_VLE_SDAREL_LO16A |
| -- : BFD_RELOC_PPC_VLE_SDAREL_LO16D |
| -- : BFD_RELOC_PPC_VLE_SDAREL_HI16A |
| -- : BFD_RELOC_PPC_VLE_SDAREL_HI16D |
| -- : BFD_RELOC_PPC_VLE_SDAREL_HA16A |
| -- : BFD_RELOC_PPC_VLE_SDAREL_HA16D |
| -- : 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 |
| -- : BFD_RELOC_PPC64_ADDR16_HIGH |
| -- : BFD_RELOC_PPC64_ADDR16_HIGHA |
| Power(rs6000) and PowerPC relocations. |
| |
| -- : BFD_RELOC_PPC_TLS |
| -- : BFD_RELOC_PPC_TLSGD |
| -- : BFD_RELOC_PPC_TLSLD |
| -- : 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 |
| -- : BFD_RELOC_PPC64_TPREL16_HIGH |
| -- : BFD_RELOC_PPC64_TPREL16_HIGHA |
| -- : BFD_RELOC_PPC64_DTPREL16_HIGH |
| -- : BFD_RELOC_PPC64_DTPREL16_HIGHA |
| 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 |
| -- : BFD_RELOC_ARM_GOT_PREL |
| 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 |
| -- : BFD_RELOC_ARM_TLS_GOTDESC |
| -- : BFD_RELOC_ARM_TLS_CALL |
| -- : BFD_RELOC_ARM_THM_TLS_CALL |
| -- : BFD_RELOC_ARM_TLS_DESCSEQ |
| -- : BFD_RELOC_ARM_THM_TLS_DESCSEQ |
| -- : BFD_RELOC_ARM_TLS_DESC |
| 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_IRELATIVE |
| ARM support for STT_GNU_IFUNC. |
| |
| -- : 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_HVC |
| -- : 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 |
| |