[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
BFD supports a number of different flavours of coff format.
The major difference between formats are the sizes and
alignments of fields in structures on disk, and the occasional
extra field.
Coff in all its varieties is implimented with a few common
files and a number of implementation specific files. For
example, The 88k bcs coff format is implemented in the file
coff-m88k.c
. This file #include
s
coff-m88k.h
which defines the external structure of the
coff format for the 88k, and internalcoff.h
which
defines the internal structure. coff-m88k.c
also
defines pthe relocations used by the 88k format
@xref{Relocations}. Then the major portion of coff code is
included (coffcode.h
) which defines the methods used to
act upon the types defined in coff-m88k.h
and
internalcoff.h
.
The Intel i960 processor version of coff is implemented in
coff-i960.c
. This file has the same structure as
coff-m88k.c
, except that it includes coff-i960.h
rather than coff-m88k.h
.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The recommended method is to select from the existing
implimentations the version of coff which is most like the one
you want to use, for our purposes, we’ll say that i386 coff is
the one you select, and that your coff flavour is called foo.
Copy the i386coff.c
to foocoff.c
, copy
../include/i386coff.h
to ../include/foocoff.h
and add the lines to targets.c
and Makefile.in
so that your new back end is used. Alter the shapes of the
structures in ../include/foocoff.h
so that they match
what you need. You will probably also have to add
#ifdef
s to the code in internalcoff.h
and
coffcode.h
if your version of coff is too wild.
You can verify that your new BFD backend works quite simply by
building objdump
from the binutils
directory,
and making sure that its version of what’s going on at your
host systems idea (assuming it has the pretty standard coff
dump utility (usually called att-dump
or just
dump
)) are the same. Then clean up your code, and send
what you’ve done to Cygnus. Then your stuff will be in the
next release, and you won’t have to keep integrating it.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Each flavour of coff supported in BFD has its own header file
descibing the external layout of the structures. There is also
an internal description of the coff layout (in
internalcoff.h
) file (). A major function of the
coff backend is swapping the bytes and twiddling the bits to
translate the external form of the structures into the normal
internal form. This is all performed in the
bfd_swap
_thing_direction routines. Some
elements are different sizes between different versions of
coff, it is the duty of the coff version specific include file
to override the definitions of various packing routines in
coffcode.h
. Eg the size of line number entry in coff is
sometimes 16 bits, and sometimes 32 bits. #define
ing
PUT_LNSZ_LNNO
and GET_LNSZ_LNNO
will select the
correct one. No doubt, some day someone will find a version of
coff which has a varying field size not catered for at the
moment. To port BFD, that person will have to add more #defines
.
Three of the bit twiddling routines are exported to
gdb
; coff_swap_aux_in
, coff_swap_sym_in
and coff_swap_linno_in
. GDB
reads the symbol
table on its own, but uses BFD to fix things up. More of the
bit twiddlers are exported for gas
;
coff_swap_aux_out
, coff_swap_sym_out
,
coff_swap_lineno_out
, coff_swap_reloc_out
,
coff_swap_filehdr_out
, coff_swap_aouthdr_out
,
coff_swap_scnhdr_out
. Gas
currently keeps track
of all the symbol table and reloc drudgery itself, thereby
saving the internal BFD overhead, but uses BFD to swap things
on the way out, making cross ports much safer. This also
allows BFD (and thus the linker) to use the same header files
as gas
, which makes one avenue to disaster disappear.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The simple canonical form for symbols used by BFD is not rich
enough to keep all the information available in a coff symbol
table. The back end gets around this by keeping the original
symbol table around, "behind the scenes".
When a symbol table is requested (through a call to
bfd_canonicalize_symtab
, a request gets through to
get_normalized_symtab
. This reads the symbol table from
the coff file and swaps all the structures inside into the
internal form. It also fixes up all the pointers in the table
(represented in the file by offsets from the first symbol in
the table) into physical pointers to elements in the new
internal table. This involves some work since the meanings of
fields changes depending upon context; a field that is a
pointer to another structure in the symbol table at one moment
may be the size in bytes of a structure in the next. Another
pass is made over the table. All symbols which mark file names
(C_FILE
symbols) are modified so that the internal
string points to the value in the auxent (the real filename)
rather than the normal text associated with the symbol
(".file"
).
At this time the symbol names are moved around. Coff stores
all symbols less than nine characters long physically
within the symbol table, longer strings are kept at the end of
the file in the string table. This pass moves all strings
into memory, and replaces them with pointers to the strings.
The symbol table is massaged once again, this time to create
the canonical table used by the BFD application. Each symbol
is inspected in turn, and a decision made (using the
sclass
field) about the various flags to set in the
asymbol
@xref{Symbols}. The generated canonical table
shares strings with the hidden internal symbol table.
Any linenumbers are read from the coff file too, and attached
to the symbols which own the functions the linenumbers belong to.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Writing a symbol to a coff file which didn’t come from a coff
file will lose any debugging information. The asymbol
structure remembers the BFD from which was born, and on output
the back end makes sure that the same destination target as
source target is present.
When the symbols have come from a coff file then all the
debugging information is preserved.
Symbol tables are provided for writing to the back end in a
vector of pointers to pointers. This allows applications like
the linker to accumulate and output large symbol tables
without having to do too much byte copying.
This function runs through the provided symbol table and
patches each symbol marked as a file place holder
(C_FILE
) to point to the next file place holder in the
list. It also marks each offset
field in the list with
the offset from the first symbol of the current symbol.
Another function of this procedure is to turn the canonical
value form of BFD into the form used by coff. Internally, BFD
expects symbol values to be offsets from a section base; so a
symbol physically at 0x120, but in a section starting at
0x100, would have the value 0x20. Coff expects symbols to
contain their final value, so symbols have their values
changed at this point to reflect their sum with their owning
section. Note that this transformation uses the
output_section
field of the asymbol
’s
asection
@xref{Sections}.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
coff_symbol_type
Description
The hidden information for an asymbol is described in a
coff_ptr_struct, which is typedefed to a combined_entry_type
.
typedef 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; /* Should the tag field of this symbol be renumbered. Created by coff_pointerize_aux. */ char fix_tag; /* Should the endidx field of this symbol be renumbered. Created by coff_pointerize_aux. */ char fix_end; /* The container for the symbol structure as read and translated from the file. */ union { union internal_auxent auxent; struct internal_syment syment; } u; } 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 ? */ boolean done_lineno; } coff_symbol_type;
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To write relocations, all the back end does is step though the
canonical relocation table, and create an
internal_reloc
. The symbol index to use is removed from
the offset
field in the symbol table supplied, the
address comes directly from the sum of the section base
address and the relocation offset and the type is dug directly
from the howto field. Then the internal_reloc
is
swapped into the shape of an external_reloc
and written
out to disk.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Creating the linenumber table is done by reading in the entire
coff linenumber table, and creating another table for internal use.
A coff line number table is structured so that each function
is marked as having a line number of 0. Each line within the
function is an offset from the first line in the function. The
base of the line number information for the table is stored in
the symbol associated with the function.
The information is copied from the external to the internal
table, and each symbol which marks a function is marked by
pointing its...
How does this work ?
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Coff relocations are easily transformed into the internal BFD form
(arelent
).
Reading a coff relocation table is done in the following stages:
bfd_canonicalize_symtab
. The back end will call the
routine and save the result if a canonicalization hasn’t been done.r_type
to directly produce an index
into a howto table vector; the 88k subtracts a number from the
r_type
field and creates an addend field.
[Top] | [Contents] | [Index] | [ ? ] |
This document was generated on December 11, 2024 using texi2html 5.0.
The buttons in the navigation panels have the following meaning:
Button | Name | Go to | From 1.2.3 go to |
---|---|---|---|
[ << ] | FastBack | Beginning of this chapter or previous chapter | 1 |
[ < ] | Back | Previous section in reading order | 1.2.2 |
[ Up ] | Up | Up section | 1.2 |
[ > ] | Forward | Next section in reading order | 1.2.4 |
[ >> ] | FastForward | Next chapter | 2 |
[Top] | Top | Cover (top) of document | |
[Contents] | Contents | Table of contents | |
[Index] | Index | Index | |
[ ? ] | About | About (help) |
where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:
This document was generated on December 11, 2024 using texi2html 5.0.