@section coff backendsBFD supports a number of different flavours of coff format.The major differences between formats are the sizes andalignments of fields in structures on disk, and the occasionalextra field. Coff in all its varieties is implemented with a few commonfiles and a number of implementation specific files. Forexample, the i386 coff format is implemented in the file@file{coff-i386.c}.  This file @code{#include}s@file{coff/i386.h} which defines the external structure of thecoff format for the i386, and @file{coff/internal.h} whichdefines the internal structure. @file{coff-i386.c} alsodefines the relocations used by the i386 coff format@xref{Relocations}. @subsection Porting to a new version of coffThe recommended method is to select from the existingimplementations the version of coff which is most like the oneyou want to use.  For example, we'll say that i386 coff isthe one you select, and that your coff flavour is called foo.Copy @file{i386coff.c} to @file{foocoff.c}, copy@file{../include/coff/i386.h} to @file{../include/coff/foo.h},and add the lines to @file{targets.c} and @file{Makefile.in}so that your new back end is used. Alter the shapes of thestructures in @file{../include/coff/foo.h} so that they matchwhat you need. You will probably also have to add@code{#ifdef}s to the code in @file{coff/internal.h} and@file{coffcode.h} if your version of coff is too wild. You can verify that your new BFD backend works quite simply bybuilding @file{objdump} from the @file{binutils} directory,and making sure that its version of what's going on and yourhost system's idea (assuming it has the pretty standard coffdump utility, usually called @code{att-dump} or just@code{dump}) are the same.  Then clean up your code, and sendwhat you've done to Cygnus. Then your stuff will be in thenext release, and you won't have to keep integrating it. @subsection How the coff backend works  @subsubsection File layoutThe Coff backend is split into generic routines that areapplicable to any Coff target and routines that are specificto a particular target.  The target-specific routines arefurther split into ones which are basically the same for allCoff targets except that they use the external symbol formator use different values for certain constants. The generic routines are in @file{coffgen.c}.  These routineswork for any Coff target.  They use some hooks into the targetspecific code; the hooks are in a @code{bfd_coff_backend_data}structure, one of which exists for each target. The essentially similar target-specific routines are in@file{coffcode.h}.  This header file includes executable C code.The various Coff targets first include the appropriate Coffheader file, make any special defines that are needed, andthen include @file{coffcode.h}. Some of the Coff targets then also have additional routines inthe target source file itself. @subsubsection Coff long section namesIn the standard Coff object format, section names are limited tothe eight bytes available in the @code{s_name} field of the@code{SCNHDR} section header structure.  The format requires thefield to be NUL-padded, but not necessarily NUL-terminated, sothe longest section names permitted are a full eight characters. The Microsoft PE variants of the Coff object file format addan extension to support the use of long section names.  Thisextension is defined in section 4 of the Microsoft PE/COFFspecification (rev 8.1).  If a section name is too long to fitinto the section header's @code{s_name} field, it is insteadplaced into the string table, and the @code{s_name} field isfilled with a slash ("/") followed by the ASCII decimalrepresentation of the offset of the full name relative to thestring table base. Note that this implies that the extension can only be used in objectfiles, as executables do not contain a string table.  The standardspecifies that long section names from objects emitted into executableimages are to be truncated. However, as a GNU extension, BFD can generate executable imagesthat contain a string table and long section names.  Thiswould appear to be technically valid, as the standard only saysthat Coff debugging information is deprecated, not forbidden,and in practice it works, although some tools that parse PE filesexpecting the MS standard format may become confused; @file{PEview} isone known example. The functionality is supported in BFD by code implemented underthe control of the macro @code{COFF_LONG_SECTION_NAMES}.  If notdefined, the format does not support long section names in any way.If defined, it is used to initialise a flag,@code{_bfd_coff_long_section_names}, and a hook function pointer,@code{_bfd_coff_set_long_section_names}, in the Coff backend datastructure.  The flag controls the generation of long section namesin output BFDs at runtime; if it is false, as it will be by defaultwhen generating an executable image, long section names are truncated;if true, the long section names extension is employed.  The hookpoints to a function that allows the value of a copy of the flagin coff object tdata to be altered at runtime, on formats thatsupport long section names at all; on other formats it pointsto a stub that returns an error indication. With input BFDs, the flag is set according to whether any long sectionnames are detected while reading the section headers.  For a completelynew BFD, the flag is set to the default for the target format.  Thisinformation can be used by a client of the BFD library when decidingwhat output format to generate, and means that a BFD that is openedfor read and subsequently converted to a writeable BFD and modifiedin-place will retain whatever format it had on input. If @code{COFF_LONG_SECTION_NAMES} is simply defined (blank), or isdefined to the value "1", then long section names are enabled bydefault; if it is defined to the value zero, they are disabled bydefault (but still accepted in input BFDs).  The header @file{coffcode.h}defines a macro, @code{COFF_DEFAULT_LONG_SECTION_NAMES}, which isused in the backends to initialise the backend data structure fieldsappropriately; see the comments for further detail. @subsubsection Bit twiddlingEach flavour of coff supported in BFD has its own header filedescribing the external layout of the structures. There is alsoan internal description of the coff layout, in@file{coff/internal.h}. A major function of thecoff backend is swapping the bytes and twiddling the bits totranslate the external form of the structures into the normalinternal form. This is all performed in the@code{bfd_swap}_@i{thing}_@i{direction} routines. Someelements are different sizes between different versions ofcoff; it is the duty of the coff version specific include fileto override the definitions of various packing routines in@file{coffcode.h}. E.g., the size of line number entry in coff issometimes 16 bits, and sometimes 32 bits. @code{#define}ing@code{PUT_LNSZ_LNNO} and @code{GET_LNSZ_LNNO} will select thecorrect one. No doubt, some day someone will find a version ofcoff which has a varying field size not catered to at themoment. To port BFD, that person will have to add more @code{#defines}.Three of the bit twiddling routines are exported to@code{gdb}; @code{coff_swap_aux_in}, @code{coff_swap_sym_in}and @code{coff_swap_lineno_in}. @code{GDB} reads the symboltable on its own, but uses BFD to fix things up.  More of thebit twiddlers are exported for @code{gas};@code{coff_swap_aux_out}, @code{coff_swap_sym_out},@code{coff_swap_lineno_out}, @code{coff_swap_reloc_out},@code{coff_swap_filehdr_out}, @code{coff_swap_aouthdr_out},@code{coff_swap_scnhdr_out}. @code{Gas} currently keeps trackof all the symbol table and reloc drudgery itself, therebysaving the internal BFD overhead, but uses BFD to swap thingson the way out, making cross ports much safer.  Doing so alsoallows BFD (and thus the linker) to use the same header filesas @code{gas}, which makes one avenue to disaster disappear. @subsubsection Symbol readingThe simple canonical form for symbols used by BFD is not richenough to keep all the information available in a coff symboltable. The back end gets around this problem by keeping the originalsymbol table around, "behind the scenes". When a symbol table is requested (through a call to@code{bfd_canonicalize_symtab}), a request gets through to@code{coff_get_normalized_symtab}. This reads the symbol table fromthe coff file and swaps all the structures inside into theinternal form. It also fixes up all the pointers in the table(represented in the file by offsets from the first symbol inthe table) into physical pointers to elements in the newinternal table. This involves some work since the meanings offields change depending upon context: a field that is apointer to another structure in the symbol table at one momentmay be the size in bytes of a structure at the next.  Anotherpass is made over the table. All symbols which mark file names(@code{C_FILE} symbols) are modified so that the internalstring points to the value in the auxent (the real filename)rather than the normal text associated with the symbol(@code{".file"}). At this time the symbol names are moved around. Coff storesall symbols less than nine characters long physicallywithin the symbol table; longer strings are kept at the end ofthe file in the string table. This pass moves all stringsinto memory and replaces them with pointers to the strings. The symbol table is massaged once again, this time to createthe canonical table used by the BFD application. Each symbolis inspected in turn, and a decision made (using the@code{sclass} field) about the various flags to set in the@code{asymbol}.  @xref{Symbols}. The generated canonical tableshares strings with the hidden internal symbol table. Any linenumbers are read from the coff file too, and attachedto the symbols which own the functions the linenumbers belong to. @subsubsection Symbol writingWriting a symbol to a coff file which didn't come from a cofffile will lose any debugging information. The @code{asymbol}structure remembers the BFD from which the symbol was taken, and onoutput the back end makes sure that the same destination target assource target is present. When the symbols have come from a coff file then all thedebugging information is preserved. Symbol tables are provided for writing to the back end in avector of pointers to pointers. This allows applications likethe linker to accumulate and output large symbol tableswithout having to do too much byte copying. This function runs through the provided symbol table andpatches each symbol marked as a file place holder(@code{C_FILE}) to point to the next file place holder in thelist. It also marks each @code{offset} field in the list withthe offset from the first symbol of the current symbol. Another function of this procedure is to turn the canonicalvalue form of BFD into the form used by coff. Internally, BFDexpects symbol values to be offsets from a section base; so asymbol physically at 0x120, but in a section starting at0x100, would have the value 0x20. Coff expects symbols tocontain their final value, so symbols have their valueschanged at this point to reflect their sum with their owningsection.  This transformation uses the@code{output_section} field of the @code{asymbol}'s@code{asection} @xref{Sections}. @itemize @bullet @item@code{coff_mangle_symbols}@end itemizeThis routine runs though the provided symbol table and usesthe offsets generated by the previous pass and the pointersgenerated when the symbol table was read in to create thestructured hierarchy required by coff. It changes each pointerto a symbol into the index into the symbol table of the asymbol. @itemize @bullet @item@code{coff_write_symbols}@end itemizeThis routine runs through the symbol table and patches up thesymbols from their internal form into the coff way, calls thebit twiddlers, and writes out the table to the file. @findex coff_symbol_type@subsubsection @code{coff_symbol_type}The hidden information for an @code{asymbol} is described in a@code{combined_entry_type}:  @exampletypedef struct coff_ptr_struct@{  /* Remembers the offset from the first symbol in the file for     this symbol.  Generated by coff_renumber_symbols.  */  unsigned int offset;   /* Selects between the elements of the union below.  */  unsigned int is_sym : 1;   /* Selects between the elements of the x_sym.x_tagndx union.  If set,     p is valid and the field will be renumbered.  */  unsigned int fix_tag : 1;   /* Selects between the elements of the x_sym.x_fcnary.x_fcn.x_endndx     union.  If set, p is valid and the field will be renumbered.  */  unsigned int fix_end : 1;   /* Selects between the elements of the x_csect.x_scnlen union.  If set,     p is valid and the field will be renumbered.  */  unsigned int fix_scnlen : 1;   /* If set, u.syment.n_value contains a pointer to a symbol.  The final     value will be the offset field.  Used for XCOFF C_BSTAT symbols.  */  unsigned int fix_value : 1;   /* If set, u.syment.n_value is an index into the line number entries.     Used for XCOFF C_BINCL/C_EINCL symbols.  */  unsigned int fix_line : 1;   /* The container for the symbol structure as read and translated     from the file.  */  union  @{    union internal_auxent auxent;    struct internal_syment syment;  @} u;  /* An extra pointer which can used by format based on COFF (like XCOFF)    to provide extra information to their backend.  */ void *extrap;@} combined_entry_type; /* Each canonical asymbol really looks like this: */ typedef struct coff_symbol_struct@{  /* The actual symbol which the rest of BFD works with */  asymbol symbol;   /* A pointer to the hidden information for this symbol */  combined_entry_type *native;   /* A pointer to the linenumber information for this symbol */  struct lineno_cache_entry *lineno;   /* Have the line numbers been relocated yet ? */  bool done_lineno;@} coff_symbol_type; @end example@findex bfd_coff_backend_data@subsubsection @code{bfd_coff_backend_data} @exampletypedef struct@{  void (*_bfd_coff_swap_aux_in)    (bfd *, void *, int, int, int, int, void *);   void (*_bfd_coff_swap_sym_in)    (bfd *, void *, void *);   void (*_bfd_coff_swap_lineno_in)    (bfd *, void *, void *);   unsigned int (*_bfd_coff_swap_aux_out)    (bfd *, void *, int, int, int, int, void *);   unsigned int (*_bfd_coff_swap_sym_out)    (bfd *, void *, void *);   unsigned int (*_bfd_coff_swap_lineno_out)    (bfd *, void *, void *);   unsigned int (*_bfd_coff_swap_reloc_out)    (bfd *, void *, void *);   unsigned int (*_bfd_coff_swap_filehdr_out)    (bfd *, void *, void *);   unsigned int (*_bfd_coff_swap_aouthdr_out)    (bfd *, void *, void *);   unsigned int (*_bfd_coff_swap_scnhdr_out)    (bfd *, void *, void *, const asection *);   unsigned int _bfd_filhsz;  unsigned int _bfd_aoutsz;  unsigned int _bfd_scnhsz;  unsigned int _bfd_symesz;  unsigned int _bfd_auxesz;  unsigned int _bfd_relsz;  unsigned int _bfd_linesz;  unsigned int _bfd_filnmlen;  bool _bfd_coff_long_filenames;   bool _bfd_coff_long_section_names;  bool (*_bfd_coff_set_long_section_names)    (bfd *, int);   unsigned int _bfd_coff_default_section_alignment_power;  bool _bfd_coff_force_symnames_in_strings;  unsigned int _bfd_coff_debug_string_prefix_length;  unsigned int _bfd_coff_max_nscns;   void (*_bfd_coff_swap_filehdr_in)    (bfd *, void *, void *);   void (*_bfd_coff_swap_aouthdr_in)    (bfd *, void *, void *);   void (*_bfd_coff_swap_scnhdr_in)    (bfd *, void *, void *);   void (*_bfd_coff_swap_reloc_in)    (bfd *abfd, void *, void *);   bool (*_bfd_coff_bad_format_hook)    (bfd *, void *);   bool (*_bfd_coff_set_arch_mach_hook)    (bfd *, void *);   void * (*_bfd_coff_mkobject_hook)    (bfd *, void *, void *);   bool (*_bfd_styp_to_sec_flags_hook)    (bfd *, void *, const char *, asection *, flagword *);   void (*_bfd_set_alignment_hook)    (bfd *, asection *, void *);   bool (*_bfd_coff_slurp_symbol_table)    (bfd *);   bool (*_bfd_coff_symname_in_debug)    (bfd *, struct internal_syment *);   bool (*_bfd_coff_pointerize_aux_hook)    (bfd *, combined_entry_type *, combined_entry_type *,     unsigned int, combined_entry_type *);   bool (*_bfd_coff_print_aux)    (bfd *, FILE *, combined_entry_type *, combined_entry_type *,     combined_entry_type *, unsigned int);   bool (*_bfd_coff_reloc16_extra_cases)    (bfd *, struct bfd_link_info *, struct bfd_link_order *, arelent *,     bfd_byte *, size_t *, size_t *);   int (*_bfd_coff_reloc16_estimate)    (bfd *, asection *, arelent *, unsigned int,     struct bfd_link_info *);   enum coff_symbol_classification (*_bfd_coff_classify_symbol)    (bfd *, struct internal_syment *);   bool (*_bfd_coff_compute_section_file_positions)    (bfd *);   bool (*_bfd_coff_start_final_link)    (bfd *, struct bfd_link_info *);   bool (*_bfd_coff_relocate_section)    (bfd *, struct bfd_link_info *, bfd *, asection *, bfd_byte *,     struct internal_reloc *, struct internal_syment *, asection **);   reloc_howto_type *(*_bfd_coff_rtype_to_howto)    (bfd *, asection *, struct internal_reloc *,     struct coff_link_hash_entry *, struct internal_syment *, bfd_vma *);   bool (*_bfd_coff_adjust_symndx)    (bfd *, struct bfd_link_info *, bfd *, asection *,     struct internal_reloc *, bool *);   bool (*_bfd_coff_link_output_has_begun)    (bfd *, struct coff_final_link_info *);   bool (*_bfd_coff_final_link_postscript)    (bfd *, struct coff_final_link_info *);   bool (*_bfd_coff_print_pdata)    (bfd *, void *); @} bfd_coff_backend_data; @end example@subsubsection Writing relocationsTo write relocations, the back end steps though thecanonical relocation table and create an@code{internal_reloc}. The symbol index to use is removed fromthe @code{offset} field in the symbol table supplied.  Theaddress comes directly from the sum of the section baseaddress and the relocation offset; the type is dug directlyfrom the howto field.  Then the @code{internal_reloc} isswapped into the shape of an @code{external_reloc} and writtenout to disk. @subsubsection Reading linenumbersCreating the linenumber table is done by reading in the entirecoff linenumber table, and creating another table for internal use. A coff linenumber table is structured so that each functionis marked as having a line number of 0. Each line within thefunction is an offset from the first line in the function. Thebase of the line number information for the table is stored inthe symbol associated with the function. Note: The PE format uses line number 0 for a flag indicating anew source file. The information is copied from the external to the internaltable, and each symbol which marks a function is marked bypointing its... How does this work ? @subsubsection Reading relocationsCoff relocations are easily transformed into the internal BFD form(@code{arelent}). Reading a coff relocation table is done in the following stages: @itemize @bullet @itemRead the entire coff relocation table into memory. @itemProcess each relocation in turn; first swap it from theexternal to the internal form. @itemTurn the symbol referenced in the relocation's symbol index

Lines 1–500 of 521. Load more