OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [gnu-old/] [gcc-4.2.2/] [gcc/] [doc/] [compat.texi] - Blame information for rev 816

Details | Compare with Previous | View Log

Line No. Rev Author Line
1 38 julius
@c Copyright (C) 2002, 2004 Free Software Foundation, Inc.
2
@c This is part of the GCC manual.
3
@c For copying conditions, see the file gcc.texi.
4
 
5
@node Compatibility
6
@chapter Binary Compatibility
7
@cindex binary compatibility
8
@cindex ABI
9
@cindex application binary interface
10
 
11
Binary compatibility encompasses several related concepts:
12
 
13
@table @dfn
14
@item application binary interface (ABI)
15
The set of runtime conventions followed by all of the tools that deal
16
with binary representations of a program, including compilers, assemblers,
17
linkers, and language runtime support.
18
Some ABIs are formal with a written specification, possibly designed
19
by multiple interested parties.  Others are simply the way things are
20
actually done by a particular set of tools.
21
 
22
@item ABI conformance
23
A compiler conforms to an ABI if it generates code that follows all of
24
the specifications enumerated by that ABI@.
25
A library conforms to an ABI if it is implemented according to that ABI@.
26
An application conforms to an ABI if it is built using tools that conform
27
to that ABI and does not contain source code that specifically changes
28
behavior specified by the ABI@.
29
 
30
@item calling conventions
31
Calling conventions are a subset of an ABI that specify of how arguments
32
are passed and function results are returned.
33
 
34
@item interoperability
35
Different sets of tools are interoperable if they generate files that
36
can be used in the same program.  The set of tools includes compilers,
37
assemblers, linkers, libraries, header files, startup files, and debuggers.
38
Binaries produced by different sets of tools are not interoperable unless
39
they implement the same ABI@.  This applies to different versions of the
40
same tools as well as tools from different vendors.
41
 
42
@item intercallability
43
Whether a function in a binary built by one set of tools can call a
44
function in a binary built by a different set of tools is a subset
45
of interoperability.
46
 
47
@item implementation-defined features
48
Language standards include lists of implementation-defined features whose
49
behavior can vary from one implementation to another.  Some of these
50
features are normally covered by a platform's ABI and others are not.
51
The features that are not covered by an ABI generally affect how a
52
program behaves, but not intercallability.
53
 
54
@item compatibility
55
Conformance to the same ABI and the same behavior of implementation-defined
56
features are both relevant for compatibility.
57
@end table
58
 
59
The application binary interface implemented by a C or C++ compiler
60
affects code generation and runtime support for:
61
 
62
@itemize @bullet
63
@item
64
size and alignment of data types
65
@item
66
layout of structured types
67
@item
68
calling conventions
69
@item
70
register usage conventions
71
@item
72
interfaces for runtime arithmetic support
73
@item
74
object file formats
75
@end itemize
76
 
77
In addition, the application binary interface implemented by a C++ compiler
78
affects code generation and runtime support for:
79
@itemize @bullet
80
@item
81
name mangling
82
@item
83
exception handling
84
@item
85
invoking constructors and destructors
86
@item
87
layout, alignment, and padding of classes
88
@item
89
layout and alignment of virtual tables
90
@end itemize
91
 
92
Some GCC compilation options cause the compiler to generate code that
93
does not conform to the platform's default ABI@.  Other options cause
94
different program behavior for implementation-defined features that are
95
not covered by an ABI@.  These options are provided for consistency with
96
other compilers that do not follow the platform's default ABI or the
97
usual behavior of implementation-defined features for the platform.
98
Be very careful about using such options.
99
 
100
Most platforms have a well-defined ABI that covers C code, but ABIs
101
that cover C++ functionality are not yet common.
102
 
103
Starting with GCC 3.2, GCC binary conventions for C++ are based on a
104
written, vendor-neutral C++ ABI that was designed to be specific to
105
64-bit Itanium but also includes generic specifications that apply to
106
any platform.
107
This C++ ABI is also implemented by other compiler vendors on some
108
platforms, notably GNU/Linux and BSD systems.
109
We have tried hard to provide a stable ABI that will be compatible with
110
future GCC releases, but it is possible that we will encounter problems
111
that make this difficult.  Such problems could include different
112
interpretations of the C++ ABI by different vendors, bugs in the ABI, or
113
bugs in the implementation of the ABI in different compilers.
114
GCC's @option{-Wabi} switch warns when G++ generates code that is
115
probably not compatible with the C++ ABI@.
116
 
117
The C++ library used with a C++ compiler includes the Standard C++
118
Library, with functionality defined in the C++ Standard, plus language
119
runtime support.  The runtime support is included in a C++ ABI, but there
120
is no formal ABI for the Standard C++ Library.  Two implementations
121
of that library are interoperable if one follows the de-facto ABI of the
122
other and if they are both built with the same compiler, or with compilers
123
that conform to the same ABI for C++ compiler and runtime support.
124
 
125
When G++ and another C++ compiler conform to the same C++ ABI, but the
126
implementations of the Standard C++ Library that they normally use do not
127
follow the same ABI for the Standard C++ Library, object files built with
128
those compilers can be used in the same program only if they use the same
129
C++ library.  This requires specifying the location of the C++ library
130
header files when invoking the compiler whose usual library is not being
131
used.  The location of GCC's C++ header files depends on how the GCC
132
build was configured, but can be seen by using the G++ @option{-v} option.
133
With default configuration options for G++ 3.3 the compile line for a
134
different C++ compiler needs to include
135
 
136
@smallexample
137
    -I@var{gcc_install_directory}/include/c++/3.3
138
@end smallexample
139
 
140
Similarly, compiling code with G++ that must use a C++ library other
141
than the GNU C++ library requires specifying the location of the header
142
files for that other library.
143
 
144
The most straightforward way to link a program to use a particular
145
C++ library is to use a C++ driver that specifies that C++ library by
146
default.  The @command{g++} driver, for example, tells the linker where
147
to find GCC's C++ library (@file{libstdc++}) plus the other libraries
148
and startup files it needs, in the proper order.
149
 
150
If a program must use a different C++ library and it's not possible
151
to do the final link using a C++ driver that uses that library by default,
152
it is necessary to tell @command{g++} the location and name of that
153
library.  It might also be necessary to specify different startup files
154
and other runtime support libraries, and to suppress the use of GCC's
155
support libraries with one or more of the options @option{-nostdlib},
156
@option{-nostartfiles}, and @option{-nodefaultlibs}.

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.