Lines Matching full:coff
69 Intel Oregon, for interoperability of applications on their COFF and
79 coff.
129 coff, but loses efficiency when applied to formats such as S-records and
177 Another example is COFF section names. COFF files may contain an
203 linking or copying big endian COFF to little endian COFF, or `a.out' to
253 This information would be useless to most COFF debuggers; the
258 example, COFF, IEEE, Oasys) and the type is simple enough to fit
273 byte being written to a 68k COFF file, even though 68k COFF has no
287 formats (COFF, IEEE and Oasys).
1111 Names need not be unique; for example a COFF file may have several
1361 /* The section is a COFF shared library section. This flag is
1365 was originally intended to be general, it really is COFF
1373 executables or shared objects. This is for COFF only. */
1461 SEC_MERGE, some coff relaxing targets), and thus the original size
2026 end knows about. For example, the coff back end keeps the original
2028 read in. On output, the coff back end can reconstruct the output symbol
2029 table so that no information is lost, even information unique to coff
2030 which BFD doesn't know or understand. If a coff symbol table were read,
2031 but were written through an a.out back end, all the coff specific
2233 location in an output file - ie in coff a `ISFCN' symbol
2476 different formats (e.g., a.out and coff) and even different
2480 more expressive than others. For instance, Intel COFF archives can
2681 generated only when linking i960 coff files with i960 b.out
2759 Using coff and an 88k, some instructions don't have enough space in
2858 in a coff environment has the type 023 - because that's
3032 record. Some native formats (e.g., basic a.out and basic coff) have no
5453 when creating COFF files. */
7387 * coff :: coff backends
7397 File: bfd.info, Node: aout, Next: coff, Prev: What to Put Where, Up: BFD back ends
7584 File: bfd.info, Node: coff, Next: elf, Prev: aout, Up: BFD back ends
7586 3.2 coff backends
7589 BFD supports a number of different flavours of coff format. The major
7593 Coff in all its varieties is implemented with a few common files and
7595 coff format is implemented in the file `coff-m88k.c'. This file
7596 `#include's `coff/m88k.h' which defines the external structure of the
7597 coff format for the 88k, and `coff/internal.h' which defines the
7598 internal structure. `coff-m88k.c' also defines the relocations used by
7601 The Intel i960 processor version of coff is implemented in
7602 `coff-i960.c'. This file has the same structure as `coff-m88k.c',
7603 except that it includes `coff/i960.h' rather than `coff-m88k.h'.
7605 3.2.1 Porting to a new version of coff
7609 the version of coff which is most like the one you want to use. For
7610 example, we'll say that i386 coff is the one you select, and that your
7611 coff flavour is called foo. Copy `i386coff.c' to `foocoff.c', copy
7612 `../include/coff/i386.h' to `../include/coff/foo.h', and add the lines
7614 Alter the shapes of the structures in `../include/coff/foo.h' so that
7616 to the code in `coff/internal.h' and `coffcode.h' if your version of
7617 coff is too wild.
7622 has the pretty standard coff dump utility, usually called `att-dump' or
7627 3.2.2 How the coff backend works
7633 The Coff backend is split into generic routines that are applicable to
7634 any Coff target and routines that are specific to a particular target.
7636 basically the same for all Coff targets except that they use the
7640 any Coff target. They use some hooks into the target specific code;
7646 various Coff targets first include the appropriate Coff header file,
7649 Some of the Coff targets then also have additional routines in the
7652 For example, `coff-i960.c' includes `coff/internal.h' and
7653 `coff/i960.h'. It then defines a few constants, such as `I960', and
7655 `coff-i960.c' also includes some code to manipulate the i960 relocs.
7662 Each flavour of coff supported in BFD has its own header file
7664 internal description of the coff layout, in `coff/internal.h'. A major
7665 function of the coff backend is swapping the bytes and twiddling the
7669 of coff; it is the duty of the coff version specific include file to
7671 E.g., the size of line number entry in coff is sometimes 16 bits, and
7674 version of coff which has a varying field size not catered to at the
7693 keep all the information available in a coff symbol table. The back end
7699 `coff_get_normalized_symtab'. This reads the symbol table from the coff
7712 At this time the symbol names are moved around. Coff stores all
7724 Any linenumbers are read from the coff file too, and attached to the
7730 Writing a symbol to a coff file which didn't come from a coff file will
7735 When the symbols have come from a coff file then all the debugging
7749 form of BFD into the form used by coff. Internally, BFD expects symbol
7752 Coff expects symbols to contain their final value, so symbols have
7761 required by coff. It changes each pointer to a symbol into the index
7766 symbols from their internal form into the coff way, calls the bit
7833 /* COFF symbol classifications. */
7848 Special entry points for gdb to swap in coff symbol table parts:
8123 Creating the linenumber table is done by reading in the entire coff
8126 A coff linenumber table is structured so that each function is
8143 Coff relocations are easily transformed into the internal BFD form
8146 Reading a coff relocation table is done in the following stages:
8148 * Read the entire coff relocation table into memory.
8166 File: bfd.info, Node: elf, Next: mmo, Prev: coff, Up: BFD back ends
8993 * bfd_coff_backend_data: coff. (line 246)
10218 * coff_symbol_type: coff. (line 186)
10298 Node: coff279957
