From 67e985a5243bfcd0a3666a7e129d2edc7a0b995f Mon Sep 17 00:00:00 2001 From: Bill Schmidt Date: Thu, 4 Jun 2020 11:09:12 -0500 Subject: [PATCH] More cleanups following discussions with Alan Signed-off-by: Bill Schmidt --- specification/ch_2.xml | 30 +++++++++++------------ specification/ch_3.xml | 54 ++++++++++++++++++++++-------------------- 2 files changed, 43 insertions(+), 41 deletions(-) diff --git a/specification/ch_2.xml b/specification/ch_2.xml index 42cc986..bf21515 100644 --- a/specification/ch_2.xml +++ b/specification/ch_2.xml @@ -4080,21 +4080,21 @@ xml:id="dbdoclet.50655240_pgfId-1156194"> all be on 4-byte (integer) boundaries. -
- Code Alignment - - Functions must be aligned on at least a 4-byte boundary. - - - If a function contains any prefixed (8-byte) instructions, - functions should preferably be aligned on at least a 64-byte - boundary. In ISA 3.1, executing a prefixed instruction that - crosses a 64-byte boundary will cause a SIGILL that must be - handled by the kernel. Compilers and assemblers can avoid - this if functions are aligned on a 64-byte boundary. - -
+ +
+ Code Alignment + + Functions must be aligned on at least a 4-byte boundary. + + + If a function contains any prefixed (8-byte) instructions, + functions should preferably be aligned on at least a 64-byte + boundary. In ISA 3.1, executing a prefixed instruction that + crosses a 64-byte boundary will cause a SIGILL that must be + handled by the kernel. Compilers and assemblers can avoid + this if functions are aligned on a 64-byte boundary. +
diff --git a/specification/ch_3.xml b/specification/ch_3.xml index 40588bb..1852399 100644 --- a/specification/ch_3.xml +++ b/specification/ch_3.xml @@ -2449,7 +2449,7 @@ my_func: Represents the address in - the .TOC. at which the address of + the TOC at which the address of the relocation entry’s symbol plus addend resides during execution. This @@ -4949,7 +4949,7 @@ my_func: - R_PPC64_GOT_TLSGD34 + R_PPC64_GOT_TLSGD_PCREL34 148 @@ -4963,7 +4963,7 @@ my_func: - R_PPC64_GOT_TLSLD34 + R_PPC64_GOT_TLSLD_PCREL34 149 @@ -4977,7 +4977,7 @@ my_func: - R_PPC64_GOT_TPREL34 + R_PPC64_GOT_TPREL_PCREL34 150 @@ -4991,7 +4991,7 @@ my_func: - R_PPC64_GOT_DTPREL34 + R_PPC64_GOT_DTPREL_PCREL34 151 @@ -5328,7 +5328,7 @@ my_func: r_offset and the instruction at r_offset + r_addend may be optimized by the linker; the compiler must guarantee that register - lifetimes are such that the optimization is safe. In both code + lifetimes are such that the optimization is safe. In code sequences where this relocation is valid, the first instruction also has another relocation at r_offset. The R_PPC64_PCREL_OPT entry occurs immediately after that relocation in @@ -5494,13 +5494,15 @@ lxv vs1, 0(r10) nop However, this optimization is not universally safe, since it - changes the value of r10 following the data reference. The - compiler or programmer must ensure that the value of r10 is not - used between the two instructions nor subsequently used, - and communicate a request for this optimization - by placing an R_PPC64_PCREL_OPT relocation on the first instruction - in the sequence that provides the offset to the second instruction - in the sequence. + changes lifetimes of registers set in both instructions. In + the example, the compiler or programmer must ensure that the + value of r10 set by the first instruction is not used after + that instruction, and that vs1 is not used between the two + instructions. If these conditions are met, the linker is + informed that the optimization is safe by placing an + R_PPC64_PCREL_OPT relocation on the first instruction in the + sequence with the addend of that relocation giving the + offset to the second instruction in the sequence.