Lines Matching full:coff
67 Intel Oregon, for interoperability of applications on their COFF and
77 coff.
127 coff, but loses efficiency when applied to formats such as S-records and
175 Another example is COFF section names. COFF files may contain an
201 linking or copying big endian COFF to little endian COFF, or `a.out' to
251 This information would be useless to most COFF debuggers; the
256 example, COFF, IEEE, Oasys) and the type is simple enough to fit
271 byte being written to a 68k COFF file, even though 68k COFF has no
285 formats (COFF, IEEE and Oasys).
1109 Names need not be unique; for example a COFF file may have several
1359 /* The section is a COFF shared library section. This flag is
1363 was originally intended to be general, it really is COFF
1371 executables or shared objects. This is for COFF only. */
1459 SEC_MERGE, some coff relaxing targets), and thus the original size
2024 end knows about. For example, the coff back end keeps the original
2026 read in. On output, the coff back end can reconstruct the output symbol
2027 table so that no information is lost, even information unique to coff
2028 which BFD doesn't know or understand. If a coff symbol table were read,
2029 but were written through an a.out back end, all the coff specific
2231 location in an output file - ie in coff a `ISFCN' symbol
2474 different formats (e.g., a.out and coff) and even different
2478 more expressive than others. For instance, Intel COFF archives can
2679 generated only when linking i960 coff files with i960 b.out
2757 Using coff and an 88k, some instructions don't have enough space in
2856 in a coff environment has the type 023 - because that's
3030 record. Some native formats (e.g., basic a.out and basic coff) have no
5451 when creating COFF files. */
7385 * coff :: coff backends
7395 File: bfd.info, Node: aout, Next: coff, Prev: What to Put Where, Up: BFD back ends
7582 File: bfd.info, Node: coff, Next: elf, Prev: aout, Up: BFD back ends
7584 3.2 coff backends
7587 BFD supports a number of different flavours of coff format. The major
7591 Coff in all its varieties is implemented with a few common files and
7593 coff format is implemented in the file `coff-m88k.c'. This file
7594 `#include's `coff/m88k.h' which defines the external structure of the
7595 coff format for the 88k, and `coff/internal.h' which defines the
7596 internal structure. `coff-m88k.c' also defines the relocations used by
7599 The Intel i960 processor version of coff is implemented in
7600 `coff-i960.c'. This file has the same structure as `coff-m88k.c',
7601 except that it includes `coff/i960.h' rather than `coff-m88k.h'.
7603 3.2.1 Porting to a new version of coff
7607 the version of coff which is most like the one you want to use. For
7608 example, we'll say that i386 coff is the one you select, and that your
7609 coff flavour is called foo. Copy `i386coff.c' to `foocoff.c', copy
7610 `../include/coff/i386.h' to `../include/coff/foo.h', and add the lines
7612 Alter the shapes of the structures in `../include/coff/foo.h' so that
7614 to the code in `coff/internal.h' and `coffcode.h' if your version of
7615 coff is too wild.
7620 has the pretty standard coff dump utility, usually called `att-dump' or
7625 3.2.2 How the coff backend works
7631 The Coff backend is split into generic routines that are applicable to
7632 any Coff target and routines that are specific to a particular target.
7634 basically the same for all Coff targets except that they use the
7638 any Coff target. They use some hooks into the target specific code;
7644 various Coff targets first include the appropriate Coff header file,
7647 Some of the Coff targets then also have additional routines in the
7650 For example, `coff-i960.c' includes `coff/internal.h' and
7651 `coff/i960.h'. It then defines a few constants, such as `I960', and
7653 `coff-i960.c' also includes some code to manipulate the i960 relocs.
7660 Each flavour of coff supported in BFD has its own header file
7662 internal description of the coff layout, in `coff/internal.h'. A major
7663 function of the coff backend is swapping the bytes and twiddling the
7667 of coff; it is the duty of the coff version specific include file to
7669 E.g., the size of line number entry in coff is sometimes 16 bits, and
7672 version of coff which has a varying field size not catered to at the
7691 keep all the information available in a coff symbol table. The back end
7697 `coff_get_normalized_symtab'. This reads the symbol table from the coff
7710 At this time the symbol names are moved around. Coff stores all
7722 Any linenumbers are read from the coff file too, and attached to the
7728 Writing a symbol to a coff file which didn't come from a coff file will
7733 When the symbols have come from a coff file then all the debugging
7747 form of BFD into the form used by coff. Internally, BFD expects symbol
7750 Coff expects symbols to contain their final value, so symbols have
7759 required by coff. It changes each pointer to a symbol into the index
7764 symbols from their internal form into the coff way, calls the bit
7831 /* COFF symbol classifications. */
7846 Special entry points for gdb to swap in coff symbol table parts:
8121 Creating the linenumber table is done by reading in the entire coff
8124 A coff linenumber table is structured so that each function is
8141 Coff relocations are easily transformed into the internal BFD form
8144 Reading a coff relocation table is done in the following stages:
8146 * Read the entire coff relocation table into memory.
8164 File: bfd.info, Node: elf, Next: mmo, Prev: coff, Up: BFD back ends
8991 * bfd_coff_backend_data: coff. (line 246)
10216 * coff_symbol_type: coff. (line 186)
10296 Node: coff279867
