| 1 | This is bfd.info, produced by makeinfo version 4.3 from bfd.texinfo.
|
|---|
| 2 |
|
|---|
| 3 | START-INFO-DIR-ENTRY
|
|---|
| 4 | * Bfd: (bfd). The Binary File Descriptor library.
|
|---|
| 5 | END-INFO-DIR-ENTRY
|
|---|
| 6 |
|
|---|
| 7 | This file documents the BFD library.
|
|---|
| 8 |
|
|---|
| 9 | Copyright (C) 1991, 2000, 2001, 2003 Free Software Foundation, Inc.
|
|---|
| 10 |
|
|---|
| 11 | Permission is granted to copy, distribute and/or modify this document
|
|---|
| 12 | under the terms of the GNU Free Documentation License, Version 1.1
|
|---|
| 13 | or any later version published by the Free Software Foundation;
|
|---|
| 14 | with no Invariant Sections, with no Front-Cover Texts, and with no
|
|---|
| 15 | Back-Cover Texts. A copy of the license is included in the
|
|---|
| 16 | section entitled "GNU Free Documentation License".
|
|---|
| 17 |
|
|---|
| 18 |
|
|---|
| 19 | File: bfd.info, Node: coff, Next: elf, Prev: aout, Up: BFD back ends
|
|---|
| 20 |
|
|---|
| 21 | coff backends
|
|---|
| 22 | =============
|
|---|
| 23 |
|
|---|
| 24 | BFD supports a number of different flavours of coff format. The
|
|---|
| 25 | major differences between formats are the sizes and alignments of
|
|---|
| 26 | fields in structures on disk, and the occasional extra field.
|
|---|
| 27 |
|
|---|
| 28 | Coff in all its varieties is implemented with a few common files and
|
|---|
| 29 | a number of implementation specific files. For example, The 88k bcs
|
|---|
| 30 | coff format is implemented in the file `coff-m88k.c'. This file
|
|---|
| 31 | `#include's `coff/m88k.h' which defines the external structure of the
|
|---|
| 32 | coff format for the 88k, and `coff/internal.h' which defines the
|
|---|
| 33 | internal structure. `coff-m88k.c' also defines the relocations used by
|
|---|
| 34 | the 88k format *Note Relocations::.
|
|---|
| 35 |
|
|---|
| 36 | The Intel i960 processor version of coff is implemented in
|
|---|
| 37 | `coff-i960.c'. This file has the same structure as `coff-m88k.c',
|
|---|
| 38 | except that it includes `coff/i960.h' rather than `coff-m88k.h'.
|
|---|
| 39 |
|
|---|
| 40 | Porting to a new version of coff
|
|---|
| 41 | --------------------------------
|
|---|
| 42 |
|
|---|
| 43 | The recommended method is to select from the existing
|
|---|
| 44 | implementations the version of coff which is most like the one you want
|
|---|
| 45 | to use. For example, we'll say that i386 coff is the one you select,
|
|---|
| 46 | and that your coff flavour is called foo. Copy `i386coff.c' to
|
|---|
| 47 | `foocoff.c', copy `../include/coff/i386.h' to `../include/coff/foo.h',
|
|---|
| 48 | and add the lines to `targets.c' and `Makefile.in' so that your new
|
|---|
| 49 | back end is used. Alter the shapes of the structures in
|
|---|
| 50 | `../include/coff/foo.h' so that they match what you need. You will
|
|---|
| 51 | probably also have to add `#ifdef's to the code in `coff/internal.h' and
|
|---|
| 52 | `coffcode.h' if your version of coff is too wild.
|
|---|
| 53 |
|
|---|
| 54 | You can verify that your new BFD backend works quite simply by
|
|---|
| 55 | building `objdump' from the `binutils' directory, and making sure that
|
|---|
| 56 | its version of what's going on and your host system's idea (assuming it
|
|---|
| 57 | has the pretty standard coff dump utility, usually called `att-dump' or
|
|---|
| 58 | just `dump') are the same. Then clean up your code, and send what
|
|---|
| 59 | you've done to Cygnus. Then your stuff will be in the next release, and
|
|---|
| 60 | you won't have to keep integrating it.
|
|---|
| 61 |
|
|---|
| 62 | How the coff backend works
|
|---|
| 63 | --------------------------
|
|---|
| 64 |
|
|---|
| 65 | File layout
|
|---|
| 66 | ...........
|
|---|
| 67 |
|
|---|
| 68 | The Coff backend is split into generic routines that are applicable
|
|---|
| 69 | to any Coff target and routines that are specific to a particular
|
|---|
| 70 | target. The target-specific routines are further split into ones which
|
|---|
| 71 | are basically the same for all Coff targets except that they use the
|
|---|
| 72 | external symbol format or use different values for certain constants.
|
|---|
| 73 |
|
|---|
| 74 | The generic routines are in `coffgen.c'. These routines work for
|
|---|
| 75 | any Coff target. They use some hooks into the target specific code;
|
|---|
| 76 | the hooks are in a `bfd_coff_backend_data' structure, one of which
|
|---|
| 77 | exists for each target.
|
|---|
| 78 |
|
|---|
| 79 | The essentially similar target-specific routines are in
|
|---|
| 80 | `coffcode.h'. This header file includes executable C code. The
|
|---|
| 81 | various Coff targets first include the appropriate Coff header file,
|
|---|
| 82 | make any special defines that are needed, and then include `coffcode.h'.
|
|---|
| 83 |
|
|---|
| 84 | Some of the Coff targets then also have additional routines in the
|
|---|
| 85 | target source file itself.
|
|---|
| 86 |
|
|---|
| 87 | For example, `coff-i960.c' includes `coff/internal.h' and
|
|---|
| 88 | `coff/i960.h'. It then defines a few constants, such as `I960', and
|
|---|
| 89 | includes `coffcode.h'. Since the i960 has complex relocation types,
|
|---|
| 90 | `coff-i960.c' also includes some code to manipulate the i960 relocs.
|
|---|
| 91 | This code is not in `coffcode.h' because it would not be used by any
|
|---|
| 92 | other target.
|
|---|
| 93 |
|
|---|
| 94 | Bit twiddling
|
|---|
| 95 | .............
|
|---|
| 96 |
|
|---|
| 97 | Each flavour of coff supported in BFD has its own header file
|
|---|
| 98 | describing the external layout of the structures. There is also an
|
|---|
| 99 | internal description of the coff layout, in `coff/internal.h'. A major
|
|---|
| 100 | function of the coff backend is swapping the bytes and twiddling the
|
|---|
| 101 | bits to translate the external form of the structures into the normal
|
|---|
| 102 | internal form. This is all performed in the `bfd_swap'_thing_direction
|
|---|
| 103 | routines. Some elements are different sizes between different versions
|
|---|
| 104 | of coff; it is the duty of the coff version specific include file to
|
|---|
| 105 | override the definitions of various packing routines in `coffcode.h'.
|
|---|
| 106 | E.g., the size of line number entry in coff is sometimes 16 bits, and
|
|---|
| 107 | sometimes 32 bits. `#define'ing `PUT_LNSZ_LNNO' and `GET_LNSZ_LNNO'
|
|---|
| 108 | will select the correct one. No doubt, some day someone will find a
|
|---|
| 109 | version of coff which has a varying field size not catered to at the
|
|---|
| 110 | moment. To port BFD, that person will have to add more `#defines'.
|
|---|
| 111 | Three of the bit twiddling routines are exported to `gdb';
|
|---|
| 112 | `coff_swap_aux_in', `coff_swap_sym_in' and `coff_swap_lineno_in'. `GDB'
|
|---|
| 113 | reads the symbol table on its own, but uses BFD to fix things up. More
|
|---|
| 114 | of the bit twiddlers are exported for `gas'; `coff_swap_aux_out',
|
|---|
| 115 | `coff_swap_sym_out', `coff_swap_lineno_out', `coff_swap_reloc_out',
|
|---|
| 116 | `coff_swap_filehdr_out', `coff_swap_aouthdr_out',
|
|---|
| 117 | `coff_swap_scnhdr_out'. `Gas' currently keeps track of all the symbol
|
|---|
| 118 | table and reloc drudgery itself, thereby saving the internal BFD
|
|---|
| 119 | overhead, but uses BFD to swap things on the way out, making cross
|
|---|
| 120 | ports much safer. Doing so also allows BFD (and thus the linker) to
|
|---|
| 121 | use the same header files as `gas', which makes one avenue to disaster
|
|---|
| 122 | disappear.
|
|---|
| 123 |
|
|---|
| 124 | Symbol reading
|
|---|
| 125 | ..............
|
|---|
| 126 |
|
|---|
| 127 | The simple canonical form for symbols used by BFD is not rich enough
|
|---|
| 128 | to keep all the information available in a coff symbol table. The back
|
|---|
| 129 | end gets around this problem by keeping the original symbol table
|
|---|
| 130 | around, "behind the scenes".
|
|---|
| 131 |
|
|---|
| 132 | When a symbol table is requested (through a call to
|
|---|
| 133 | `bfd_canonicalize_symtab'), a request gets through to
|
|---|
| 134 | `coff_get_normalized_symtab'. This reads the symbol table from the coff
|
|---|
| 135 | file and swaps all the structures inside into the internal form. It
|
|---|
| 136 | also fixes up all the pointers in the table (represented in the file by
|
|---|
| 137 | offsets from the first symbol in the table) into physical pointers to
|
|---|
| 138 | elements in the new internal table. This involves some work since the
|
|---|
| 139 | meanings of fields change depending upon context: a field that is a
|
|---|
| 140 | pointer to another structure in the symbol table at one moment may be
|
|---|
| 141 | the size in bytes of a structure at the next. Another pass is made
|
|---|
| 142 | over the table. All symbols which mark file names (`C_FILE' symbols)
|
|---|
| 143 | are modified so that the internal string points to the value in the
|
|---|
| 144 | auxent (the real filename) rather than the normal text associated with
|
|---|
| 145 | the symbol (`".file"').
|
|---|
| 146 |
|
|---|
| 147 | At this time the symbol names are moved around. Coff stores all
|
|---|
| 148 | symbols less than nine characters long physically within the symbol
|
|---|
| 149 | table; longer strings are kept at the end of the file in the string
|
|---|
| 150 | table. This pass moves all strings into memory and replaces them with
|
|---|
| 151 | pointers to the strings.
|
|---|
| 152 |
|
|---|
| 153 | The symbol table is massaged once again, this time to create the
|
|---|
| 154 | canonical table used by the BFD application. Each symbol is inspected
|
|---|
| 155 | in turn, and a decision made (using the `sclass' field) about the
|
|---|
| 156 | various flags to set in the `asymbol'. *Note Symbols::. The generated
|
|---|
| 157 | canonical table shares strings with the hidden internal symbol table.
|
|---|
| 158 |
|
|---|
| 159 | Any linenumbers are read from the coff file too, and attached to the
|
|---|
| 160 | symbols which own the functions the linenumbers belong to.
|
|---|
| 161 |
|
|---|
| 162 | Symbol writing
|
|---|
| 163 | ..............
|
|---|
| 164 |
|
|---|
| 165 | Writing a symbol to a coff file which didn't come from a coff file
|
|---|
| 166 | will lose any debugging information. The `asymbol' structure remembers
|
|---|
| 167 | the BFD from which the symbol was taken, and on output the back end
|
|---|
| 168 | makes sure that the same destination target as source target is present.
|
|---|
| 169 |
|
|---|
| 170 | When the symbols have come from a coff file then all the debugging
|
|---|
| 171 | information is preserved.
|
|---|
| 172 |
|
|---|
| 173 | Symbol tables are provided for writing to the back end in a vector
|
|---|
| 174 | of pointers to pointers. This allows applications like the linker to
|
|---|
| 175 | accumulate and output large symbol tables without having to do too much
|
|---|
| 176 | byte copying.
|
|---|
| 177 |
|
|---|
| 178 | This function runs through the provided symbol table and patches
|
|---|
| 179 | each symbol marked as a file place holder (`C_FILE') to point to the
|
|---|
| 180 | next file place holder in the list. It also marks each `offset' field
|
|---|
| 181 | in the list with the offset from the first symbol of the current symbol.
|
|---|
| 182 |
|
|---|
| 183 | Another function of this procedure is to turn the canonical value
|
|---|
| 184 | form of BFD into the form used by coff. Internally, BFD expects symbol
|
|---|
| 185 | values to be offsets from a section base; so a symbol physically at
|
|---|
| 186 | 0x120, but in a section starting at 0x100, would have the value 0x20.
|
|---|
| 187 | Coff expects symbols to contain their final value, so symbols have
|
|---|
| 188 | their values changed at this point to reflect their sum with their
|
|---|
| 189 | owning section. This transformation uses the `output_section' field of
|
|---|
| 190 | the `asymbol''s `asection' *Note Sections::.
|
|---|
| 191 |
|
|---|
| 192 | * `coff_mangle_symbols'
|
|---|
| 193 | This routine runs though the provided symbol table and uses the
|
|---|
| 194 | offsets generated by the previous pass and the pointers generated when
|
|---|
| 195 | the symbol table was read in to create the structured hierarchy
|
|---|
| 196 | required by coff. It changes each pointer to a symbol into the index
|
|---|
| 197 | into the symbol table of the asymbol.
|
|---|
| 198 |
|
|---|
| 199 | * `coff_write_symbols'
|
|---|
| 200 | This routine runs through the symbol table and patches up the
|
|---|
| 201 | symbols from their internal form into the coff way, calls the bit
|
|---|
| 202 | twiddlers, and writes out the table to the file.
|
|---|
| 203 |
|
|---|
| 204 | `coff_symbol_type'
|
|---|
| 205 | ..................
|
|---|
| 206 |
|
|---|
| 207 | *Description*
|
|---|
| 208 | The hidden information for an `asymbol' is described in a
|
|---|
| 209 | `combined_entry_type':
|
|---|
| 210 |
|
|---|
| 211 |
|
|---|
| 212 | typedef struct coff_ptr_struct
|
|---|
| 213 | {
|
|---|
| 214 | /* Remembers the offset from the first symbol in the file for
|
|---|
| 215 | this symbol. Generated by coff_renumber_symbols. */
|
|---|
| 216 | unsigned int offset;
|
|---|
| 217 |
|
|---|
| 218 | /* Should the value of this symbol be renumbered. Used for
|
|---|
| 219 | XCOFF C_BSTAT symbols. Set by coff_slurp_symbol_table. */
|
|---|
| 220 | unsigned int fix_value : 1;
|
|---|
| 221 |
|
|---|
| 222 | /* Should the tag field of this symbol be renumbered.
|
|---|
| 223 | Created by coff_pointerize_aux. */
|
|---|
| 224 | unsigned int fix_tag : 1;
|
|---|
| 225 |
|
|---|
| 226 | /* Should the endidx field of this symbol be renumbered.
|
|---|
| 227 | Created by coff_pointerize_aux. */
|
|---|
| 228 | unsigned int fix_end : 1;
|
|---|
| 229 |
|
|---|
| 230 | /* Should the x_csect.x_scnlen field be renumbered.
|
|---|
| 231 | Created by coff_pointerize_aux. */
|
|---|
| 232 | unsigned int fix_scnlen : 1;
|
|---|
| 233 |
|
|---|
| 234 | /* Fix up an XCOFF C_BINCL/C_EINCL symbol. The value is the
|
|---|
| 235 | index into the line number entries. Set by coff_slurp_symbol_table. */
|
|---|
| 236 | unsigned int fix_line : 1;
|
|---|
| 237 |
|
|---|
| 238 | /* The container for the symbol structure as read and translated
|
|---|
| 239 | from the file. */
|
|---|
| 240 | union
|
|---|
| 241 | {
|
|---|
| 242 | union internal_auxent auxent;
|
|---|
| 243 | struct internal_syment syment;
|
|---|
| 244 | } u;
|
|---|
| 245 | } combined_entry_type;
|
|---|
| 246 |
|
|---|
| 247 |
|
|---|
| 248 | /* Each canonical asymbol really looks like this: */
|
|---|
| 249 |
|
|---|
| 250 | typedef struct coff_symbol_struct
|
|---|
| 251 | {
|
|---|
| 252 | /* The actual symbol which the rest of BFD works with */
|
|---|
| 253 | asymbol symbol;
|
|---|
| 254 |
|
|---|
| 255 | /* A pointer to the hidden information for this symbol */
|
|---|
| 256 | combined_entry_type *native;
|
|---|
| 257 |
|
|---|
| 258 | /* A pointer to the linenumber information for this symbol */
|
|---|
| 259 | struct lineno_cache_entry *lineno;
|
|---|
| 260 |
|
|---|
| 261 | /* Have the line numbers been relocated yet ? */
|
|---|
| 262 | bfd_boolean done_lineno;
|
|---|
| 263 | } coff_symbol_type;
|
|---|
| 264 |
|
|---|
| 265 | `bfd_coff_backend_data'
|
|---|
| 266 | .......................
|
|---|
| 267 |
|
|---|
| 268 | /* COFF symbol classifications. */
|
|---|
| 269 |
|
|---|
| 270 | enum coff_symbol_classification
|
|---|
| 271 | {
|
|---|
| 272 | /* Global symbol. */
|
|---|
| 273 | COFF_SYMBOL_GLOBAL,
|
|---|
| 274 | /* Common symbol. */
|
|---|
| 275 | COFF_SYMBOL_COMMON,
|
|---|
| 276 | /* Undefined symbol. */
|
|---|
| 277 | COFF_SYMBOL_UNDEFINED,
|
|---|
| 278 | /* Local symbol. */
|
|---|
| 279 | COFF_SYMBOL_LOCAL,
|
|---|
| 280 | /* PE section symbol. */
|
|---|
| 281 | COFF_SYMBOL_PE_SECTION
|
|---|
| 282 | };
|
|---|
| 283 | Special entry points for gdb to swap in coff symbol table parts:
|
|---|
| 284 | typedef struct
|
|---|
| 285 | {
|
|---|
| 286 | void (*_bfd_coff_swap_aux_in)
|
|---|
| 287 | PARAMS ((bfd *, PTR, int, int, int, int, PTR));
|
|---|
| 288 |
|
|---|
| 289 | void (*_bfd_coff_swap_sym_in)
|
|---|
| 290 | PARAMS ((bfd *, PTR, PTR));
|
|---|
| 291 |
|
|---|
| 292 | void (*_bfd_coff_swap_lineno_in)
|
|---|
| 293 | PARAMS ((bfd *, PTR, PTR));
|
|---|
| 294 |
|
|---|
| 295 | unsigned int (*_bfd_coff_swap_aux_out)
|
|---|
| 296 | PARAMS ((bfd *, PTR, int, int, int, int, PTR));
|
|---|
| 297 |
|
|---|
| 298 | unsigned int (*_bfd_coff_swap_sym_out)
|
|---|
| 299 | PARAMS ((bfd *, PTR, PTR));
|
|---|
| 300 |
|
|---|
| 301 | unsigned int (*_bfd_coff_swap_lineno_out)
|
|---|
| 302 | PARAMS ((bfd *, PTR, PTR));
|
|---|
| 303 |
|
|---|
| 304 | unsigned int (*_bfd_coff_swap_reloc_out)
|
|---|
| 305 | PARAMS ((bfd *, PTR, PTR));
|
|---|
| 306 |
|
|---|
| 307 | unsigned int (*_bfd_coff_swap_filehdr_out)
|
|---|
| 308 | PARAMS ((bfd *, PTR, PTR));
|
|---|
| 309 |
|
|---|
| 310 | unsigned int (*_bfd_coff_swap_aouthdr_out)
|
|---|
| 311 | PARAMS ((bfd *, PTR, PTR));
|
|---|
| 312 |
|
|---|
| 313 | unsigned int (*_bfd_coff_swap_scnhdr_out)
|
|---|
| 314 | PARAMS ((bfd *, PTR, PTR));
|
|---|
| 315 |
|
|---|
| 316 | unsigned int _bfd_filhsz;
|
|---|
| 317 | unsigned int _bfd_aoutsz;
|
|---|
| 318 | unsigned int _bfd_scnhsz;
|
|---|
| 319 | unsigned int _bfd_symesz;
|
|---|
| 320 | unsigned int _bfd_auxesz;
|
|---|
| 321 | unsigned int _bfd_relsz;
|
|---|
| 322 | unsigned int _bfd_linesz;
|
|---|
| 323 | unsigned int _bfd_filnmlen;
|
|---|
| 324 | bfd_boolean _bfd_coff_long_filenames;
|
|---|
| 325 | bfd_boolean _bfd_coff_long_section_names;
|
|---|
| 326 | unsigned int _bfd_coff_default_section_alignment_power;
|
|---|
| 327 | bfd_boolean _bfd_coff_force_symnames_in_strings;
|
|---|
| 328 | unsigned int _bfd_coff_debug_string_prefix_length;
|
|---|
| 329 |
|
|---|
| 330 | void (*_bfd_coff_swap_filehdr_in)
|
|---|
| 331 | PARAMS ((bfd *, PTR, PTR));
|
|---|
| 332 |
|
|---|
| 333 | void (*_bfd_coff_swap_aouthdr_in)
|
|---|
| 334 | PARAMS ((bfd *, PTR, PTR));
|
|---|
| 335 |
|
|---|
| 336 | void (*_bfd_coff_swap_scnhdr_in)
|
|---|
| 337 | PARAMS ((bfd *, PTR, PTR));
|
|---|
| 338 |
|
|---|
| 339 | void (*_bfd_coff_swap_reloc_in)
|
|---|
| 340 | PARAMS ((bfd *abfd, PTR, PTR));
|
|---|
| 341 |
|
|---|
| 342 | bfd_boolean (*_bfd_coff_bad_format_hook)
|
|---|
| 343 | PARAMS ((bfd *, PTR));
|
|---|
| 344 |
|
|---|
| 345 | bfd_boolean (*_bfd_coff_set_arch_mach_hook)
|
|---|
| 346 | PARAMS ((bfd *, PTR));
|
|---|
| 347 |
|
|---|
| 348 | PTR (*_bfd_coff_mkobject_hook)
|
|---|
| 349 | PARAMS ((bfd *, PTR, PTR));
|
|---|
| 350 |
|
|---|
| 351 | bfd_boolean (*_bfd_styp_to_sec_flags_hook)
|
|---|
| 352 | PARAMS ((bfd *, PTR, const char *, asection *, flagword *));
|
|---|
| 353 |
|
|---|
| 354 | void (*_bfd_set_alignment_hook)
|
|---|
| 355 | PARAMS ((bfd *, asection *, PTR));
|
|---|
| 356 |
|
|---|
| 357 | bfd_boolean (*_bfd_coff_slurp_symbol_table)
|
|---|
| 358 | PARAMS ((bfd *));
|
|---|
| 359 |
|
|---|
| 360 | bfd_boolean (*_bfd_coff_symname_in_debug)
|
|---|
| 361 | PARAMS ((bfd *, struct internal_syment *));
|
|---|
| 362 |
|
|---|
| 363 | bfd_boolean (*_bfd_coff_pointerize_aux_hook)
|
|---|
| 364 | PARAMS ((bfd *, combined_entry_type *, combined_entry_type *,
|
|---|
| 365 | unsigned int, combined_entry_type *));
|
|---|
| 366 |
|
|---|
| 367 | bfd_boolean (*_bfd_coff_print_aux)
|
|---|
| 368 | PARAMS ((bfd *, FILE *, combined_entry_type *, combined_entry_type *,
|
|---|
| 369 | combined_entry_type *, unsigned int));
|
|---|
| 370 |
|
|---|
| 371 | void (*_bfd_coff_reloc16_extra_cases)
|
|---|
| 372 | PARAMS ((bfd *, struct bfd_link_info *, struct bfd_link_order *, arelent *,
|
|---|
| 373 | bfd_byte *, unsigned int *, unsigned int *));
|
|---|
| 374 |
|
|---|
| 375 | int (*_bfd_coff_reloc16_estimate)
|
|---|
| 376 | PARAMS ((bfd *, asection *, arelent *, unsigned int,
|
|---|
| 377 | struct bfd_link_info *));
|
|---|
| 378 |
|
|---|
| 379 | enum coff_symbol_classification (*_bfd_coff_classify_symbol)
|
|---|
| 380 | PARAMS ((bfd *, struct internal_syment *));
|
|---|
| 381 |
|
|---|
| 382 | bfd_boolean (*_bfd_coff_compute_section_file_positions)
|
|---|
| 383 | PARAMS ((bfd *));
|
|---|
| 384 |
|
|---|
| 385 | bfd_boolean (*_bfd_coff_start_final_link)
|
|---|
| 386 | PARAMS ((bfd *, struct bfd_link_info *));
|
|---|
| 387 |
|
|---|
| 388 | bfd_boolean (*_bfd_coff_relocate_section)
|
|---|
| 389 | PARAMS ((bfd *, struct bfd_link_info *, bfd *, asection *, bfd_byte *,
|
|---|
| 390 | struct internal_reloc *, struct internal_syment *, asection **));
|
|---|
| 391 |
|
|---|
| 392 | reloc_howto_type *(*_bfd_coff_rtype_to_howto)
|
|---|
| 393 | PARAMS ((bfd *, asection *, struct internal_reloc *,
|
|---|
| 394 | struct coff_link_hash_entry *, struct internal_syment *,
|
|---|
| 395 | bfd_vma *));
|
|---|
| 396 |
|
|---|
| 397 | bfd_boolean (*_bfd_coff_adjust_symndx)
|
|---|
| 398 | PARAMS ((bfd *, struct bfd_link_info *, bfd *, asection *,
|
|---|
| 399 | struct internal_reloc *, bfd_boolean *));
|
|---|
| 400 |
|
|---|
| 401 | bfd_boolean (*_bfd_coff_link_add_one_symbol)
|
|---|
| 402 | PARAMS ((struct bfd_link_info *, bfd *, const char *, flagword,
|
|---|
| 403 | asection *, bfd_vma, const char *, bfd_boolean, bfd_boolean,
|
|---|
| 404 | struct bfd_link_hash_entry **));
|
|---|
| 405 |
|
|---|
| 406 | bfd_boolean (*_bfd_coff_link_output_has_begun)
|
|---|
| 407 | PARAMS ((bfd *, struct coff_final_link_info *));
|
|---|
| 408 |
|
|---|
| 409 | bfd_boolean (*_bfd_coff_final_link_postscript)
|
|---|
| 410 | PARAMS ((bfd *, struct coff_final_link_info *));
|
|---|
| 411 |
|
|---|
| 412 | } bfd_coff_backend_data;
|
|---|
| 413 |
|
|---|
| 414 | #define coff_backend_info(abfd) \
|
|---|
| 415 | ((bfd_coff_backend_data *) (abfd)->xvec->backend_data)
|
|---|
| 416 |
|
|---|
| 417 | #define bfd_coff_swap_aux_in(a,e,t,c,ind,num,i) \
|
|---|
| 418 | ((coff_backend_info (a)->_bfd_coff_swap_aux_in) (a,e,t,c,ind,num,i))
|
|---|
| 419 |
|
|---|
| 420 | #define bfd_coff_swap_sym_in(a,e,i) \
|
|---|
| 421 | ((coff_backend_info (a)->_bfd_coff_swap_sym_in) (a,e,i))
|
|---|
| 422 |
|
|---|
| 423 | #define bfd_coff_swap_lineno_in(a,e,i) \
|
|---|
| 424 | ((coff_backend_info ( a)->_bfd_coff_swap_lineno_in) (a,e,i))
|
|---|
| 425 |
|
|---|
| 426 | #define bfd_coff_swap_reloc_out(abfd, i, o) \
|
|---|
| 427 | ((coff_backend_info (abfd)->_bfd_coff_swap_reloc_out) (abfd, i, o))
|
|---|
| 428 |
|
|---|
| 429 | #define bfd_coff_swap_lineno_out(abfd, i, o) \
|
|---|
| 430 | ((coff_backend_info (abfd)->_bfd_coff_swap_lineno_out) (abfd, i, o))
|
|---|
| 431 |
|
|---|
| 432 | #define bfd_coff_swap_aux_out(a,i,t,c,ind,num,o) \
|
|---|
| 433 | ((coff_backend_info (a)->_bfd_coff_swap_aux_out) (a,i,t,c,ind,num,o))
|
|---|
| 434 |
|
|---|
| 435 | #define bfd_coff_swap_sym_out(abfd, i,o) \
|
|---|
| 436 | ((coff_backend_info (abfd)->_bfd_coff_swap_sym_out) (abfd, i, o))
|
|---|
| 437 |
|
|---|
| 438 | #define bfd_coff_swap_scnhdr_out(abfd, i,o) \
|
|---|
| 439 | ((coff_backend_info (abfd)->_bfd_coff_swap_scnhdr_out) (abfd, i, o))
|
|---|
| 440 |
|
|---|
| 441 | #define bfd_coff_swap_filehdr_out(abfd, i,o) \
|
|---|
| 442 | ((coff_backend_info (abfd)->_bfd_coff_swap_filehdr_out) (abfd, i, o))
|
|---|
| 443 |
|
|---|
| 444 | #define bfd_coff_swap_aouthdr_out(abfd, i,o) \
|
|---|
| 445 | ((coff_backend_info (abfd)->_bfd_coff_swap_aouthdr_out) (abfd, i, o))
|
|---|
| 446 |
|
|---|
| 447 | #define bfd_coff_filhsz(abfd) (coff_backend_info (abfd)->_bfd_filhsz)
|
|---|
| 448 | #define bfd_coff_aoutsz(abfd) (coff_backend_info (abfd)->_bfd_aoutsz)
|
|---|
| 449 | #define bfd_coff_scnhsz(abfd) (coff_backend_info (abfd)->_bfd_scnhsz)
|
|---|
| 450 | #define bfd_coff_symesz(abfd) (coff_backend_info (abfd)->_bfd_symesz)
|
|---|
| 451 | #define bfd_coff_auxesz(abfd) (coff_backend_info (abfd)->_bfd_auxesz)
|
|---|
| 452 | #define bfd_coff_relsz(abfd) (coff_backend_info (abfd)->_bfd_relsz)
|
|---|
| 453 | #define bfd_coff_linesz(abfd) (coff_backend_info (abfd)->_bfd_linesz)
|
|---|
| 454 | #define bfd_coff_filnmlen(abfd) (coff_backend_info (abfd)->_bfd_filnmlen)
|
|---|
| 455 | #define bfd_coff_long_filenames(abfd) \
|
|---|
| 456 | (coff_backend_info (abfd)->_bfd_coff_long_filenames)
|
|---|
| 457 | #define bfd_coff_long_section_names(abfd) \
|
|---|
| 458 | (coff_backend_info (abfd)->_bfd_coff_long_section_names)
|
|---|
| 459 | #define bfd_coff_default_section_alignment_power(abfd) \
|
|---|
| 460 | (coff_backend_info (abfd)->_bfd_coff_default_section_alignment_power)
|
|---|
| 461 | #define bfd_coff_swap_filehdr_in(abfd, i,o) \
|
|---|
| 462 | ((coff_backend_info (abfd)->_bfd_coff_swap_filehdr_in) (abfd, i, o))
|
|---|
| 463 |
|
|---|
| 464 | #define bfd_coff_swap_aouthdr_in(abfd, i,o) \
|
|---|
| 465 | ((coff_backend_info (abfd)->_bfd_coff_swap_aouthdr_in) (abfd, i, o))
|
|---|
| 466 |
|
|---|
| 467 | #define bfd_coff_swap_scnhdr_in(abfd, i,o) \
|
|---|
| 468 | ((coff_backend_info (abfd)->_bfd_coff_swap_scnhdr_in) (abfd, i, o))
|
|---|
| 469 |
|
|---|
| 470 | #define bfd_coff_swap_reloc_in(abfd, i, o) \
|
|---|
| 471 | ((coff_backend_info (abfd)->_bfd_coff_swap_reloc_in) (abfd, i, o))
|
|---|
| 472 |
|
|---|
| 473 | #define bfd_coff_bad_format_hook(abfd, filehdr) \
|
|---|
| 474 | ((coff_backend_info (abfd)->_bfd_coff_bad_format_hook) (abfd, filehdr))
|
|---|
| 475 |
|
|---|
| 476 | #define bfd_coff_set_arch_mach_hook(abfd, filehdr)\
|
|---|
| 477 | ((coff_backend_info (abfd)->_bfd_coff_set_arch_mach_hook) (abfd, filehdr))
|
|---|
| 478 | #define bfd_coff_mkobject_hook(abfd, filehdr, aouthdr)\
|
|---|
| 479 | ((coff_backend_info (abfd)->_bfd_coff_mkobject_hook)\
|
|---|
| 480 | (abfd, filehdr, aouthdr))
|
|---|
| 481 |
|
|---|
| 482 | #define bfd_coff_styp_to_sec_flags_hook(abfd, scnhdr, name, section, flags_ptr)\
|
|---|
| 483 | ((coff_backend_info (abfd)->_bfd_styp_to_sec_flags_hook)\
|
|---|
| 484 | (abfd, scnhdr, name, section, flags_ptr))
|
|---|
| 485 |
|
|---|
| 486 | #define bfd_coff_set_alignment_hook(abfd, sec, scnhdr)\
|
|---|
| 487 | ((coff_backend_info (abfd)->_bfd_set_alignment_hook) (abfd, sec, scnhdr))
|
|---|
| 488 |
|
|---|
| 489 | #define bfd_coff_slurp_symbol_table(abfd)\
|
|---|
| 490 | ((coff_backend_info (abfd)->_bfd_coff_slurp_symbol_table) (abfd))
|
|---|
| 491 |
|
|---|
| 492 | #define bfd_coff_symname_in_debug(abfd, sym)\
|
|---|
| 493 | ((coff_backend_info (abfd)->_bfd_coff_symname_in_debug) (abfd, sym))
|
|---|
| 494 |
|
|---|
| 495 | #define bfd_coff_force_symnames_in_strings(abfd)\
|
|---|
| 496 | (coff_backend_info (abfd)->_bfd_coff_force_symnames_in_strings)
|
|---|
| 497 |
|
|---|
| 498 | #define bfd_coff_debug_string_prefix_length(abfd)\
|
|---|
| 499 | (coff_backend_info (abfd)->_bfd_coff_debug_string_prefix_length)
|
|---|
| 500 |
|
|---|
| 501 | #define bfd_coff_print_aux(abfd, file, base, symbol, aux, indaux)\
|
|---|
| 502 | ((coff_backend_info (abfd)->_bfd_coff_print_aux)\
|
|---|
| 503 | (abfd, file, base, symbol, aux, indaux))
|
|---|
| 504 |
|
|---|
| 505 | #define bfd_coff_reloc16_extra_cases(abfd, link_info, link_order,\
|
|---|
| 506 | reloc, data, src_ptr, dst_ptr)\
|
|---|
| 507 | ((coff_backend_info (abfd)->_bfd_coff_reloc16_extra_cases)\
|
|---|
| 508 | (abfd, link_info, link_order, reloc, data, src_ptr, dst_ptr))
|
|---|
| 509 |
|
|---|
| 510 | #define bfd_coff_reloc16_estimate(abfd, section, reloc, shrink, link_info)\
|
|---|
| 511 | ((coff_backend_info (abfd)->_bfd_coff_reloc16_estimate)\
|
|---|
| 512 | (abfd, section, reloc, shrink, link_info))
|
|---|
| 513 |
|
|---|
| 514 | #define bfd_coff_classify_symbol(abfd, sym)\
|
|---|
| 515 | ((coff_backend_info (abfd)->_bfd_coff_classify_symbol)\
|
|---|
| 516 | (abfd, sym))
|
|---|
| 517 |
|
|---|
| 518 | #define bfd_coff_compute_section_file_positions(abfd)\
|
|---|
| 519 | ((coff_backend_info (abfd)->_bfd_coff_compute_section_file_positions)\
|
|---|
| 520 | (abfd))
|
|---|
| 521 |
|
|---|
| 522 | #define bfd_coff_start_final_link(obfd, info)\
|
|---|
| 523 | ((coff_backend_info (obfd)->_bfd_coff_start_final_link)\
|
|---|
| 524 | (obfd, info))
|
|---|
| 525 | #define bfd_coff_relocate_section(obfd,info,ibfd,o,con,rel,isyms,secs)\
|
|---|
| 526 | ((coff_backend_info (ibfd)->_bfd_coff_relocate_section)\
|
|---|
| 527 | (obfd, info, ibfd, o, con, rel, isyms, secs))
|
|---|
| 528 | #define bfd_coff_rtype_to_howto(abfd, sec, rel, h, sym, addendp)\
|
|---|
| 529 | ((coff_backend_info (abfd)->_bfd_coff_rtype_to_howto)\
|
|---|
| 530 | (abfd, sec, rel, h, sym, addendp))
|
|---|
| 531 | #define bfd_coff_adjust_symndx(obfd, info, ibfd, sec, rel, adjustedp)\
|
|---|
| 532 | ((coff_backend_info (abfd)->_bfd_coff_adjust_symndx)\
|
|---|
| 533 | (obfd, info, ibfd, sec, rel, adjustedp))
|
|---|
| 534 | #define bfd_coff_link_add_one_symbol(info, abfd, name, flags, section,\
|
|---|
| 535 | value, string, cp, coll, hashp)\
|
|---|
| 536 | ((coff_backend_info (abfd)->_bfd_coff_link_add_one_symbol)\
|
|---|
| 537 | (info, abfd, name, flags, section, value, string, cp, coll, hashp))
|
|---|
| 538 |
|
|---|
| 539 | #define bfd_coff_link_output_has_begun(a,p) \
|
|---|
| 540 | ((coff_backend_info (a)->_bfd_coff_link_output_has_begun) (a,p))
|
|---|
| 541 | #define bfd_coff_final_link_postscript(a,p) \
|
|---|
| 542 | ((coff_backend_info (a)->_bfd_coff_final_link_postscript) (a,p))
|
|---|
| 543 |
|
|---|
| 544 | Writing relocations
|
|---|
| 545 | ...................
|
|---|
| 546 |
|
|---|
| 547 | To write relocations, the back end steps though the canonical
|
|---|
| 548 | relocation table and create an `internal_reloc'. The symbol index to
|
|---|
| 549 | use is removed from the `offset' field in the symbol table supplied.
|
|---|
| 550 | The address comes directly from the sum of the section base address and
|
|---|
| 551 | the relocation offset; the type is dug directly from the howto field.
|
|---|
| 552 | Then the `internal_reloc' is swapped into the shape of an
|
|---|
| 553 | `external_reloc' and written out to disk.
|
|---|
| 554 |
|
|---|
| 555 | Reading linenumbers
|
|---|
| 556 | ...................
|
|---|
| 557 |
|
|---|
| 558 | Creating the linenumber table is done by reading in the entire coff
|
|---|
| 559 | linenumber table, and creating another table for internal use.
|
|---|
| 560 |
|
|---|
| 561 | A coff linenumber table is structured so that each function is
|
|---|
| 562 | marked as having a line number of 0. Each line within the function is
|
|---|
| 563 | an offset from the first line in the function. The base of the line
|
|---|
| 564 | number information for the table is stored in the symbol associated
|
|---|
| 565 | with the function.
|
|---|
| 566 |
|
|---|
| 567 | Note: The PE format uses line number 0 for a flag indicating a new
|
|---|
| 568 | source file.
|
|---|
| 569 |
|
|---|
| 570 | The information is copied from the external to the internal table,
|
|---|
| 571 | and each symbol which marks a function is marked by pointing its...
|
|---|
| 572 |
|
|---|
| 573 | How does this work ?
|
|---|
| 574 |
|
|---|
| 575 | Reading relocations
|
|---|
| 576 | ...................
|
|---|
| 577 |
|
|---|
| 578 | Coff relocations are easily transformed into the internal BFD form
|
|---|
| 579 | (`arelent').
|
|---|
| 580 |
|
|---|
| 581 | Reading a coff relocation table is done in the following stages:
|
|---|
| 582 |
|
|---|
| 583 | * Read the entire coff relocation table into memory.
|
|---|
| 584 |
|
|---|
| 585 | * Process each relocation in turn; first swap it from the external
|
|---|
| 586 | to the internal form.
|
|---|
| 587 |
|
|---|
| 588 | * Turn the symbol referenced in the relocation's symbol index into a
|
|---|
| 589 | pointer into the canonical symbol table. This table is the same
|
|---|
| 590 | as the one returned by a call to `bfd_canonicalize_symtab'. The
|
|---|
| 591 | back end will call that routine and save the result if a
|
|---|
| 592 | canonicalization hasn't been done.
|
|---|
| 593 |
|
|---|
| 594 | * The reloc index is turned into a pointer to a howto structure, in
|
|---|
| 595 | a back end specific way. For instance, the 386 and 960 use the
|
|---|
| 596 | `r_type' to directly produce an index into a howto table vector;
|
|---|
| 597 | the 88k subtracts a number from the `r_type' field and creates an
|
|---|
| 598 | addend field.
|
|---|
| 599 |
|
|---|
| 600 |
|
|---|
| 601 | File: bfd.info, Node: elf, Next: mmo, Prev: coff, Up: BFD back ends
|
|---|
| 602 |
|
|---|
| 603 |
|
|---|
| 604 |
|
|---|
| 605 | ELF backends
|
|---|
| 606 |
|
|---|
| 607 | BFD support for ELF formats is being worked on. Currently, the best
|
|---|
| 608 | supported back ends are for sparc and i386 (running svr4 or Solaris 2).
|
|---|
| 609 |
|
|---|
| 610 | Documentation of the internals of the support code still needs to be
|
|---|
| 611 | written. The code is changing quickly enough that we haven't bothered
|
|---|
| 612 | yet.
|
|---|
| 613 |
|
|---|
| 614 | `bfd_elf_find_section'
|
|---|
| 615 | ......................
|
|---|
| 616 |
|
|---|
| 617 | *Synopsis*
|
|---|
| 618 | struct elf_internal_shdr *bfd_elf_find_section (bfd *abfd, char *name);
|
|---|
| 619 | *Description*
|
|---|
| 620 | Helper functions for GDB to locate the string tables. Since BFD hides
|
|---|
| 621 | string tables from callers, GDB needs to use an internal hook to find
|
|---|
| 622 | them. Sun's .stabstr, in particular, isn't even pointed to by the
|
|---|
| 623 | .stab section, so ordinary mechanisms wouldn't work to find it, even if
|
|---|
| 624 | we had some.
|
|---|
| 625 |
|
|---|
| 626 |
|
|---|
| 627 | File: bfd.info, Node: mmo, Prev: elf, Up: BFD back ends
|
|---|
| 628 |
|
|---|
| 629 | mmo backend
|
|---|
| 630 | ===========
|
|---|
| 631 |
|
|---|
| 632 | The mmo object format is used exclusively together with Professor
|
|---|
| 633 | Donald E. Knuth's educational 64-bit processor MMIX. The simulator
|
|---|
| 634 | `mmix' which is available at
|
|---|
| 635 | <http://www-cs-faculty.stanford.edu/~knuth/programs/mmix.tar.gz>
|
|---|
| 636 | understands this format. That package also includes a combined
|
|---|
| 637 | assembler and linker called `mmixal'. The mmo format has no advantages
|
|---|
| 638 | feature-wise compared to e.g. ELF. It is a simple non-relocatable
|
|---|
| 639 | object format with no support for archives or debugging information,
|
|---|
| 640 | except for symbol value information and line numbers (which is not yet
|
|---|
| 641 | implemented in BFD). See
|
|---|
| 642 | <http://www-cs-faculty.stanford.edu/~knuth/mmix.html> for more
|
|---|
| 643 | information about MMIX. The ELF format is used for intermediate object
|
|---|
| 644 | files in the BFD implementation.
|
|---|
| 645 |
|
|---|
| 646 | * Menu:
|
|---|
| 647 |
|
|---|
| 648 | * File layout::
|
|---|
| 649 | * Symbol-table::
|
|---|
| 650 | * mmo section mapping::
|
|---|
| 651 |
|
|---|
| 652 |
|
|---|
| 653 | File: bfd.info, Node: File layout, Next: Symbol-table, Prev: mmo, Up: mmo
|
|---|
| 654 |
|
|---|
| 655 | File layout
|
|---|
| 656 | -----------
|
|---|
| 657 |
|
|---|
| 658 | The mmo file contents is not partitioned into named sections as with
|
|---|
| 659 | e.g. ELF. Memory areas is formed by specifying the location of the
|
|---|
| 660 | data that follows. Only the memory area `0x0000...00' to `0x01ff...ff'
|
|---|
| 661 | is executable, so it is used for code (and constants) and the area
|
|---|
| 662 | `0x2000...00' to `0x20ff...ff' is used for writable data. *Note mmo
|
|---|
| 663 | section mapping::.
|
|---|
| 664 |
|
|---|
| 665 | Contents is entered as 32-bit words, xor:ed over previous contents,
|
|---|
| 666 | always zero-initialized. A word that starts with the byte `0x98' forms
|
|---|
| 667 | a command called a `lopcode', where the next byte distinguished between
|
|---|
| 668 | the thirteen lopcodes. The two remaining bytes, called the `Y' and `Z'
|
|---|
| 669 | fields, or the `YZ' field (a 16-bit big-endian number), are used for
|
|---|
| 670 | various purposes different for each lopcode. As documented in
|
|---|
| 671 | <http://www-cs-faculty.stanford.edu/~knuth/mmixal-intro.ps.gz>, the
|
|---|
| 672 | lopcodes are:
|
|---|
| 673 |
|
|---|
| 674 | There is provision for specifying "special data" of 65536 different
|
|---|
| 675 | types. We use type 80 (decimal), arbitrarily chosen the same as the
|
|---|
| 676 | ELF `e_machine' number for MMIX, filling it with section information
|
|---|
| 677 | normally found in ELF objects. *Note mmo section mapping::.
|
|---|
| 678 |
|
|---|
| 679 | `lop_quote'
|
|---|
| 680 | 0x98000001. The next word is contents, regardless of whether it
|
|---|
| 681 | starts with 0x98 or not.
|
|---|
| 682 |
|
|---|
| 683 | `lop_loc'
|
|---|
| 684 | 0x9801YYZZ, where `Z' is 1 or 2. This is a location directive,
|
|---|
| 685 | setting the location for the next data to the next 32-bit word
|
|---|
| 686 | (for Z = 1) or 64-bit word (for Z = 2), plus Y * 2^56. Normally
|
|---|
| 687 | `Y' is 0 for the text segment and 2 for the data segment.
|
|---|
| 688 |
|
|---|
| 689 | `lop_skip'
|
|---|
| 690 | 0x9802YYZZ. Increase the current location by `YZ' bytes.
|
|---|
| 691 |
|
|---|
| 692 | `lop_fixo'
|
|---|
| 693 | 0x9803YYZZ, where `Z' is 1 or 2. Store the current location as 64
|
|---|
| 694 | bits into the location pointed to by the next 32-bit (Z = 1) or
|
|---|
| 695 | 64-bit (Z = 2) word, plus Y * 2^56.
|
|---|
| 696 |
|
|---|
| 697 | `lop_fixr'
|
|---|
| 698 | 0x9804YYZZ. `YZ' is stored into the current location plus 2 - 4 *
|
|---|
| 699 | YZ.
|
|---|
| 700 |
|
|---|
| 701 | `lop_fixrx'
|
|---|
| 702 | 0x980500ZZ. `Z' is 16 or 24. A value `L' derived from the
|
|---|
| 703 | following 32-bit word are used in a manner similar to `YZ' in
|
|---|
| 704 | lop_fixr: it is xor:ed into the current location minus 4 * L. The
|
|---|
| 705 | first byte of the word is 0 or 1. If it is 1, then L = (LOWEST 24
|
|---|
| 706 | BITS OF WORD) - 2^Z, if 0, then L = (LOWEST 24 BITS OF WORD).
|
|---|
| 707 |
|
|---|
| 708 | `lop_file'
|
|---|
| 709 | 0x9806YYZZ. `Y' is the file number, `Z' is count of 32-bit words.
|
|---|
| 710 | Set the file number to `Y' and the line counter to 0. The next Z
|
|---|
| 711 | * 4 bytes contain the file name, padded with zeros if the count is
|
|---|
| 712 | not a multiple of four. The same `Y' may occur multiple times,
|
|---|
| 713 | but `Z' must be 0 for all but the first occurrence.
|
|---|
| 714 |
|
|---|
| 715 | `lop_line'
|
|---|
| 716 | 0x9807YYZZ. `YZ' is the line number. Together with lop_file, it
|
|---|
| 717 | forms the source location for the next 32-bit word. Note that for
|
|---|
| 718 | each non-lopcode 32-bit word, line numbers are assumed incremented
|
|---|
| 719 | by one.
|
|---|
| 720 |
|
|---|
| 721 | `lop_spec'
|
|---|
| 722 | 0x9808YYZZ. `YZ' is the type number. Data until the next lopcode
|
|---|
| 723 | other than lop_quote forms special data of type `YZ'. *Note mmo
|
|---|
| 724 | section mapping::.
|
|---|
| 725 |
|
|---|
| 726 | Other types than 80, (or type 80 with a content that does not
|
|---|
| 727 | parse) is stored in sections named `.MMIX.spec_data.N' where N is
|
|---|
| 728 | the `YZ'-type. The flags for such a sections say not to allocate
|
|---|
| 729 | or load the data. The vma is 0. Contents of multiple occurrences
|
|---|
| 730 | of special data N is concatenated to the data of the previous
|
|---|
| 731 | lop_spec Ns. The location in data or code at which the lop_spec
|
|---|
| 732 | occurred is lost.
|
|---|
| 733 |
|
|---|
| 734 | `lop_pre'
|
|---|
| 735 | 0x980901ZZ. The first lopcode in a file. The `Z' field forms the
|
|---|
| 736 | length of header information in 32-bit words, where the first word
|
|---|
| 737 | tells the time in seconds since `00:00:00 GMT Jan 1 1970'.
|
|---|
| 738 |
|
|---|
| 739 | `lop_post'
|
|---|
| 740 | 0x980a00ZZ. Z > 32. This lopcode follows after all
|
|---|
| 741 | content-generating lopcodes in a program. The `Z' field denotes
|
|---|
| 742 | the value of `rG' at the beginning of the program. The following
|
|---|
| 743 | 256 - Z big-endian 64-bit words are loaded into global registers
|
|---|
| 744 | `$G' ... `$255'.
|
|---|
| 745 |
|
|---|
| 746 | `lop_stab'
|
|---|
| 747 | 0x980b0000. The next-to-last lopcode in a program. Must follow
|
|---|
| 748 | immediately after the lop_post lopcode and its data. After this
|
|---|
| 749 | lopcode follows all symbols in a compressed format (*note
|
|---|
| 750 | Symbol-table::).
|
|---|
| 751 |
|
|---|
| 752 | `lop_end'
|
|---|
| 753 | 0x980cYYZZ. The last lopcode in a program. It must follow the
|
|---|
| 754 | lop_stab lopcode and its data. The `YZ' field contains the number
|
|---|
| 755 | of 32-bit words of symbol table information after the preceding
|
|---|
| 756 | lop_stab lopcode.
|
|---|
| 757 |
|
|---|
| 758 | Note that the lopcode "fixups"; `lop_fixr', `lop_fixrx' and
|
|---|
| 759 | `lop_fixo' are not generated by BFD, but are handled. They are
|
|---|
| 760 | generated by `mmixal'.
|
|---|
| 761 |
|
|---|
| 762 | This trivial one-label, one-instruction file:
|
|---|
| 763 |
|
|---|
| 764 | :Main TRAP 1,2,3
|
|---|
| 765 |
|
|---|
| 766 | can be represented this way in mmo:
|
|---|
| 767 |
|
|---|
| 768 | 0x98090101 - lop_pre, one 32-bit word with timestamp.
|
|---|
| 769 | <timestamp>
|
|---|
| 770 | 0x98010002 - lop_loc, text segment, using a 64-bit address.
|
|---|
| 771 | Note that mmixal does not emit this for the file above.
|
|---|
| 772 | 0x00000000 - Address, high 32 bits.
|
|---|
| 773 | 0x00000000 - Address, low 32 bits.
|
|---|
| 774 | 0x98060002 - lop_file, 2 32-bit words for file-name.
|
|---|
| 775 | 0x74657374 - "test"
|
|---|
| 776 | 0x2e730000 - ".s\0\0"
|
|---|
| 777 | 0x98070001 - lop_line, line 1.
|
|---|
| 778 | 0x00010203 - TRAP 1,2,3
|
|---|
| 779 | 0x980a00ff - lop_post, setting $255 to 0.
|
|---|
| 780 | 0x00000000
|
|---|
| 781 | 0x00000000
|
|---|
| 782 | 0x980b0000 - lop_stab for ":Main" = 0, serial 1.
|
|---|
| 783 | 0x203a4040 *Note Symbol-table::.
|
|---|
| 784 | 0x10404020
|
|---|
| 785 | 0x4d206120
|
|---|
| 786 | 0x69016e00
|
|---|
| 787 | 0x81000000
|
|---|
| 788 | 0x980c0005 - lop_end; symbol table contained five 32-bit words.
|
|---|
| 789 |
|
|---|
| 790 |
|
|---|
| 791 | File: bfd.info, Node: Symbol-table, Next: mmo section mapping, Prev: File layout, Up: mmo
|
|---|
| 792 |
|
|---|
| 793 | Symbol table format
|
|---|
| 794 | -------------------
|
|---|
| 795 |
|
|---|
| 796 | From mmixal.w (or really, the generated mmixal.tex) in
|
|---|
| 797 | <http://www-cs-faculty.stanford.edu/~knuth/programs/mmix.tar.gz>):
|
|---|
| 798 | "Symbols are stored and retrieved by means of a `ternary search trie',
|
|---|
| 799 | following ideas of Bentley and Sedgewick. (See ACM-SIAM Symp. on
|
|---|
| 800 | Discrete Algorithms `8' (1997), 360-369; R.Sedgewick, `Algorithms in C'
|
|---|
| 801 | (Reading, Mass. Addison-Wesley, 1998), `15.4'.) Each trie node stores
|
|---|
| 802 | a character, and there are branches to subtries for the cases where a
|
|---|
| 803 | given character is less than, equal to, or greater than the character
|
|---|
| 804 | in the trie. There also is a pointer to a symbol table entry if a
|
|---|
| 805 | symbol ends at the current node."
|
|---|
| 806 |
|
|---|
| 807 | So it's a tree encoded as a stream of bytes. The stream of bytes
|
|---|
| 808 | acts on a single virtual global symbol, adding and removing characters
|
|---|
| 809 | and signalling complete symbol points. Here, we read the stream and
|
|---|
| 810 | create symbols at the completion points.
|
|---|
| 811 |
|
|---|
| 812 | First, there's a control byte `m'. If any of the listed bits in `m'
|
|---|
| 813 | is nonzero, we execute what stands at the right, in the listed order:
|
|---|
| 814 |
|
|---|
| 815 | (MMO3_LEFT)
|
|---|
| 816 | 0x40 - Traverse left trie.
|
|---|
| 817 | (Read a new command byte and recurse.)
|
|---|
| 818 |
|
|---|
| 819 | (MMO3_SYMBITS)
|
|---|
| 820 | 0x2f - Read the next byte as a character and store it in the
|
|---|
| 821 | current character position; increment character position.
|
|---|
| 822 | Test the bits of `m':
|
|---|
| 823 |
|
|---|
| 824 | (MMO3_WCHAR)
|
|---|
| 825 | 0x80 - The character is 16-bit (so read another byte,
|
|---|
| 826 | merge into current character.
|
|---|
| 827 |
|
|---|
| 828 | (MMO3_TYPEBITS)
|
|---|
| 829 | 0xf - We have a complete symbol; parse the type, value
|
|---|
| 830 | and serial number and do what should be done
|
|---|
| 831 | with a symbol. The type and length information
|
|---|
| 832 | is in j = (m & 0xf).
|
|---|
| 833 |
|
|---|
| 834 | (MMO3_REGQUAL_BITS)
|
|---|
| 835 | j == 0xf: A register variable. The following
|
|---|
| 836 | byte tells which register.
|
|---|
| 837 | j <= 8: An absolute symbol. Read j bytes as the
|
|---|
| 838 | big-endian number the symbol equals.
|
|---|
| 839 | A j = 2 with two zero bytes denotes an
|
|---|
| 840 | unknown symbol.
|
|---|
| 841 | j > 8: As with j <= 8, but add (0x20 << 56)
|
|---|
| 842 | to the value in the following j - 8
|
|---|
| 843 | bytes.
|
|---|
| 844 |
|
|---|
| 845 | Then comes the serial number, as a variant of
|
|---|
| 846 | uleb128, but better named ubeb128:
|
|---|
| 847 | Read bytes and shift the previous value left 7
|
|---|
| 848 | (multiply by 128). Add in the new byte, repeat
|
|---|
| 849 | until a byte has bit 7 set. The serial number
|
|---|
| 850 | is the computed value minus 128.
|
|---|
| 851 |
|
|---|
| 852 | (MMO3_MIDDLE)
|
|---|
| 853 | 0x20 - Traverse middle trie. (Read a new command byte
|
|---|
| 854 | and recurse.) Decrement character position.
|
|---|
| 855 |
|
|---|
| 856 | (MMO3_RIGHT)
|
|---|
| 857 | 0x10 - Traverse right trie. (Read a new command byte and
|
|---|
| 858 | recurse.)
|
|---|
| 859 |
|
|---|
| 860 | Let's look again at the `lop_stab' for the trivial file (*note File
|
|---|
| 861 | layout::).
|
|---|
| 862 |
|
|---|
| 863 | 0x980b0000 - lop_stab for ":Main" = 0, serial 1.
|
|---|
| 864 | 0x203a4040
|
|---|
| 865 | 0x10404020
|
|---|
| 866 | 0x4d206120
|
|---|
| 867 | 0x69016e00
|
|---|
| 868 | 0x81000000
|
|---|
| 869 |
|
|---|
| 870 | This forms the trivial trie (note that the path between ":" and "M"
|
|---|
| 871 | is redundant):
|
|---|
| 872 |
|
|---|
| 873 | 203a ":"
|
|---|
| 874 | 40 /
|
|---|
| 875 | 40 /
|
|---|
| 876 | 10 \
|
|---|
| 877 | 40 /
|
|---|
| 878 | 40 /
|
|---|
| 879 | 204d "M"
|
|---|
| 880 | 2061 "a"
|
|---|
| 881 | 2069 "i"
|
|---|
| 882 | 016e "n" is the last character in a full symbol, and
|
|---|
| 883 | with a value represented in one byte.
|
|---|
| 884 | 00 The value is 0.
|
|---|
| 885 | 81 The serial number is 1.
|
|---|
| 886 |
|
|---|
| 887 |
|
|---|
| 888 | File: bfd.info, Node: mmo section mapping, Prev: Symbol-table, Up: mmo
|
|---|
| 889 |
|
|---|
| 890 | mmo section mapping
|
|---|
| 891 | -------------------
|
|---|
| 892 |
|
|---|
| 893 | The implementation in BFD uses special data type 80 (decimal) to
|
|---|
| 894 | encapsulate and describe named sections, containing e.g. debug
|
|---|
| 895 | information. If needed, any datum in the encapsulation will be quoted
|
|---|
| 896 | using lop_quote. First comes a 32-bit word holding the number of
|
|---|
| 897 | 32-bit words containing the zero-terminated zero-padded segment name.
|
|---|
| 898 | After the name there's a 32-bit word holding flags describing the
|
|---|
| 899 | section type. Then comes a 64-bit big-endian word with the section
|
|---|
| 900 | length (in bytes), then another with the section start address.
|
|---|
| 901 | Depending on the type of section, the contents might follow,
|
|---|
| 902 | zero-padded to 32-bit boundary. For a loadable section (such as data
|
|---|
| 903 | or code), the contents might follow at some later point, not
|
|---|
| 904 | necessarily immediately, as a lop_loc with the same start address as in
|
|---|
| 905 | the section description, followed by the contents. This in effect
|
|---|
| 906 | forms a descriptor that must be emitted before the actual contents.
|
|---|
| 907 | Sections described this way must not overlap.
|
|---|
| 908 |
|
|---|
| 909 | For areas that don't have such descriptors, synthetic sections are
|
|---|
| 910 | formed by BFD. Consecutive contents in the two memory areas
|
|---|
| 911 | `0x0000...00' to `0x01ff...ff' and `0x2000...00' to `0x20ff...ff' are
|
|---|
| 912 | entered in sections named `.text' and `.data' respectively. If an area
|
|---|
| 913 | is not otherwise described, but would together with a neighboring lower
|
|---|
| 914 | area be less than `0x40000000' bytes long, it is joined with the lower
|
|---|
| 915 | area and the gap is zero-filled. For other cases, a new section is
|
|---|
| 916 | formed, named `.MMIX.sec.N'. Here, N is a number, a running count
|
|---|
| 917 | through the mmo file, starting at 0.
|
|---|
| 918 |
|
|---|
| 919 | A loadable section specified as:
|
|---|
| 920 |
|
|---|
| 921 | .section secname,"ax"
|
|---|
| 922 | TETRA 1,2,3,4,-1,-2009
|
|---|
| 923 | BYTE 80
|
|---|
| 924 |
|
|---|
| 925 | and linked to address `0x4', is represented by the sequence:
|
|---|
| 926 |
|
|---|
| 927 | 0x98080050 - lop_spec 80
|
|---|
| 928 | 0x00000002 - two 32-bit words for the section name
|
|---|
| 929 | 0x7365636e - "secn"
|
|---|
| 930 | 0x616d6500 - "ame\0"
|
|---|
| 931 | 0x00000033 - flags CODE, READONLY, LOAD, ALLOC
|
|---|
| 932 | 0x00000000 - high 32 bits of section length
|
|---|
| 933 | 0x0000001c - section length is 28 bytes; 6 * 4 + 1 + alignment to 32 bits
|
|---|
| 934 | 0x00000000 - high 32 bits of section address
|
|---|
| 935 | 0x00000004 - section address is 4
|
|---|
| 936 | 0x98010002 - 64 bits with address of following data
|
|---|
| 937 | 0x00000000 - high 32 bits of address
|
|---|
| 938 | 0x00000004 - low 32 bits: data starts at address 4
|
|---|
| 939 | 0x00000001 - 1
|
|---|
| 940 | 0x00000002 - 2
|
|---|
| 941 | 0x00000003 - 3
|
|---|
| 942 | 0x00000004 - 4
|
|---|
| 943 | 0xffffffff - -1
|
|---|
| 944 | 0xfffff827 - -2009
|
|---|
| 945 | 0x50000000 - 80 as a byte, padded with zeros.
|
|---|
| 946 |
|
|---|
| 947 | Note that the lop_spec wrapping does not include the section
|
|---|
| 948 | contents. Compare this to a non-loaded section specified as:
|
|---|
| 949 |
|
|---|
| 950 | .section thirdsec
|
|---|
| 951 | TETRA 200001,100002
|
|---|
| 952 | BYTE 38,40
|
|---|
| 953 |
|
|---|
| 954 | This, when linked to address `0x200000000000001c', is represented by:
|
|---|
| 955 |
|
|---|
| 956 | 0x98080050 - lop_spec 80
|
|---|
| 957 | 0x00000002 - two 32-bit words for the section name
|
|---|
| 958 | 0x7365636e - "thir"
|
|---|
| 959 | 0x616d6500 - "dsec"
|
|---|
| 960 | 0x00000010 - flag READONLY
|
|---|
| 961 | 0x00000000 - high 32 bits of section length
|
|---|
| 962 | 0x0000000c - section length is 12 bytes; 2 * 4 + 2 + alignment to 32 bits
|
|---|
| 963 | 0x20000000 - high 32 bits of address
|
|---|
| 964 | 0x0000001c - low 32 bits of address 0x200000000000001c
|
|---|
| 965 | 0x00030d41 - 200001
|
|---|
| 966 | 0x000186a2 - 100002
|
|---|
| 967 | 0x26280000 - 38, 40 as bytes, padded with zeros
|
|---|
| 968 |
|
|---|
| 969 | For the latter example, the section contents must not be loaded in
|
|---|
| 970 | memory, and is therefore specified as part of the special data. The
|
|---|
| 971 | address is usually unimportant but might provide information for e.g.
|
|---|
| 972 | the DWARF 2 debugging format.
|
|---|
| 973 |
|
|---|
