arduino-0018-windows
This commit is contained in:
parent
157fd6f1a1
commit
f39fc49523
5182 changed files with 950586 additions and 0 deletions
|
|
@ -0,0 +1,118 @@
|
|||
<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="BFD-outline.html#BFD-outline" title="BFD outline">
|
||||
<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 GNU linker LD
|
||||
(GNU Binutils)
|
||||
version 2.19.
|
||||
|
||||
Copyright (C) 1991, 92, 93, 94, 95, 96, 97, 98, 99, 2000,
|
||||
2001, 2002, 2003, 2004, 2005, 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 no Invariant Sections, with no Front-Cover Texts, and with no
|
||||
Back-Cover Texts. A copy of the license is included in the
|
||||
section entitled ``GNU Free Documentation License''.-->
|
||||
<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="BFD-outline.html#BFD-outline">BFD outline</a>
|
||||
<hr><br>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">5.1.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-636"></a><a name="index-internal-object_002dfile-format-637"></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>
|
||||
|
||||
Reference in a new issue