You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
173 lines
8.1 KiB
HTML
173 lines
8.1 KiB
HTML
4 years ago
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||
|
|
<html>
|
||
|
|
<!-- This file documents the BFD library.
|
||
|
|
|
||
|
|
Copyright (C) 1991-2019 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.3 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. -->
|
||
|
|
<!-- Created by GNU Texinfo 6.4, http://www.gnu.org/software/texinfo/ -->
|
||
|
|
<head>
|
||
|
|
<title>Canonical format (Untitled Document)</title>
|
||
|
|
|
||
|
|
<meta name="description" content="Canonical format (Untitled Document)">
|
||
|
|
<meta name="keywords" content="Canonical format (Untitled Document)">
|
||
|
|
<meta name="resource-type" content="document">
|
||
|
|
<meta name="distribution" content="global">
|
||
|
|
<meta name="Generator" content="makeinfo">
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<link href="index.html#Top" rel="start" title="Top">
|
||
|
|
<link href="BFD-Index.html#BFD-Index" rel="index" title="BFD Index">
|
||
|
|
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
|
||
|
|
<link href="What-BFD-Version-2-Can-Do.html#What-BFD-Version-2-Can-Do" rel="up" title="What BFD Version 2 Can Do">
|
||
|
|
<link href="BFD-front-end.html#BFD-front-end" rel="next" title="BFD front end">
|
||
|
|
<link href="BFD-information-loss.html#BFD-information-loss" rel="prev" title="BFD information loss">
|
||
|
|
<style type="text/css">
|
||
|
|
<!--
|
||
|
|
a.summary-letter {text-decoration: none}
|
||
|
|
blockquote.indentedblock {margin-right: 0em}
|
||
|
|
blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
|
||
|
|
blockquote.smallquotation {font-size: smaller}
|
||
|
|
div.display {margin-left: 3.2em}
|
||
|
|
div.example {margin-left: 3.2em}
|
||
|
|
div.lisp {margin-left: 3.2em}
|
||
|
|
div.smalldisplay {margin-left: 3.2em}
|
||
|
|
div.smallexample {margin-left: 3.2em}
|
||
|
|
div.smalllisp {margin-left: 3.2em}
|
||
|
|
kbd {font-style: oblique}
|
||
|
|
pre.display {font-family: inherit}
|
||
|
|
pre.format {font-family: inherit}
|
||
|
|
pre.menu-comment {font-family: serif}
|
||
|
|
pre.menu-preformatted {font-family: serif}
|
||
|
|
pre.smalldisplay {font-family: inherit; font-size: smaller}
|
||
|
|
pre.smallexample {font-size: smaller}
|
||
|
|
pre.smallformat {font-family: inherit; font-size: smaller}
|
||
|
|
pre.smalllisp {font-size: smaller}
|
||
|
|
span.nolinebreak {white-space: nowrap}
|
||
|
|
span.roman {font-family: initial; font-weight: normal}
|
||
|
|
span.sansserif {font-family: sans-serif; font-weight: normal}
|
||
|
|
ul.no-bullet {list-style: none}
|
||
|
|
-->
|
||
|
|
</style>
|
||
|
|
|
||
|
|
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body lang="en">
|
||
|
|
<a name="Canonical-format"></a>
|
||
|
|
<div class="header">
|
||
|
|
<p>
|
||
|
|
Previous: <a href="BFD-information-loss.html#BFD-information-loss" accesskey="p" rel="prev">BFD information loss</a>, Up: <a href="What-BFD-Version-2-Can-Do.html#What-BFD-Version-2-Can-Do" accesskey="u" rel="up">What BFD Version 2 Can Do</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="BFD-Index.html#BFD-Index" title="Index" rel="index">Index</a>]</p>
|
||
|
|
</div>
|
||
|
|
<hr>
|
||
|
|
<a name="The-BFD-canonical-object_002dfile-format"></a>
|
||
|
|
<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"></a>
|
||
|
|
<a name="index-internal-object_002dfile-format"></a>
|
||
|
|
</p>
|
||
|
|
<dl compact="compact">
|
||
|
|
<dt><em>files</em></dt>
|
||
|
|
<dd><p>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.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><em>sections</em></dt>
|
||
|
|
<dd><p>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.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><em>symbols</em></dt>
|
||
|
|
<dd><p>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>
|
||
|
|
<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>
|
||
|
|
<p>There is one word of type information within the symbol, so if the
|
||
|
|
format supports symbol type information within symbols (for example, COFF,
|
||
|
|
Oasys) and the type is simple enough to fit within one word
|
||
|
|
(nearly everything but aggregates), the information will be preserved.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><em>relocation level</em></dt>
|
||
|
|
<dd><p>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.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><em>line numbers</em></dt>
|
||
|
|
<dd><p>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.
|
||
|
|
</p></dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<hr>
|
||
|
|
<div class="header">
|
||
|
|
<p>
|
||
|
|
Previous: <a href="BFD-information-loss.html#BFD-information-loss" accesskey="p" rel="prev">BFD information loss</a>, Up: <a href="What-BFD-Version-2-Can-Do.html#What-BFD-Version-2-Can-Do" accesskey="u" rel="up">What BFD Version 2 Can Do</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="BFD-Index.html#BFD-Index" title="Index" rel="index">Index</a>]</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|