|
|
|
|
@ -21,8 +21,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640572">
|
|
|
|
|
<title>Processor Architecture</title>
|
|
|
|
|
<para>This ABI is predicated on, at a minimum, Power ISA version
|
|
|
|
|
<phrase revisionflag="deleted">2.7</phrase> <phrase
|
|
|
|
|
revisionflag="added">2.07</phrase> and
|
|
|
|
|
2.07 and
|
|
|
|
|
contains additional implementation characteristics.</para>
|
|
|
|
|
<para>All OpenPOWER instructions that are defined by the Power
|
|
|
|
|
Architecture can be assumed to be implemented and to work as specified.
|
|
|
|
|
@ -2601,7 +2600,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
2<superscript>16</superscript> – 1.</para>
|
|
|
|
|
</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row revisionflag="added">
|
|
|
|
|
<row>
|
|
|
|
|
<entry>
|
|
|
|
|
<para></para>
|
|
|
|
|
</entry>
|
|
|
|
|
@ -2764,23 +2763,6 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
<para>Vector of 1 signed quadword.</para>
|
|
|
|
|
</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row revisionflag="deleted">
|
|
|
|
|
<entry>
|
|
|
|
|
<para></para>
|
|
|
|
|
</entry>
|
|
|
|
|
<entry>
|
|
|
|
|
<para>vector _Float16</para>
|
|
|
|
|
</entry>
|
|
|
|
|
<entry>
|
|
|
|
|
<para>16</para>
|
|
|
|
|
</entry>
|
|
|
|
|
<entry>
|
|
|
|
|
<para>Quadword</para>
|
|
|
|
|
</entry>
|
|
|
|
|
<entry>
|
|
|
|
|
<para>Vector of 8 half-precision floats.</para>
|
|
|
|
|
</entry>
|
|
|
|
|
</row>
|
|
|
|
|
<row>
|
|
|
|
|
<entry>
|
|
|
|
|
<para></para>
|
|
|
|
|
@ -3097,15 +3079,10 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</table>
|
|
|
|
|
<bridgehead revisionflag="deleted">>IBM EXTENDED PRECISION
|
|
|
|
|
&& IEEE BINARY 128 QUADRUPLE PRECISION</bridgehead>
|
|
|
|
|
<para>Availability of the long double data type is subject to
|
|
|
|
|
conformance to a long double standard where the IBM EXTENDED PRECISION
|
|
|
|
|
format and the IEEE BINARY 128 QUADRUPLE PRECISION format are mutually
|
|
|
|
|
exclusive.</para>
|
|
|
|
|
<bridgehead xml:id="dbdoclet.50655240_95080"
|
|
|
|
|
revisionflag="deleted">IEEE BINARY 128 QUADRUPLE
|
|
|
|
|
PRECISION || IBM EXTENDED PRECISION</bridgehead>
|
|
|
|
|
<para>This ABI provides the following choices for implementation of
|
|
|
|
|
long double in compilers and systems. The preferred implementation for
|
|
|
|
|
long double is the IEEE 128-bit quad-precision binary floating-point
|
|
|
|
|
@ -3132,7 +3109,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
long double ISO C type. However, this is not part of the C
|
|
|
|
|
standard.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
<listitem revisionflag="added">
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>This implementation differs from the IEEE 754
|
|
|
|
|
Standard in the following ways:</para>
|
|
|
|
|
<itemizedlist>
|
|
|
|
|
@ -3201,29 +3178,6 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
<para revisionflag="deleted">This implementation differs from
|
|
|
|
|
the IEEE 754 Standard in the
|
|
|
|
|
following ways:</para>
|
|
|
|
|
<itemizedlist revisionflag="deleted">
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>The software support is restricted to round-to-nearest mode.
|
|
|
|
|
Programs that use extended precision must ensure that this rounding
|
|
|
|
|
mode is in effect when extended-precision calculations are
|
|
|
|
|
performed.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>This implementation does not fully support the IEEE special
|
|
|
|
|
numbers NaN and INF. These values are encoded in the high-order
|
|
|
|
|
double value only. The low-order value is not significant, but the
|
|
|
|
|
low-order value of an infinity must be positive or negative
|
|
|
|
|
zero.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>This implementation does not support the IEEE status flags
|
|
|
|
|
for overflow, underflow, and other conditions. These flags have no
|
|
|
|
|
meaning in this format.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
</section>
|
|
|
|
|
<section xml:id="dbdoclet.50655240___RefHeading___Toc377640576">
|
|
|
|
|
<title>Aggregates and Unions</title>
|
|
|
|
|
@ -3519,9 +3473,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
xml:id="dbdoclet.50655240_54268">
|
|
|
|
|
<?dbhtml table-width="60%" ?>
|
|
|
|
|
<?dbfo table-width="60%" ?>
|
|
|
|
|
<title>Little-Endian Bit Numbering for <phrase
|
|
|
|
|
revisionflag="added">0x0001000200030004</phrase> <phrase
|
|
|
|
|
revisionflag="deleted">0x01020304</phrase></title>
|
|
|
|
|
<title>Little-Endian Bit Numbering for
|
|
|
|
|
0x0001000200030004</title>
|
|
|
|
|
<tgroup cols="12">
|
|
|
|
|
<colspec colname="c1" colwidth="3*" />
|
|
|
|
|
<colspec colname="c2" colwidth="3*" />
|
|
|
|
|
@ -3776,8 +3729,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
xml:id="dbdoclet.50655240_47219">
|
|
|
|
|
<?dbhtml table-width="60%" ?>
|
|
|
|
|
<?dbfo table-width="60%" ?>
|
|
|
|
|
<title>Big-Endian Bit Numbering for <phrase
|
|
|
|
|
revisionflag="added">0x0001000200030004</phrase> <phrase revisionflag="deleted">0x01020304</phrase></title>
|
|
|
|
|
<title>Big-Endian Bit Numbering for
|
|
|
|
|
0x0001000200030004</title>
|
|
|
|
|
<tgroup cols="12">
|
|
|
|
|
<colspec colname="c1" colwidth="3*" />
|
|
|
|
|
<colspec colname="c2" colwidth="3*" />
|
|
|
|
|
@ -4079,7 +4032,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
</figure>
|
|
|
|
|
|
|
|
|
|
<note>
|
|
|
|
|
<para><phrase revisionflag="added">In</phrase> <xref
|
|
|
|
|
<para>In <xref
|
|
|
|
|
linkend="dbdoclet.50655240_30073" />, the alignment of the
|
|
|
|
|
structure is not affected by the unnamed short and int fields. The
|
|
|
|
|
named members are aligned relative to the start of the structure.
|
|
|
|
|
@ -4091,8 +4044,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
</note>
|
|
|
|
|
</section>
|
|
|
|
|
</section>
|
|
|
|
|
<section xml:id="dbdoclet.50655240___codealign"
|
|
|
|
|
revisionflag="added">
|
|
|
|
|
<section xml:id="dbdoclet.50655240___codealign">
|
|
|
|
|
<title>Code Alignment</title>
|
|
|
|
|
<para>
|
|
|
|
|
Functions must be aligned on at least a 4-byte boundary.
|
|
|
|
|
@ -4116,7 +4068,6 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
and restore functions.</para>
|
|
|
|
|
<para>The conventions given in this section are adhered to by C programs.
|
|
|
|
|
For more information about the implementation of C, See
|
|
|
|
|
<phrase revisionflag="deleted">https://apps.na.collabserv.com/meetings/join?id=2897-3986</phrase>
|
|
|
|
|
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640591" />.</para>
|
|
|
|
|
<note>
|
|
|
|
|
<para>While it is recommended that all functions use the standard
|
|
|
|
|
@ -4127,7 +4078,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
requirements. Some tools may not work with alternate calling sequences
|
|
|
|
|
and conventions.</para>
|
|
|
|
|
</note>
|
|
|
|
|
<section xml:id="dbdoclet.50655241_FnLinkage" revisionflag="added">
|
|
|
|
|
<section xml:id="dbdoclet.50655241_FnLinkage">
|
|
|
|
|
<title>Function Call Linkage Protocols</title>
|
|
|
|
|
<para>
|
|
|
|
|
The compiler (or assembly programmer) and linker cooperate to make
|
|
|
|
|
@ -4694,23 +4645,20 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
<para>Nonvolatile<footnote>
|
|
|
|
|
<para>Register r2 is nonvolatile with respect to calls
|
|
|
|
|
between functions in the same compilation
|
|
|
|
|
unit<phrase revisionflag="deleted">. It is saved and
|
|
|
|
|
restored by code inserted by the linker resolving a
|
|
|
|
|
call to an external function.</phrase><phrase
|
|
|
|
|
revisionflag="added">, except under the conditions
|
|
|
|
|
in footnote (b).</phrase> For more information, see
|
|
|
|
|
<xref linkend="dbdoclet.50655240_51083" /> <phrase
|
|
|
|
|
revisionflag="added"> and <xref
|
|
|
|
|
unit, except under the conditions
|
|
|
|
|
in footnote (b). For more information, see
|
|
|
|
|
<xref linkend="dbdoclet.50655240_51083" />
|
|
|
|
|
and <xref
|
|
|
|
|
linkend="dbdoclet.50655241_FnLinkage"
|
|
|
|
|
/></phrase>.</para>
|
|
|
|
|
</footnote><phrase revisionflag="added"> or
|
|
|
|
|
/>.</para>
|
|
|
|
|
</footnote> or
|
|
|
|
|
Volatile<footnote>
|
|
|
|
|
<para>Register r2 is volatile and available for use in a
|
|
|
|
|
function that does not use a TOC pointer and that does
|
|
|
|
|
not guarantee that it preserves r2. See
|
|
|
|
|
<xref linkend="dbdoclet.50655241_FnLinkage" /> and
|
|
|
|
|
<xref linkend="dbdoclet.50655241_95185" />.</para>
|
|
|
|
|
</footnote></phrase></para>
|
|
|
|
|
</footnote></para>
|
|
|
|
|
</entry>
|
|
|
|
|
<entry>
|
|
|
|
|
<para>TOC pointer.</para>
|
|
|
|
|
@ -4900,17 +4848,17 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
dynamic linker. For references through function pointers, it is the
|
|
|
|
|
compiler's or assembler programmer's responsibility to insert
|
|
|
|
|
appropriate TOC save and restore code. If the function is called from
|
|
|
|
|
the same module as the callee, the callee must <phrase
|
|
|
|
|
revisionflag="added">normally</phrase> preserve the value of r2.
|
|
|
|
|
<phrase revisionflag="added">If the callee function is called from
|
|
|
|
|
the same module as the callee, the callee must
|
|
|
|
|
normally preserve the value of r2.
|
|
|
|
|
If the callee function is called from
|
|
|
|
|
a function in the same compilation unit as the callee, and the
|
|
|
|
|
callee does not preserve r2, the
|
|
|
|
|
caller is responsible for saving and restoring the TOC pointer if it
|
|
|
|
|
needs it.</phrase> (See <phrase revisionflag="changed"><xref
|
|
|
|
|
needs it. (See <xref
|
|
|
|
|
linkend="dbdoclet.50655241_FnLinkage" />
|
|
|
|
|
for more information.</phrase>)</para>
|
|
|
|
|
<para>When a function calls another function <phrase
|
|
|
|
|
revisionflag="added">that requires a TOC pointer</phrase>, the TOC
|
|
|
|
|
for more information.)</para>
|
|
|
|
|
<para>When a function calls another function
|
|
|
|
|
that requires a TOC pointer, the TOC
|
|
|
|
|
pointer must have a legal value pointing to the TOC base, which may be
|
|
|
|
|
initialized as described in <xref
|
|
|
|
|
linkend="dbdoclet.50655242_47739" />.</para>
|
|
|
|
|
@ -4943,8 +4891,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
context.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>When a function <phrase revisionflag="added">that requires a
|
|
|
|
|
TOC pointer</phrase> is entered through its global entry point,
|
|
|
|
|
<para>When a function that requires a
|
|
|
|
|
TOC pointer is entered through its global entry point,
|
|
|
|
|
register r12 contains the entry-point address. For more
|
|
|
|
|
information, see the description of dual entry points in
|
|
|
|
|
<xref linkend="dbdoclet.50655240___RefHeading___Toc377640597" />
|
|
|
|
|
@ -5000,15 +4948,15 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
mask the value received from
|
|
|
|
|
<emphasis role="bold">mfocr</emphasis> to avoid corruption of the resulting
|
|
|
|
|
(partial) condition register word.</para>
|
|
|
|
|
<para>This erratum does not apply to <phrase
|
|
|
|
|
revisionflag="changed">POWER9 and subsequent
|
|
|
|
|
processors.</phrase></para>
|
|
|
|
|
<para>This erratum does not apply to
|
|
|
|
|
POWER9 and subsequent
|
|
|
|
|
processors.</para>
|
|
|
|
|
</note>
|
|
|
|
|
|
|
|
|
|
<para><anchor xml:id="dbdoclet.50655240_Power-ISA-version-and-the-user-s-manual"
|
|
|
|
|
xreflabel="" />For more information, see
|
|
|
|
|
<citetitle>Power ISA</citetitle>, version <phrase
|
|
|
|
|
revisionflag="changed">3.0B</phrase> and "Fixed-Point Invalid
|
|
|
|
|
<citetitle>Power ISA</citetitle>, version
|
|
|
|
|
3.0B and "Fixed-Point Invalid
|
|
|
|
|
Forms and Undefined Conditions" in
|
|
|
|
|
<citetitle>POWER9 Processor User's Manual.</citetitle></para>
|
|
|
|
|
<bridgehead>Floating-Point Registers</bridgehead>
|
|
|
|
|
@ -5050,11 +4998,11 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
special-purpose register to provide floating-point status and control.
|
|
|
|
|
Throughout this document, the symbol fN is used, where N is a register
|
|
|
|
|
number, to refer to floating-point register N.</para>
|
|
|
|
|
<para>For the purpose of function calls, the <phrase
|
|
|
|
|
revisionflag="changed">least-significant halves of those VSX
|
|
|
|
|
registers corresponding</phrase> to the classic floating-point
|
|
|
|
|
registers (that is, vsr0–vsr31), <phrase
|
|
|
|
|
revisionflag="changed">are</phrase> volatile.</para>
|
|
|
|
|
<para>For the purpose of function calls, the
|
|
|
|
|
least-significant halves of those VSX
|
|
|
|
|
registers corresponding to the classic floating-point
|
|
|
|
|
registers (that is, vsr0–vsr31),
|
|
|
|
|
are volatile.</para>
|
|
|
|
|
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_83567">
|
|
|
|
|
<title>Floating-Point Register Roles for Binary Floating-Point
|
|
|
|
|
@ -5681,8 +5629,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
general-purpose register save and restore functions are to be used, the
|
|
|
|
|
general-purpose registers shall be saved in a contiguous range.
|
|
|
|
|
General-purpose register rN is saved in the doubleword located 8 x
|
|
|
|
|
(32 – N) bytes before the <phrase
|
|
|
|
|
revisionflag="changed">Floating-Point Register Save Area,</phrase>
|
|
|
|
|
(32 – N) bytes before the
|
|
|
|
|
Floating-Point Register Save Area,
|
|
|
|
|
as shown in
|
|
|
|
|
<xref linkend="dbdoclet.50655240_97610" />.</para>
|
|
|
|
|
<para>The General-Purpose Register Save Area is always doubleword
|
|
|
|
|
@ -5699,7 +5647,7 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
saved in arbitrary locations in the stack frame. If the system vector
|
|
|
|
|
register save and restore functions are to be used, the vector
|
|
|
|
|
registers shall be saved in a contiguous range. Vector register vN is
|
|
|
|
|
saved in the <phrase revisionflag="changed">quadword</phrase> located
|
|
|
|
|
saved in the quadword located
|
|
|
|
|
16 x (32 – N) bytes before the
|
|
|
|
|
General-Purpose Register Save Areas plus alignment padding, as shown in
|
|
|
|
|
|
|
|
|
|
@ -5762,8 +5710,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
<para>Functions without a suitable declaration available to the
|
|
|
|
|
caller to determine the called function's characteristics (for
|
|
|
|
|
example, functions in C without a prototype in scope, in accordance
|
|
|
|
|
with Brian Kernighan and Dennis <phrase
|
|
|
|
|
revisionflag="changed">Ritchie</phrase>,
|
|
|
|
|
with Brian Kernighan and Dennis
|
|
|
|
|
Ritchie,
|
|
|
|
|
<citetitle>The C Programming Language</citetitle>, 1st
|
|
|
|
|
edition).</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
@ -5992,9 +5940,8 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
floating-point type. (A complex floating-point data type is treated as if
|
|
|
|
|
two separate scalar values of the base type were passed.)</para>
|
|
|
|
|
<para>Homogeneous floating-point aggregates can have up to four IBM
|
|
|
|
|
EXTENDED PRECISION members, <phrase
|
|
|
|
|
revisionflag="deleted">four IEEE BINARY 128 QUADRUPLE
|
|
|
|
|
PRECISION members,</phrase> four _Decimal128 members, or
|
|
|
|
|
EXTENDED PRECISION members,
|
|
|
|
|
four _Decimal128 members, or
|
|
|
|
|
eight members of other
|
|
|
|
|
floating-point types. (Unions are treated as their largest member. For
|
|
|
|
|
homogeneous unions, different union alternatives may have different
|
|
|
|
|
@ -6020,14 +5967,12 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
|
|
|
|
|
<xref linkend="dbdoclet.50655240_15141" />) or processed in vector
|
|
|
|
|
registers</para>
|
|
|
|
|
<para>For the purpose of determining a qualified
|
|
|
|
|
floating-point argument, <phrase
|
|
|
|
|
revisionflag="deleted">_Float128</phrase><phrase
|
|
|
|
|
revisionflag="added">IEEE BINARY 128 QUADRUPLE
|
|
|
|
|
PRECISION</phrase> shall be considered a vector data type. In
|
|
|
|
|
addition, <phrase
|
|
|
|
|
revisionflag="deleted">_Float128</phrase><phrase
|
|
|
|
|
revisionflag="added">IEEE BINARY 128 QUADRUPLE
|
|
|
|
|
PRECISION</phrase>
|
|
|
|
|
floating-point argument,
|
|
|
|
|
IEEE BINARY 128 QUADRUPLE
|
|
|
|
|
PRECISION shall be considered a vector data type. In
|
|
|
|
|
addition,
|
|
|
|
|
IEEE BINARY 128 QUADRUPLE
|
|
|
|
|
PRECISION
|
|
|
|
|
is like a vector data type for determining if multiple aggregate members
|
|
|
|
|
are like.</para>
|
|
|
|
|
<para>A homogeneous aggregate can consist of a variety of nested
|
|
|
|
|
@ -6603,14 +6548,7 @@ s6 - 72 (stored)</programlisting>
|
|
|
|
|
architectures that pass some of the arguments in registers. The Power
|
|
|
|
|
Architecture is one of the architectures that passes some of the
|
|
|
|
|
arguments in registers.</para>
|
|
|
|
|
<para revisionflag="deleted"><anchor
|
|
|
|
|
xml:id="dbdoclet.50655240_page61" xreflabel="" />The parameter
|
|
|
|
|
list may be zero length and is only allocated when parameters are
|
|
|
|
|
spilled, when a function has unnamed parameters, or when no prototype is
|
|
|
|
|
provided. When the Parameter Save Area is allocated, the Parameter Save
|
|
|
|
|
Area must be large enough to accommodate all parameters, including
|
|
|
|
|
parameters passed in registers.</para>
|
|
|
|
|
<para revisionflag="added">
|
|
|
|
|
<para>
|
|
|
|
|
The caller of any function with a variable argument list
|
|
|
|
|
must allocate a Parameter Save Area, as described in <xref
|
|
|
|
|
linkend="dbdoclet.50655240_78421" />.
|
|
|
|
|
@ -6691,7 +6629,7 @@ s6 - 72 (stored)</programlisting>
|
|
|
|
|
<para>When instructions hold relative addresses, a program library can be
|
|
|
|
|
loaded at various positions in virtual memory and is referred to as a
|
|
|
|
|
position-independent code model.</para>
|
|
|
|
|
<para revisionflag="added">When generating code for PowerISA version 3.1
|
|
|
|
|
<para>When generating code for PowerISA version 3.1
|
|
|
|
|
or above, this specification provides two ways to address non-local data
|
|
|
|
|
and text. The historical method relies on a dedicated table-of-contents
|
|
|
|
|
(TOC) pointer to obtain such addresses. PowerISA version 3.1 introduces
|
|
|
|
|
@ -6729,7 +6667,7 @@ s6 - 72 (stored)</programlisting>
|
|
|
|
|
instructions:</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
<programlisting revisionflag="changed">lis r16, symbol@ha
|
|
|
|
|
<programlisting>lis r16, symbol@ha
|
|
|
|
|
ld r10, symbol@l(r16)
|
|
|
|
|
|
|
|
|
|
lis r16, symbol2@ha
|
|
|
|
|
@ -6742,7 +6680,7 @@ lvx v1, r0, r16</programlisting>
|
|
|
|
|
<xref linkend="dbdoclet.50655241_66700" />.)</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
<programlisting revisionflag="changed"><load TOC base to r2>
|
|
|
|
|
<programlisting><load TOC base to r2>
|
|
|
|
|
ld r10, symbol@toc(r2)
|
|
|
|
|
|
|
|
|
|
li r16, symbol2@toc
|
|
|
|
|
@ -6753,7 +6691,7 @@ lvx v1, r2, r16</programlisting>
|
|
|
|
|
addressing:</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
<programlisting revisionflag="changed"><load TOC base to r2>
|
|
|
|
|
<programlisting><load TOC base to r2>
|
|
|
|
|
|
|
|
|
|
ld r10, symbol@got(r2)
|
|
|
|
|
ld r10, 0(r10)
|
|
|
|
|
@ -6762,12 +6700,12 @@ ld r10, symbol2@got(r2)
|
|
|
|
|
lvx v1, 0, r10</programlisting>
|
|
|
|
|
<itemizedlist>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para revisionflag="added">
|
|
|
|
|
<para>
|
|
|
|
|
By using PC-relative addressing.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
<programlisting revisionflag="added">pld r10, symbol@pcrel
|
|
|
|
|
<programlisting>pld r10, symbol@pcrel
|
|
|
|
|
|
|
|
|
|
plxv v1, symbol@pcrel</programlisting>
|
|
|
|
|
<para>In the OpenPOWER ELF V2 ABI, position-dependent code built with
|
|
|
|
|
@ -6809,7 +6747,7 @@ plxv v1, symbol@pcrel</programlisting>
|
|
|
|
|
loaded in the first 2 GB of the address space because direct address
|
|
|
|
|
references and TOC-pointer initializations can be performed using a
|
|
|
|
|
two-instruction sequence.</para>
|
|
|
|
|
<para revisionflag="added">
|
|
|
|
|
<para>
|
|
|
|
|
PC-relative offsets are usually 34 bits for all code models, with
|
|
|
|
|
a maximum addressing reach of 16GB. The effective addressing reach
|
|
|
|
|
for global data is 8GB, since data sections are always located at
|
|
|
|
|
@ -6853,7 +6791,7 @@ plxv v1, symbol@pcrel</programlisting>
|
|
|
|
|
relative addressing (for private data).</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
<programlisting revisionflag="changed"><load TOC base to r2>
|
|
|
|
|
<programlisting><load TOC base to r2>
|
|
|
|
|
|
|
|
|
|
ld r10, symbol@toc(r2)
|
|
|
|
|
|
|
|
|
|
@ -6866,7 +6804,7 @@ lvx v1, r2, r16</programlisting>
|
|
|
|
|
sections):</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
<programlisting revisionflag="changed"><load TOC base to r2>
|
|
|
|
|
<programlisting><load TOC base to r2>
|
|
|
|
|
|
|
|
|
|
ld r10, symbol@got(r2)
|
|
|
|
|
|
|
|
|
|
@ -6876,26 +6814,26 @@ ld r10, symbol2@got(r2)
|
|
|
|
|
lvx v1, 0, r10</programlisting>
|
|
|
|
|
<itemizedlist>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para revisionflag="added">By using PC-relative addressing (for
|
|
|
|
|
<para>By using PC-relative addressing (for
|
|
|
|
|
private data).</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
<programlisting revisionflag="added">pld r10, symbol@pcrel
|
|
|
|
|
<programlisting>pld r10, symbol@pcrel
|
|
|
|
|
|
|
|
|
|
plxv v1, symbol@pcrel</programlisting>
|
|
|
|
|
<itemizedlist>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para revisionflag="added">By using PC-relative GOT-indirect
|
|
|
|
|
<para>By using PC-relative GOT-indirect
|
|
|
|
|
addressing (for shared data):
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</itemizedlist>
|
|
|
|
|
<programlisting revisionflag="added">pld r10, symbol@got@pcrel
|
|
|
|
|
<programlisting>pld r10, symbol@got@pcrel
|
|
|
|
|
ld r10, 0(r10)
|
|
|
|
|
|
|
|
|
|
pld r10, symbol@got@pcrel
|
|
|
|
|
lvx v1, 0, r10</programlisting>
|
|
|
|
|
<para revisionflag="added">
|
|
|
|
|
<para>
|
|
|
|
|
A compiler may generate a PC-relative addressing sequence to access
|
|
|
|
|
static or restricted-visibility data, but must generate a PC-relative
|
|
|
|
|
GOT-indirect sequence for extern data. Extern data may be satisfied
|
|
|
|
|
@ -6946,8 +6884,8 @@ lvx v1, 0, r10</programlisting>
|
|
|
|
|
addition, accesses to module-local code and data objects use TOC
|
|
|
|
|
pointer relative addressing with 32-bit offsets. Using TOC pointer
|
|
|
|
|
relative addressing removes a level of indirection, resulting in
|
|
|
|
|
faster access and a smaller GOT. <phrase
|
|
|
|
|
revisionflag="changed">However,</phrase> it limits the size of the
|
|
|
|
|
faster access and a smaller GOT.
|
|
|
|
|
However, it limits the size of the
|
|
|
|
|
entire binary to between 2 GB and 4 GB, depending on the placement
|
|
|
|
|
of the TOC base.</para>
|
|
|
|
|
<note>
|
|
|
|
|
@ -6967,7 +6905,7 @@ lvx v1, 0, r10</programlisting>
|
|
|
|
|
TOCs, or by some other method. The suggested allocation order of
|
|
|
|
|
sections is provided in
|
|
|
|
|
<xref linkend="dbdoclet.50655241_66700" />.</para>
|
|
|
|
|
<para revisionflag="added">
|
|
|
|
|
<para>
|
|
|
|
|
PC-relative addressing may be used with the medium code model.
|
|
|
|
|
Accesses to
|
|
|
|
|
module-local code and data objects use PC-relative addressing with
|
|
|
|
|
@ -6985,17 +6923,16 @@ lvx v1, 0, r10</programlisting>
|
|
|
|
|
<para>A function's prologue establishes addressability by
|
|
|
|
|
initializing a TOC pointer in register r2, if necessary, and a stack
|
|
|
|
|
frame, if necessary, and may save any nonvolatile registers it
|
|
|
|
|
uses. <phrase revisionflag="added">Not all functions must initialize
|
|
|
|
|
uses. Not all functions must initialize
|
|
|
|
|
a TOC pointer, and not all functions must preserve the existing value
|
|
|
|
|
of r2. See <xref linkend="dbdoclet.50655241_FnLinkage" /> for more
|
|
|
|
|
information.</phrase></para>
|
|
|
|
|
<para>All functions have a global entry point <phrase revisionflag="deleted">(GEP)</phrase> available to any
|
|
|
|
|
information.</para>
|
|
|
|
|
<para>All functions have a global entry point available to any
|
|
|
|
|
caller and pointing to the beginning of the prologue. Some functions
|
|
|
|
|
may have a secondary entry point to optimize the cost of TOC pointer
|
|
|
|
|
management. In particular, functions within a common module sharing the
|
|
|
|
|
same TOC base value in r2 may be entered using a secondary entry point
|
|
|
|
|
(the local entry point<phrase revisionflag="deleted"> or
|
|
|
|
|
LEP</phrase>) that may bypass the code that loads a
|
|
|
|
|
(the local entry point) that may bypass the code that loads a
|
|
|
|
|
suitable TOC pointer value into the r2 register. When a dynamic or
|
|
|
|
|
global linker transfers control from a function to another function in
|
|
|
|
|
the same module, it
|
|
|
|
|
@ -7003,22 +6940,21 @@ lvx v1, 0, r10</programlisting>
|
|
|
|
|
entry point when the r2 register is known to hold a valid TOC base
|
|
|
|
|
value. Function pointers shared between modules shall always use the
|
|
|
|
|
global entry point to specify the address of a function.</para>
|
|
|
|
|
<para><phrase revisionflag="deleted">When a linker causes
|
|
|
|
|
control to transfer</phrase><phrase revisionflag="added">When
|
|
|
|
|
control is transferred</phrase> to a global entry point
|
|
|
|
|
<phrase revisionflag="added">of a function that also has a local entry
|
|
|
|
|
point</phrase>, <phrase revisionflag="deleted">it</phrase>
|
|
|
|
|
<phrase revisionflag="added">the linker</phrase> must insert a
|
|
|
|
|
<para>When
|
|
|
|
|
control is transferred to a global entry point
|
|
|
|
|
of a function that also has a local entry
|
|
|
|
|
point,
|
|
|
|
|
the linker must insert a
|
|
|
|
|
glue code sequence that loads r12 with the global
|
|
|
|
|
entry-point address. Code at the global entry point <phrase
|
|
|
|
|
revisionflag="added">of a function that also has a local entry
|
|
|
|
|
point</phrase> can assume that
|
|
|
|
|
register r12 points to the <phrase
|
|
|
|
|
revisionflag="deleted">GEP</phrase><phrase revisionflag="added">global
|
|
|
|
|
entry point</phrase>. <phrase revisionflag="added">
|
|
|
|
|
entry-point address. Code at the global entry point
|
|
|
|
|
of a function that also has a local entry
|
|
|
|
|
point can assume that
|
|
|
|
|
register r12 points to the
|
|
|
|
|
global
|
|
|
|
|
entry point.
|
|
|
|
|
However, code at the global entry point of a function that does not
|
|
|
|
|
have a separate local entry point cannot make any assumptions about
|
|
|
|
|
the values of either r2 or 12.</phrase></para>
|
|
|
|
|
the values of either r2 or 12.</para>
|
|
|
|
|
<para>Addresses between the global and local entry points must not be
|
|
|
|
|
branch targets, either for function entry or referenced by program
|
|
|
|
|
logic of the function, because a linker may rewrite the code sequence
|
|
|
|
|
@ -7066,7 +7002,6 @@ or r0, r0, r1</programlisting>
|
|
|
|
|
either 0 or the correct in-order value of the corresponding CR field at
|
|
|
|
|
the point where the <emphasis role="bold">mfocrf</emphasis>
|
|
|
|
|
instruction is performed.</para>
|
|
|
|
|
<para revisionflag="deleted"> </para>
|
|
|
|
|
<bridgehead>Assembly Language Syntax for Defining Entry
|
|
|
|
|
Points</bridgehead>
|
|
|
|
|
<para>When a function has two entry points, the global entry point is
|
|
|
|
|
@ -7493,15 +7428,12 @@ _restvr_31: addi r12,r0,-16
|
|
|
|
|
The values of symbols or their absolute virtual addresses are placed
|
|
|
|
|
directly into instructions for symbolic references in absolute
|
|
|
|
|
code.</para>
|
|
|
|
|
<para revisionflag="deleted">
|
|
|
|
|
<xref linkend="dbdoclet.50655242_page119" /> shows an example of this
|
|
|
|
|
method.</para>
|
|
|
|
|
<para>Examples of absolute and position-independent compilations are
|
|
|
|
|
shown in <phrase revisionflag="changed"><xref
|
|
|
|
|
shown in <xref
|
|
|
|
|
linkend="dbdoclet.50655240_12719" />,
|
|
|
|
|
<xref linkend="dbdoclet.50655240_page77" />,
|
|
|
|
|
<xref linkend="dbdoclet.50655240_19926" />, and
|
|
|
|
|
<xref linkend="dbdoclet.50655240_StaticPCRel" /></phrase>. These
|
|
|
|
|
<xref linkend="dbdoclet.50655240_StaticPCRel" />. These
|
|
|
|
|
examples show the
|
|
|
|
|
C language statements together with the generated assembly language. The
|
|
|
|
|
assumption for these figures is that only executables can use absolute
|
|
|
|
|
@ -7767,8 +7699,7 @@ stw r0,0,(r7)</programlisting>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</table>
|
|
|
|
|
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_StaticPCRel"
|
|
|
|
|
revisionflag="added">
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_StaticPCRel">
|
|
|
|
|
<title>PC-Relative Load and Store</title>
|
|
|
|
|
<tgroup cols="2">
|
|
|
|
|
<colspec colname="c1" colwidth="30*" />
|
|
|
|
|
@ -7837,7 +7768,7 @@ stw r9, 0(r11)</programlisting>
|
|
|
|
|
a signed 32-bit offset from a base register.</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>For <phrase revisionflag="changed">TOC-based</phrase> PIC
|
|
|
|
|
<para>For TOC-based PIC
|
|
|
|
|
code (see <xref linkend="dbdoclet.50655240_page77" /> and
|
|
|
|
|
<xref linkend="dbdoclet.50655240_19926" />), the offset in the
|
|
|
|
|
Global Offset Table where the value of the symbol is stored is
|
|
|
|
|
@ -7983,15 +7914,13 @@ nop</programlisting>
|
|
|
|
|
<para>For indirect function calls, the address of the function to be
|
|
|
|
|
called is placed in r12 and the CTR register. A bctrl instruction is used
|
|
|
|
|
to perform the indirect branch as shown in
|
|
|
|
|
<phrase revisionflag="added">
|
|
|
|
|
<xref linkend="dbdoclet.50655240_95364" />,
|
|
|
|
|
</phrase>
|
|
|
|
|
<xref linkend="dbdoclet.50655240_16744" />, and
|
|
|
|
|
<xref linkend="dbdoclet.50655240_95225" />. The ELF V2 ABI requires the
|
|
|
|
|
address of the called function to be in r12 when a cross-module function
|
|
|
|
|
call is made.</para>
|
|
|
|
|
|
|
|
|
|
<table frame="all" pgwide="1" revisionflag="changed"
|
|
|
|
|
<table frame="all" pgwide="1"
|
|
|
|
|
xml:id="dbdoclet.50655240_95364">
|
|
|
|
|
<title>Indirect Function Call (Absolute Medium Model)</title>
|
|
|
|
|
<tgroup cols="2">
|
|
|
|
|
@ -8051,7 +7980,7 @@ bctrl</programlisting>
|
|
|
|
|
function call using small-model position-independent code.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<table frame="all" pgwide="1" revisionflag="changed"
|
|
|
|
|
<table frame="all" pgwide="1"
|
|
|
|
|
xml:id="dbdoclet.50655240_16744">
|
|
|
|
|
<title>Small-Model Position-Independent Indirect Function Call</title>
|
|
|
|
|
<tgroup cols="2">
|
|
|
|
|
@ -8113,7 +8042,7 @@ ld r2,24(r1)</programlisting>
|
|
|
|
|
function call using large-model position-independent code.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<table frame="all" pgwide="1" revisionflag="changed"
|
|
|
|
|
<table frame="all" pgwide="1"
|
|
|
|
|
xml:id="dbdoclet.50655240_95225">
|
|
|
|
|
<title>Large-Model Position-Independent Indirect Function Call</title>
|
|
|
|
|
<tgroup cols="2">
|
|
|
|
|
@ -8178,12 +8107,12 @@ ld r2,24(r1)</programlisting>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</table>
|
|
|
|
|
<para revisionflag="added">
|
|
|
|
|
<para>
|
|
|
|
|
<xref linkend="dbdoclet.50655240_PCRelPICIndirect" /> shows how to
|
|
|
|
|
make an indirect function call using PC-relative addressing in a
|
|
|
|
|
function that does not preserve r2.
|
|
|
|
|
</para>
|
|
|
|
|
<table frame="all" pgwide="1" revisionflag="added"
|
|
|
|
|
<table frame="all" pgwide="1"
|
|
|
|
|
xml:id="dbdoclet.50655240_PCRelPICIndirect">
|
|
|
|
|
<title>PC-Relative Position-Independent Indirect Function Call</title>
|
|
|
|
|
<tgroup cols="2">
|
|
|
|
|
@ -8234,20 +8163,7 @@ bctrl</programlisting>
|
|
|
|
|
</tbody>
|
|
|
|
|
</tgroup>
|
|
|
|
|
</table>
|
|
|
|
|
<para revisionflag="deleted">Function calls
|
|
|
|
|
need to be performed in conjunction with
|
|
|
|
|
establishing, maintaining, and restoring addressability through the TOC
|
|
|
|
|
pointer register, r2. When a function is called, the TOC pointer register
|
|
|
|
|
may be modified. The caller must provide a nop
|
|
|
|
|
after the bl instruction performing a call, if r2 is not known to have
|
|
|
|
|
the same value in the callee. This is generally true for external calls.
|
|
|
|
|
The linker will replace the nop with an r2 restoring instruction if the
|
|
|
|
|
caller and callee use different r2 values, The linker leaves it
|
|
|
|
|
unchanged if they
|
|
|
|
|
use the same r2 value. This scheme avoids having a compiler generate an
|
|
|
|
|
overconservative r2 save and restore around every external
|
|
|
|
|
call.</para>
|
|
|
|
|
<para revisionflag="added">
|
|
|
|
|
<para>
|
|
|
|
|
When a function requires addressability through the TOC
|
|
|
|
|
pointer register, r2, and that function calls another function
|
|
|
|
|
that may not preserve the value of r2, the caller must provide
|
|
|
|
|
@ -8258,7 +8174,7 @@ bctrl</programlisting>
|
|
|
|
|
<xref linkend="dbdoclet.50655241_FnLinkage" /> for a full
|
|
|
|
|
description of when a nop must be inserted.
|
|
|
|
|
</para>
|
|
|
|
|
<para revisionflag="added">
|
|
|
|
|
<para>
|
|
|
|
|
There are two cases where the caller need not provide a nop after
|
|
|
|
|
the bl instruction performing a call:
|
|
|
|
|
<itemizedlist spacing="compact">
|
|
|
|
|
@ -8272,12 +8188,12 @@ bctrl</programlisting>
|
|
|
|
|
<para>For calls to functions resolved at runtime, the linker must
|
|
|
|
|
generate stub code to load the function address from the PLT.</para>
|
|
|
|
|
<para>The stub code also must save r2 to 24(r1) unless
|
|
|
|
|
<phrase revisionflag="added">either the call is marked with an
|
|
|
|
|
R_PPC64_REL24_NOTOC relocation, or</phrase> the call is marked
|
|
|
|
|
either the call is marked with an
|
|
|
|
|
R_PPC64_REL24_NOTOC relocation, or the call is marked
|
|
|
|
|
with an R_PPC64_TOCSAVE relocation that points to a nop provided in the
|
|
|
|
|
caller's prologue. In <phrase revisionflag="changed">either</phrase>
|
|
|
|
|
caller's prologue. In either
|
|
|
|
|
case, the stub code can omit the r2 save.
|
|
|
|
|
<phrase revisionflag="changed">In the latter case,</phrase>
|
|
|
|
|
In the latter case,
|
|
|
|
|
the linker replaces the prologue nop with an r2 save.</para>
|
|
|
|
|
<programlisting>tocsaveloc:
|
|
|
|
|
nop
|
|
|
|
|
@ -8307,7 +8223,7 @@ bl target
|
|
|
|
|
<xref linkend="dbdoclet.50655240_66111" /> shows the model for branch
|
|
|
|
|
instructions.</para>
|
|
|
|
|
|
|
|
|
|
<table frame="all" pgwide="1" revisionflag="changed"
|
|
|
|
|
<table frame="all" pgwide="1"
|
|
|
|
|
xml:id="dbdoclet.50655240_66111">
|
|
|
|
|
<title>Branch Instruction Model</title>
|
|
|
|
|
<tgroup cols="2">
|
|
|
|
|
@ -8366,7 +8282,7 @@ b .L01</programlisting>
|
|
|
|
|
application) loaded into the low or high address range, absolute
|
|
|
|
|
addressing of a branch table yields the best performance.</para>
|
|
|
|
|
|
|
|
|
|
<table frame="all" pgwide="1" revisionflag="changed"
|
|
|
|
|
<table frame="all" pgwide="1"
|
|
|
|
|
xml:id="dbdoclet.50655240_AbsSwitch">
|
|
|
|
|
<title>Absolute Switch Code (Within) for static modules located in low
|
|
|
|
|
or high 2 GB of address space</title>
|
|
|
|
|
@ -8432,7 +8348,7 @@ bctr
|
|
|
|
|
lwz instruction in place of the lwa instruction.</para>
|
|
|
|
|
</note>
|
|
|
|
|
|
|
|
|
|
<table frame="all" pgwide="1" revisionflag="changed"
|
|
|
|
|
<table frame="all" pgwide="1"
|
|
|
|
|
xml:id="dbdoclet.50655240_AbsSwitchBeyond">
|
|
|
|
|
<title>Absolute Switch Code (Beyond) for static modules beyond the top
|
|
|
|
|
or bottom 2 GB of the address space</title>
|
|
|
|
|
@ -8499,7 +8415,7 @@ bctr
|
|
|
|
|
relative offsets from the start address of the branch table ensures
|
|
|
|
|
position-independence when code is loaded at different addresses.</para>
|
|
|
|
|
|
|
|
|
|
<table frame="all" pgwide="1" revisionflag="changed"
|
|
|
|
|
<table frame="all" pgwide="1"
|
|
|
|
|
xml:id="dbdoclet.50655240_SwitchPicMed">
|
|
|
|
|
<title>Position-Independent Switch Code for Small/Medium Models
|
|
|
|
|
(preferred, with TOC-relative addressing)</title>
|
|
|
|
|
@ -8567,7 +8483,7 @@ bctr
|
|
|
|
|
table ensures position independence when code is loaded at different
|
|
|
|
|
addresses.</para>
|
|
|
|
|
|
|
|
|
|
<table frame="all" pgwide="1" revisionflag="changed"
|
|
|
|
|
<table frame="all" pgwide="1"
|
|
|
|
|
xml:id="dbdoclet.50655240_SwitchGotAll">
|
|
|
|
|
<title>Position-Independent Switch Code for All Models (alternate, with
|
|
|
|
|
GOT-indirect addressing)</title>
|
|
|
|
|
@ -8649,12 +8565,11 @@ f1:
|
|
|
|
|
.long .TOC. - Ldefault
|
|
|
|
|
.long .TOC. - Lcase13</programlisting>
|
|
|
|
|
</figure>
|
|
|
|
|
<para revisionflag="added">
|
|
|
|
|
<para>
|
|
|
|
|
<xref linkend="dbdoclet.50655240_PCRelSwitch" /> shows a switch
|
|
|
|
|
implementation for PC-relative compilation units.
|
|
|
|
|
</para>
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_PCRelSwitch"
|
|
|
|
|
revisionflag="added">
|
|
|
|
|
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_PCRelSwitch">
|
|
|
|
|
<title>
|
|
|
|
|
Position-Independent Switch Code (PC-Relative Addressing)
|
|
|
|
|
</title>
|
|
|
|
|
@ -8780,10 +8695,8 @@ addi r3,r1,p ; R3 = new data area following parameter save area.</pro
|
|
|
|
|
<para>Because it is allowed (and common) to return without first
|
|
|
|
|
deallocating this dynamically allocated memory, all the linkage
|
|
|
|
|
information in the new location must be valid. Therefore, it is also
|
|
|
|
|
necessary to copy the <phrase revisionflag="deleted">CR save
|
|
|
|
|
word and the</phrase> TOC pointer doubleword from <phrase
|
|
|
|
|
revisionflag="deleted">their old locations</phrase> <phrase
|
|
|
|
|
revisionflag="added">its old location</phrase> to the new. It is
|
|
|
|
|
necessary to copy the TOC pointer doubleword from its old location
|
|
|
|
|
to the new. It is
|
|
|
|
|
not necessary to copy the LR save
|
|
|
|
|
doubleword because, until this function makes a call, it does not contain
|
|
|
|
|
a value that needs to be preserved. In the future, if it is defined and
|
|
|
|
|
@ -9162,7 +9075,7 @@ addi r3,r1,p ; R3 = new data area following parameter save area.</pro
|
|
|
|
|
in the Itanium C++ ABI, the normative text on the issue. For information
|
|
|
|
|
about how to locate this material, see
|
|
|
|
|
<xref linkend="dbdoclet.50655239___RefHeading___Toc377640569" />.</para>
|
|
|
|
|
<para revisionflag="added">
|
|
|
|
|
<para>
|
|
|
|
|
When unwinding, care must be taken to restore the TOC pointer r2 if and
|
|
|
|
|
only if it has been saved. It is recommended that the unwinder reads the
|
|
|
|
|
instruction at the return address in the link register and restores r2
|
|
|
|
|
|
Bill Schmidt
3 years ago