From 30df295235a9c4e5604236c3d59ba38c39a227f1 Mon Sep 17 00:00:00 2001 From: Bill Schmidt Date: Tue, 6 Feb 2018 09:51:22 -0600 Subject: [PATCH] Add the errata-1.4 document. Signed-off-by: Bill Schmidt --- errata-1.4/bk_main.xml | 110 +++++++++++++++++++ errata-1.4/ch_errata.xml | 224 +++++++++++++++++++++++++++++++++++++++ errata-1.4/pom.xml | 156 +++++++++++++++++++++++++++ pom.xml | 1 + 4 files changed, 491 insertions(+) create mode 100644 errata-1.4/bk_main.xml create mode 100644 errata-1.4/ch_errata.xml create mode 100644 errata-1.4/pom.xml diff --git a/errata-1.4/bk_main.xml b/errata-1.4/bk_main.xml new file mode 100644 index 0000000..10660d3 --- /dev/null +++ b/errata-1.4/bk_main.xml @@ -0,0 +1,110 @@ + + + + + +]> + + + + OpenPOWER ELFv2 Errata + For ELFv2 ABI Version 1.4 + + + + + System Software Work Group + + syssw-chair@openpowerfoundation.org + + OpenPower Foundation + + + + 2018 + OpenPOWER Foundation + + Revision 1.0 + OpenPOWER + + + + + + + + + + Copyright details are filled in by the template. + + + + + + This document provides errata against version 1.4 of the + OpenPOWER ELF v2 Application Binary Interface Specification. These + errata should be considered part of said specification until such + time as a newer version of the full specification is published. + This document is a Non-standard Track, Work Group Note work + product owned by the System Software Workgroup and handled in compliance + with the requirements outlined in the OpenPOWER Foundation + Work Group (WG) Process document. It was created using the + Document Development Guide version + &template_version;. Comments, questions, etc. can be submitted to the + public mailing list for the parent specification at + syssw-elfv2abi@mailinglist.openpowerfoundation.org. + + + + + + 2018-02-05 + + + + Initial document creation + + + + + + + + + + + + + + + + + + + + + diff --git a/errata-1.4/ch_errata.xml b/errata-1.4/ch_errata.xml new file mode 100644 index 0000000..cf1dfde --- /dev/null +++ b/errata-1.4/ch_errata.xml @@ -0,0 +1,224 @@ + + + +Errata +The following statements in version 1.4 of the 64-Bit ELF V2 ABI +Specification for the Power Architecture are incorrect, and should be +considered corrected as specified. +
+ Section 2.1.2.2, Fundamental Types + + Problem: Paragraph 2 contains a + statement that makes use of undefined behavior according to the C standard. + + +
+ + Regardless of the alignment rules for the allocation of data types, + pointers to both aligned and unaligned data of each data type shall + return the value corresponding to a data type starting at the specified + address when accessed with either the pointer dereference operator * or + the array reference operator [ ]. + +
+ + + Resolution: Paragraph 2 is stricken + from the ABI. + +
+
+ Section 6.1, Vector Data Types + + Problem 1: The following sentence + likewise makes use of undefined behavior according to the C standard. + + +
+ + While the preferred alignment for vector data types is a multiple of 16 + bytes, pointers may point to vector objects at an arbitrary alignment. + +
+ + + As stated in Table 2.12, Vector Types, all vector + types have quadword alignment; there is no "preferred" alignment. + + + Resolution 1: The offending sentence + is stricken from the ABI. + + + Problem 2: This section contains + another sentence and an example that likewise make use of undefined + behavior according to the C standard. The offending sentence reads: + + +
+ + The use of vector built-in functions such as vec_xl and vec_xst is + discouraged except for languages where no dereference operators are + available. + +
+ + + The offending example appears directly afterwards. + + + Resolution 2: The offending sentence + is replaced as follows: + + +
+ + The dereference operator * may not be used to + access data that is not aligned at least to a quadword boundary. + Built-in functions such as vec_xl and vec_xst are provided for + unaligned data access. + +
+ + + The offending example is stricken from the ABI. + +
+
+ Section 6.4, Vector Built-In Functions + + Problem 1: The Note following + Table 6.1 likewise encourages undefined behavior (in this context): + + +
+ + Reminder: The assignment operator = is the preferred way to assign + values from one vector data type to another vector data type in + accordance with the C and C++ programming languages. + +
+ + + Resolution 1: The Note is + stricken from the ABI. + + + Problem 2: The paragraph following + Table 6.2 ends with the following sentence that likewise encourages + undefined behavior: + + +
+ + It is recommended that programmers use the assignment operator = + or the vector vec_xl and vec_xst vector built-in functions to access + unaligned data streams. + +
+ + + Resolution 2: This sentence is + replaced as follows: + + +
+ + It is recommended that programmers use the vec_xl and vec_xst + vector built-in functions to access unaligned data streams. + +
+ + + Problem 3: The first sentence of + the second paragraph following Table 6.2 wrongly identifies vec_xl and + vec_xst as optional built-ins: + + +
+ + The set of extended mnemonics in Table 6.3, "Optional Built-In Memory + Access Functions" [127] may be provided by some compilers and are not + required by the Power SIMD programming interfaces. + +
+ + + The title of Table 6.3 likewise calls these optional. + + + Resolution 3: The title of Table + 6.3 is changed to "VSX Memory Access Built-In Functions", and this + sentence is replaced as follows: + + +
+ + The built-in functions in Table 6.3, "VSX Memory Access Built-In + Functions" [127] provide unaligned access to data in memory that + is to be copied to or from a variable having vector data type. + +
+ + + Problem 4: The second paragraph + following Table 6.2 contains one sentence that likewise encourages + undefined behavior, and another sentence that is simply incorrect: + + +
+ + In particular, the assignment operator = will have the same effect + of copying values between vector data types and provides a preferable + method to assign values while giving the compiler more freedom to + optimize data allocation. The only use for these functions is to + support some coding patterns enabling big-endian vector layout code + sequences in both big-endian and little-endian environments. + +
+ + + The second sentence applies to functions in table 6.4, not 6.3. + + + Resolution 4: The offending + sentences are stricken from the ABI. + +
+
+ + Section 6.4.1, Big-Endian Vector Layout in Little-Endian Environments + + + Problem: Table 6.8, and the + sentence preceding it, wrongly identify the vec_xl and vec_xst + built-in functions as optional. + + +
+ + See Table 6.8, "Optional Built-In Memory Access Functions (BE Layout + in LE Mode)" [129]. + +
+ + + Resolution: Table 6.8 is renamed + "VSX Built-In Memory Access Functions (BE Layout in LE Mode)" and + referenced thus in the preceding sentence. + +
+ diff --git a/errata-1.4/pom.xml b/errata-1.4/pom.xml new file mode 100644 index 0000000..18c87d4 --- /dev/null +++ b/errata-1.4/pom.xml @@ -0,0 +1,156 @@ + + + + + + org.openpowerfoundation.docs + workgroup-pom + 1.0.0-SNAPSHOT + ../pom.xml + + 4.0.0 + + elfv2-1_4-errata + + jar + + OpenPOWER ELFv2 ABI 1.4 Errata + + + + + 0 + + + + + + + + + org.openpowerfoundation.docs + + openpowerdocs-maven-plugin + + + + generate-webhelp + + generate-webhelp + + generate-sources + + + ${comments.enabled} + openpower-template-guide + 1 + UA-17511903-1 + + appendix toc,title + article/appendix nop + article toc,title + book toc,title,figure,table,example,equation + book/appendix nop + book/chapter nop + chapter toc,title + chapter/section nop + section toc + part toc,title + reference toc,title + set toc,title + + + 1 + 3 + 1 + + elfv2-1_4-errata + + elfv2-1_4-errata + + + workgroupNotes + + + + + + workgroupConfidential + + + + + draft + + + + + + + + + true + . + + bk_main.xml + + + + + ${basedir}/../glossary/glossary-terms.xml + 1 + www.openpowerfoundation.org + + + + + diff --git a/pom.xml b/pom.xml index 2c3f051..daf2050 100644 --- a/pom.xml +++ b/pom.xml @@ -18,5 +18,6 @@ specification + errata-1.4