127 lines
6.4 KiB
HTML
127 lines
6.4 KiB
HTML
|
<html lang="en">
|
||
|
|
<head>
|
||
|
|
<title>Canonical format - Untitled</title>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html">
|
||
|
|
<meta name="description" content="Untitled">
|
||
|
|
<meta name="generator" content="makeinfo 4.7">
|
||
|
|
<link title="Top" rel="start" href="index.html#Top">
|
||
|
|
<link rel="up" href="What-BFD-Version-2-Can-Do.html#What-BFD-Version-2-Can-Do" title="What BFD Version 2 Can Do">
|
||
|
|
<link rel="prev" href="BFD-information-loss.html#BFD-information-loss" title="BFD information loss">
|
||
|
|
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||
|
|
<!--
|
||
|
|
This file documents the BFD library.
|
||
|
|
|
||
|
|
Copyright (C) 1991, 2000, 2001, 2003, 2006, 2007 Free Software Foundation, Inc.
|
||
|
|
|
||
|
|
Permission is granted to copy, distribute and/or modify this document
|
||
|
|
under the terms of the GNU Free Documentation License, Version 1.1 or
|
||
|
|
any later version published by the Free Software Foundation; with the
|
||
|
|
Invariant Sections being ``GNU General Public License'' and ``Funding
|
||
|
|
Free Software'', the Front-Cover texts being (a) (see below), and with
|
||
|
|
the Back-Cover Texts being (b) (see below). A copy of the license is
|
||
|
|
included in the section entitled ``GNU Free Documentation License''.
|
||
|
|
|
||
|
|
(a) The FSF's Front-Cover Text is:
|
||
|
|
|
||
|
|
A GNU Manual
|
||
|
|
|
||
|
|
(b) The FSF's Back-Cover Text is:
|
||
|
|
|
||
|
|
You have freedom to copy and modify this GNU Manual, like GNU
|
||
|
|
software. Copies published by the Free Software Foundation raise
|
||
|
|
funds for GNU development.-->
|
||
|
|
<meta http-equiv="Content-Style-Type" content="text/css">
|
||
|
|
<style type="text/css"><!--
|
||
|
|
pre.display { font-family:inherit }
|
||
|
|
pre.format { font-family:inherit }
|
||
|
|
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||
|
|
pre.smallformat { font-family:inherit; font-size:smaller }
|
||
|
|
pre.smallexample { font-size:smaller }
|
||
|
|
pre.smalllisp { font-size:smaller }
|
||
|
|
span.sc { font-variant:small-caps }
|
||
|
|
span.roman { font-family: serif; font-weight: normal; }
|
||
|
|
--></style>
|
||
|
|
</head>
|
||
|
|
<body>
|
||
|
|
<div class="node">
|
||
|
|
<p>
|
||
|
|
<a name="Canonical-format"></a>Previous: <a rel="previous" accesskey="p" href="BFD-information-loss.html#BFD-information-loss">BFD information loss</a>,
|
||
|
|
Up: <a rel="up" accesskey="u" href="What-BFD-Version-2-Can-Do.html#What-BFD-Version-2-Can-Do">What BFD Version 2 Can Do</a>
|
||
|
|
<hr><br>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
<h4 class="subsection">1.3.2 The BFD canonical object-file format</h4>
|
||
|
|
|
||
|
|
<p>The greatest potential for loss of information occurs when there is the least
|
||
|
|
overlap between the information provided by the source format, that
|
||
|
|
stored by the canonical format, and that needed by the
|
||
|
|
destination format. A brief description of the canonical form may help
|
||
|
|
you understand which kinds of data you can count on preserving across
|
||
|
|
conversions.
|
||
|
|
<a name="index-BFD-canonical-format-3"></a><a name="index-internal-object_002dfile-format-4"></a>
|
||
|
|
<dl>
|
||
|
|
<dt><em>files</em><dd>Information stored on a per-file basis includes target machine
|
||
|
|
architecture, particular implementation format type, a demand pageable
|
||
|
|
bit, and a write protected bit. Information like Unix magic numbers is
|
||
|
|
not stored here—only the magic numbers' meaning, so a <code>ZMAGIC</code>
|
||
|
|
file would have both the demand pageable bit and the write protected
|
||
|
|
text bit set. The byte order of the target is stored on a per-file
|
||
|
|
basis, so that big- and little-endian object files may be used with one
|
||
|
|
another.
|
||
|
|
|
||
|
|
<br><dt><em>sections</em><dd>Each section in the input file contains the name of the section, the
|
||
|
|
section's original address in the object file, size and alignment
|
||
|
|
information, various flags, and pointers into other BFD data
|
||
|
|
structures.
|
||
|
|
|
||
|
|
<br><dt><em>symbols</em><dd>Each symbol contains a pointer to the information for the object file
|
||
|
|
which originally defined it, its name, its value, and various flag
|
||
|
|
bits. When a BFD back end reads in a symbol table, it relocates all
|
||
|
|
symbols to make them relative to the base of the section where they were
|
||
|
|
defined. Doing this ensures that each symbol points to its containing
|
||
|
|
section. Each symbol also has a varying amount of hidden private data
|
||
|
|
for the BFD back end. Since the symbol points to the original file, the
|
||
|
|
private data format for that symbol is accessible. <code>ld</code> can
|
||
|
|
operate on a collection of symbols of wildly different formats without
|
||
|
|
problems.
|
||
|
|
|
||
|
|
<p>Normal global and simple local symbols are maintained on output, so an
|
||
|
|
output file (no matter its format) will retain symbols pointing to
|
||
|
|
functions and to global, static, and common variables. Some symbol
|
||
|
|
information is not worth retaining; in <code>a.out</code>, type information is
|
||
|
|
stored in the symbol table as long symbol names. This information would
|
||
|
|
be useless to most COFF debuggers; the linker has command line switches
|
||
|
|
to allow users to throw it away.
|
||
|
|
|
||
|
|
<p>There is one word of type information within the symbol, so if the
|
||
|
|
format supports symbol type information within symbols (for example, COFF,
|
||
|
|
IEEE, Oasys) and the type is simple enough to fit within one word
|
||
|
|
(nearly everything but aggregates), the information will be preserved.
|
||
|
|
|
||
|
|
<br><dt><em>relocation level</em><dd>Each canonical BFD relocation record contains a pointer to the symbol to
|
||
|
|
relocate to, the offset of the data to relocate, the section the data
|
||
|
|
is in, and a pointer to a relocation type descriptor. Relocation is
|
||
|
|
performed by passing messages through the relocation type
|
||
|
|
descriptor and the symbol pointer. Therefore, relocations can be performed
|
||
|
|
on output data using a relocation method that is only available in one of the
|
||
|
|
input formats. For instance, Oasys provides a byte relocation format.
|
||
|
|
A relocation record requesting this relocation type would point
|
||
|
|
indirectly to a routine to perform this, so the relocation may be
|
||
|
|
performed on a byte being written to a 68k COFF file, even though 68k COFF
|
||
|
|
has no such relocation type.
|
||
|
|
|
||
|
|
<br><dt><em>line numbers</em><dd>Object formats can contain, for debugging purposes, some form of mapping
|
||
|
|
between symbols, source line numbers, and addresses in the output file.
|
||
|
|
These addresses have to be relocated along with the symbol information.
|
||
|
|
Each symbol with an associated list of line number records points to the
|
||
|
|
first record of the list. The head of a line number list consists of a
|
||
|
|
pointer to the symbol, which allows finding out the address of the
|
||
|
|
function whose line number is being described. The rest of the list is
|
||
|
|
made up of pairs: offsets into the section and line numbers. Any format
|
||
|
|
which can simply derive this information can pass it successfully
|
||
|
|
between formats (COFF, IEEE and Oasys).
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
</body></html>
|
||
|
|
|