xref: /netbsd-src/external/gpl3/gcc.old/dist/libstdc++-v3/doc/html/manual/internals.html (revision 36ac495d2b3ea2b9d96377b2143ebfedac224b92)
1*36ac495dSmrg<?xml version="1.0" encoding="UTF-8" standalone="no"?>
2*36ac495dSmrg<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Porting to New Hardware or Operating Systems</title><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><meta name="keywords" content="ISO C++, internals" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="appendix_porting.html" title="Appendix B.  Porting and Maintenance" /><link rel="prev" href="documentation_hacking.html" title="Writing and Generating Documentation" /><link rel="next" href="test.html" title="Testing" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Porting to New Hardware or Operating Systems</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="documentation_hacking.html">Prev</a> </td><th width="60%" align="center">Appendix B. 
3*36ac495dSmrg  Porting and Maintenance
4*36ac495dSmrg
5*36ac495dSmrg</th><td width="20%" align="right"> <a accesskey="n" href="test.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="appendix.porting.internals"></a>Porting to New Hardware or Operating Systems</h2></div></div></div><p>
6*36ac495dSmrg</p><p>This document explains how to port libstdc++ (the GNU C++ library) to
7*36ac495dSmrga new target.
8*36ac495dSmrg</p><p>In order to make the GNU C++ library (libstdc++) work with a new
9*36ac495dSmrgtarget, you must edit some configuration files and provide some new
10*36ac495dSmrgheader files.  Unless this is done, libstdc++ will use generic
11*36ac495dSmrgsettings which may not be correct for your target; even if they are
12*36ac495dSmrgcorrect, they will likely be inefficient.
13*36ac495dSmrg   </p><p>Before you get started, make sure that you have a working C library on
14*36ac495dSmrgyour target.  The C library need not precisely comply with any
15*36ac495dSmrgparticular standard, but should generally conform to the requirements
16*36ac495dSmrgimposed by the ANSI/ISO standard.
17*36ac495dSmrg   </p><p>In addition, you should try to verify that the C++ compiler generally
18*36ac495dSmrgworks.  It is difficult to test the C++ compiler without a working
19*36ac495dSmrglibrary, but you should at least try some minimal test cases.
20*36ac495dSmrg   </p><p>(Note that what we think of as a "target," the library refers to as
21*36ac495dSmrga "host."  The comment at the top of <code class="code">configure.ac</code> explains why.)
22*36ac495dSmrg   </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="internals.os"></a>Operating System</h3></div></div></div><p>If you are porting to a new operating system (as opposed to a new chip
23*36ac495dSmrgusing an existing operating system), you will need to create a new
24*36ac495dSmrgdirectory in the <code class="code">config/os</code> hierarchy.  For example, the IRIX
25*36ac495dSmrgconfiguration files are all in <code class="code">config/os/irix</code>.  There is no set
26*36ac495dSmrgway to organize the OS configuration directory.  For example,
27*36ac495dSmrg<code class="code">config/os/solaris/solaris-2.6</code> and
28*36ac495dSmrg<code class="code">config/os/solaris/solaris-2.7</code> are used as configuration
29*36ac495dSmrgdirectories for these two versions of Solaris.  On the other hand, both
30*36ac495dSmrgSolaris 2.7 and Solaris 2.8 use the <code class="code">config/os/solaris/solaris-2.7</code>
31*36ac495dSmrgdirectory.  The important information is that there needs to be a
32*36ac495dSmrgdirectory under <code class="code">config/os</code> to store the files for your operating
33*36ac495dSmrgsystem.
34*36ac495dSmrg</p><p>You might have to change the <code class="code">configure.host</code> file to ensure that
35*36ac495dSmrgyour new directory is activated.  Look for the switch statement that sets
36*36ac495dSmrg<code class="code">os_include_dir</code>, and add a pattern to handle your operating system
37*36ac495dSmrgif the default will not suffice.  The switch statement switches on only
38*36ac495dSmrgthe OS portion of the standard target triplet; e.g., the <code class="code">solaris2.8</code>
39*36ac495dSmrgin <code class="code">sparc-sun-solaris2.8</code>.  If the new directory is named after the
40*36ac495dSmrgOS portion of the triplet (the default), then nothing needs to be changed.
41*36ac495dSmrg   </p><p>The first file to create in this directory, should be called
42*36ac495dSmrg<code class="code">os_defines.h</code>.  This file contains basic macro definitions
43*36ac495dSmrgthat are required to allow the C++ library to work with your C library.
44*36ac495dSmrg   </p><p>Several libstdc++ source files unconditionally define the macro
45*36ac495dSmrg<code class="code">_POSIX_SOURCE</code>.  On many systems, defining this macro causes
46*36ac495dSmrglarge portions of the C library header files to be eliminated
47*36ac495dSmrgat preprocessing time.  Therefore, you may have to <code class="code">#undef</code> this
48*36ac495dSmrgmacro, or define other macros (like <code class="code">_LARGEFILE_SOURCE</code> or
49*36ac495dSmrg<code class="code">__EXTENSIONS__</code>).  You won't know what macros to define or
50*36ac495dSmrgundefine at this point; you'll have to try compiling the library and
51*36ac495dSmrgseeing what goes wrong.  If you see errors about calling functions
52*36ac495dSmrgthat have not been declared, look in your C library headers to see if
53*36ac495dSmrgthe functions are declared there, and then figure out what macros you
54*36ac495dSmrgneed to define.  You will need to add them to the
55*36ac495dSmrg<code class="code">CPLUSPLUS_CPP_SPEC</code> macro in the GCC configuration file for your
56*36ac495dSmrgtarget.  It will not work to simply define these macros in
57*36ac495dSmrg<code class="code">os_defines.h</code>.
58*36ac495dSmrg   </p><p>At this time, there are a few libstdc++-specific macros which may be
59*36ac495dSmrgdefined:
60*36ac495dSmrg   </p><p><code class="code">_GLIBCXX_USE_C99_CHECK</code> may be defined to 1 to check C99
61*36ac495dSmrgfunction declarations (which are not covered by specialization below)
62*36ac495dSmrgfound in system headers against versions found in the library headers
63*36ac495dSmrgderived from the standard.
64*36ac495dSmrg   </p><p><code class="code">_GLIBCXX_USE_C99_DYNAMIC</code> may be defined to an expression that
65*36ac495dSmrgyields 0 if and only if the system headers are exposing proper support
66*36ac495dSmrgfor C99 functions (which are not covered by specialization below).  If
67*36ac495dSmrgdefined, it must be 0 while bootstrapping the compiler/rebuilding the
68*36ac495dSmrglibrary.
69*36ac495dSmrg   </p><p><code class="code">_GLIBCXX_USE_C99_LONG_LONG_CHECK</code> may be defined to 1 to check
70*36ac495dSmrgthe set of C99 long long function declarations found in system headers
71*36ac495dSmrgagainst versions found in the library headers derived from the
72*36ac495dSmrgstandard.
73*36ac495dSmrg
74*36ac495dSmrg   </p><p><code class="code">_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC</code> may be defined to an
75*36ac495dSmrgexpression that yields 0 if and only if the system headers are
76*36ac495dSmrgexposing proper support for the set of C99 long long functions.  If
77*36ac495dSmrgdefined, it must be 0 while bootstrapping the compiler/rebuilding the
78*36ac495dSmrglibrary.
79*36ac495dSmrg   </p><p><code class="code">_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC</code> may be defined to an
80*36ac495dSmrgexpression that yields 0 if and only if the system headers
81*36ac495dSmrgare exposing proper support for the related set of macros.  If defined,
82*36ac495dSmrgit must be 0 while bootstrapping the compiler/rebuilding the library.
83*36ac495dSmrg   </p><p><code class="code">_GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK</code> may be defined
84*36ac495dSmrgto 1 to check the related set of function declarations found in system
85*36ac495dSmrgheaders against versions found in the library headers derived from
86*36ac495dSmrgthe standard.
87*36ac495dSmrg   </p><p><code class="code">_GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC</code> may be defined
88*36ac495dSmrgto an expression that yields 0 if and only if the system headers
89*36ac495dSmrgare exposing proper support for the related set of functions.  If defined,
90*36ac495dSmrgit must be 0 while bootstrapping the compiler/rebuilding the library.
91*36ac495dSmrg   </p><p><code class="code">_GLIBCXX_NO_OBSOLETE_ISINF_ISNAN_DYNAMIC</code> may be defined
92*36ac495dSmrgto an expression that yields 0 if and only if the system headers
93*36ac495dSmrgare exposing non-standard <code class="code">isinf(double)</code> and
94*36ac495dSmrg<code class="code">isnan(double)</code> functions in the global namespace. Those functions
95*36ac495dSmrgshould be detected automatically by the <code class="code">configure</code> script when
96*36ac495dSmrglibstdc++ is built but if their presence depends on compilation flags or
97*36ac495dSmrgother macros the static configuration can be overridden.
98*36ac495dSmrg   </p><p>Finally, you should bracket the entire file in an include-guard, like
99*36ac495dSmrgthis:
100*36ac495dSmrg   </p><pre class="programlisting">
101*36ac495dSmrg
102*36ac495dSmrg#ifndef _GLIBCXX_OS_DEFINES
103*36ac495dSmrg#define _GLIBCXX_OS_DEFINES
104*36ac495dSmrg...
105*36ac495dSmrg#endif
106*36ac495dSmrg</pre><p>We recommend copying an existing <code class="code">os_defines.h</code> to use as a
107*36ac495dSmrgstarting point.
108*36ac495dSmrg   </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="internals.cpu"></a>CPU</h3></div></div></div><p>If you are porting to a new chip (as opposed to a new operating system
109*36ac495dSmrgrunning on an existing chip), you will need to create a new directory in the
110*36ac495dSmrg<code class="code">config/cpu</code> hierarchy.  Much like the <a class="link" href="internals.html#internals.os" title="Operating System">Operating system</a> setup,
111*36ac495dSmrgthere are no strict rules on how to organize the CPU configuration
112*36ac495dSmrgdirectory, but careful naming choices will allow the configury to find your
113*36ac495dSmrgsetup files without explicit help.
114*36ac495dSmrg</p><p>We recommend that for a target triplet <code class="code">&lt;CPU&gt;-&lt;vendor&gt;-&lt;OS&gt;</code>, you
115*36ac495dSmrgname your configuration directory <code class="code">config/cpu/&lt;CPU&gt;</code>.  If you do this,
116*36ac495dSmrgthe configury will find the directory by itself.  Otherwise you will need to
117*36ac495dSmrgedit the <code class="code">configure.host</code> file and, in the switch statement that sets
118*36ac495dSmrg<code class="code">cpu_include_dir</code>, add a pattern to handle your chip.
119*36ac495dSmrg   </p><p>Note that some chip families share a single configuration directory, for
120*36ac495dSmrgexample, <code class="code">alpha</code>, <code class="code">alphaev5</code>, and <code class="code">alphaev6</code> all use the
121*36ac495dSmrg<code class="code">config/cpu/alpha</code> directory, and there is an entry in the
122*36ac495dSmrg<code class="code">configure.host</code> switch statement to handle this.
123*36ac495dSmrg   </p><p>The <code class="code">cpu_include_dir</code> sets default locations for the files controlling
124*36ac495dSmrg<a class="link" href="internals.html#internals.thread_safety" title="Thread Safety">Thread safety</a> and <a class="link" href="internals.html#internals.numeric_limits" title="Numeric Limits">Numeric limits</a>, if the defaults are not
125*36ac495dSmrgappropriate for your chip.
126*36ac495dSmrg   </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="internals.char_types"></a>Character Types</h3></div></div></div><p>The library requires that you provide three header files to implement
127*36ac495dSmrgcharacter classification, analogous to that provided by the C libraries
128*36ac495dSmrg<code class="code">&lt;ctype.h&gt;</code> header.  You can model these on the files provided in
129*36ac495dSmrg<code class="code">config/os/generic</code>.  However, these files will almost
130*36ac495dSmrgcertainly need some modification.
131*36ac495dSmrg</p><p>The first file to write is <code class="code">ctype_base.h</code>.  This file provides
132*36ac495dSmrgsome very basic information about character classification.  The libstdc++
133*36ac495dSmrglibrary assumes that your C library implements <code class="code">&lt;ctype.h&gt;</code> by using
134*36ac495dSmrga table (indexed by character code) containing integers, where each of
135*36ac495dSmrgthese integers is a bit-mask indicating whether the character is
136*36ac495dSmrgupper-case, lower-case, alphabetic, etc.  The <code class="code">ctype_base.h</code>
137*36ac495dSmrgfile gives the type of the integer, and the values of the various bit
138*36ac495dSmrgmasks.  You will have to peer at your own <code class="code">&lt;ctype.h&gt;</code> to figure out
139*36ac495dSmrghow to define the values required by this file.
140*36ac495dSmrg   </p><p>The <code class="code">ctype_base.h</code> header file does not need include guards.
141*36ac495dSmrgIt should contain a single <code class="code">struct</code> definition called
142*36ac495dSmrg<code class="code">ctype_base</code>.  This <code class="code">struct</code> should contain two type
143*36ac495dSmrgdeclarations, and one enumeration declaration, like this example, taken
144*36ac495dSmrgfrom the IRIX configuration:
145*36ac495dSmrg   </p><pre class="programlisting">
146*36ac495dSmrg  struct ctype_base
147*36ac495dSmrg     {
148*36ac495dSmrg       typedef unsigned int 	mask;
149*36ac495dSmrg       typedef int* 		__to_type;
150*36ac495dSmrg
151*36ac495dSmrg       enum
152*36ac495dSmrg       {
153*36ac495dSmrg	 space = _ISspace,
154*36ac495dSmrg	 print = _ISprint,
155*36ac495dSmrg	 cntrl = _IScntrl,
156*36ac495dSmrg	 upper = _ISupper,
157*36ac495dSmrg	 lower = _ISlower,
158*36ac495dSmrg	 alpha = _ISalpha,
159*36ac495dSmrg	 digit = _ISdigit,
160*36ac495dSmrg	 punct = _ISpunct,
161*36ac495dSmrg	 xdigit = _ISxdigit,
162*36ac495dSmrg	 alnum = _ISalnum,
163*36ac495dSmrg	 graph = _ISgraph
164*36ac495dSmrg       };
165*36ac495dSmrg     };
166*36ac495dSmrg</pre><p>The <code class="code">mask</code> type is the type of the elements in the table.  If your
167*36ac495dSmrgC library uses a table to map lower-case numbers to upper-case numbers,
168*36ac495dSmrgand vice versa, you should define <code class="code">__to_type</code> to be the type of the
169*36ac495dSmrgelements in that table.  If you don't mind taking a minor performance
170*36ac495dSmrgpenalty, or if your library doesn't implement <code class="code">toupper</code> and
171*36ac495dSmrg<code class="code">tolower</code> in this way, you can pick any pointer-to-integer type,
172*36ac495dSmrgbut you must still define the type.
173*36ac495dSmrg</p><p>The enumeration should give definitions for all the values in the above
174*36ac495dSmrgexample, using the values from your native <code class="code">&lt;ctype.h&gt;</code>.  They can
175*36ac495dSmrgbe given symbolically (as above), or numerically, if you prefer.  You do
176*36ac495dSmrgnot have to include <code class="code">&lt;ctype.h&gt;</code> in this header; it will always be
177*36ac495dSmrgincluded before <code class="code">ctype_base.h</code> is included.
178*36ac495dSmrg   </p><p>The next file to write is <code class="code">ctype_configure_char.cc</code>.
179*36ac495dSmrgThe first function that must be written is the <code class="code">ctype&lt;char&gt;::ctype</code> constructor.  Here is the IRIX example:
180*36ac495dSmrg   </p><pre class="programlisting">
181*36ac495dSmrgctype&lt;char&gt;::ctype(const mask* __table = 0, bool __del = false,
182*36ac495dSmrg	   size_t __refs = 0)
183*36ac495dSmrg       : _Ctype_nois&lt;char&gt;(__refs), _M_del(__table != 0 &amp;&amp; __del),
184*36ac495dSmrg	 _M_toupper(NULL),
185*36ac495dSmrg	 _M_tolower(NULL),
186*36ac495dSmrg	 _M_ctable(NULL),
187*36ac495dSmrg	 _M_table(!__table
188*36ac495dSmrg		  ? (const mask*) (__libc_attr._ctype_tbl-&gt;_class + 1)
189*36ac495dSmrg		  : __table)
190*36ac495dSmrg       { }
191*36ac495dSmrg</pre><p>There are two parts of this that you might choose to alter. The first,
192*36ac495dSmrgand most important, is the line involving <code class="code">__libc_attr</code>.  That is
193*36ac495dSmrgIRIX system-dependent code that gets the base of the table mapping
194*36ac495dSmrgcharacter codes to attributes.  You need to substitute code that obtains
195*36ac495dSmrgthe address of this table on your system.  If you want to use your
196*36ac495dSmrgoperating system's tables to map upper-case letters to lower-case, and
197*36ac495dSmrgvice versa, you should initialize <code class="code">_M_toupper</code> and
198*36ac495dSmrg<code class="code">_M_tolower</code> with those tables, in similar fashion.
199*36ac495dSmrg</p><p>Now, you have to write two functions to convert from upper-case to
200*36ac495dSmrglower-case, and vice versa.  Here are the IRIX versions:
201*36ac495dSmrg   </p><pre class="programlisting">
202*36ac495dSmrg     char
203*36ac495dSmrg     ctype&lt;char&gt;::do_toupper(char __c) const
204*36ac495dSmrg     { return _toupper(__c); }
205*36ac495dSmrg
206*36ac495dSmrg     char
207*36ac495dSmrg     ctype&lt;char&gt;::do_tolower(char __c) const
208*36ac495dSmrg     { return _tolower(__c); }
209*36ac495dSmrg</pre><p>Your C library provides equivalents to IRIX's <code class="code">_toupper</code> and
210*36ac495dSmrg<code class="code">_tolower</code>.  If you initialized <code class="code">_M_toupper</code> and
211*36ac495dSmrg<code class="code">_M_tolower</code> above, then you could use those tables instead.
212*36ac495dSmrg</p><p>Finally, you have to provide two utility functions that convert strings
213*36ac495dSmrgof characters.  The versions provided here will always work - but you
214*36ac495dSmrgcould use specialized routines for greater performance if you have
215*36ac495dSmrgmachinery to do that on your system:
216*36ac495dSmrg   </p><pre class="programlisting">
217*36ac495dSmrg     const char*
218*36ac495dSmrg     ctype&lt;char&gt;::do_toupper(char* __low, const char* __high) const
219*36ac495dSmrg     {
220*36ac495dSmrg       while (__low &lt; __high)
221*36ac495dSmrg	 {
222*36ac495dSmrg	   *__low = do_toupper(*__low);
223*36ac495dSmrg	   ++__low;
224*36ac495dSmrg	 }
225*36ac495dSmrg       return __high;
226*36ac495dSmrg     }
227*36ac495dSmrg
228*36ac495dSmrg     const char*
229*36ac495dSmrg     ctype&lt;char&gt;::do_tolower(char* __low, const char* __high) const
230*36ac495dSmrg     {
231*36ac495dSmrg       while (__low &lt; __high)
232*36ac495dSmrg	 {
233*36ac495dSmrg	   *__low = do_tolower(*__low);
234*36ac495dSmrg	   ++__low;
235*36ac495dSmrg	 }
236*36ac495dSmrg       return __high;
237*36ac495dSmrg     }
238*36ac495dSmrg</pre><p>You must also provide the <code class="code">ctype_inline.h</code> file, which
239*36ac495dSmrgcontains a few more functions.  On most systems, you can just copy
240*36ac495dSmrg<code class="code">config/os/generic/ctype_inline.h</code> and use it on your system.
241*36ac495dSmrg   </p><p>In detail, the functions provided test characters for particular
242*36ac495dSmrgproperties; they are analogous to the functions like <code class="code">isalpha</code> and
243*36ac495dSmrg<code class="code">islower</code> provided by the C library.
244*36ac495dSmrg   </p><p>The first function is implemented like this on IRIX:
245*36ac495dSmrg   </p><pre class="programlisting">
246*36ac495dSmrg     bool
247*36ac495dSmrg     ctype&lt;char&gt;::
248*36ac495dSmrg     is(mask __m, char __c) const throw()
249*36ac495dSmrg     { return (_M_table)[(unsigned char)(__c)] &amp; __m; }
250*36ac495dSmrg</pre><p>The <code class="code">_M_table</code> is the table passed in above, in the constructor.
251*36ac495dSmrgThis is the table that contains the bitmasks for each character.  The
252*36ac495dSmrgimplementation here should work on all systems.
253*36ac495dSmrg</p><p>The next function is:
254*36ac495dSmrg   </p><pre class="programlisting">
255*36ac495dSmrg     const char*
256*36ac495dSmrg     ctype&lt;char&gt;::
257*36ac495dSmrg     is(const char* __low, const char* __high, mask* __vec) const throw()
258*36ac495dSmrg     {
259*36ac495dSmrg       while (__low &lt; __high)
260*36ac495dSmrg	 *__vec++ = (_M_table)[(unsigned char)(*__low++)];
261*36ac495dSmrg       return __high;
262*36ac495dSmrg     }
263*36ac495dSmrg</pre><p>This function is similar; it copies the masks for all the characters
264*36ac495dSmrgfrom <code class="code">__low</code> up until <code class="code">__high</code> into the vector given by
265*36ac495dSmrg<code class="code">__vec</code>.
266*36ac495dSmrg</p><p>The last two functions again are entirely generic:
267*36ac495dSmrg   </p><pre class="programlisting">
268*36ac495dSmrg     const char*
269*36ac495dSmrg     ctype&lt;char&gt;::
270*36ac495dSmrg     scan_is(mask __m, const char* __low, const char* __high) const throw()
271*36ac495dSmrg     {
272*36ac495dSmrg       while (__low &lt; __high &amp;&amp; !this-&gt;is(__m, *__low))
273*36ac495dSmrg	 ++__low;
274*36ac495dSmrg       return __low;
275*36ac495dSmrg     }
276*36ac495dSmrg
277*36ac495dSmrg     const char*
278*36ac495dSmrg     ctype&lt;char&gt;::
279*36ac495dSmrg     scan_not(mask __m, const char* __low, const char* __high) const throw()
280*36ac495dSmrg     {
281*36ac495dSmrg       while (__low &lt; __high &amp;&amp; this-&gt;is(__m, *__low))
282*36ac495dSmrg	 ++__low;
283*36ac495dSmrg       return __low;
284*36ac495dSmrg     }
285*36ac495dSmrg</pre></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="internals.thread_safety"></a>Thread Safety</h3></div></div></div><p>The C++ library string functionality requires a couple of atomic
286*36ac495dSmrgoperations to provide thread-safety.  If you don't take any special
287*36ac495dSmrgaction, the library will use stub versions of these functions that are
288*36ac495dSmrgnot thread-safe.  They will work fine, unless your applications are
289*36ac495dSmrgmulti-threaded.
290*36ac495dSmrg</p><p>If you want to provide custom, safe, versions of these functions, there
291*36ac495dSmrgare two distinct approaches.  One is to provide a version for your CPU,
292*36ac495dSmrgusing assembly language constructs.  The other is to use the
293*36ac495dSmrgthread-safety primitives in your operating system.  In either case, you
294*36ac495dSmrgmake a file called <code class="code">atomicity.h</code>, and the variable
295*36ac495dSmrg<code class="code">ATOMICITYH</code> must point to this file.
296*36ac495dSmrg   </p><p>If you are using the assembly-language approach, put this code in
297*36ac495dSmrg<code class="code">config/cpu/&lt;chip&gt;/atomicity.h</code>, where chip is the name of
298*36ac495dSmrgyour processor (see <a class="link" href="internals.html#internals.cpu" title="CPU">CPU</a>).  No additional changes are necessary to
299*36ac495dSmrglocate the file in this case; <code class="code">ATOMICITYH</code> will be set by default.
300*36ac495dSmrg   </p><p>If you are using the operating system thread-safety primitives approach,
301*36ac495dSmrgyou can also put this code in the same CPU directory, in which case no more
302*36ac495dSmrgwork is needed to locate the file.  For examples of this approach,
303*36ac495dSmrgsee the <code class="code">atomicity.h</code> file for IRIX or IA64.
304*36ac495dSmrg   </p><p>Alternatively, if the primitives are more closely related to the OS
305*36ac495dSmrgthan they are to the CPU, you can put the <code class="code">atomicity.h</code> file in
306*36ac495dSmrgthe <a class="link" href="internals.html#internals.os" title="Operating System">Operating system</a> directory instead.  In this case, you must
307*36ac495dSmrgedit <code class="code">configure.host</code>, and in the switch statement that handles
308*36ac495dSmrgoperating systems, override the <code class="code">ATOMICITYH</code> variable to point to
309*36ac495dSmrgthe appropriate <code class="code">os_include_dir</code>.  For examples of this approach,
310*36ac495dSmrgsee the <code class="code">atomicity.h</code> file for AIX.
311*36ac495dSmrg   </p><p>With those bits out of the way, you have to actually write
312*36ac495dSmrg<code class="code">atomicity.h</code> itself.  This file should be wrapped in an
313*36ac495dSmrginclude guard named <code class="code">_GLIBCXX_ATOMICITY_H</code>.  It should define one
314*36ac495dSmrgtype, and two functions.
315*36ac495dSmrg   </p><p>The type is <code class="code">_Atomic_word</code>.  Here is the version used on IRIX:
316*36ac495dSmrg   </p><pre class="programlisting">
317*36ac495dSmrgtypedef long _Atomic_word;
318*36ac495dSmrg</pre><p>This type must be a signed integral type supporting atomic operations.
319*36ac495dSmrgIf you're using the OS approach, use the same type used by your system's
320*36ac495dSmrgprimitives.  Otherwise, use the type for which your CPU provides atomic
321*36ac495dSmrgprimitives.
322*36ac495dSmrg</p><p>Then, you must provide two functions.  The bodies of these functions
323*36ac495dSmrgmust be equivalent to those provided here, but using atomic operations:
324*36ac495dSmrg   </p><pre class="programlisting">
325*36ac495dSmrg     static inline _Atomic_word
326*36ac495dSmrg     __attribute__ ((__unused__))
327*36ac495dSmrg     __exchange_and_add (_Atomic_word* __mem, int __val)
328*36ac495dSmrg     {
329*36ac495dSmrg       _Atomic_word __result = *__mem;
330*36ac495dSmrg       *__mem += __val;
331*36ac495dSmrg       return __result;
332*36ac495dSmrg     }
333*36ac495dSmrg
334*36ac495dSmrg     static inline void
335*36ac495dSmrg     __attribute__ ((__unused__))
336*36ac495dSmrg     __atomic_add (_Atomic_word* __mem, int __val)
337*36ac495dSmrg     {
338*36ac495dSmrg       *__mem += __val;
339*36ac495dSmrg     }
340*36ac495dSmrg</pre></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="internals.numeric_limits"></a>Numeric Limits</h3></div></div></div><p>The C++ library requires information about the fundamental data types,
341*36ac495dSmrgsuch as the minimum and maximum representable values of each type.
342*36ac495dSmrgYou can define each of these values individually, but it is usually
343*36ac495dSmrgeasiest just to indicate how many bits are used in each of the data
344*36ac495dSmrgtypes and let the library do the rest.  For information about the
345*36ac495dSmrgmacros to define, see the top of <code class="code">include/bits/std_limits.h</code>.
346*36ac495dSmrg</p><p>If you need to define any macros, you can do so in <code class="code">os_defines.h</code>.
347*36ac495dSmrgHowever, if all operating systems for your CPU are likely to use the
348*36ac495dSmrgsame values, you can provide a CPU-specific file instead so that you
349*36ac495dSmrgdo not have to provide the same definitions for each operating system.
350*36ac495dSmrgTo take that approach, create a new file called <code class="code">cpu_limits.h</code> in
351*36ac495dSmrgyour CPU configuration directory (see <a class="link" href="internals.html#internals.cpu" title="CPU">CPU</a>).
352*36ac495dSmrg   </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="internals.libtool"></a>Libtool</h3></div></div></div><p>The C++ library is compiled, archived and linked with libtool.
353*36ac495dSmrgExplaining the full workings of libtool is beyond the scope of this
354*36ac495dSmrgdocument, but there are a few, particular bits that are necessary for
355*36ac495dSmrgporting.
356*36ac495dSmrg</p><p>Some parts of the libstdc++ library are compiled with the libtool
357*36ac495dSmrg<code class="code">--tags CXX</code> option (the C++ definitions for libtool).  Therefore,
358*36ac495dSmrg<code class="code">ltcf-cxx.sh</code> in the top-level directory needs to have the correct
359*36ac495dSmrglogic to compile and archive objects equivalent to the C version of libtool,
360*36ac495dSmrg<code class="code">ltcf-c.sh</code>.  Some libtool targets have definitions for C but not
361*36ac495dSmrgfor C++, or C++ definitions which have not been kept up to date.
362*36ac495dSmrg   </p><p>The C++ run-time library contains initialization code that needs to be
363*36ac495dSmrgrun as the library is loaded.  Often, that requires linking in special
364*36ac495dSmrgobject files when the C++ library is built as a shared library, or
365*36ac495dSmrgtaking other system-specific actions.
366*36ac495dSmrg   </p><p>The libstdc++ library is linked with the C version of libtool, even
367*36ac495dSmrgthough it is a C++ library.  Therefore, the C version of libtool needs to
368*36ac495dSmrgensure that the run-time library initializers are run.  The usual way to
369*36ac495dSmrgdo this is to build the library using <code class="code">gcc -shared</code>.
370*36ac495dSmrg   </p><p>If you need to change how the library is linked, look at
371*36ac495dSmrg<code class="code">ltcf-c.sh</code> in the top-level directory.  Find the switch statement
372*36ac495dSmrgthat sets <code class="code">archive_cmds</code>.  Here, adjust the setting for your
373*36ac495dSmrgoperating system.
374*36ac495dSmrg   </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="documentation_hacking.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_porting.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="test.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Writing and Generating Documentation </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Testing</td></tr></table></div></body></html>