Next:gcov—a Test Coverage Program, Previous:GNU Objective-C Features, Up:Introduction [Contents][Index]
Binary compatibility encompasses several related concepts:
The set of runtime conventions followed by all of the tools that dealwith binary representations of a program, including compilers, assemblers,linkers, and language runtime support.Some ABIs are formal with a written specification, possibly designedby multiple interested parties. Others are simply the way things areactually done by a particular set of tools.
A compiler conforms to an ABI if it generates code that follows all ofthe 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 conformto that ABI and does not contain source code that specifically changesbehavior specified by the ABI.
Calling conventions are a subset of an ABI that specify of how argumentsare passed and function results are returned.
Different sets of tools are interoperable if they generate files thatcan 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 unlessthey implement the same ABI. This applies to different versions of thesame tools as well as tools from different vendors.
Whether a function in a binary built by one set of tools can call afunction in a binary built by a different set of tools is a subsetof interoperability.
Language standards include lists of implementation-defined features whosebehavior can vary from one implementation to another. Some of thesefeatures are normally covered by a platform’s ABI and others are not.The features that are not covered by an ABI generally affect how aprogram behaves, but not intercallability.
Conformance to the same ABI and the same behavior of implementation-definedfeatures are both relevant for compatibility.
The application binary interface implemented by a C or C++ compileraffects code generation and runtime support for:
In addition, the application binary interface implemented by a C++ compileraffects code generation and runtime support for:
Some GCC compilation options cause the compiler to generate code thatdoes not conform to the platform’s default ABI. Other options causedifferent program behavior for implementation-defined features that arenot covered by an ABI. These options are provided for consistency withother compilers that do not follow the platform’s default ABI or theusual behavior of implementation-defined features for the platform.Be very careful about using such options.
Most platforms have a well-defined ABI that covers C code, but ABIsthat cover C++ functionality are not yet common.
Starting with GCC 3.2, GCC binary conventions for C++ are based on awritten, vendor-neutral C++ ABI that was designed to be specific to64-bit Itanium but also includes generic specifications that apply toany platform.This C++ ABI is also implemented by other compiler vendors on someplatforms, notably GNU/Linux and BSD systems.We have tried hard to provide a stable ABI that will be compatible withfuture GCC releases, but it is possible that we will encounter problemsthat make this difficult. Such problems could include differentinterpretations of the C++ ABI by different vendors, bugs in the ABI, orbugs in the implementation of the ABI in different compilers.GCC’s-Wabi switch warns when G++ generates code that isprobably not compatible with the C++ ABI.
The C++ library used with a C++ compiler includes the Standard C++Library, with functionality defined in the C++ Standard, plus languageruntime support. The runtime support is included in a C++ ABI, but thereis no formal ABI for the Standard C++ Library. Two implementationsof that library are interoperable if one follows the de-facto ABI of theother and if they are both built with the same compiler, or with compilersthat conform to the same ABI for C++ compiler and runtime support.
When G++ and another C++ compiler conform to the same C++ ABI, but theimplementations of the Standard C++ Library that they normally use do notfollow the same ABI for the Standard C++ Library, object files built withthose compilers can be used in the same program only if they use the sameC++ library. This requires specifying the location of the C++ libraryheader files when invoking the compiler whose usual library is not beingused. The location of GCC’s C++ header files depends on how the GCCbuild was configured, but can be seen by using the G++-v option.With default configuration options for G++ 3.3 the compile line for adifferent C++ compiler needs to include
-Igcc_install_directory/include/c++/3.3
Similarly, compiling code with G++ that must use a C++ library otherthan the GNU C++ library requires specifying the location of the headerfiles for that other library.
The most straightforward way to link a program to use a particularC++ library is to use a C++ driver that specifies that C++ library bydefault. Theg++ driver, for example, tells the linker whereto find GCC’s C++ library (libstdc++) plus the other librariesand startup files it needs, in the proper order.
If a program must use a different C++ library and it’s not possibleto do the final link using a C++ driver that uses that library by default,it is necessary to tellg++ the location and name of thatlibrary. It might also be necessary to specify different startup filesand other runtime support libraries, and to suppress the use of GCC’ssupport libraries with one or more of the options-nostdlib,-nostartfiles, and-nodefaultlibs.
Next:gcov—a Test Coverage Program, Previous:GNU Objective-C Features, Up:Introduction [Contents][Index]