systemsoftware
/
ELFv2-ABI
35
1
Fork 0
Code Issues 10 Pull Requests Projects Releases Wiki Activity

Changes for fourth draft of PC-relative changes.

Browse Source 
Signed-off-by: Bill Schmidt <wschmidt@linux.ibm.com>
master
Bill Schmidt 7 years ago
parent 9968764818
commit ebdc859ac4
4 changed files with 623 additions and 332 deletions
Show Stats Download Patch File Download Diff File

13
specification/bk_main.xml
Unescape Escape View File

@ -57,7 +57,7 @@
<holder>Freescale Semiconductor, Inc</holder>
</copyright>
<!-- TODO: Set the correct document releaseinfo -->
<releaseinfo>Revision 1.5c draft</releaseinfo>
<releaseinfo>Revision 1.5d draft</releaseinfo>
<productname>OpenPOWER</productname>
<pubdate/>

@ -93,6 +93,17 @@

<revhistory>
<!-- TODO: Set the initial version information and clear any old information out -->
<revision>
<date>2018-05-10</date>
<revdescription>
<itemizedlist spacing="compact">
<listitem>
<para>Revision 1.5d: PC-relative addressing fourth
draft.</para>
</listitem>
</itemizedlist>
</revdescription>
</revision>
<revision>
<date>2018-04-28</date>
<revdescription>

24
specification/ch_1.xml
Unescape Escape View File

@ -181,6 +181,28 @@
</section>
<section revisionflag="added">
<title>Changes from Revision 1.4</title>
<para>TBD</para>
<itemizedlist>
<listitem>
<para>
Errata recorded at <link xl:href="https://openpowerfoundation.org/?resource_lib=openpower-elfv2-errata-elfv2-abi-version-1-4">https://openpowerfoundation.org/?resource_lib=openpower-elfv2-errata-elfv2-abi-version-1-4</link>
have been incorporated into this document.
</para>
</listitem>
<listitem>
<para>
PowerISA version 3.1 introduces PC-relative instructions for
accessing code and data. Thus compilers and assembly programmers
that target version 3.1 or later can, if desired, avoid usage of
a TOC pointer for such accesses. The ABI has been updated to
describe the implications of this new capability. For specifics,
see <xref linkend="dbdoclet.50655241_FnLinkage" />, <xref
linkend="dbdoclet.50655240___RefHeading___Toc377640591" />, <xref
linkend="dbdoclet.50655241_18894" />, <xref
linkend="dbdoclet.50655241_LinkerOpts" />, <xref
linkend="dbdoclet.50655242_47739" />, and <xref
linkend="dbdoclet.50655242_82622" />.
</para>
</listitem>
</itemizedlist>
</section>
</chapter>

226
specification/ch_2.xml
Unescape Escape View File

@ -4086,7 +4086,9 @@ xml:id="dbdoclet.50655240_pgfId-1156194">
protocol requirements for external function calls, and
<xref linkend="dbdoclet.50655241_LocalProtocols" /> summarizes the
protocol requirements for local function calls. Each entry in these
tables is further described in the referenced section.
tables is further described in the referenced section. A program may
contain any combination of the function call protocols in these
tables.
<note><para>Note that
this ABI does not define protocols where the caller does not use
a TOC pointer, but does preserve r2. It is most efficient when
@ -7899,16 +7901,8 @@ nop</programlisting>
address of the called function to be in r12 when a cross-module function
call is made.</para>

<figure xml:id="dbdoclet.50655240_95364">
<title>Indirect Function Call (Absolute Medium Model)</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-33.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!-- table frame="all" pgwide="1" xml:id="dbdoclet.50655240_95364">
<table frame="all" pgwide="1" revisionflag="changed"
xml:id="dbdoclet.50655240_95364">
<title>Indirect Function Call (Absolute Medium Model)</title>
<tgroup cols="2">
<colspec colname="c1" colwidth="30*" />
@ -7937,9 +7931,11 @@ ptrfunc = function;




(*ptrfunc) ( );



</programlisting>
</entry>
<entry>
@ -7950,6 +7946,7 @@ lis r11,ptrfunc@ha
lis r9,function@ha
ld r9,function@l(r9)
std r9,ptrfunc@l(r11)

lis r12,ptrfunc@ha
ld r12,ptrfunc@l(r12)
mtctr r12
@ -7958,22 +7955,14 @@ bctrl</programlisting>
</row>
</tbody>
</tgroup>
</table -->
</table>
<para>
<xref linkend="dbdoclet.50655240_16744" /> shows how to make an indirect
function call using small-model position-independent code.
</para>

<figure xml:id="dbdoclet.50655240_16744">
<title>Small-Model Position-Independent Indirect Function Call</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-34.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1" xml:id="dbdoclet.50655240_16744">
<table frame="all" pgwide="1" revisionflag="changed"
xml:id="dbdoclet.50655240_16744">
<title>Small-Model Position-Independent Indirect Function Call</title>
<tgroup cols="2">
<colspec colname="c1" colwidth="30*" />
@ -8002,9 +7991,8 @@ extern void (*ptrfunc) ( );
ptrfunc = function;


...
(*ptrfunc) ( );

(*ptrfunc) ( );



@ -8018,7 +8006,7 @@ ptrfunc = function;
ld r9,ptrfunc@got(r2)
ld r0,function@got(r2)
std r0,0(r9)
...

ld r9,ptrfunc@got(r2)
ld r12,0(r9)
mtctr r12
@ -8029,25 +8017,81 @@ ld r2,24(r1)</programlisting>
</row>
</tbody>
</tgroup>
</table -->
</table>
<para>
<xref linkend="dbdoclet.50655240_95225" /> shows how to make an indirect
function call using large-model position-independent code.
</para>

<figure xml:id="dbdoclet.50655240_95225">
<table frame="all" pgwide="1" revisionflag="changed"
xml:id="dbdoclet.50655240_95225">
<title>Large-Model Position-Independent Indirect Function Call</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-35.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<tgroup cols="2">
<colspec colname="c1" colwidth="30*" />
<colspec colname="c2" colwidth="70*" />
<thead>
<row>
<entry>
<para>
<emphasis role="bold">C Code</emphasis>
</para>
</entry>
<entry>
<para>
<emphasis role="bold">Assembly Code</emphasis>
</para>
</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<programlisting>extern void function( );
extern void (*ptrfunc) ( );


ptrfunc = function;





(*ptrfunc) ( );






</programlisting>
</entry>
<entry>
<programlisting>

.section .text
/* TOC pointer is in r2 */
addis r9,r2,ptrfunc@got@ha
ld r9,ptrfunc@got@l(r9)
addis r12,r2,function@got@ha
ld r12,function@got@l(r12)
std r12,0(r9)

addis r9,r2,ptrfunc@got@ha
ld r9,ptrfunc@got@l(r9)
ld r12,0(r9)
std r2,24(r1)
mtctr r12
bctrl
ld r2,24(r1)</programlisting>
</entry>
</row>
</tbody>
</tgroup>
</table>
<para revisionflag="added">
<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. [TBD: Formatting]
function that does not preserve r2.
</para>
<table frame="all" pgwide="1" revisionflag="added"
xml:id="dbdoclet.50655240_PCRelPICIndirect">
@ -8114,24 +8158,21 @@ bctrl</programlisting>
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">
There are two cases where the caller should not provide a nop after
There are two cases where the caller need not provide a nop after
the bl instruction performing a call:
<itemizedlist spacing="compact">
<listitem><para>When the caller is not guaranteed to preserve r2 (see
<xref linkend="dbdoclet.50655241_95185" />); or</para></listitem>
<listitem><para>When the bl instruction is marked with an
R_PPC64_REL24_NOTOC relocation (see
<xref linkend="dbdoclet.50655241_90220" />); or</para></listitem>
<listitem><para>When the callee is in the same compilation unit and
is guaranteed to preserve r2.</para></listitem>
</itemizedlist>
In the first case, the bl instruction must be marked with an
R_PPC64_REL24_NOTOC relocation. See <xref
linkend="dbdoclet.50655241_90220" />.
</para>
<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 as above, or</phrase>
the call is marked
R_PPC64_REL24_NOTOC relocation, or</phrase> 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>
case, the stub code can omit the r2 save.
@ -8165,20 +8206,12 @@ bl target
<xref linkend="dbdoclet.50655240_66111" /> shows the model for branch
instructions.</para>

<figure xml:id="dbdoclet.50655240_66111">
<title>Branch Instruction Model</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-36.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1" xml:id="dbdoclet.50655240_66111">
<table frame="all" pgwide="1" revisionflag="changed"
xml:id="dbdoclet.50655240_66111">
<title>Branch Instruction Model</title>
<tgroup cols="2">
<colspec colname="c1" colwidth="50*" />
<colspec colname="c2" colwidth="50*" />
<colspec colname="c1" colwidth="30*" />
<colspec colname="c2" colwidth="70*" />
<thead>
<row>
<entry>
@ -8208,7 +8241,7 @@ b .L01</programlisting>
</row>
</tbody>
</tgroup>
</table-->
</table>
<para>Selecting one of multiple branches is accomplished in C with switch
statements. An address table is used by the compiler to implement the
switch statement selections in cases where the case labels satisfy
@ -8232,17 +8265,8 @@ b .L01</programlisting>
application) loaded into the low or high address range, absolute
addressing of a branch table yields the best performance.</para>

<figure>
<title>Absolute Switch Code (Within) for static modules located in low
or high 2 GB of address space</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-37.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1">
<table frame="all" pgwide="1" revisionflag="changed"
xml:id="dbdoclet.50655240_AbsSwitch">
<title>Absolute Switch Code (Within) for static modules located in low
or high 2 GB of address space</title>
<tgroup cols="2">
@ -8278,6 +8302,7 @@ default:
}



</programlisting>
</entry>
<entry>
@ -8299,24 +8324,15 @@ bctr
</row>
</tbody>
</tgroup>
</table-->
</table>
<note>
<para>A faster variant of this code may be used to locate branch
targets in the bottom 2 GB of the address space in conjunction with the
lwz instruction in place of the lwa instruction.</para>
</note>
<figure>
<title>Absolute Switch Code (Beyond) for static modules beyond the top
or bottom 2 GB of the address space</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-38.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1">
<table frame="all" pgwide="1" revisionflag="changed"
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>
<tgroup cols="2">
@ -8352,6 +8368,7 @@ default:
}



</programlisting>
</entry>
<entry>
@ -8364,16 +8381,16 @@ mtctr r12
bctr
.rodata
.Ltab:
.quad .Lcase0
.quad .Lcase1
.quad .Ldefault
.quad .Lcase3
.long .Lcase0
.long .Lcase1
.long .Ldefault
.long .Lcase3
.text</programlisting>
</entry>
</row>
</tbody>
</tgroup>
</table -->
</table>
<para>For position-independent code targeted at being dynamically loaded
to different address ranges as DSO, the preferred code pattern uses
TOC-relative addressing by taking advantage of the fact that the TOC
@ -8381,19 +8398,10 @@ bctr
relative offsets from the start address of the branch table ensures
position-independence when code is loaded at different addresses.</para>


<figure>
<table frame="all" pgwide="1" revisionflag="changed"
xml:id="dbdoclet.50655240_SwitchPicMed">
<title>Position-Independent Switch Code for Small/Medium Models
(preferred, with TOC-relative addressing)</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-39.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1">
<title>Position-Independent Switch Code for Small/Medium Models</title>
<tgroup cols="2">
<colspec colname="c1" colwidth="30*" />
<colspec colname="c2" colwidth="70*" />
@ -8427,6 +8435,7 @@ default:
}



</programlisting>
</entry>
<entry>
@ -8448,7 +8457,7 @@ bctr
</row>
</tbody>
</tgroup>
</table-->
</table>
<para>For position-independent code targeted at being dynamically loaded
to different address ranges as a DSO or a position-independent executable
(PIE), the preferred code pattern uses TOC-indirect addresses for code
@ -8457,17 +8466,8 @@ bctr
table ensures position independence when code is loaded at different
addresses.</para>

<figure>
<title>Position-Independent Switch Code for All Models (alternate, with
GOT-indirect addressing)</title>
<mediaobject>
<imageobject>
<imagedata fileref="figures/fig2-40.png" format="PNG"
scalefit="1" width="100%" />
</imageobject>
</mediaobject>
</figure>
<!--table frame="all" pgwide="1">
<table frame="all" pgwide="1" revisionflag="changed"
xml:id="dbdoclet.50655240_SwitchGotAll">
<title>Position-Independent Switch Code for All Models (alternate, with
GOT-indirect addressing)</title>
<tgroup cols="2">
@ -8503,16 +8503,17 @@ default:
}



</programlisting>
</entry>
<entry>
<programlisting>cmplwi r12,4
bge .Ldefault
addis r10,r2,.Ltab@got@ha
ld r10,.Ltab@got@l(r10)
ld r10,r10,.Ltab@got@l(r10)
slwi r12,2
lwax r8,r10,r8
add r10,r8,r12
lwax r8,r10,r12
add r10,r8,r10
mtctr r10
bctr
.Ltab:
@ -8524,7 +8525,7 @@ bctr
</row>
</tbody>
</tgroup>
</table-->
</table>
<para>
<xref linkend="dbdoclet.50655240_11405" /> shows how, in the medium code
model, PIC code can be used to avoid using the lwa instruction, which may
@ -8549,7 +8550,7 @@ f1:
</figure>
<para revisionflag="added">
<xref linkend="dbdoclet.50655240_PCRelSwitch" /> shows a switch
implementation for PC-relative compilation units. [TBD: Formatting]
implementation for PC-relative compilation units.
</para>
<table frame="all" pgwide="1" xml:id="dbdoclet.50655240_PCRelSwitch"
revisionflag="added">
@ -8589,6 +8590,7 @@ default:
}



</programlisting>
</entry>
<entry>

468
specification/ch_3.xml
Unescape Escape View File

@ -992,7 +992,8 @@ my_func:
</tgroup>
</informaltable>
<para>In the following figure, low24 specifies a 24-bit field taking up
bits 6&#8211;29 of a word and maintaining 4-byte alignment. The other bits
bits 6&#8211;29 of a <phrase revisionflag="changed">word. The 32-bit
word is 4-byte aligned.</phrase> The other bits
remain unchanged. A call or unconditional branch instruction is an
example of this field.</para>
<para> </para>
@ -2228,10 +2229,9 @@ my_func:
</tgroup>
</informaltable>
<para revisionflag="added">
In the following figure, prefix34ds is similar to prefix34, but is
really just 32 bits because the two least-significant bits must be
zero and are not really part of the field. This is used, for example,
by the pld instruction.
In the following figure, prefix32 specifies a 32-bit field taking up
bits 14-31 and 48-61 of a doubleword. The doubleword is 8-byte
aligned. This is used, for example, by the pld instruction.
</para>
<informaltable frame="all" rowsep="0" colsep="0" revisionflag="added">
<tgroup cols="7">
@ -2274,7 +2274,7 @@ my_func:
<para> </para>
</entry>
<entry nameend="c7" namest="c3" align="center">
<para>prefix34ds</para>
<para>prefix32</para>
</entry>
</row>
<row rowsep="1">
@ -2334,7 +2334,7 @@ my_func:
<para> </para>
</entry>
<entry nameend="c5" namest="c4" align="center" colsep="1">
<para>prefix34ds (continued)</para>
<para>prefix32 (continued)</para>
</entry>
<entry>
<para> </para>
@ -2370,10 +2370,9 @@ my_func:
</tgroup>
</informaltable>
<para revisionflag="added">
In the following figure, prefix34dq is similar to prefix34, but is
really just 31 bits because the three least-significant bits must be
zero and are not really part of the field. This is used, for example,
by the plxv instruction.
In the following figure, prefix31 specifies a 31-bit field taking up
bits 14-31 and 48-60 of a doubleword. The doubleword is 8-byte
aligned. This is used, for example, by the plxv instruction.
</para>
<informaltable frame="all" rowsep="0" colsep="0" revisionflag="added">
<tgroup cols="7">
@ -2416,7 +2415,7 @@ my_func:
<para> </para>
</entry>
<entry nameend="c7" namest="c3" align="center">
<para>prefix34dq</para>
<para>prefix31</para>
</entry>
</row>
<row rowsep="1">
@ -2476,7 +2475,7 @@ my_func:
<para> </para>
</entry>
<entry nameend="c5" namest="c4" align="center" colsep="1">
<para>prefix34dq (continued)</para>
<para>prefix31 (continued)</para>
</entry>
<entry>
<para> </para>
@ -2512,11 +2511,9 @@ my_func:
</tgroup>
</informaltable>
<para revisionflag="added">
In the following figure, prefix28dq specifies a 25-bit field split
between bits 20-31 and 48-60 of a doubleword. The other bits
remain unchanged, and the 25-bit field is assumed to be concatenated
with three zero bits on the right to form a 28-bit offset. This is
used, for example, by the pmlxv instruction.
In the following figure, prefix25 specifies a 25-bit field taking up
bits 20-31 and 48-60 of a doubleword. The doubleword is 8-byte
aligned. This is used, for example, by the pmlxv instruction.
</para>
<informaltable frame="all" rowsep="0" colsep="0" revisionflag="added">
<tgroup cols="6">
@ -2558,7 +2555,7 @@ my_func:
<para> </para>
</entry>
<entry nameend="c6" namest="c4" align="center">
<para>prefix28dq</para>
<para>prefix25</para>
</entry>
</row>
<row rowsep="1">
@ -2609,7 +2606,7 @@ my_func:
<para> </para>
</entry>
<entry nameend="c4" namest="c3" align="center" colsep="1">
<para>prefix28dq (continued)</para>
<para>prefix25 (continued)</para>
</entry>
<entry>
<para> </para>
@ -2678,7 +2675,8 @@ my_func:
<para>G</para>
</entry>
<entry>
<para>Represents the offset from .TOC. at which the address of
<para>Represents the <phrase revisionflag="changed">address in
the</phrase> .TOC. at which the address of
the relocation entry’s symbol resides during execution. This
implies the creation of a .got section. For more information,
see
@ -2694,7 +2692,8 @@ my_func:
<para>L</para>
</entry>
<entry>
<para>Represents the section offset or address of the procedure
<para>Represents the <phrase revisionflag="deleted">section
offset or</phrase> address of the procedure
linkage table entry for the symbol. This implies the creation
of a .plt section if one does not already exist. It also
implies the creation of a procedure linkage table (PLT) entry
@ -2922,15 +2921,6 @@ my_func:
<para>tp + tprel = (S + A)</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>pcrel</para>
</entry>
<entry>
<para>Represents the offset of the symbol being relocated
relative to the current instruction address.</para>
</entry>
</row>
<row>
<entry>
<para>tlsgd</para>
@ -3205,7 +3195,9 @@ my_func:
<para>half16*</para>
</entry>
<entry>
<para>G</para>
<para>
<phrase revisionflag="changed">G &#8211; .TOC.</phrase>
</para>
</entry>
</row>
<row>
@ -3219,7 +3211,9 @@ my_func:
<para>half16</para>
</entry>
<entry>
<para>#lo(G)</para>
<para>
<phrase revisionflag="changed">#lo(G &#8211; .TOC.)</phrase>
</para>
</entry>
</row>
<row>
@ -3233,7 +3227,9 @@ my_func:
<para>half16*</para>
</entry>
<entry>
<para>#hi(G)</para>
<para>
<phrase revisionflag="changed">#hi(G &#8211; .TOC.)</phrase>
</para>
</entry>
</row>
<row>
@ -3247,7 +3243,9 @@ my_func:
<para>half16*</para>
</entry>
<entry>
<para>#ha(G)</para>
<para>
<phrase revisionflag="changed">#ha(G &#8211; .TOC.)</phrase>
</para>
</entry>
</row>
<row>
@ -3389,7 +3387,9 @@ my_func:
<para>half16</para>
</entry>
<entry>
<para>#lo(L)</para>
<para>
<phrase revisionflag="changed">#lo(L &#8211; .TOC.)</phrase>
</para>
</entry>
</row>
<row>
@ -3403,7 +3403,9 @@ my_func:
<para>half16*</para>
</entry>
<entry>
<para>#hi(L)</para>
<para>
<phrase revisionflag="changed">#hi(L &#8211; .TOC.)</phrase>
</para>
</entry>
</row>
<row>
@ -3417,7 +3419,9 @@ my_func:
<para>half16*</para>
</entry>
<entry>
<para>#ha(L)</para>
<para>
<phrase revisionflag="changed">#ha(L &#8211; .TOC.)</phrase>
</para>
</entry>
</row>
<row>
@ -3781,7 +3785,10 @@ my_func:
<para>half16ds*</para>
</entry>
<entry>
<para>G &gt;&gt; 2</para>
<para>
<phrase revisionflag="changed">(G &#8211; .TOC.) &gt;&gt;
2</phrase>
</para>
</entry>
</row>
<row>
@ -3795,7 +3802,10 @@ my_func:
<para>half16ds</para>
</entry>
<entry>
<para>#lo(G) &gt;&gt; 2</para>
<para>
<phrase revisionflag="changed">#lo(G &#8211; .TOC.) &gt;&gt;
2</phrase>
</para>
</entry>
</row>
<row>
@ -3809,7 +3819,10 @@ my_func:
<para>half16ds</para>
</entry>
<entry>
<para>#lo(L) &gt;&gt; 2</para>
<para>
<phrase revisionflag="changed">#lo(L &#8211; .TOC.) &gt;&gt;
2</phrase>
</para>
</entry>
</row>
<row>
@ -4633,103 +4646,116 @@ my_func:
<para>none</para>
</entry>
</row>
<row>
<row revisionflag="added">
<entry>
<para>R_PPC64_IRELATIVE</para>
<para>R_PPC64_PLTSEQ</para>
</entry>
<entry>
<para>248</para>
<para>119</para>
</entry>
<entry>
<para>doubleword64</para>
<para>none</para>
</entry>
<entry>
<para>See
<xref linkend="dbdoclet.50655241_90220" />.</para>
<para>none</para>
</entry>
</row>
<row>
<row revisionflag="added">
<entry>
<para>R_PPC64_REL16</para>
<para>R_PPC64_PLTCALL</para>
</entry>
<entry>
<para>249</para>
<para>120</para>
</entry>
<entry>
<para>half16*</para>
<para>none</para>
</entry>
<entry>
<para>S + A &#8211; P</para>
<para>none</para>
</entry>
</row>
<row>
<row revisionflag="added">
<entry>
<para>R_PPC64_REL16_LO</para>
<para>R_PPC64_PLTSEQ_NOTOC</para>
</entry>
<entry>
<para>250</para>
<para>121</para>
</entry>
<entry>
<para>half16</para>
<para>none</para>
</entry>
<entry>
<para>#lo(S + A &#8211; P)</para>
<para>none</para>
</entry>
</row>
<row>
<row revisionflag="added">
<entry>
<para>R_PPC64_REL16_HI</para>
<para>R_PPC64_PLTCALL_NOTOC</para>
</entry>
<entry>
<para>251</para>
<para>122</para>
</entry>
<entry>
<para>half16*</para>
<para>none</para>
</entry>
<entry>
<para>#hi(S + A &#8211; P)</para>
<para>none</para>
</entry>
</row>
<row>
<row revisionflag="added">
<entry>
<para>R_PPC64_REL16_HA</para>
<para>R_PPC64_PLT16_LO_NOTOC</para>
</entry>
<entry>
<para>252</para>
<para>123</para>
</entry>
<entry>
<para>half16</para>
</entry>
<entry>
<para>#lo(L &#8211; .TOC.)</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_PLT16_HI_NOTOC</para>
</entry>
<entry>
<para>124</para>
</entry>
<entry>
<para>half16*</para>
</entry>
<entry>
<para>#ha(S + A &#8211; P)</para>
<para>#hi(L &#8211; .TOC.)</para>
</entry>
</row>
<row>
<row revisionflag="added">
<entry>
<para>R_PPC64_GNU_VTINHERIT</para>
<para>R_PPC64_PLT16_HA_NOTOC</para>
</entry>
<entry>
<para>253</para>
<para>125</para>
</entry>
<entry>
<para> </para>
<para>half16*</para>
</entry>
<entry>
<para> </para>
<para>#ha(L &#8211; .TOC.)</para>
</entry>
</row>
<row>
<row revisionflag="added">
<entry>
<para>R_PPC64_GNU_VTENTRY</para>
<para>R_PPC64_PLT16_LO_DS_NOTOC</para>
</entry>
<entry>
<para>254</para>
<para>126</para>
</entry>
<entry>
<para> </para>
<para>half16ds</para>
</entry>
<entry>
<para> </para>
<para>#lo(L &#8211; .TOC.) &gt;&gt; 2</para>
</entry>
</row>
<row revisionflag="added">
@ -4737,55 +4763,55 @@ my_func:
<para>R_PPC64_PCREL34</para>
</entry>
<entry>
<para>256</para>
<para>127</para>
</entry>
<entry>
<para>prefix34*</para>
</entry>
<entry>
<para>@pcrel</para>
<para>S + A &#8211; P</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_PCREL34_DS</para>
<para>R_PPC64_PCREL32</para>
</entry>
<entry>
<para>257</para>
<para>128</para>
</entry>
<entry>
<para>prefix34ds*</para>
<para>prefix32*</para>
</entry>
<entry>
<para>@pcrel >> 2</para>
<para>(S + A &#8211; P) >> 2</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_PCREL34_DQ</para>
<para>R_PPC64_PCREL31</para>
</entry>
<entry>
<para>258</para>
<para>129</para>
</entry>
<entry>
<para>prefix34dq*</para>
<para>prefix31*</para>
</entry>
<entry>
<para>@pcrel >> 3</para>
<para>(S + A &#8211; P) >> 3</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_PCREL28_DQ</para>
<para>R_PPC64_PCREL25</para>
</entry>
<entry>
<para>259</para>
<para>130</para>
</entry>
<entry>
<para>prefix28dq*</para>
<para>prefix25*</para>
</entry>
<entry>
<para>@pcrel >> 3</para>
<para>(S + A &#8211; P) >> 3</para>
</entry>
</row>
<row revisionflag="added">
@ -4793,55 +4819,55 @@ my_func:
<para>R_PPC64_GOT_PCREL34</para>
</entry>
<entry>
<para>260</para>
<para>131</para>
</entry>
<entry>
<para>prefix34*</para>
</entry>
<entry>
<para>@got@pcrel</para>
<para>G &#8211; P</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_GOT_PCREL34_DS</para>
<para>R_PPC64_GOT_PCREL32</para>
</entry>
<entry>
<para>261</para>
<para>132</para>
</entry>
<entry>
<para>prefix34ds*</para>
<para>prefix32*</para>
</entry>
<entry>
<para>@got@pcrel >> 2</para>
<para>(G &#8211; P) >> 2</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_GOT_PCREL34_DQ</para>
<para>R_PPC64_GOT_PCREL31</para>
</entry>
<entry>
<para>262</para>
<para>133</para>
</entry>
<entry>
<para>prefix34dq*</para>
<para>prefix31*</para>
</entry>
<entry>
<para>@got@pcrel >> 3</para>
<para>(G &#8211; P) >> 3</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_GOT_PCREL28_DQ</para>
<para>R_PPC64_GOT_PCREL25</para>
</entry>
<entry>
<para>263</para>
<para>134</para>
</entry>
<entry>
<para>prefix28dq*</para>
<para>prefix25*</para>
</entry>
<entry>
<para>@got@pcrel >> 3</para>
<para>(G &#8211; P) >> 3</para>
</entry>
</row>
<row revisionflag="added">
@ -4849,7 +4875,218 @@ my_func:
<para>R_PPC64_PCREL_OPT</para>
</entry>
<entry>
<para>264</para>
<para>135</para>
</entry>
<entry>
<para>none</para>
</entry>
<entry>
<para>none</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_PLT_PCREL34</para>
</entry>
<entry>
<para>136</para>
</entry>
<entry>
<para>prefix34*</para>
</entry>
<entry>
<para>S + A &#8211; P</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_PLT_PCREL32</para>
</entry>
<entry>
<para>137</para>
</entry>
<entry>
<para>prefix32*</para>
</entry>
<entry>
<para>(S + A &#8211; P) &gt;&gt; 2</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_PLT_PCREL31</para>
</entry>
<entry>
<para>138</para>
</entry>
<entry>
<para>prefix31*</para>
</entry>
<entry>
<para>(S + A &#8211; P) &gt;&gt; 3</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_PLT_PCREL25</para>
</entry>
<entry>
<para>139</para>
</entry>
<entry>
<para>prefix25*</para>
</entry>
<entry>
<para>(S + A &#8211; P) &gt;&gt; 3</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_PLT_PCREL34_NOTOC</para>
</entry>
<entry>
<para>140</para>
</entry>
<entry>
<para>prefix34*</para>
</entry>
<entry>
<para>S + A &#8211; P</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_PLT_PCREL32_NOTOC</para>
</entry>
<entry>
<para>141</para>
</entry>
<entry>
<para>prefix32*</para>
</entry>
<entry>
<para>(S + A &#8211; P) &gt;&gt; 2</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_PLT_PCREL31_NOTOC</para>
</entry>
<entry>
<para>142</para>
</entry>
<entry>
<para>prefix31*</para>
</entry>
<entry>
<para>(S + A &#8211; P) &gt;&gt; 3</para>
</entry>
</row>
<row revisionflag="added">
<entry>
<para>R_PPC64_PLT_PCREL25_NOTOC</para>
</entry>
<entry>
<para>143</para>
</entry>
<entry>
<para>prefix25*</para>
</entry>
<entry>
<para>(S + A &#8211; P) &gt;&gt; 3</para>
</entry>
</row>
<row>
<entry>
<para>R_PPC64_IRELATIVE</para>
</entry>
<entry>
<para>248</para>
</entry>
<entry>
<para>doubleword64</para>
</entry>
<entry>
<para>See
<xref linkend="dbdoclet.50655241_90220" />.</para>
</entry>
</row>
<row>
<entry>
<para>R_PPC64_REL16</para>
</entry>
<entry>
<para>249</para>
</entry>
<entry>
<para>half16*</para>
</entry>
<entry>
<para>S + A &#8211; P</para>
</entry>
</row>
<row>
<entry>
<para>R_PPC64_REL16_LO</para>
</entry>
<entry>
<para>250</para>
</entry>
<entry>
<para>half16</para>
</entry>
<entry>
<para>#lo(S + A &#8211; P)</para>
</entry>
</row>
<row>
<entry>
<para>R_PPC64_REL16_HI</para>
</entry>
<entry>
<para>251</para>
</entry>
<entry>
<para>half16*</para>
</entry>
<entry>
<para>#hi(S + A &#8211; P)</para>
</entry>
</row>
<row>
<entry>
<para>R_PPC64_REL16_HA</para>
</entry>
<entry>
<para>252</para>
</entry>
<entry>
<para>half16*</para>
</entry>
<entry>
<para>#ha(S + A &#8211; P)</para>
</entry>
</row>
<row>
<entry>
<para>R_PPC64_GNU_VTINHERIT</para>
</entry>
<entry>
<para>253</para>
</entry>
<entry>
<para> </para>
</entry>
<entry>
<para> </para>
</entry>
</row>
<row>
<entry>
<para>R_PPC64_GNU_VTENTRY</para>
</entry>
<entry>
<para>254</para>
</entry>
<entry>
<para> </para>
@ -4961,6 +5198,25 @@ my_func:
associated with a global entry point. See
<xref linkend="dbdoclet.50655241_95185" /> for discussion of its
use.</para>
<para revisionflag="added">R_PPC64_PLTSEQ, R_PPC64_PLTCALL</para>
<para revisionflag="added">
These relocations mark the instruction as being part of an inline
PLT call sequence in a function where r2 is a valid TOC pointer.
R_PPC64_PLTCALL is used to mark the call instruction, while
R_PPC64_PLTSEQ is used on other instructions in the sequence that
don't have PLT relocations. All instructions in a given sequence
shall have relocations with the same symbol and addend. Note that
R_PPC64_PLTCALL also implicitly marks the nop or TOC-restoring
instruction immediately following the call instruction.
</para>
<para revisionflag="added">R_PPC64_PLTSEQ_NOTOC,
R_PPC64_PLTCALL_NOTOC</para>
<para revisionflag="added">
These relocations are like the corresponding R_PPC64_PLTSEQ and
R_PPC64_PLTCALL relocations, but are used in functions where r2 is
not a valid TOC pointer. All instructions in the sequence shall use
_NOTOC variant relocations.
</para>
<para revisionflag="added">R_PPC64_PCREL_OPT</para>
<para revisionflag="added">
This relocation type requests that the annotated
@ -5023,7 +5279,7 @@ addi 2,2,.TOC.-func@l</programlisting>
<programlisting>.quad func@localentry</programlisting>
</section>
</section>
<section>
<section xml:id="dbdoclet.50655241_LinkerOpts">
<title>Assembler- and Linker-Mediated Executable Optimization</title>
<para>To optimize object code, the assembler and linker may rewrite object
code to implement the function call and return conventions and access to

Write Preview
Loading…
Cancel
Save