Non-functional changes to content of commits made since last release

These are minor grammatical and style changes to commits since the 2025Q1
release. They should not change the meaning of what is in the documents.

Author: stuij

aadwarf64/aadwarf64.rst

@@ -638,13 +638,14 @@ The ``DW_CFA_AARCH64_negate_ra_state`` instruction toggles between the
 ``DW_AARCH64_RA_NOT_SIGNED`` and ``DW_AARCH64_RA_SIGNED_SP`` return address
 states in RA_SIGN_STATE pseudo-register. It does not take any operands.
 
-The ``DW_CFA_AARCH64_set_ra_state`` instruction takes two operands: an unsigned
-LEB128 value representing a return address state ra_state; and a signed LEB128
-factored offset. The required action is to set the RA_SIGN_STATE pseudo-register
-to the ra_state value and if the ra_state value is ``DW_AARCH64_RA_SIGNED_SP_PC``
-to capture the current code location + (offset * ``code_alignment_factor``)
-as the signing/authenticating PAC instruction, otherwise it is has the value 0.
-The code location information can be used for authenticating the return address.
+The `DW_CFA_AARCH64_set_ra_state` instruction takes two operands. The first is
+an unsigned LEB128 value that specifies the return address state ra_state. The
+second is a signed LEB128 factored offset. The instruction sets the
+`RA_SIGN_STATE` pseudo-register to the ra_state value. If the ra_state value is
+`DW_AARCH64_RA_SIGNED_SP_PC`, it records the current code location + (offset *
+``code_alignment_factor``) as the signing/authenticating PAC instruction,
+otherwise it is 0. The code location information can be used to authenticate the
+return address.
 
 The ``DW_CFA_AARCH64_negate_ra_state_with_pc`` instruction toggles between the
 ``DW_AARCH64_RA_NOT_SIGNED`` and ``DW_AARCH64_RA_SIGNED_SP_PC`` return

aaelf64-morello/aaelf64-morello.rst

@@ -318,7 +318,7 @@ space reserved by [CHERI_ELF_] for processor-specific use:
 .. note::
 
   Mixing any combination of two or more of CHERI_TLS_ABI_TRAD,
-  CHERI_TLS_ABI_MORELLO_MIXED and CHERI_TLS_ABI_MORELLO_TGOT_COMPAT objects is
+  CHERI_TLS_ABI_MORELLO_MIXED, and CHERI_TLS_ABI_MORELLO_TGOT_COMPAT objects is
   permitted, and yields a CHERI_TLS_ABI_MORELLO_MIXED object if merged at
   static link time.
 
@@ -905,7 +905,7 @@ Dynamic Morello relocations
 
   ``R_MORELLO_TLS_TGOT_SLOT`` is similar to ``R_MORELLO_CAPINIT`` but should
   not be applied to the TGOT template itself. Instead, represents
-  initialisation to be performed per TGOT. If ``S`` is the null symbol (ELF
+  initialization to be performed per TGOT. If ``S`` is the null symbol (ELF
   symbol index 0), it contains a fragment in the same format as
   ``R_MORELLO_RELATIVE``.
 
@@ -1030,7 +1030,7 @@ A Morello toolchain can emit segments in accordance to [CHERI_ELF_]. The
 following fields have Morello-specific meanings.
 
 p\_type
-  The below table lists the Morello-specific segment types.
+  The following table lists the Morello-specific segment types.
 
 .. table:: Morello-specific segment types
 
@@ -1283,7 +1283,7 @@ TLS for the pure capability ABI (indirect)
 ------------------------------------------
 
 The design is based on TLSDESC, using a TGOT (as described in [CHERI_ELF_]) for
-indirection to minimise privilege and enable compartmentalisation.
+indirection to minimise privilege and enable compartmentalization.
 
 TLS static block
 ^^^^^^^^^^^^^^^^
@@ -1329,7 +1329,7 @@ Local Exec
 
 The capability to the TLS variable is loaded from ``CTPIDR_EL0``. There are no
 requirements on how this is performed or the registers used, except that the
-sequence doesn't produce a dynamic relocation. A possible instruction sequence
+sequence does not produce a dynamic relocation. A possible instruction sequence
 could be:
 
 .. code-block:: text
@@ -1420,13 +1420,13 @@ The relaxed sequence is:
 TLS for the pure capability ABI (mixed / compat)
 ------------------------------------------------
 
-In order to support transitioning from direct to indirect TLS, both can be used
-at once. In this mixed model, direct TLS is entirely as defined above. However,
-for indirect TLS, a "compat" model is used, where the location of the static
-TGOT within the static TLS block is unspecified. This has the following
-implications:
+To support transitioning from direct to indirect TLS, they can be used
+together. In this mixed model, direct TLS is entirely as defined in the `TLS for
+the pure capability ABI (direct)`_ section. However, for indirect TLS, a
+"compat" model is used, where the location of the static TGOT within the static
+TLS block is unspecified. This has the following implications:
 
-- Local Exec is forbidden (including for relaxation); the most optimised access
+- Local Exec is forbidden (including for relaxation); the most optimized access
   model available is Initial Exec
 
 - ``R_MORELLO_TLS_TGOTREL64`` is never statically resolvable to a constant at

aaelf64/aaelf64.rst

@@ -292,8 +292,8 @@ changes to the content of the document for that release.
   | 2025Q2        | 9\ :sup:`th`       | - In `Call and Jump relocations`_ added |
   |               | April 2025         |   static linker requirements on veneers |
   |               |                    |   when BTI guarded pages are used.      |
-  |               |                    | - Added section for structure protection|
-  |               |                    |   extension relocations.                |
+  |               |                    | - Added section for Structure Protection|
+  |               |                    |   Extension relocations.                |
   |               |                    | - R_AARCH64_GOTPCREL32, clarify addend  |
   +---------------+--------------------+-----------------------------------------+
   | 2026Q1        | 12\ :sup:`th`      | - R_AARCH64_TLS_DTPREL can be used as a |
@@ -1751,10 +1751,14 @@ A data relocation is required to describe the location of a TLS variable in debu
   |            |            | R\_<CLS>\_TLS\_DTPREL       | DTPREL(S+A)                        | See note below                            |
   +------------+------------+-----------------------------+------------------------------------+-------------------------------------------+
 
-``R_<CLS>_TLS_DTPREL`` is both a static and dynamic relocation. When used as a static relocation ``S`` must be fully resolved at static link time to a symbol definition in the same module as the relocation.
-
 It is implementation defined whether ``R_<CLS>_TLS_IMPDEF1`` implements ``R_<CLS>_TLS_DTPREL`` and ``R_<CLS>_TLS_IMPDEF2`` implements ``R_<CLS>_TLS_DTPMOD`` or whether ``R_<CLS>_TLS_IMPDEF1`` implements ``R_<CLS>_TLS_DTPMOD`` and ``R_<CLS>_TLS_IMPDEF2`` implements ``R_<CLS>_TLS_DTPREL``; a platform must document its choice\ [#aaelf64-f1]_.
 
+.. note::
+   ``R_<CLS>_TLS_DTPREL`` is both a static and dynamic relocation. When used as
+   a static relocation ``S`` must be fully resolved at static link time to a
+   symbol definition in the same module as the relocation.
+
+
 Relocations for PAuth ABI Extension
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

atomicsabi64/atomicsabi64.rst

@@ -382,11 +382,12 @@ Suggestions and improvements to this specification may be submitted to the:
 Atomic types
 ============
 
-``_Atomic`` struct types types with size less than 16 bytes must be padded to the nearest power
-of 2.  Their alignment must be the same as their size so that they can be used by atomic instructions.
+``_Atomic`` struct types with size less than 16 bytes must be padded to the
+nearest power of 2.  Their alignment must be the same as their size so that they
+can be used by atomic instructions.
 
-``atomic_is_lock_free`` must return ``true`` for all ``_Atomic`` objects with size less than or equal
-to 16 bytes, and ``false`` otherwise.
+``atomic_is_lock_free`` must return ``true`` for all ``_Atomic`` objects with
+size less than or equal to 16 bytes, and ``false`` otherwise.
 
 
 AArch64 atomic mappings

baabielf64/README.md

@@ -6,7 +6,8 @@
 
 ## About this document
 
-The [AArch64 ELF Conventions for Binary Analysis](baabielf64.rst) specifies code-patterns recognised by Binary Analysis tools.
+The [AArch64 ELF Conventions for Binary Analysis](baabielf64.rst) specifies code
+patterns recognized by Binary Analysis tools.
 
 ## About the license
 

baabielf64/baabielf64.rst

@@ -191,7 +191,7 @@ changes to the content of the document for that release.
   +------------+------------------------------+------------------------------------------------------------------+
   | Issue      | Date                         | Change                                                           |
   +============+==============================+==================================================================+
-  | 0.1        | 10\ :sup:`st` September 2025 | Alpha draft release.                                             |
+  | 0.1        | 10\ :sup:`th` September 2025 | Alpha draft release.                                             |
   +------------+------------------------------+------------------------------------------------------------------+
 
 References
@@ -232,7 +232,7 @@ Other terms may be defined when first used.
 AArch64 Veneer Types Recognized by Binary Analysis Tools
 ========================================================
 
-As described in AAELF64_, section Call and Jump relocations, the linker may insert veneers (also referred to as thunks, stubs or trampolines) to implement call and jump relocations. This section defines the commonly used types and instruction sequences for such veneers on AArch64, enabling better recognition by binary analysis tools.
+As described in AAELF64_, section Call and Jump relocations, the linker may insert veneers (also referred to as thunks, stubs, or trampolines) to implement call and jump relocations. This section defines the commonly used types and instruction sequences for such veneers on AArch64, enabling better recognition by binary analysis tools.
 
 Toolchains are encouraged to follow these patterns to ensure veneers can be reliably recognized during binary analysis. These pattern sets are intended to remain open, and toolchains may introduce new veneer forms.
 
@@ -346,4 +346,4 @@ In cases where the veneer is placed immediately before the target, the B instruc
     BTI C
   <target>:
 
-Recognized by alternative names: ``__<target>_bti_veneer``
+Recognized by alternative names: ``__<target>_bti_veneer``

sysvabi64/sysvabi64.rst

@@ -213,10 +213,10 @@ Change History
  | 2025Q1     | 7\ :sup:`th` April 2025      | - Require hard-float ABI for sysvabi platforms.       |
  |            |                              | - Document requirements for tools wrt BTI.            |
  +------------+------------------------------+-------------------------------------------------------+
- | 2025Q2     | 20\ :sup:`th` June     2024  | Require that ``PT_GNU_PROPERTY`` program header be    |
+ | 2025Q2     | 20\ :sup:`th` June     2024  | Require that ``PT_GNU_PROPERTY`` program header is    |
  |            |                              | present in executables and shared-libraries if a      |
- |            |                              | .note.gnu.property section is present.                |
- |            |                              | - Update distance to GOT for small code-model         |
+ |            |                              | ``.note.gnu.property`` section is present.            |
+ |            |                              | - Update distance to GOT for small code model         |
  +------------+------------------------------+-------------------------------------------------------+
  | 2026Q1     | 12\ :sup:`th` January 2026   | Add assembler conventions for data directive          |
  |            |                              | relocation expressions.                               |
@@ -862,7 +862,7 @@ Sample code sequences for code models
 
 The following section provide some sample code sequences for
 addressing static data. The samples are provided to illustrate the
-effects on code-generation of the code-models.
+effects on code-generation of the code models.
 
 Get the address of a symbol defined in the same ELF file
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -1617,23 +1617,22 @@ IFUNC requirements for dynamic linkers
 To resolve an ``R_AARCH64_IRELATIVE`` relocation the dynamic linker
 performs the calculation described in AAELF64_ Dynamic Relocations.
 
-Function Multi-versioning
+Function Multi-Versioning
 -------------------------
 
-Function Multi-versioning (FMV) is an Arm C Language Extension that
+Function Multi-Versioning (FMV) is an Arm C Language Extension that
 lets the compiler generate multiple function versions and auto-dispatch
 between them. Each of the function versions is specialized for a set
 of architecture extensions. The most suitable version is selected
 at load time. This requires runtime information about the CPU features
 available on the host. FMV is supported on GNU/Linux, Android, and
 many of the BSD operating systems.
 
-On System V platforms Function Multi-versioning is implemented using
-GNU Indirect Functions (IFUNC). The compiler generated IFUNC resolver
-may rely on the presence of a global variable ``__aarch64_cpu_features``
-provided by the runtime library. It contains information about the
-available CPU features. The runtime library must also provide a
-function ``__init_cpu_features_resolver`` that the IFUNC resolver
+On System V platforms FMV is implemented using GNU Indirect Functions
+(IFUNC). The compiler generated IFUNC resolver may rely on the presence of a
+global variable ``__aarch64_cpu_features`` provided by the runtime library. It
+contains information about the available CPU features. The runtime library must
+also provide a function ``__init_cpu_features_resolver`` that the IFUNC resolver
 can call to initialize ``__aarch64_cpu_features``.
 
 .. code-block:: c
@@ -1763,7 +1762,7 @@ prototype:
 
    void __init_cpu_features_resolver (uint64_t, const uint64_t *);
 
-The above interface expects the same parameters as a GNU Indirect
+This interface expects the same parameters as a GNU Indirect
 Function resolver. See `GNU C Library IFUNC interface`_. Other
 platforms may use a different interface with the runtime library.
 However, all implementations must provide a DSO-local definition
@@ -1878,7 +1877,7 @@ include:
   means that RET instructions are only used for function returns, and
   never as an indirect branch.
 
-* Any functions used by the program that manipulate the stack such as
+* Any functions used by the program that manipulate the stack, such as
   ``setjmp`` and ``longjmp``, must be aware of GCS.
 
 Program Properties and program headers