📄 bfd-information-loss.html

📁 gcc手册
💻 HTML
字号:
<html lang="en">

<head>

<title>Untitled</title>

<meta http-equiv="Content-Type" content="text/html">

<meta name="description" content="Untitled">

<meta name="generator" content="makeinfo 4.3">

<link href="http://www.gnu.org/software/texinfo/" rel="generator-home">

</head>

<body>

<div class="node">

<p>

Node:<a name="BFD%20information%20loss">BFD information loss</a>,

Next:<a rel="next" accesskey="n" href="Canonical-format.html#Canonical%20format">Canonical format</a>,

Up:<a rel="up" accesskey="u" href="BFD-outline.html#BFD%20outline">BFD outline</a>

<hr><br>

</div>



<h4 class="subsection">Information Loss</h4>



   <p><em>Information can be lost during output.</em> The output formats

supported by BFD do not provide identical facilities, and

information which can be described in one form has nowhere to go in

another format. One example of this is alignment information in

<code>b.out</code>. There is nowhere in an <code>a.out</code> format file to store

alignment information on the contained data, so when a file is linked

from <code>b.out</code> and an <code>a.out</code> image is produced, alignment

information will not propagate to the output file. (The linker will

still use the alignment information internally, so the link is performed

correctly).



   <p>Another example is COFF section names. COFF files may contain an

unlimited number of sections, each one with a textual section name. If

the target of the link is a format which does not have many sections (e.g.,

<code>a.out</code>) or has sections without names (e.g., the Oasys format), the

link cannot be done simply. You can circumvent this problem by

describing the desired input-to-output section mapping with the linker command

language.



   <p><em>Information can be lost during canonicalization.</em> The BFD

internal canonical form of the external formats is not exhaustive; there

are structures in input formats for which there is no direct

representation internally.  This means that the BFD back ends

cannot maintain all possible data richness through the transformation

between external to internal and back to external formats.



   <p>This limitation is only a problem when an application reads one

format and writes another.  Each BFD back end is responsible for

maintaining as much data as possible, and the internal BFD

canonical form has structures which are opaque to the BFD core,

and exported only to the back ends. When a file is read in one format,

the canonical form is generated for BFD and the application. At the

same time, the back end saves away any information which may otherwise

be lost. If the data is then written back in the same format, the back

end routine will be able to use the canonical form provided by the

BFD core as well as the information it prepared earlier.  Since

there is a great deal of commonality between back ends,

there is no information lost when

linking or copying big endian COFF to little endian COFF, or <code>a.out</code> to

<code>b.out</code>.  When a mixture of formats is linked, the information is

only lost from the files whose format differs from the destination.



   </body></html>
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -