Subversion Repositories openrisc_2011-10-31

This is bfd.info, produced by makeinfo version 4.13 from bfd.texinfo.

START-INFO-DIR-ENTRY

* Bfd: (bfd).                   The Binary File Descriptor library.

END-INFO-DIR-ENTRY

   This file documents the BFD library.

   Copyright (C) 1991, 2000, 2001, 2003, 2006, 2007, 2008 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

***************

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

       /* 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;

     };

2.2 Error reporting

===================

Most BFD functions return nonzero on success (check their individual

documentation for precise semantics).  On an error, they call

`bfd_set_error' to set an error condition that callers can check by

calling `bfd_get_error'.  If that returns `bfd_error_system_call', then

check `errno'.

   The easiest way to report a BFD error to the user is to use

`bfd_perror'.

2.2.1 Type `bfd_error_type'

---------------------------

The values returned by `bfd_get_error' are defined by the enumerated

type `bfd_error_type'.

     typedef enum bfd_error

     {

       bfd_error_no_error = 0,

       bfd_error_system_call,

       bfd_error_invalid_target,

       bfd_error_wrong_format,

       bfd_error_wrong_object_format,

       bfd_error_invalid_operation,

       bfd_error_no_memory,

       bfd_error_no_symbols,

       bfd_error_no_armap,

       bfd_error_no_more_archived_files,

       bfd_error_malformed_archive,

       bfd_error_file_not_recognized,

       bfd_error_file_ambiguously_recognized,

       bfd_error_no_contents,

       bfd_error_nonrepresentable_section,

       bfd_error_no_debug_section,

       bfd_error_bad_value,

       bfd_error_file_truncated,

       bfd_error_file_too_big,

       bfd_error_on_input,

       bfd_error_invalid_error_code

     }

     bfd_error_type;

2.2.1.1 `bfd_get_error'

.......................

*Synopsis*

     bfd_error_type bfd_get_error (void);

   *Description*

Return the current BFD error condition.

2.2.1.2 `bfd_set_error'

.......................

*Synopsis*

     void bfd_set_error (bfd_error_type error_tag, ...);

   *Description*

Set the BFD error condition to be ERROR_TAG.  If ERROR_TAG is

bfd_error_on_input, then this function takes two more parameters, the

input bfd where the error occurred, and the bfd_error_type error.

2.2.1.3 `bfd_errmsg'

....................

*Synopsis*

     const char *bfd_errmsg (bfd_error_type error_tag);

   *Description*

Return a string describing the error ERROR_TAG, or the system error if

ERROR_TAG is `bfd_error_system_call'.

2.2.1.4 `bfd_perror'

....................

*Synopsis*

     void bfd_perror (const char *message);

   *Description*

Print to the standard error stream a string describing the last BFD

error that occurred, or the last system error if the last BFD error was

a system call failure.  If MESSAGE is non-NULL and non-empty, the error

string printed is preceded by MESSAGE, a colon, and a space.  It is

followed by a newline.

2.2.2 BFD error handler

-----------------------

Some BFD functions want to print messages describing the problem.  They

call a BFD error handler function.  This function may be overridden by

the program.

   The BFD error handler acts like printf.

     typedef void (*bfd_error_handler_type) (const char *, ...);

2.2.2.1 `bfd_set_error_handler'

...............................

*Synopsis*

     bfd_error_handler_type bfd_set_error_handler (bfd_error_handler_type);

   *Description*

Set the BFD error handler function.  Returns the previous function.

2.2.2.2 `bfd_set_error_program_name'

....................................

*Synopsis*

     void bfd_set_error_program_name (const char *);

   *Description*

Set the program name to use when printing a BFD error.  This is printed

before the error message followed by a colon and space.  The string

must not be changed after it is passed to this function.

2.2.2.3 `bfd_get_error_handler'

...............................

*Synopsis*

     bfd_error_handler_type bfd_get_error_handler (void);

   *Description*

Return the BFD error handler function.

2.3 Miscellaneous

=================

2.3.1 Miscellaneous functions

-----------------------------

2.3.1.1 `bfd_get_reloc_upper_bound'

...................................

*Synopsis*

     long bfd_get_reloc_upper_bound (bfd *abfd, asection *sect);

   *Description*

Return the number of bytes required to store the relocation information

associated with section SECT attached to bfd ABFD.  If an error occurs,

return -1.

2.3.1.2 `bfd_canonicalize_reloc'

................................

*Synopsis*

     long bfd_canonicalize_reloc

        (bfd *abfd, asection *sec, arelent **loc, asymbol **syms);

   *Description*

Call the back end associated with the open BFD ABFD and translate the

external form of the relocation information attached to SEC into the

internal canonical form.  Place the table into memory at LOC, which has

been preallocated, usually by a call to `bfd_get_reloc_upper_bound'.

Returns the number of relocs, or -1 on error.

   The SYMS table is also needed for horrible internal magic reasons.

2.3.1.3 `bfd_set_reloc'

.......................

*Synopsis*

     void bfd_set_reloc

        (bfd *abfd, asection *sec, arelent **rel, unsigned int count);

   *Description*

Set the relocation pointer and count within section SEC to the values

REL and COUNT.  The argument ABFD is ignored.

2.3.1.4 `bfd_set_file_flags'

............................

*Synopsis*

     bfd_boolean bfd_set_file_flags (bfd *abfd, flagword flags);

   *Description*

Set the flag word in the BFD ABFD to the value FLAGS.

   Possible errors are:

   * `bfd_error_wrong_format' - The target bfd was not of object format.

   * `bfd_error_invalid_operation' - The target bfd was open for

     reading.

   * `bfd_error_invalid_operation' - The flag word contained a bit

     which was not applicable to the type of file.  E.g., an attempt

     was made to set the `D_PAGED' bit on a BFD format which does not

     support demand paging.

2.3.1.5 `bfd_get_arch_size'

...........................

*Synopsis*

     int bfd_get_arch_size (bfd *abfd);

   *Description*

Returns the architecture address size, in bits, as determined by the

object file's format.  For ELF, this information is included in the

header.

   *Returns*

Returns the arch size in bits if known, `-1' otherwise.

2.3.1.6 `bfd_get_sign_extend_vma'

.................................

*Synopsis*

     int bfd_get_sign_extend_vma (bfd *abfd);

   *Description*

Indicates if the target architecture "naturally" sign extends an

address.  Some architectures implicitly sign extend address values when

they are converted to types larger than the size of an address.  For

instance, bfd_get_start_address() will return an address sign extended

to fill a bfd_vma when this is the case.

   *Returns*

Returns `1' if the target architecture is known to sign extend

addresses, `0' if the target architecture is known to not sign extend

addresses, and `-1' otherwise.

2.3.1.7 `bfd_set_start_address'

...............................

*Synopsis*

     bfd_boolean bfd_set_start_address (bfd *abfd, bfd_vma vma);

   *Description*

Make VMA the entry point of output BFD ABFD.

   *Returns*

Returns `TRUE' on success, `FALSE' otherwise.

2.3.1.8 `bfd_get_gp_size'

.........................

*Synopsis*

     unsigned int bfd_get_gp_size (bfd *abfd);

   *Description*

Return the maximum size of objects to be optimized using the GP

register under MIPS ECOFF.  This is typically set by the `-G' argument

to the compiler, assembler or linker.

2.3.1.9 `bfd_set_gp_size'

.........................

*Synopsis*

     void bfd_set_gp_size (bfd *abfd, unsigned int i);

   *Description*

Set the maximum size of objects to be optimized using the GP register

under ECOFF or MIPS ELF.  This is typically set by the `-G' argument to

the compiler, assembler or linker.

2.3.1.10 `bfd_scan_vma'

.......................

*Synopsis*

     bfd_vma bfd_scan_vma (const char *string, const char **end, int base);

   *Description*

Convert, like `strtoul', a numerical expression STRING into a `bfd_vma'

integer, and return that integer.  (Though without as many bells and

whistles as `strtoul'.)  The expression is assumed to be unsigned

(i.e., positive).  If given a BASE, it is used as the base for

conversion.  A base of 0 causes the function to interpret the string in

hex if a leading "0x" or "0X" is found, otherwise in octal if a leading

zero is found, otherwise in decimal.

   If the value would overflow, the maximum `bfd_vma' value is returned.

2.3.1.11 `bfd_copy_private_header_data'

.......................................

*Synopsis*

     bfd_boolean bfd_copy_private_header_data (bfd *ibfd, bfd *obfd);

   *Description*

Copy private BFD header information from the BFD IBFD to the the BFD

OBFD.  This copies information that may require sections to exist, but

does not require symbol tables.  Return `true' on success, `false' on

error.  Possible error returns are:

   * `bfd_error_no_memory' - Not enough memory exists to create private

     data for OBFD.

     #define bfd_copy_private_header_data(ibfd, obfd) \

          BFD_SEND (obfd, _bfd_copy_private_header_data, \

                    (ibfd, obfd))

2.3.1.12 `bfd_copy_private_bfd_data'

....................................

*Synopsis*

     bfd_boolean bfd_copy_private_bfd_data (bfd *ibfd, bfd *obfd);

   *Description*

Copy private BFD information from the BFD IBFD to the the BFD OBFD.

Return `TRUE' on success, `FALSE' on error.  Possible error returns are:

   * `bfd_error_no_memory' - Not enough memory exists to create private

     data for OBFD.

     #define bfd_copy_private_bfd_data(ibfd, obfd) \

          BFD_SEND (obfd, _bfd_copy_private_bfd_data, \

                    (ibfd, obfd))

2.3.1.13 `bfd_merge_private_bfd_data'

.....................................

*Synopsis*

     bfd_boolean bfd_merge_private_bfd_data (bfd *ibfd, bfd *obfd);

   *Description*

Merge private BFD information from the BFD IBFD to the the output file

BFD OBFD when linking.  Return `TRUE' on success, `FALSE' on error.

Possible error returns are:

   * `bfd_error_no_memory' - Not enough memory exists to create private

     data for OBFD.

     #define bfd_merge_private_bfd_data(ibfd, obfd) \

          BFD_SEND (obfd, _bfd_merge_private_bfd_data, \

                    (ibfd, obfd))

2.3.1.14 `bfd_set_private_flags'

................................

*Synopsis*

     bfd_boolean bfd_set_private_flags (bfd *abfd, flagword flags);

   *Description*

Set private BFD flag information in the BFD ABFD.  Return `TRUE' on

success, `FALSE' on error.  Possible error returns are:

   * `bfd_error_no_memory' - Not enough memory exists to create private

     data for OBFD.

     #define bfd_set_private_flags(abfd, flags) \

          BFD_SEND (abfd, _bfd_set_private_flags, (abfd, flags))

2.3.1.15 `Other functions'

..........................

*Description*

The following functions exist but have not yet been documented.

     #define bfd_sizeof_headers(abfd, info) \

            BFD_SEND (abfd, _bfd_sizeof_headers, (abfd, info))

     #define bfd_find_nearest_line(abfd, sec, syms, off, file, func, line) \

            BFD_SEND (abfd, _bfd_find_nearest_line, \

                      (abfd, sec, syms, off, file, func, line))

     #define bfd_find_line(abfd, syms, sym, file, line) \

            BFD_SEND (abfd, _bfd_find_line, \

                      (abfd, syms, sym, file, line))

     #define bfd_find_inliner_info(abfd, file, func, line) \

            BFD_SEND (abfd, _bfd_find_inliner_info, \

                      (abfd, file, func, line))

     #define bfd_debug_info_start(abfd) \

            BFD_SEND (abfd, _bfd_debug_info_start, (abfd))

     #define bfd_debug_info_end(abfd) \

            BFD_SEND (abfd, _bfd_debug_info_end, (abfd))

     #define bfd_debug_info_accumulate(abfd, section) \

            BFD_SEND (abfd, _bfd_debug_info_accumulate, (abfd, section))

     #define bfd_stat_arch_elt(abfd, stat) \

            BFD_SEND (abfd, _bfd_stat_arch_elt,(abfd, stat))

     #define bfd_update_armap_timestamp(abfd) \

            BFD_SEND (abfd, _bfd_update_armap_timestamp, (abfd))

     #define bfd_set_arch_mach(abfd, arch, mach)\

            BFD_SEND ( abfd, _bfd_set_arch_mach, (abfd, arch, mach))

     #define bfd_relax_section(abfd, section, link_info, again) \

            BFD_SEND (abfd, _bfd_relax_section, (abfd, section, link_info, again))

     #define bfd_gc_sections(abfd, link_info) \

            BFD_SEND (abfd, _bfd_gc_sections, (abfd, link_info))