toolchain/gcc-linaro-6.3.1-2017.02-x8.../share/doc/gcc/Compatibility.html

237 lines
11 KiB
HTML
Raw Permalink Normal View History

2024-03-22 05:10:17 +00:00
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Copyright (C) 1988-2016 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 "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 5.2, http://www.gnu.org/software/texinfo/ -->
<head>
<title>Using the GNU Compiler Collection (GCC): Compatibility</title>
<meta name="description" content="Using the GNU Compiler Collection (GCC): Compatibility">
<meta name="keywords" content="Using the GNU Compiler Collection (GCC): Compatibility">
<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="Option-Index.html#Option-Index" rel="index" title="Option Index">
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="index.html#Top" rel="up" title="Top">
<link href="Gcov.html#Gcov" rel="next" title="Gcov">
<link href="Forwarding-hook.html#Forwarding-hook" rel="prev" title="Forwarding hook">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.indentedblock {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
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.nocodebreak {white-space:nowrap}
span.nolinebreak {white-space:nowrap}
span.roman {font-family:serif; font-weight:normal}
span.sansserif {font-family:sans-serif; font-weight:normal}
ul.no-bullet {list-style: none}
-->
</style>
</head>
<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<a name="Compatibility"></a>
<div class="header">
<p>
Next: <a href="Gcov.html#Gcov" accesskey="n" rel="next">Gcov</a>, Previous: <a href="Objective_002dC.html#Objective_002dC" accesskey="p" rel="prev">Objective-C</a>, Up: <a href="index.html#Top" accesskey="u" rel="up">Top</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
</div>
<hr>
<a name="Binary-Compatibility"></a>
<h2 class="chapter">9 Binary Compatibility</h2>
<a name="index-binary-compatibility"></a>
<a name="index-ABI"></a>
<a name="index-application-binary-interface"></a>
<p>Binary compatibility encompasses several related concepts:
</p>
<dl compact="compact">
<dt><em>application binary interface (ABI)</em></dt>
<dd><p>The set of runtime conventions followed by all of the tools that deal
with binary representations of a program, including compilers, assemblers,
linkers, and language runtime support.
Some ABIs are formal with a written specification, possibly designed
by multiple interested parties. Others are simply the way things are
actually done by a particular set of tools.
</p>
</dd>
<dt><em>ABI conformance</em></dt>
<dd><p>A compiler conforms to an ABI if it generates code that follows all of
the specifications enumerated by that ABI.
A library conforms to an ABI if it is implemented according to that ABI.
An application conforms to an ABI if it is built using tools that conform
to that ABI and does not contain source code that specifically changes
behavior specified by the ABI.
</p>
</dd>
<dt><em>calling conventions</em></dt>
<dd><p>Calling conventions are a subset of an ABI that specify of how arguments
are passed and function results are returned.
</p>
</dd>
<dt><em>interoperability</em></dt>
<dd><p>Different sets of tools are interoperable if they generate files that
can be used in the same program. The set of tools includes compilers,
assemblers, linkers, libraries, header files, startup files, and debuggers.
Binaries produced by different sets of tools are not interoperable unless
they implement the same ABI. This applies to different versions of the
same tools as well as tools from different vendors.
</p>
</dd>
<dt><em>intercallability</em></dt>
<dd><p>Whether a function in a binary built by one set of tools can call a
function in a binary built by a different set of tools is a subset
of interoperability.
</p>
</dd>
<dt><em>implementation-defined features</em></dt>
<dd><p>Language standards include lists of implementation-defined features whose
behavior can vary from one implementation to another. Some of these
features are normally covered by a platform&rsquo;s ABI and others are not.
The features that are not covered by an ABI generally affect how a
program behaves, but not intercallability.
</p>
</dd>
<dt><em>compatibility</em></dt>
<dd><p>Conformance to the same ABI and the same behavior of implementation-defined
features are both relevant for compatibility.
</p></dd>
</dl>
<p>The application binary interface implemented by a C or C++ compiler
affects code generation and runtime support for:
</p>
<ul>
<li> size and alignment of data types
</li><li> layout of structured types
</li><li> calling conventions
</li><li> register usage conventions
</li><li> interfaces for runtime arithmetic support
</li><li> object file formats
</li></ul>
<p>In addition, the application binary interface implemented by a C++ compiler
affects code generation and runtime support for:
</p><ul>
<li> name mangling
</li><li> exception handling
</li><li> invoking constructors and destructors
</li><li> layout, alignment, and padding of classes
</li><li> layout and alignment of virtual tables
</li></ul>
<p>Some GCC compilation options cause the compiler to generate code that
does not conform to the platform&rsquo;s default ABI. Other options cause
different program behavior for implementation-defined features that are
not covered by an ABI. These options are provided for consistency with
other compilers that do not follow the platform&rsquo;s default ABI or the
usual behavior of implementation-defined features for the platform.
Be very careful about using such options.
</p>
<p>Most platforms have a well-defined ABI that covers C code, but ABIs
that cover C++ functionality are not yet common.
</p>
<p>Starting with GCC 3.2, GCC binary conventions for C++ are based on a
written, vendor-neutral C++ ABI that was designed to be specific to
64-bit Itanium but also includes generic specifications that apply to
any platform.
This C++ ABI is also implemented by other compiler vendors on some
platforms, notably GNU/Linux and BSD systems.
We have tried hard to provide a stable ABI that will be compatible with
future GCC releases, but it is possible that we will encounter problems
that make this difficult. Such problems could include different
interpretations of the C++ ABI by different vendors, bugs in the ABI, or
bugs in the implementation of the ABI in different compilers.
GCC&rsquo;s <samp>-Wabi</samp> switch warns when G++ generates code that is
probably not compatible with the C++ ABI.
</p>
<p>The C++ library used with a C++ compiler includes the Standard C++
Library, with functionality defined in the C++ Standard, plus language
runtime support. The runtime support is included in a C++ ABI, but there
is no formal ABI for the Standard C++ Library. Two implementations
of that library are interoperable if one follows the de-facto ABI of the
other and if they are both built with the same compiler, or with compilers
that conform to the same ABI for C++ compiler and runtime support.
</p>
<p>When G++ and another C++ compiler conform to the same C++ ABI, but the
implementations of the Standard C++ Library that they normally use do not
follow the same ABI for the Standard C++ Library, object files built with
those compilers can be used in the same program only if they use the same
C++ library. This requires specifying the location of the C++ library
header files when invoking the compiler whose usual library is not being
used. The location of GCC&rsquo;s C++ header files depends on how the GCC
build was configured, but can be seen by using the G++ <samp>-v</samp> option.
With default configuration options for G++ 3.3 the compile line for a
different C++ compiler needs to include
</p>
<div class="smallexample">
<pre class="smallexample"> -I<var>gcc_install_directory</var>/include/c++/3.3
</pre></div>
<p>Similarly, compiling code with G++ that must use a C++ library other
than the GNU C++ library requires specifying the location of the header
files for that other library.
</p>
<p>The most straightforward way to link a program to use a particular
C++ library is to use a C++ driver that specifies that C++ library by
default. The <code>g++</code> driver, for example, tells the linker where
to find GCC&rsquo;s C++ library (<samp>libstdc++</samp>) plus the other libraries
and startup files it needs, in the proper order.
</p>
<p>If a program must use a different C++ library and it&rsquo;s not possible
to do the final link using a C++ driver that uses that library by default,
it is necessary to tell <code>g++</code> the location and name of that
library. It might also be necessary to specify different startup files
and other runtime support libraries, and to suppress the use of GCC&rsquo;s
support libraries with one or more of the options <samp>-nostdlib</samp>,
<samp>-nostartfiles</samp>, and <samp>-nodefaultlibs</samp>.
</p>
<hr>
<div class="header">
<p>
Next: <a href="Gcov.html#Gcov" accesskey="n" rel="next">Gcov</a>, Previous: <a href="Objective_002dC.html#Objective_002dC" accesskey="p" rel="prev">Objective-C</a>, Up: <a href="index.html#Top" accesskey="u" rel="up">Top</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
</div>
</body>
</html>