bfdint.texi revision 60484
1\input texinfo 2@setfilename bfdint.info 3 4@settitle BFD Internals 5@iftex 6@titlepage 7@title{BFD Internals} 8@author{Ian Lance Taylor} 9@author{Cygnus Solutions} 10@page 11@end iftex 12 13@node Top 14@top BFD Internals 15@raisesections 16@cindex bfd internals 17 18This document describes some BFD internal information which may be 19helpful when working on BFD. It is very incomplete. 20 21This document is not updated regularly, and may be out of date. It was 22last modified on $Date: 2000/04/30 15:07:52 $. 23 24The initial version of this document was written by Ian Lance Taylor 25@email{ian@@cygnus.com}. 26 27@menu 28* BFD overview:: BFD overview 29* BFD guidelines:: BFD programming guidelines 30* BFD target vector:: BFD target vector 31* BFD generated files:: BFD generated files 32* BFD multiple compilations:: Files compiled multiple times in BFD 33* BFD relocation handling:: BFD relocation handling 34* BFD ELF support:: BFD ELF support 35* BFD glossary:: Glossary 36* Index:: Index 37@end menu 38 39@node BFD overview 40@section BFD overview 41 42BFD is a library which provides a single interface to read and write 43object files, executables, archive files, and core files in any format. 44 45@menu 46* BFD library interfaces:: BFD library interfaces 47* BFD library users:: BFD library users 48* BFD view:: The BFD view of a file 49* BFD blindness:: BFD loses information 50@end menu 51 52@node BFD library interfaces 53@subsection BFD library interfaces 54 55One way to look at the BFD library is to divide it into four parts by 56type of interface. 57 58The first interface is the set of generic functions which programs using 59the BFD library will call. These generic function normally translate 60directly or indirectly into calls to routines which are specific to a 61particular object file format. Many of these generic functions are 62actually defined as macros in @file{bfd.h}. These functions comprise 63the official BFD interface. 64 65The second interface is the set of functions which appear in the target 66vectors. This is the bulk of the code in BFD. A target vector is a set 67of function pointers specific to a particular object file format. The 68target vector is used to implement the generic BFD functions. These 69functions are always called through the target vector, and are never 70called directly. The target vector is described in detail in @ref{BFD 71target vector}. The set of functions which appear in a particular 72target vector is often referred to as a BFD backend. 73 74The third interface is a set of oddball functions which are typically 75specific to a particular object file format, are not generic functions, 76and are called from outside of the BFD library. These are used as hooks 77by the linker and the assembler when a particular object file format 78requires some action which the BFD generic interface does not provide. 79These functions are typically declared in @file{bfd.h}, but in many 80cases they are only provided when BFD is configured with support for a 81particular object file format. These functions live in a grey area, and 82are not really part of the official BFD interface. 83 84The fourth interface is the set of BFD support functions which are 85called by the other BFD functions. These manage issues like memory 86allocation, error handling, file access, hash tables, swapping, and the 87like. These functions are never called from outside of the BFD library. 88 89@node BFD library users 90@subsection BFD library users 91 92Another way to look at the BFD library is to divide it into three parts 93by the manner in which it is used. 94 95The first use is to read an object file. The object file readers are 96programs like @samp{gdb}, @samp{nm}, @samp{objdump}, and @samp{objcopy}. 97These programs use BFD to view an object file in a generic form. The 98official BFD interface is normally fully adequate for these programs. 99 100The second use is to write an object file. The object file writers are 101programs like @samp{gas} and @samp{objcopy}. These programs use BFD to 102create an object file. The official BFD interface is normally adequate 103for these programs, but for some object file formats the assembler needs 104some additional hooks in order to set particular flags or other 105information. The official BFD interface includes functions to copy 106private information from one object file to another, and these functions 107are used by @samp{objcopy} to avoid information loss. 108 109The third use is to link object files. There is only one object file 110linker, @samp{ld}. Originally, @samp{ld} was an object file reader and 111an object file writer, and it did the link operation using the generic 112BFD structures. However, this turned out to be too slow and too memory 113intensive. 114 115The official BFD linker functions were written to permit specific BFD 116backends to perform the link without translating through the generic 117structures, in the normal case where all the input files and output file 118have the same object file format. Not all of the backends currently 119implement the new interface, and there are default linking functions 120within BFD which use the generic structures and which work with all 121backends. 122 123For several object file formats the linker needs additional hooks which 124are not provided by the official BFD interface, particularly for dynamic 125linking support. These functions are typically called from the linker 126emulation template. 127 128@node BFD view 129@subsection The BFD view of a file 130 131BFD uses generic structures to manage information. It translates data 132into the generic form when reading files, and out of the generic form 133when writing files. 134 135BFD describes a file as a pointer to the @samp{bfd} type. A @samp{bfd} 136is composed of the following elements. The BFD information can be 137displayed using the @samp{objdump} program with various options. 138 139@table @asis 140@item general information 141The object file format, a few general flags, the start address. 142@item architecture 143The architecture, including both a general processor type (m68k, MIPS 144etc.) and a specific machine number (m68000, R4000, etc.). 145@item sections 146A list of sections. 147@item symbols 148A symbol table. 149@end table 150 151BFD represents a section as a pointer to the @samp{asection} type. Each 152section has a name and a size. Most sections also have an associated 153block of data, known as the section contents. Sections also have 154associated flags, a virtual memory address, a load memory address, a 155required alignment, a list of relocations, and other miscellaneous 156information. 157 158BFD represents a relocation as a pointer to the @samp{arelent} type. A 159relocation describes an action which the linker must take to modify the 160section contents. Relocations have a symbol, an address, an addend, and 161a pointer to a howto structure which describes how to perform the 162relocation. For more information, see @ref{BFD relocation handling}. 163 164BFD represents a symbol as a pointer to the @samp{asymbol} type. A 165symbol has a name, a pointer to a section, an offset within that 166section, and some flags. 167 168Archive files do not have any sections or symbols. Instead, BFD 169represents an archive file as a file which contains a list of 170@samp{bfd}s. BFD also provides access to the archive symbol map, as a 171list of symbol names. BFD provides a function to return the @samp{bfd} 172within the archive which corresponds to a particular entry in the 173archive symbol map. 174 175@node BFD blindness 176@subsection BFD loses information 177 178Most object file formats have information which BFD can not represent in 179its generic form, at least as currently defined. 180 181There is often explicit information which BFD can not represent. For 182example, the COFF version stamp, or the ELF program segments. BFD 183provides special hooks to handle this information when copying, 184printing, or linking an object file. The BFD support for a particular 185object file format will normally store this information in private data 186and handle it using the special hooks. 187 188In some cases there is also implicit information which BFD can not 189represent. For example, the MIPS processor distinguishes small and 190large symbols, and requires that all small symbls be within 32K of the 191GP register. This means that the MIPS assembler must be able to mark 192variables as either small or large, and the MIPS linker must know to put 193small symbols within range of the GP register. Since BFD can not 194represent this information, this means that the assembler and linker 195must have information that is specific to a particular object file 196format which is outside of the BFD library. 197 198This loss of information indicates areas where the BFD paradigm breaks 199down. It is not actually possible to represent the myriad differences 200among object file formats using a single generic interface, at least not 201in the manner which BFD does it today. 202 203Nevertheless, the BFD library does greatly simplify the task of dealing 204with object files, and particular problems caused by information loss 205can normally be solved using some sort of relatively constrained hook 206into the library. 207 208 209 210@node BFD guidelines 211@section BFD programming guidelines 212@cindex bfd programming guidelines 213@cindex programming guidelines for bfd 214@cindex guidelines, bfd programming 215 216There is a lot of poorly written and confusing code in BFD. New BFD 217code should be written to a higher standard. Merely because some BFD 218code is written in a particular manner does not mean that you should 219emulate it. 220 221Here are some general BFD programming guidelines: 222 223@itemize @bullet 224@item 225Follow the GNU coding standards. 226 227@item 228Avoid global variables. We ideally want BFD to be fully reentrant, so 229that it can be used in multiple threads. All uses of global or static 230variables interfere with that. Initialized constant variables are OK, 231and they should be explicitly marked with const. Instead of global 232variables, use data attached to a BFD or to a linker hash table. 233 234@item 235All externally visible functions should have names which start with 236@samp{bfd_}. All such functions should be declared in some header file, 237typically @file{bfd.h}. See, for example, the various declarations near 238the end of @file{bfd-in.h}, which mostly declare functions required by 239specific linker emulations. 240 241@item 242All functions which need to be visible from one file to another within 243BFD, but should not be visible outside of BFD, should start with 244@samp{_bfd_}. Although external names beginning with @samp{_} are 245prohibited by the ANSI standard, in practice this usage will always 246work, and it is required by the GNU coding standards. 247 248@item 249Always remember that people can compile using @samp{--enable-targets} to 250build several, or all, targets at once. It must be possible to link 251together the files for all targets. 252 253@item 254BFD code should compile with few or no warnings using @samp{gcc -Wall}. 255Some warnings are OK, like the absence of certain function declarations 256which may or may not be declared in system header files. Warnings about 257ambiguous expressions and the like should always be fixed. 258@end itemize 259 260@node BFD target vector 261@section BFD target vector 262@cindex bfd target vector 263@cindex target vector in bfd 264 265BFD supports multiple object file formats by using the @dfn{target 266vector}. This is simply a set of function pointers which implement 267behaviour that is specific to a particular object file format. 268 269In this section I list all of the entries in the target vector and 270describe what they do. 271 272@menu 273* BFD target vector miscellaneous:: Miscellaneous constants 274* BFD target vector swap:: Swapping functions 275* BFD target vector format:: Format type dependent functions 276* BFD_JUMP_TABLE macros:: BFD_JUMP_TABLE macros 277* BFD target vector generic:: Generic functions 278* BFD target vector copy:: Copy functions 279* BFD target vector core:: Core file support functions 280* BFD target vector archive:: Archive functions 281* BFD target vector symbols:: Symbol table functions 282* BFD target vector relocs:: Relocation support 283* BFD target vector write:: Output functions 284* BFD target vector link:: Linker functions 285* BFD target vector dynamic:: Dynamic linking information functions 286@end menu 287 288@node BFD target vector miscellaneous 289@subsection Miscellaneous constants 290 291The target vector starts with a set of constants. 292 293@table @samp 294@item name 295The name of the target vector. This is an arbitrary string. This is 296how the target vector is named in command line options for tools which 297use BFD, such as the @samp{-oformat} linker option. 298 299@item flavour 300A general description of the type of target. The following flavours are 301currently defined: 302 303@table @samp 304@item bfd_target_unknown_flavour 305Undefined or unknown. 306@item bfd_target_aout_flavour 307a.out. 308@item bfd_target_coff_flavour 309COFF. 310@item bfd_target_ecoff_flavour 311ECOFF. 312@item bfd_target_elf_flavour 313ELF. 314@item bfd_target_ieee_flavour 315IEEE-695. 316@item bfd_target_nlm_flavour 317NLM. 318@item bfd_target_oasys_flavour 319OASYS. 320@item bfd_target_tekhex_flavour 321Tektronix hex format. 322@item bfd_target_srec_flavour 323Motorola S-record format. 324@item bfd_target_ihex_flavour 325Intel hex format. 326@item bfd_target_som_flavour 327SOM (used on HP/UX). 328@item bfd_target_os9k_flavour 329os9000. 330@item bfd_target_versados_flavour 331VERSAdos. 332@item bfd_target_msdos_flavour 333MS-DOS. 334@item bfd_target_evax_flavour 335openVMS. 336@end table 337 338@item byteorder 339The byte order of data in the object file. One of 340@samp{BFD_ENDIAN_BIG}, @samp{BFD_ENDIAN_LITTLE}, or 341@samp{BFD_ENDIAN_UNKNOWN}. The latter would be used for a format such 342as S-records which do not record the architecture of the data. 343 344@item header_byteorder 345The byte order of header information in the object file. Normally the 346same as the @samp{byteorder} field, but there are certain cases where it 347may be different. 348 349@item object_flags 350Flags which may appear in the @samp{flags} field of a BFD with this 351format. 352 353@item section_flags 354Flags which may appear in the @samp{flags} field of a section within a 355BFD with this format. 356 357@item symbol_leading_char 358A character which the C compiler normally puts before a symbol. For 359example, an a.out compiler will typically generate the symbol 360@samp{_foo} for a function named @samp{foo} in the C source, in which 361case this field would be @samp{_}. If there is no such character, this 362field will be @samp{0}. 363 364@item ar_pad_char 365The padding character to use at the end of an archive name. Normally 366@samp{/}. 367 368@item ar_max_namelen 369The maximum length of a short name in an archive. Normally @samp{14}. 370 371@item backend_data 372A pointer to constant backend data. This is used by backends to store 373whatever additional information they need to distinguish similar target 374vectors which use the same sets of functions. 375@end table 376 377@node BFD target vector swap 378@subsection Swapping functions 379 380Every target vector has fuction pointers used for swapping information 381in and out of the target representation. There are two sets of 382functions: one for data information, and one for header information. 383Each set has three sizes: 64-bit, 32-bit, and 16-bit. Each size has 384three actual functions: put, get unsigned, and get signed. 385 386These 18 functions are used to convert data between the host and target 387representations. 388 389@node BFD target vector format 390@subsection Format type dependent functions 391 392Every target vector has three arrays of function pointers which are 393indexed by the BFD format type. The BFD format types are as follows: 394 395@table @samp 396@item bfd_unknown 397Unknown format. Not used for anything useful. 398@item bfd_object 399Object file. 400@item bfd_archive 401Archive file. 402@item bfd_core 403Core file. 404@end table 405 406The three arrays of function pointers are as follows: 407 408@table @samp 409@item bfd_check_format 410Check whether the BFD is of a particular format (object file, archive 411file, or core file) corresponding to this target vector. This is called 412by the @samp{bfd_check_format} function when examining an existing BFD. 413If the BFD matches the desired format, this function will initialize any 414format specific information such as the @samp{tdata} field of the BFD. 415This function must be called before any other BFD target vector function 416on a file opened for reading. 417 418@item bfd_set_format 419Set the format of a BFD which was created for output. This is called by 420the @samp{bfd_set_format} function after creating the BFD with a 421function such as @samp{bfd_openw}. This function will initialize format 422specific information required to write out an object file or whatever of 423the given format. This function must be called before any other BFD 424target vector function on a file opened for writing. 425 426@item bfd_write_contents 427Write out the contents of the BFD in the given format. This is called 428by @samp{bfd_close} function for a BFD opened for writing. This really 429should not be an array selected by format type, as the 430@samp{bfd_set_format} function provides all the required information. 431In fact, BFD will fail if a different format is used when calling 432through the @samp{bfd_set_format} and the @samp{bfd_write_contents} 433arrays; fortunately, since @samp{bfd_close} gets it right, this is a 434difficult error to make. 435@end table 436 437@node BFD_JUMP_TABLE macros 438@subsection @samp{BFD_JUMP_TABLE} macros 439@cindex @samp{BFD_JUMP_TABLE} 440 441Most target vectors are defined using @samp{BFD_JUMP_TABLE} macros. 442These macros take a single argument, which is a prefix applied to a set 443of functions. The macros are then used to initialize the fields in the 444target vector. 445 446For example, the @samp{BFD_JUMP_TABLE_RELOCS} macro defines three 447functions: @samp{_get_reloc_upper_bound}, @samp{_canonicalize_reloc}, 448and @samp{_bfd_reloc_type_lookup}. A reference like 449@samp{BFD_JUMP_TABLE_RELOCS (foo)} will expand into three functions 450prefixed with @samp{foo}: @samp{foo_get_reloc_upper_bound}, etc. The 451@samp{BFD_JUMP_TABLE_RELOCS} macro will be placed such that those three 452functions initialize the appropriate fields in the BFD target vector. 453 454This is done because it turns out that many different target vectors can 455share certain classes of functions. For example, archives are similar 456on most platforms, so most target vectors can use the same archive 457functions. Those target vectors all use @samp{BFD_JUMP_TABLE_ARCHIVE} 458with the same argument, calling a set of functions which is defined in 459@file{archive.c}. 460 461Each of the @samp{BFD_JUMP_TABLE} macros is mentioned below along with 462the description of the function pointers which it defines. The function 463pointers will be described using the name without the prefix which the 464@samp{BFD_JUMP_TABLE} macro defines. This name is normally the same as 465the name of the field in the target vector structure. Any differences 466will be noted. 467 468@node BFD target vector generic 469@subsection Generic functions 470@cindex @samp{BFD_JUMP_TABLE_GENERIC} 471 472The @samp{BFD_JUMP_TABLE_GENERIC} macro is used for some catch all 473functions which don't easily fit into other categories. 474 475@table @samp 476@item _close_and_cleanup 477Free any target specific information associated with the BFD. This is 478called when any BFD is closed (the @samp{bfd_write_contents} function 479mentioned earlier is only called for a BFD opened for writing). Most 480targets use @samp{bfd_alloc} to allocate all target specific 481information, and therefore don't have to do anything in this function. 482This function pointer is typically set to 483@samp{_bfd_generic_close_and_cleanup}, which simply returns true. 484 485@item _bfd_free_cached_info 486Free any cached information associated with the BFD which can be 487recreated later if necessary. This is used to reduce the memory 488consumption required by programs using BFD. This is normally called via 489the @samp{bfd_free_cached_info} macro. It is used by the default 490archive routines when computing the archive map. Most targets do not 491do anything special for this entry point, and just set it to 492@samp{_bfd_generic_free_cached_info}, which simply returns true. 493 494@item _new_section_hook 495This is called from @samp{bfd_make_section_anyway} whenever a new 496section is created. Most targets use it to initialize section specific 497information. This function is called whether or not the section 498corresponds to an actual section in an actual BFD. 499 500@item _get_section_contents 501Get the contents of a section. This is called from 502@samp{bfd_get_section_contents}. Most targets set this to 503@samp{_bfd_generic_get_section_contents}, which does a @samp{bfd_seek} 504based on the section's @samp{filepos} field and a @samp{bfd_read}. The 505corresponding field in the target vector is named 506@samp{_bfd_get_section_contents}. 507 508@item _get_section_contents_in_window 509Set a @samp{bfd_window} to hold the contents of a section. This is 510called from @samp{bfd_get_section_contents_in_window}. The 511@samp{bfd_window} idea never really caught on, and I don't think this is 512ever called. Pretty much all targets implement this as 513@samp{bfd_generic_get_section_contents_in_window}, which uses 514@samp{bfd_get_section_contents} to do the right thing. The 515corresponding field in the target vector is named 516@samp{_bfd_get_section_contents_in_window}. 517@end table 518 519@node BFD target vector copy 520@subsection Copy functions 521@cindex @samp{BFD_JUMP_TABLE_COPY} 522 523The @samp{BFD_JUMP_TABLE_COPY} macro is used for functions which are 524called when copying BFDs, and for a couple of functions which deal with 525internal BFD information. 526 527@table @samp 528@item _bfd_copy_private_bfd_data 529This is called when copying a BFD, via @samp{bfd_copy_private_bfd_data}. 530If the input and output BFDs have the same format, this will copy any 531private information over. This is called after all the section contents 532have been written to the output file. Only a few targets do anything in 533this function. 534 535@item _bfd_merge_private_bfd_data 536This is called when linking, via @samp{bfd_merge_private_bfd_data}. It 537gives the backend linker code a chance to set any special flags in the 538output file based on the contents of the input file. Only a few targets 539do anything in this function. 540 541@item _bfd_copy_private_section_data 542This is similar to @samp{_bfd_copy_private_bfd_data}, but it is called 543for each section, via @samp{bfd_copy_private_section_data}. This 544function is called before any section contents have been written. Only 545a few targets do anything in this function. 546 547@item _bfd_copy_private_symbol_data 548This is called via @samp{bfd_copy_private_symbol_data}, but I don't 549think anything actually calls it. If it were defined, it could be used 550to copy private symbol data from one BFD to another. However, most BFDs 551store extra symbol information by allocating space which is larger than 552the @samp{asymbol} structure and storing private information in the 553extra space. Since @samp{objcopy} and other programs copy symbol 554information by copying pointers to @samp{asymbol} structures, the 555private symbol information is automatically copied as well. Most 556targets do not do anything in this function. 557 558@item _bfd_set_private_flags 559This is called via @samp{bfd_set_private_flags}. It is basically a hook 560for the assembler to set magic information. For example, the PowerPC 561ELF assembler uses it to set flags which appear in the e_flags field of 562the ELF header. Most targets do not do anything in this function. 563 564@item _bfd_print_private_bfd_data 565This is called by @samp{objdump} when the @samp{-p} option is used. It 566is called via @samp{bfd_print_private_data}. It prints any interesting 567information about the BFD which can not be otherwise represented by BFD 568and thus can not be printed by @samp{objdump}. Most targets do not do 569anything in this function. 570@end table 571 572@node BFD target vector core 573@subsection Core file support functions 574@cindex @samp{BFD_JUMP_TABLE_CORE} 575 576The @samp{BFD_JUMP_TABLE_CORE} macro is used for functions which deal 577with core files. Obviously, these functions only do something 578interesting for targets which have core file support. 579 580@table @samp 581@item _core_file_failing_command 582Given a core file, this returns the command which was run to produce the 583core file. 584 585@item _core_file_failing_signal 586Given a core file, this returns the signal number which produced the 587core file. 588 589@item _core_file_matches_executable_p 590Given a core file and a BFD for an executable, this returns whether the 591core file was generated by the executable. 592@end table 593 594@node BFD target vector archive 595@subsection Archive functions 596@cindex @samp{BFD_JUMP_TABLE_ARCHIVE} 597 598The @samp{BFD_JUMP_TABLE_ARCHIVE} macro is used for functions which deal 599with archive files. Most targets use COFF style archive files 600(including ELF targets), and these use @samp{_bfd_archive_coff} as the 601argument to @samp{BFD_JUMP_TABLE_ARCHIVE}. Some targets use BSD/a.out 602style archives, and these use @samp{_bfd_archive_bsd}. (The main 603difference between BSD and COFF archives is the format of the archive 604symbol table). Targets with no archive support use 605@samp{_bfd_noarchive}. Finally, a few targets have unusual archive 606handling. 607 608@table @samp 609@item _slurp_armap 610Read in the archive symbol table, storing it in private BFD data. This 611is normally called from the archive @samp{check_format} routine. The 612corresponding field in the target vector is named 613@samp{_bfd_slurp_armap}. 614 615@item _slurp_extended_name_table 616Read in the extended name table from the archive, if there is one, 617storing it in private BFD data. This is normally called from the 618archive @samp{check_format} routine. The corresponding field in the 619target vector is named @samp{_bfd_slurp_extended_name_table}. 620 621@item construct_extended_name_table 622Build and return an extended name table if one is needed to write out 623the archive. This also adjusts the archive headers to refer to the 624extended name table appropriately. This is normally called from the 625archive @samp{write_contents} routine. The corresponding field in the 626target vector is named @samp{_bfd_construct_extended_name_table}. 627 628@item _truncate_arname 629This copies a file name into an archive header, truncating it as 630required. It is normally called from the archive @samp{write_contents} 631routine. This function is more interesting in targets which do not 632support extended name tables, but I think the GNU @samp{ar} program 633always uses extended name tables anyhow. The corresponding field in the 634target vector is named @samp{_bfd_truncate_arname}. 635 636@item _write_armap 637Write out the archive symbol table using calls to @samp{bfd_write}. 638This is normally called from the archive @samp{write_contents} routine. 639The corresponding field in the target vector is named @samp{write_armap} 640(no leading underscore). 641 642@item _read_ar_hdr 643Read and parse an archive header. This handles expanding the archive 644header name into the real file name using the extended name table. This 645is called by routines which read the archive symbol table or the archive 646itself. The corresponding field in the target vector is named 647@samp{_bfd_read_ar_hdr_fn}. 648 649@item _openr_next_archived_file 650Given an archive and a BFD representing a file stored within the 651archive, return a BFD for the next file in the archive. This is called 652via @samp{bfd_openr_next_archived_file}. The corresponding field in the 653target vector is named @samp{openr_next_archived_file} (no leading 654underscore). 655 656@item _get_elt_at_index 657Given an archive and an index, return a BFD for the file in the archive 658corresponding to that entry in the archive symbol table. This is called 659via @samp{bfd_get_elt_at_index}. The corresponding field in the target 660vector is named @samp{_bfd_get_elt_at_index}. 661 662@item _generic_stat_arch_elt 663Do a stat on an element of an archive, returning information read from 664the archive header (modification time, uid, gid, file mode, size). This 665is called via @samp{bfd_stat_arch_elt}. The corresponding field in the 666target vector is named @samp{_bfd_stat_arch_elt}. 667 668@item _update_armap_timestamp 669After the entire contents of an archive have been written out, update 670the timestamp of the archive symbol table to be newer than that of the 671file. This is required for a.out style archives. This is normally 672called by the archive @samp{write_contents} routine. The corresponding 673field in the target vector is named @samp{_bfd_update_armap_timestamp}. 674@end table 675 676@node BFD target vector symbols 677@subsection Symbol table functions 678@cindex @samp{BFD_JUMP_TABLE_SYMBOLS} 679 680The @samp{BFD_JUMP_TABLE_SYMBOLS} macro is used for functions which deal 681with symbols. 682 683@table @samp 684@item _get_symtab_upper_bound 685Return a sensible upper bound on the amount of memory which will be 686required to read the symbol table. In practice most targets return the 687amount of memory required to hold @samp{asymbol} pointers for all the 688symbols plus a trailing @samp{NULL} entry, and store the actual symbol 689information in BFD private data. This is called via 690@samp{bfd_get_symtab_upper_bound}. The corresponding field in the 691target vector is named @samp{_bfd_get_symtab_upper_bound}. 692 693@item _get_symtab 694Read in the symbol table. This is called via 695@samp{bfd_canonicalize_symtab}. The corresponding field in the target 696vector is named @samp{_bfd_canonicalize_symtab}. 697 698@item _make_empty_symbol 699Create an empty symbol for the BFD. This is needed because most targets 700store extra information with each symbol by allocating a structure 701larger than an @samp{asymbol} and storing the extra information at the 702end. This function will allocate the right amount of memory, and return 703what looks like a pointer to an empty @samp{asymbol}. This is called 704via @samp{bfd_make_empty_symbol}. The corresponding field in the target 705vector is named @samp{_bfd_make_empty_symbol}. 706 707@item _print_symbol 708Print information about the symbol. This is called via 709@samp{bfd_print_symbol}. One of the arguments indicates what sort of 710information should be printed: 711 712@table @samp 713@item bfd_print_symbol_name 714Just print the symbol name. 715@item bfd_print_symbol_more 716Print the symbol name and some interesting flags. I don't think 717anything actually uses this. 718@item bfd_print_symbol_all 719Print all information about the symbol. This is used by @samp{objdump} 720when run with the @samp{-t} option. 721@end table 722The corresponding field in the target vector is named 723@samp{_bfd_print_symbol}. 724 725@item _get_symbol_info 726Return a standard set of information about the symbol. This is called 727via @samp{bfd_symbol_info}. The corresponding field in the target 728vector is named @samp{_bfd_get_symbol_info}. 729 730@item _bfd_is_local_label_name 731Return whether the given string would normally represent the name of a 732local label. This is called via @samp{bfd_is_local_label} and 733@samp{bfd_is_local_label_name}. Local labels are normally discarded by 734the assembler. In the linker, this defines the difference between the 735@samp{-x} and @samp{-X} options. 736 737@item _get_lineno 738Return line number information for a symbol. This is only meaningful 739for a COFF target. This is called when writing out COFF line numbers. 740 741@item _find_nearest_line 742Given an address within a section, use the debugging information to find 743the matching file name, function name, and line number, if any. This is 744called via @samp{bfd_find_nearest_line}. The corresponding field in the 745target vector is named @samp{_bfd_find_nearest_line}. 746 747@item _bfd_make_debug_symbol 748Make a debugging symbol. This is only meaningful for a COFF target, 749where it simply returns a symbol which will be placed in the 750@samp{N_DEBUG} section when it is written out. This is called via 751@samp{bfd_make_debug_symbol}. 752 753@item _read_minisymbols 754Minisymbols are used to reduce the memory requirements of programs like 755@samp{nm}. A minisymbol is a cookie pointing to internal symbol 756information which the caller can use to extract complete symbol 757information. This permits BFD to not convert all the symbols into 758generic form, but to instead convert them one at a time. This is called 759via @samp{bfd_read_minisymbols}. Most targets do not implement this, 760and just use generic support which is based on using standard 761@samp{asymbol} structures. 762 763@item _minisymbol_to_symbol 764Convert a minisymbol to a standard @samp{asymbol}. This is called via 765@samp{bfd_minisymbol_to_symbol}. 766@end table 767 768@node BFD target vector relocs 769@subsection Relocation support 770@cindex @samp{BFD_JUMP_TABLE_RELOCS} 771 772The @samp{BFD_JUMP_TABLE_RELOCS} macro is used for functions which deal 773with relocations. 774 775@table @samp 776@item _get_reloc_upper_bound 777Return a sensible upper bound on the amount of memory which will be 778required to read the relocations for a section. In practice most 779targets return the amount of memory required to hold @samp{arelent} 780pointers for all the relocations plus a trailing @samp{NULL} entry, and 781store the actual relocation information in BFD private data. This is 782called via @samp{bfd_get_reloc_upper_bound}. 783 784@item _canonicalize_reloc 785Return the relocation information for a section. This is called via 786@samp{bfd_canonicalize_reloc}. The corresponding field in the target 787vector is named @samp{_bfd_canonicalize_reloc}. 788 789@item _bfd_reloc_type_lookup 790Given a relocation code, return the corresponding howto structure 791(@pxref{BFD relocation codes}). This is called via 792@samp{bfd_reloc_type_lookup}. The corresponding field in the target 793vector is named @samp{reloc_type_lookup}. 794@end table 795 796@node BFD target vector write 797@subsection Output functions 798@cindex @samp{BFD_JUMP_TABLE_WRITE} 799 800The @samp{BFD_JUMP_TABLE_WRITE} macro is used for functions which deal 801with writing out a BFD. 802 803@table @samp 804@item _set_arch_mach 805Set the architecture and machine number for a BFD. This is called via 806@samp{bfd_set_arch_mach}. Most targets implement this by calling 807@samp{bfd_default_set_arch_mach}. The corresponding field in the target 808vector is named @samp{_bfd_set_arch_mach}. 809 810@item _set_section_contents 811Write out the contents of a section. This is called via 812@samp{bfd_set_section_contents}. The corresponding field in the target 813vector is named @samp{_bfd_set_section_contents}. 814@end table 815 816@node BFD target vector link 817@subsection Linker functions 818@cindex @samp{BFD_JUMP_TABLE_LINK} 819 820The @samp{BFD_JUMP_TABLE_LINK} macro is used for functions called by the 821linker. 822 823@table @samp 824@item _sizeof_headers 825Return the size of the header information required for a BFD. This is 826used to implement the @samp{SIZEOF_HEADERS} linker script function. It 827is normally used to align the first section at an efficient position on 828the page. This is called via @samp{bfd_sizeof_headers}. The 829corresponding field in the target vector is named 830@samp{_bfd_sizeof_headers}. 831 832@item _bfd_get_relocated_section_contents 833Read the contents of a section and apply the relocation information. 834This handles both a final link and a relocateable link; in the latter 835case, it adjust the relocation information as well. This is called via 836@samp{bfd_get_relocated_section_contents}. Most targets implement it by 837calling @samp{bfd_generic_get_relocated_section_contents}. 838 839@item _bfd_relax_section 840Try to use relaxation to shrink the size of a section. This is called 841by the linker when the @samp{-relax} option is used. This is called via 842@samp{bfd_relax_section}. Most targets do not support any sort of 843relaxation. 844 845@item _bfd_link_hash_table_create 846Create the symbol hash table to use for the linker. This linker hook 847permits the backend to control the size and information of the elements 848in the linker symbol hash table. This is called via 849@samp{bfd_link_hash_table_create}. 850 851@item _bfd_link_add_symbols 852Given an object file or an archive, add all symbols into the linker 853symbol hash table. Use callbacks to the linker to include archive 854elements in the link. This is called via @samp{bfd_link_add_symbols}. 855 856@item _bfd_final_link 857Finish the linking process. The linker calls this hook after all of the 858input files have been read, when it is ready to finish the link and 859generate the output file. This is called via @samp{bfd_final_link}. 860 861@item _bfd_link_split_section 862I don't know what this is for. Nothing seems to call it. The only 863non-trivial definition is in @file{som.c}. 864@end table 865 866@node BFD target vector dynamic 867@subsection Dynamic linking information functions 868@cindex @samp{BFD_JUMP_TABLE_DYNAMIC} 869 870The @samp{BFD_JUMP_TABLE_DYNAMIC} macro is used for functions which read 871dynamic linking information. 872 873@table @samp 874@item _get_dynamic_symtab_upper_bound 875Return a sensible upper bound on the amount of memory which will be 876required to read the dynamic symbol table. In practice most targets 877return the amount of memory required to hold @samp{asymbol} pointers for 878all the symbols plus a trailing @samp{NULL} entry, and store the actual 879symbol information in BFD private data. This is called via 880@samp{bfd_get_dynamic_symtab_upper_bound}. The corresponding field in 881the target vector is named @samp{_bfd_get_dynamic_symtab_upper_bound}. 882 883@item _canonicalize_dynamic_symtab 884Read the dynamic symbol table. This is called via 885@samp{bfd_canonicalize_dynamic_symtab}. The corresponding field in the 886target vector is named @samp{_bfd_canonicalize_dynamic_symtab}. 887 888@item _get_dynamic_reloc_upper_bound 889Return a sensible upper bound on the amount of memory which will be 890required to read the dynamic relocations. In practice most targets 891return the amount of memory required to hold @samp{arelent} pointers for 892all the relocations plus a trailing @samp{NULL} entry, and store the 893actual relocation information in BFD private data. This is called via 894@samp{bfd_get_dynamic_reloc_upper_bound}. The corresponding field in 895the target vector is named @samp{_bfd_get_dynamic_reloc_upper_bound}. 896 897@item _canonicalize_dynamic_reloc 898Read the dynamic relocations. This is called via 899@samp{bfd_canonicalize_dynamic_reloc}. The corresponding field in the 900target vector is named @samp{_bfd_canonicalize_dynamic_reloc}. 901@end table 902 903@node BFD generated files 904@section BFD generated files 905@cindex generated files in bfd 906@cindex bfd generated files 907 908BFD contains several automatically generated files. This section 909describes them. Some files are created at configure time, when you 910configure BFD. Some files are created at make time, when you build 911BFD. Some files are automatically rebuilt at make time, but only if 912you configure with the @samp{--enable-maintainer-mode} option. Some 913files live in the object directory---the directory from which you run 914configure---and some live in the source directory. All files that live 915in the source directory are checked into the CVS repository. 916 917@table @file 918@item bfd.h 919@cindex @file{bfd.h} 920@cindex @file{bfd-in3.h} 921Lives in the object directory. Created at make time from 922@file{bfd-in2.h} via @file{bfd-in3.h}. @file{bfd-in3.h} is created at 923configure time from @file{bfd-in2.h}. There are automatic dependencies 924to rebuild @file{bfd-in3.h} and hence @file{bfd.h} if @file{bfd-in2.h} 925changes, so you can normally ignore @file{bfd-in3.h}, and just think 926about @file{bfd-in2.h} and @file{bfd.h}. 927 928@file{bfd.h} is built by replacing a few strings in @file{bfd-in2.h}. 929To see them, search for @samp{@@} in @file{bfd-in2.h}. They mainly 930control whether BFD is built for a 32 bit target or a 64 bit target. 931 932@item bfd-in2.h 933@cindex @file{bfd-in2.h} 934Lives in the source directory. Created from @file{bfd-in.h} and several 935other BFD source files. If you configure with the 936@samp{--enable-maintainer-mode} option, @file{bfd-in2.h} is rebuilt 937automatically when a source file changes. 938 939@item elf32-target.h 940@itemx elf64-target.h 941@cindex @file{elf32-target.h} 942@cindex @file{elf64-target.h} 943Live in the object directory. Created from @file{elfxx-target.h}. 944These files are versions of @file{elfxx-target.h} customized for either 945a 32 bit ELF target or a 64 bit ELF target. 946 947@item libbfd.h 948@cindex @file{libbfd.h} 949Lives in the source directory. Created from @file{libbfd-in.h} and 950several other BFD source files. If you configure with the 951@samp{--enable-maintainer-mode} option, @file{libbfd.h} is rebuilt 952automatically when a source file changes. 953 954@item libcoff.h 955@cindex @file{libcoff.h} 956Lives in the source directory. Created from @file{libcoff-in.h} and 957@file{coffcode.h}. If you configure with the 958@samp{--enable-maintainer-mode} option, @file{libcoff.h} is rebuilt 959automatically when a source file changes. 960 961@item targmatch.h 962@cindex @file{targmatch.h} 963Lives in the object directory. Created at make time from 964@file{config.bfd}. This file is used to map configuration triplets into 965BFD target vector variable names at run time. 966@end table 967 968@node BFD multiple compilations 969@section Files compiled multiple times in BFD 970Several files in BFD are compiled multiple times. By this I mean that 971there are header files which contain function definitions. These header 972files are included by other files, and thus the functions are compiled 973once per file which includes them. 974 975Preprocessor macros are used to control the compilation, so that each 976time the files are compiled the resulting functions are slightly 977different. Naturally, if they weren't different, there would be no 978reason to compile them multiple times. 979 980This is a not a particularly good programming technique, and future BFD 981work should avoid it. 982 983@itemize @bullet 984@item 985Since this technique is rarely used, even experienced C programmers find 986it confusing. 987 988@item 989It is difficult to debug programs which use BFD, since there is no way 990to describe which version of a particular function you are looking at. 991 992@item 993Programs which use BFD wind up incorporating two or more slightly 994different versions of the same function, which wastes space in the 995executable. 996 997@item 998This technique is never required nor is it especially efficient. It is 999always possible to use statically initialized structures holding 1000function pointers and magic constants instead. 1001@end itemize 1002 1003The following is a list of the files which are compiled multiple times. 1004 1005@table @file 1006@item aout-target.h 1007@cindex @file{aout-target.h} 1008Describes a few functions and the target vector for a.out targets. This 1009is used by individual a.out targets with different definitions of 1010@samp{N_TXTADDR} and similar a.out macros. 1011 1012@item aoutf1.h 1013@cindex @file{aoutf1.h} 1014Implements standard SunOS a.out files. In principle it supports 64 bit 1015a.out targets based on the preprocessor macro @samp{ARCH_SIZE}, but 1016since all known a.out targets are 32 bits, this code may or may not 1017work. This file is only included by a few other files, and it is 1018difficult to justify its existence. 1019 1020@item aoutx.h 1021@cindex @file{aoutx.h} 1022Implements basic a.out support routines. This file can be compiled for 1023either 32 or 64 bit support. Since all known a.out targets are 32 bits, 1024the 64 bit support may or may not work. I believe the original 1025intention was that this file would only be included by @samp{aout32.c} 1026and @samp{aout64.c}, and that other a.out targets would simply refer to 1027the functions it defined. Unfortunately, some other a.out targets 1028started including it directly, leading to a somewhat confused state of 1029affairs. 1030 1031@item coffcode.h 1032@cindex @file{coffcode.h} 1033Implements basic COFF support routines. This file is included by every 1034COFF target. It implements code which handles COFF magic numbers as 1035well as various hook functions called by the generic COFF functions in 1036@file{coffgen.c}. This file is controlled by a number of different 1037macros, and more are added regularly. 1038 1039@item coffswap.h 1040@cindex @file{coffswap.h} 1041Implements COFF swapping routines. This file is included by 1042@file{coffcode.h}, and thus by every COFF target. It implements the 1043routines which swap COFF structures between internal and external 1044format. The main control for this file is the external structure 1045definitions in the files in the @file{include/coff} directory. A COFF 1046target file will include one of those files before including 1047@file{coffcode.h} and thus @file{coffswap.h}. There are a few other 1048macros which affect @file{coffswap.h} as well, mostly describing whether 1049certain fields are present in the external structures. 1050 1051@item ecoffswap.h 1052@cindex @file{ecoffswap.h} 1053Implements ECOFF swapping routines. This is like @file{coffswap.h}, but 1054for ECOFF. It is included by the ECOFF target files (of which there are 1055only two). The control is the preprocessor macro @samp{ECOFF_32} or 1056@samp{ECOFF_64}. 1057 1058@item elfcode.h 1059@cindex @file{elfcode.h} 1060Implements ELF functions that use external structure definitions. This 1061file is included by two other files: @file{elf32.c} and @file{elf64.c}. 1062It is controlled by the @samp{ARCH_SIZE} macro which is defined to be 1063@samp{32} or @samp{64} before including it. The @samp{NAME} macro is 1064used internally to give the functions different names for the two target 1065sizes. 1066 1067@item elfcore.h 1068@cindex @file{elfcore.h} 1069Like @file{elfcode.h}, but for functions that are specific to ELF core 1070files. This is included only by @file{elfcode.h}. 1071 1072@item elflink.h 1073@cindex @file{elflink.h} 1074Like @file{elfcode.h}, but for functions used by the ELF linker. This 1075is included only by @file{elfcode.h}. 1076 1077@item elfxx-target.h 1078@cindex @file{elfxx-target.h} 1079This file is the source for the generated files @file{elf32-target.h} 1080and @file{elf64-target.h}, one of which is included by every ELF target. 1081It defines the ELF target vector. 1082 1083@item freebsd.h 1084@cindex @file{freebsd.h} 1085Presumably intended to be included by all FreeBSD targets, but in fact 1086there is only one such target, @samp{i386-freebsd}. This defines a 1087function used to set the right magic number for FreeBSD, as well as 1088various macros, and includes @file{aout-target.h}. 1089 1090@item netbsd.h 1091@cindex @file{netbsd.h} 1092Like @file{freebsd.h}, except that there are several files which include 1093it. 1094 1095@item nlm-target.h 1096@cindex @file{nlm-target.h} 1097Defines the target vector for a standard NLM target. 1098 1099@item nlmcode.h 1100@cindex @file{nlmcode.h} 1101Like @file{elfcode.h}, but for NLM targets. This is only included by 1102@file{nlm32.c} and @file{nlm64.c}, both of which define the macro 1103@samp{ARCH_SIZE} to an appropriate value. There are no 64 bit NLM 1104targets anyhow, so this is sort of useless. 1105 1106@item nlmswap.h 1107@cindex @file{nlmswap.h} 1108Like @file{coffswap.h}, but for NLM targets. This is included by each 1109NLM target, but I think it winds up compiling to the exact same code for 1110every target, and as such is fairly useless. 1111 1112@item peicode.h 1113@cindex @file{peicode.h} 1114Provides swapping routines and other hooks for PE targets. 1115@file{coffcode.h} will include this rather than @file{coffswap.h} for a 1116PE target. This defines PE specific versions of the COFF swapping 1117routines, and also defines some macros which control @file{coffcode.h} 1118itself. 1119@end table 1120 1121@node BFD relocation handling 1122@section BFD relocation handling 1123@cindex bfd relocation handling 1124@cindex relocations in bfd 1125 1126The handling of relocations is one of the more confusing aspects of BFD. 1127Relocation handling has been implemented in various different ways, all 1128somewhat incompatible, none perfect. 1129 1130@menu 1131* BFD relocation concepts:: BFD relocation concepts 1132* BFD relocation functions:: BFD relocation functions 1133* BFD relocation codes:: BFD relocation codes 1134* BFD relocation future:: BFD relocation future 1135@end menu 1136 1137@node BFD relocation concepts 1138@subsection BFD relocation concepts 1139 1140A relocation is an action which the linker must take when linking. It 1141describes a change to the contents of a section. The change is normally 1142based on the final value of one or more symbols. Relocations are 1143created by the assembler when it creates an object file. 1144 1145Most relocations are simple. A typical simple relocation is to set 32 1146bits at a given offset in a section to the value of a symbol. This type 1147of relocation would be generated for code like @code{int *p = &i;} where 1148@samp{p} and @samp{i} are global variables. A relocation for the symbol 1149@samp{i} would be generated such that the linker would initialize the 1150area of memory which holds the value of @samp{p} to the value of the 1151symbol @samp{i}. 1152 1153Slightly more complex relocations may include an addend, which is a 1154constant to add to the symbol value before using it. In some cases a 1155relocation will require adding the symbol value to the existing contents 1156of the section in the object file. In others the relocation will simply 1157replace the contents of the section with the symbol value. Some 1158relocations are PC relative, so that the value to be stored in the 1159section is the difference between the value of a symbol and the final 1160address of the section contents. 1161 1162In general, relocations can be arbitrarily complex. For example, 1163relocations used in dynamic linking systems often require the linker to 1164allocate space in a different section and use the offset within that 1165section as the value to store. In the IEEE object file format, 1166relocations may involve arbitrary expressions. 1167 1168When doing a relocateable link, the linker may or may not have to do 1169anything with a relocation, depending upon the definition of the 1170relocation. Simple relocations generally do not require any special 1171action. 1172 1173@node BFD relocation functions 1174@subsection BFD relocation functions 1175 1176In BFD, each section has an array of @samp{arelent} structures. Each 1177structure has a pointer to a symbol, an address within the section, an 1178addend, and a pointer to a @samp{reloc_howto_struct} structure. The 1179howto structure has a bunch of fields describing the reloc, including a 1180type field. The type field is specific to the object file format 1181backend; none of the generic code in BFD examines it. 1182 1183Originally, the function @samp{bfd_perform_relocation} was supposed to 1184handle all relocations. In theory, many relocations would be simple 1185enough to be described by the fields in the howto structure. For those 1186that weren't, the howto structure included a @samp{special_function} 1187field to use as an escape. 1188 1189While this seems plausible, a look at @samp{bfd_perform_relocation} 1190shows that it failed. The function has odd special cases. Some of the 1191fields in the howto structure, such as @samp{pcrel_offset}, were not 1192adequately documented. 1193 1194The linker uses @samp{bfd_perform_relocation} to do all relocations when 1195the input and output file have different formats (e.g., when generating 1196S-records). The generic linker code, which is used by all targets which 1197do not define their own special purpose linker, uses 1198@samp{bfd_get_relocated_section_contents}, which for most targets turns 1199into a call to @samp{bfd_generic_get_relocated_section_contents}, which 1200calls @samp{bfd_perform_relocation}. So @samp{bfd_perform_relocation} 1201is still widely used, which makes it difficult to change, since it is 1202difficult to test all possible cases. 1203 1204The assembler used @samp{bfd_perform_relocation} for a while. This 1205turned out to be the wrong thing to do, since 1206@samp{bfd_perform_relocation} was written to handle relocations on an 1207existing object file, while the assembler needed to create relocations 1208in a new object file. The assembler was changed to use the new function 1209@samp{bfd_install_relocation} instead, and @samp{bfd_install_relocation} 1210was created as a copy of @samp{bfd_perform_relocation}. 1211 1212Unfortunately, the work did not progress any farther, so 1213@samp{bfd_install_relocation} remains a simple copy of 1214@samp{bfd_perform_relocation}, with all the odd special cases and 1215confusing code. This again is difficult to change, because again any 1216change can affect any assembler target, and so is difficult to test. 1217 1218The new linker, when using the same object file format for all input 1219files and the output file, does not convert relocations into 1220@samp{arelent} structures, so it can not use 1221@samp{bfd_perform_relocation} at all. Instead, users of the new linker 1222are expected to write a @samp{relocate_section} function which will 1223handle relocations in a target specific fashion. 1224 1225There are two helper functions for target specific relocation: 1226@samp{_bfd_final_link_relocate} and @samp{_bfd_relocate_contents}. 1227These functions use a howto structure, but they @emph{do not} use the 1228@samp{special_function} field. Since the functions are normally called 1229from target specific code, the @samp{special_function} field adds 1230little; any relocations which require special handling can be handled 1231without calling those functions. 1232 1233So, if you want to add a new target, or add a new relocation to an 1234existing target, you need to do the following: 1235 1236@itemize @bullet 1237@item 1238Make sure you clearly understand what the contents of the section should 1239look like after assembly, after a relocateable link, and after a final 1240link. Make sure you clearly understand the operations the linker must 1241perform during a relocateable link and during a final link. 1242 1243@item 1244Write a howto structure for the relocation. The howto structure is 1245flexible enough to represent any relocation which should be handled by 1246setting a contiguous bitfield in the destination to the value of a 1247symbol, possibly with an addend, possibly adding the symbol value to the 1248value already present in the destination. 1249 1250@item 1251Change the assembler to generate your relocation. The assembler will 1252call @samp{bfd_install_relocation}, so your howto structure has to be 1253able to handle that. You may need to set the @samp{special_function} 1254field to handle assembly correctly. Be careful to ensure that any code 1255you write to handle the assembler will also work correctly when doing a 1256relocateable link. For example, see @samp{bfd_elf_generic_reloc}. 1257 1258@item 1259Test the assembler. Consider the cases of relocation against an 1260undefined symbol, a common symbol, a symbol defined in the object file 1261in the same section, and a symbol defined in the object file in a 1262different section. These cases may not all be applicable for your 1263reloc. 1264 1265@item 1266If your target uses the new linker, which is recommended, add any 1267required handling to the target specific relocation function. In simple 1268cases this will just involve a call to @samp{_bfd_final_link_relocate} 1269or @samp{_bfd_relocate_contents}, depending upon the definition of the 1270relocation and whether the link is relocateable or not. 1271 1272@item 1273Test the linker. Test the case of a final link. If the relocation can 1274overflow, use a linker script to force an overflow and make sure the 1275error is reported correctly. Test a relocateable link, whether the 1276symbol is defined or undefined in the relocateable output. For both the 1277final and relocateable link, test the case when the symbol is a common 1278symbol, when the symbol looked like a common symbol but became a defined 1279symbol, when the symbol is defined in a different object file, and when 1280the symbol is defined in the same object file. 1281 1282@item 1283In order for linking to another object file format, such as S-records, 1284to work correctly, @samp{bfd_perform_relocation} has to do the right 1285thing for the relocation. You may need to set the 1286@samp{special_function} field to handle this correctly. Test this by 1287doing a link in which the output object file format is S-records. 1288 1289@item 1290Using the linker to generate relocateable output in a different object 1291file format is impossible in the general case, so you generally don't 1292have to worry about that. Linking input files of different object file 1293formats together is quite unusual, but if you're really dedicated you 1294may want to consider testing this case, both when the output object file 1295format is the same as your format, and when it is different. 1296@end itemize 1297 1298@node BFD relocation codes 1299@subsection BFD relocation codes 1300 1301BFD has another way of describing relocations besides the howto 1302structures described above: the enum @samp{bfd_reloc_code_real_type}. 1303 1304Every known relocation type can be described as a value in this 1305enumeration. The enumeration contains many target specific relocations, 1306but where two or more targets have the same relocation, a single code is 1307used. For example, the single value @samp{BFD_RELOC_32} is used for all 1308simple 32 bit relocation types. 1309 1310The main purpose of this relocation code is to give the assembler some 1311mechanism to create @samp{arelent} structures. In order for the 1312assembler to create an @samp{arelent} structure, it has to be able to 1313obtain a howto structure. The function @samp{bfd_reloc_type_lookup}, 1314which simply calls the target vector entry point 1315@samp{reloc_type_lookup}, takes a relocation code and returns a howto 1316structure. 1317 1318The function @samp{bfd_get_reloc_code_name} returns the name of a 1319relocation code. This is mainly used in error messages. 1320 1321Using both howto structures and relocation codes can be somewhat 1322confusing. There are many processor specific relocation codes. 1323However, the relocation is only fully defined by the howto structure. 1324The same relocation code will map to different howto structures in 1325different object file formats. For example, the addend handling may be 1326different. 1327 1328Most of the relocation codes are not really general. The assembler can 1329not use them without already understanding what sorts of relocations can 1330be used for a particular target. It might be possible to replace the 1331relocation codes with something simpler. 1332 1333@node BFD relocation future 1334@subsection BFD relocation future 1335 1336Clearly the current BFD relocation support is in bad shape. A 1337wholescale rewrite would be very difficult, because it would require 1338thorough testing of every BFD target. So some sort of incremental 1339change is required. 1340 1341My vague thoughts on this would involve defining a new, clearly defined, 1342howto structure. Some mechanism would be used to determine which type 1343of howto structure was being used by a particular format. 1344 1345The new howto structure would clearly define the relocation behaviour in 1346the case of an assembly, a relocateable link, and a final link. At 1347least one special function would be defined as an escape, and it might 1348make sense to define more. 1349 1350One or more generic functions similar to @samp{bfd_perform_relocation} 1351would be written to handle the new howto structure. 1352 1353This should make it possible to write a generic version of the relocate 1354section functions used by the new linker. The target specific code 1355would provide some mechanism (a function pointer or an initial 1356conversion) to convert target specific relocations into howto 1357structures. 1358 1359Ideally it would be possible to use this generic relocate section 1360function for the generic linker as well. That is, it would replace the 1361@samp{bfd_generic_get_relocated_section_contents} function which is 1362currently normally used. 1363 1364For the special case of ELF dynamic linking, more consideration needs to 1365be given to writing ELF specific but ELF target generic code to handle 1366special relocation types such as GOT and PLT. 1367 1368@node BFD ELF support 1369@section BFD ELF support 1370@cindex elf support in bfd 1371@cindex bfd elf support 1372 1373The ELF object file format is defined in two parts: a generic ABI and a 1374processor specific supplement. The ELF support in BFD is split in a 1375similar fashion. The processor specific support is largely kept within 1376a single file. The generic support is provided by several other files. 1377The processor specific support provides a set of function pointers and 1378constants used by the generic support. 1379 1380@menu 1381* BFD ELF sections and segments:: ELF sections and segments 1382* BFD ELF generic support:: BFD ELF generic support 1383* BFD ELF processor specific support:: BFD ELF processor specific support 1384* BFD ELF core files:: BFD ELF core files 1385* BFD ELF future:: BFD ELF future 1386@end menu 1387 1388@node BFD ELF sections and segments 1389@subsection ELF sections and segments 1390 1391The ELF ABI permits a file to have either sections or segments or both. 1392Relocateable object files conventionally have only sections. 1393Executables conventionally have both. Core files conventionally have 1394only program segments. 1395 1396ELF sections are similar to sections in other object file formats: they 1397have a name, a VMA, file contents, flags, and other miscellaneous 1398information. ELF relocations are stored in sections of a particular 1399type; BFD automatically converts these sections into internal relocation 1400information. 1401 1402ELF program segments are intended for fast interpretation by a system 1403loader. They have a type, a VMA, an LMA, file contents, and a couple of 1404other fields. When an ELF executable is run on a Unix system, the 1405system loader will examine the program segments to decide how to load 1406it. The loader will ignore the section information. Loadable program 1407segments (type @samp{PT_LOAD}) are directly loaded into memory. Other 1408program segments are interpreted by the loader, and generally provide 1409dynamic linking information. 1410 1411When an ELF file has both program segments and sections, an ELF program 1412segment may encompass one or more ELF sections, in the sense that the 1413portion of the file which corresponds to the program segment may include 1414the portions of the file corresponding to one or more sections. When 1415there is more than one section in a loadable program segment, the 1416relative positions of the section contents in the file must correspond 1417to the relative positions they should hold when the program segment is 1418loaded. This requirement should be obvious if you consider that the 1419system loader will load an entire program segment at a time. 1420 1421On a system which supports dynamic paging, such as any native Unix 1422system, the contents of a loadable program segment must be at the same 1423offset in the file as in memory, modulo the memory page size used on the 1424system. This is because the system loader will map the file into memory 1425starting at the start of a page. The system loader can easily remap 1426entire pages to the correct load address. However, if the contents of 1427the file were not correctly aligned within the page, the system loader 1428would have to shift the contents around within the page, which is too 1429expensive. For example, if the LMA of a loadable program segment is 1430@samp{0x40080} and the page size is @samp{0x1000}, then the position of 1431the segment contents within the file must equal @samp{0x80} modulo 1432@samp{0x1000}. 1433 1434BFD has only a single set of sections. It does not provide any generic 1435way to examine both sections and segments. When BFD is used to open an 1436object file or executable, the BFD sections will represent ELF sections. 1437When BFD is used to open a core file, the BFD sections will represent 1438ELF program segments. 1439 1440When BFD is used to examine an object file or executable, any program 1441segments will be read to set the LMA of the sections. This is because 1442ELF sections only have a VMA, while ELF program segments have both a VMA 1443and an LMA. Any program segments will be copied by the 1444@samp{copy_private} entry points. They will be printed by the 1445@samp{print_private} entry point. Otherwise, the program segments are 1446ignored. In particular, programs which use BFD currently have no direct 1447access to the program segments. 1448 1449When BFD is used to create an executable, the program segments will be 1450created automatically based on the section information. This is done in 1451the function @samp{assign_file_positions_for_segments} in @file{elf.c}. 1452This function has been tweaked many times, and probably still has 1453problems that arise in particular cases. 1454 1455There is a hook which may be used to explicitly define the program 1456segments when creating an executable: the @samp{bfd_record_phdr} 1457function in @file{bfd.c}. If this function is called, BFD will not 1458create program segments itself, but will only create the program 1459segments specified by the caller. The linker uses this function to 1460implement the @samp{PHDRS} linker script command. 1461 1462@node BFD ELF generic support 1463@subsection BFD ELF generic support 1464 1465In general, functions which do not read external data from the ELF file 1466are found in @file{elf.c}. They operate on the internal forms of the 1467ELF structures, which are defined in @file{include/elf/internal.h}. The 1468internal structures are defined in terms of @samp{bfd_vma}, and so may 1469be used for both 32 bit and 64 bit ELF targets. 1470 1471The file @file{elfcode.h} contains functions which operate on the 1472external data. @file{elfcode.h} is compiled twice, once via 1473@file{elf32.c} with @samp{ARCH_SIZE} defined as @samp{32}, and once via 1474@file{elf64.c} with @samp{ARCH_SIZE} defined as @samp{64}. 1475@file{elfcode.h} includes functions to swap the ELF structures in and 1476out of external form, as well as a few more complex functions. 1477 1478Linker support is found in @file{elflink.c} and @file{elflink.h}. The 1479latter file is compiled twice, for both 32 and 64 bit support. The 1480linker support is only used if the processor specific file defines 1481@samp{elf_backend_relocate_section}, which is required to relocate the 1482section contents. If that macro is not defined, the generic linker code 1483is used, and relocations are handled via @samp{bfd_perform_relocation}. 1484 1485The core file support is in @file{elfcore.h}, which is compiled twice, 1486for both 32 and 64 bit support. The more interesting cases of core file 1487support only work on a native system which has the @file{sys/procfs.h} 1488header file. Without that file, the core file support does little more 1489than read the ELF program segments as BFD sections. 1490 1491The BFD internal header file @file{elf-bfd.h} is used for communication 1492among these files and the processor specific files. 1493 1494The default entries for the BFD ELF target vector are found mainly in 1495@file{elf.c}. Some functions are found in @file{elfcode.h}. 1496 1497The processor specific files may override particular entries in the 1498target vector, but most do not, with one exception: the 1499@samp{bfd_reloc_type_lookup} entry point is always processor specific. 1500 1501@node BFD ELF processor specific support 1502@subsection BFD ELF processor specific support 1503 1504By convention, the processor specific support for a particular processor 1505will be found in @file{elf@var{nn}-@var{cpu}.c}, where @var{nn} is 1506either 32 or 64, and @var{cpu} is the name of the processor. 1507 1508@menu 1509* BFD ELF processor required:: Required processor specific support 1510* BFD ELF processor linker:: Processor specific linker support 1511* BFD ELF processor other:: Other processor specific support options 1512@end menu 1513 1514@node BFD ELF processor required 1515@subsubsection Required processor specific support 1516 1517When writing a @file{elf@var{nn}-@var{cpu}.c} file, you must do the 1518following: 1519 1520@itemize @bullet 1521@item 1522Define either @samp{TARGET_BIG_SYM} or @samp{TARGET_LITTLE_SYM}, or 1523both, to a unique C name to use for the target vector. This name should 1524appear in the list of target vectors in @file{targets.c}, and will also 1525have to appear in @file{config.bfd} and @file{configure.in}. Define 1526@samp{TARGET_BIG_SYM} for a big-endian processor, 1527@samp{TARGET_LITTLE_SYM} for a little-endian processor, and define both 1528for a bi-endian processor. 1529@item 1530Define either @samp{TARGET_BIG_NAME} or @samp{TARGET_LITTLE_NAME}, or 1531both, to a string used as the name of the target vector. This is the 1532name which a user of the BFD tool would use to specify the object file 1533format. It would normally appear in a linker emulation parameters 1534file. 1535@item 1536Define @samp{ELF_ARCH} to the BFD architecture (an element of the 1537@samp{bfd_architecture} enum, typically @samp{bfd_arch_@var{cpu}}). 1538@item 1539Define @samp{ELF_MACHINE_CODE} to the magic number which should appear 1540in the @samp{e_machine} field of the ELF header. As of this writing, 1541these magic numbers are assigned by SCO; if you want to get a magic 1542number for a particular processor, try sending a note to 1543@email{registry@@sco.com}. In the BFD sources, the magic numbers are 1544found in @file{include/elf/common.h}; they have names beginning with 1545@samp{EM_}. 1546@item 1547Define @samp{ELF_MAXPAGESIZE} to the maximum size of a virtual page in 1548memory. This can normally be found at the start of chapter 5 in the 1549processor specific supplement. For a processor which will only be used 1550in an embedded system, or which has no memory management hardware, this 1551can simply be @samp{1}. 1552@item 1553If the format should use @samp{Rel} rather than @samp{Rela} relocations, 1554define @samp{USE_REL}. This is normally defined in chapter 4 of the 1555processor specific supplement. 1556 1557In the absence of a supplement, it's easier to work with @samp{Rela} 1558relocations. @samp{Rela} relocations will require more space in object 1559files (but not in executables, except when using dynamic linking). 1560However, this is outweighed by the simplicity of addend handling when 1561using @samp{Rela} relocations. With @samp{Rel} relocations, the addend 1562must be stored in the section contents, which makes relocateable links 1563more complex. 1564 1565For example, consider C code like @code{i = a[1000];} where @samp{a} is 1566a global array. The instructions which load the value of @samp{a[1000]} 1567will most likely use a relocation which refers to the symbol 1568representing @samp{a}, with an addend that gives the offset from the 1569start of @samp{a} to element @samp{1000}. When using @samp{Rel} 1570relocations, that addend must be stored in the instructions themselves. 1571If you are adding support for a RISC chip which uses two or more 1572instructions to load an address, then the addend may not fit in a single 1573instruction, and will have to be somehow split among the instructions. 1574This makes linking awkward, particularly when doing a relocateable link 1575in which the addend may have to be updated. It can be done---the MIPS 1576ELF support does it---but it should be avoided when possible. 1577 1578It is possible, though somewhat awkward, to support both @samp{Rel} and 1579@samp{Rela} relocations for a single target; @file{elf64-mips.c} does it 1580by overriding the relocation reading and writing routines. 1581@item 1582Define howto structures for all the relocation types. 1583@item 1584Define a @samp{bfd_reloc_type_lookup} routine. This must be named 1585@samp{bfd_elf@var{nn}_bfd_reloc_type_lookup}, and may be either a 1586function or a macro. It must translate a BFD relocation code into a 1587howto structure. This is normally a table lookup or a simple switch. 1588@item 1589If using @samp{Rel} relocations, define @samp{elf_info_to_howto_rel}. 1590If using @samp{Rela} relocations, define @samp{elf_info_to_howto}. 1591Either way, this is a macro defined as the name of a function which 1592takes an @samp{arelent} and a @samp{Rel} or @samp{Rela} structure, and 1593sets the @samp{howto} field of the @samp{arelent} based on the 1594@samp{Rel} or @samp{Rela} structure. This is normally uses 1595@samp{ELF@var{nn}_R_TYPE} to get the ELF relocation type and uses it as 1596an index into a table of howto structures. 1597@end itemize 1598 1599You must also add the magic number for this processor to the 1600@samp{prep_headers} function in @file{elf.c}. 1601 1602You must also create a header file in the @file{include/elf} directory 1603called @file{@var{cpu}.h}. This file should define any target specific 1604information which may be needed outside of the BFD code. In particular 1605it should use the @samp{START_RELOC_NUMBERS}, @samp{RELOC_NUMBER}, 1606@samp{FAKE_RELOC}, @samp{EMPTY_RELOC} and @samp{END_RELOC_NUMBERS} 1607macros to create a table mapping the number used to indentify a 1608relocation to a name describing that relocation. 1609 1610@node BFD ELF processor linker 1611@subsubsection Processor specific linker support 1612 1613The linker will be much more efficient if you define a relocate section 1614function. This will permit BFD to use the ELF specific linker support. 1615 1616If you do not define a relocate section function, BFD must use the 1617generic linker support, which requires converting all symbols and 1618relocations into BFD @samp{asymbol} and @samp{arelent} structures. In 1619this case, relocations will be handled by calling 1620@samp{bfd_perform_relocation}, which will use the howto structures you 1621have defined. @xref{BFD relocation handling}. 1622 1623In order to support linking into a different object file format, such as 1624S-records, @samp{bfd_perform_relocation} must work correctly with your 1625howto structures, so you can't skip that step. However, if you define 1626the relocate section function, then in the normal case of linking into 1627an ELF file the linker will not need to convert symbols and relocations, 1628and will be much more efficient. 1629 1630To use a relocation section function, define the macro 1631@samp{elf_backend_relocate_section} as the name of a function which will 1632take the contents of a section, as well as relocation, symbol, and other 1633information, and modify the section contents according to the relocation 1634information. In simple cases, this is little more than a loop over the 1635relocations which computes the value of each relocation and calls 1636@samp{_bfd_final_link_relocate}. The function must check for a 1637relocateable link, and in that case normally needs to do nothing other 1638than adjust the addend for relocations against a section symbol. 1639 1640The complex cases generally have to do with dynamic linker support. GOT 1641and PLT relocations must be handled specially, and the linker normally 1642arranges to set up the GOT and PLT sections while handling relocations. 1643When generating a shared library, random relocations must normally be 1644copied into the shared library, or converted to RELATIVE relocations 1645when possible. 1646 1647@node BFD ELF processor other 1648@subsubsection Other processor specific support options 1649 1650There are many other macros which may be defined in 1651@file{elf@var{nn}-@var{cpu}.c}. These macros may be found in 1652@file{elfxx-target.h}. 1653 1654Macros may be used to override some of the generic ELF target vector 1655functions. 1656 1657Several processor specific hook functions which may be defined as 1658macros. These functions are found as function pointers in the 1659@samp{elf_backend_data} structure defined in @file{elf-bfd.h}. In 1660general, a hook function is set by defining a macro 1661@samp{elf_backend_@var{name}}. 1662 1663There are a few processor specific constants which may also be defined. 1664These are again found in the @samp{elf_backend_data} structure. 1665 1666I will not define the various functions and constants here; see the 1667comments in @file{elf-bfd.h}. 1668 1669Normally any odd characteristic of a particular ELF processor is handled 1670via a hook function. For example, the special @samp{SHN_MIPS_SCOMMON} 1671section number found in MIPS ELF is handled via the hooks 1672@samp{section_from_bfd_section}, @samp{symbol_processing}, 1673@samp{add_symbol_hook}, and @samp{output_symbol_hook}. 1674 1675Dynamic linking support, which involves processor specific relocations 1676requiring special handling, is also implemented via hook functions. 1677 1678@node BFD ELF core files 1679@subsection BFD ELF core files 1680@cindex elf core files 1681 1682On native ELF Unix systems, core files are generated without any 1683sections. Instead, they only have program segments. 1684 1685When BFD is used to read an ELF core file, the BFD sections will 1686actually represent program segments. Since ELF program segments do not 1687have names, BFD will invent names like @samp{segment@var{n}} where 1688@var{n} is a number. 1689 1690A single ELF program segment may include both an initialized part and an 1691uninitialized part. The size of the initialized part is given by the 1692@samp{p_filesz} field. The total size of the segment is given by the 1693@samp{p_memsz} field. If @samp{p_memsz} is larger than @samp{p_filesz}, 1694then the extra space is uninitialized, or, more precisely, initialized 1695to zero. 1696 1697BFD will represent such a program segment as two different sections. 1698The first, named @samp{segment@var{n}a}, will represent the initialized 1699part of the program segment. The second, named @samp{segment@var{n}b}, 1700will represent the uninitialized part. 1701 1702ELF core files store special information such as register values in 1703program segments with the type @samp{PT_NOTE}. BFD will attempt to 1704interpret the information in these segments, and will create additional 1705sections holding the information. Some of this interpretation requires 1706information found in the host header file @file{sys/procfs.h}, and so 1707will only work when BFD is built on a native system. 1708 1709BFD does not currently provide any way to create an ELF core file. In 1710general, BFD does not provide a way to create core files. The way to 1711implement this would be to write @samp{bfd_set_format} and 1712@samp{bfd_write_contents} routines for the @samp{bfd_core} type; see 1713@ref{BFD target vector format}. 1714 1715@node BFD ELF future 1716@subsection BFD ELF future 1717 1718The current dynamic linking support has too much code duplication. 1719While each processor has particular differences, much of the dynamic 1720linking support is quite similar for each processor. The GOT and PLT 1721are handled in fairly similar ways, the details of -Bsymbolic linking 1722are generally similar, etc. This code should be reworked to use more 1723generic functions, eliminating the duplication. 1724 1725Similarly, the relocation handling has too much duplication. Many of 1726the @samp{reloc_type_lookup} and @samp{info_to_howto} functions are 1727quite similar. The relocate section functions are also often quite 1728similar, both in the standard linker handling and the dynamic linker 1729handling. Many of the COFF processor specific backends share a single 1730relocate section function (@samp{_bfd_coff_generic_relocate_section}), 1731and it should be possible to do something like this for the ELF targets 1732as well. 1733 1734The appearance of the processor specific magic number in 1735@samp{prep_headers} in @file{elf.c} is somewhat bogus. It should be 1736possible to add support for a new processor without changing the generic 1737support. 1738 1739The processor function hooks and constants are ad hoc and need better 1740documentation. 1741 1742When a linker script uses @samp{SIZEOF_HEADERS}, the ELF backend must 1743guess at the number of program segments which will be required, in 1744@samp{get_program_header_size}. This is because the linker calls 1745@samp{bfd_sizeof_headers} before it knows all the section addresses and 1746sizes. The ELF backend may later discover, when creating program 1747segments, that more program segments are required. This is currently 1748reported as an error in @samp{assign_file_positions_for_segments}. 1749 1750In practice this makes it difficult to use @samp{SIZEOF_HEADERS} except 1751with a carefully defined linker script. Unfortunately, 1752@samp{SIZEOF_HEADERS} is required for fast program loading on a native 1753system, since it permits the initial code section to appear on the same 1754page as the program segments, saving a page read when the program starts 1755running. Fortunately, native systems permit careful definition of the 1756linker script. Still, ideally it would be possible to use relaxation to 1757compute the number of program segments. 1758 1759@node BFD glossary 1760@section BFD glossary 1761@cindex glossary for bfd 1762@cindex bfd glossary 1763 1764This is a short glossary of some BFD terms. 1765 1766@table @asis 1767@item a.out 1768The a.out object file format. The original Unix object file format. 1769Still used on SunOS, though not Solaris. Supports only three sections. 1770 1771@item archive 1772A collection of object files produced and manipulated by the @samp{ar} 1773program. 1774 1775@item backend 1776The implementation within BFD of a particular object file format. The 1777set of functions which appear in a particular target vector. 1778 1779@item BFD 1780The BFD library itself. Also, each object file, archive, or exectable 1781opened by the BFD library has the type @samp{bfd *}, and is sometimes 1782referred to as a bfd. 1783 1784@item COFF 1785The Common Object File Format. Used on Unix SVR3. Used by some 1786embedded targets, although ELF is normally better. 1787 1788@item DLL 1789A shared library on Windows. 1790 1791@item dynamic linker 1792When a program linked against a shared library is run, the dynamic 1793linker will locate the appropriate shared library and arrange to somehow 1794include it in the running image. 1795 1796@item dynamic object 1797Another name for an ELF shared library. 1798 1799@item ECOFF 1800The Extended Common Object File Format. Used on Alpha Digital Unix 1801(formerly OSF/1), as well as Ultrix and Irix 4. A variant of COFF. 1802 1803@item ELF 1804The Executable and Linking Format. The object file format used on most 1805modern Unix systems, including GNU/Linux, Solaris, Irix, and SVR4. Also 1806used on many embedded systems. 1807 1808@item executable 1809A program, with instructions and symbols, and perhaps dynamic linking 1810information. Normally produced by a linker. 1811 1812@item LMA 1813Load Memory Address. This is the address at which a section will be 1814loaded. Compare with VMA, below. 1815 1816@item NLM 1817NetWare Loadable Module. Used to describe the format of an object which 1818be loaded into NetWare, which is some kind of PC based network server 1819program. 1820 1821@item object file 1822A binary file including machine instructions, symbols, and relocation 1823information. Normally produced by an assembler. 1824 1825@item object file format 1826The format of an object file. Typically object files and executables 1827for a particular system are in the same format, although executables 1828will not contain any relocation information. 1829 1830@item PE 1831The Portable Executable format. This is the object file format used for 1832Windows (specifically, Win32) object files. It is based closely on 1833COFF, but has a few significant differences. 1834 1835@item PEI 1836The Portable Executable Image format. This is the object file format 1837used for Windows (specifically, Win32) executables. It is very similar 1838to PE, but includes some additional header information. 1839 1840@item relocations 1841Information used by the linker to adjust section contents. Also called 1842relocs. 1843 1844@item section 1845Object files and executable are composed of sections. Sections have 1846optional data and optional relocation information. 1847 1848@item shared library 1849A library of functions which may be used by many executables without 1850actually being linked into each executable. There are several different 1851implementations of shared libraries, each having slightly different 1852features. 1853 1854@item symbol 1855Each object file and executable may have a list of symbols, often 1856referred to as the symbol table. A symbol is basically a name and an 1857address. There may also be some additional information like the type of 1858symbol, although the type of a symbol is normally something simple like 1859function or object, and should be confused with the more complex C 1860notion of type. Typically every global function and variable in a C 1861program will have an associated symbol. 1862 1863@item target vector 1864A set of functions which implement support for a particular object file 1865format. The @samp{bfd_target} structure. 1866 1867@item Win32 1868The current Windows API, implemented by Windows 95 and later and Windows 1869NT 3.51 and later, but not by Windows 3.1. 1870 1871@item XCOFF 1872The eXtended Common Object File Format. Used on AIX. A variant of 1873COFF, with a completely different symbol table implementation. 1874 1875@item VMA 1876Virtual Memory Address. This is the address a section will have when 1877an executable is run. Compare with LMA, above. 1878@end table 1879 1880@node Index 1881@unnumberedsec Index 1882@printindex cp 1883 1884@contents 1885@bye 1886