AArch64 build attributes specification #230
Conversation
|
I don't think the PDF creation is to do with this pull-request as I didn't add the directory to the generate-pdfs script and the same attribute error happens in other documents. Looks like we may need to upgrade rst2pdf to 0.101 for python 3.12 compatibility. |
smithp35
force-pushed
the
build-attributes
branch
from
986daf3
to
5e6ee79
Compare
| Formal Syntax of aeabi prefixed subsections | ||
| ------------------------------------------- | ||
|
|
||
| <uint8: optional> <uint8: parameter type> |
There was a problem hiding this comment.
The design doc mentions "optimized for size". If we optimize for size, "optional" and "parameter type" can be merged into one byte. In contrast, the current design using two bytes is cleaner. I wonder whether there are additional thoughts into the current choice.
There was a problem hiding this comment.
That is true. In this particular case I'm not expecting too many different subsections, currently we only define one so my instinct is to keep it simple for now.
| *0* the values are ULEB128 encoded. | ||
|
|
||
| *1* the values are NTBS. | ||
|
|
There was a problem hiding this comment.
Looks good. This can be extended in the future if addenda32-style Tag_compatibility is needed.
| The effect of omitting a public tag in file scope is identical to | ||
| including it with a value of 0 or “”, depending on its parameter type. | ||
|
|
||
| Formal Syntax of aeabi prefixed subsections |
| * There is a least a3 such that a1 ≤ a3 and a2 ≤ a3. | ||
| Then a1 + a2 = a3. | ||
|
|
||
| Example: ``Tag_CPU_arch`` from (ADDENDA32_) when a1 = v6KZ, a2 = v6T2, and a3 = v7. |
There was a problem hiding this comment.
I assume that this AArch32-specific example can be replaced when an AArch64 tag with the right semantics arises.
There was a problem hiding this comment.
Yes. I'm somewhat limited with the examples right now.
buildattr64/buildattr64.rst
Outdated
|
|
||
| GNU Program Properties as defined by [LINUX_ABI_] are a similar | ||
| concept to Build Attributes. Program properties are encoded in | ||
| .note.gnu.property sections. A static linker combines the program |
There was a problem hiding this comment.
Should .note.gnu.property be placed in backquotes?
buildattr64/buildattr64.rst
Outdated
|
|
||
| The parameter type is ULEB128. | ||
|
|
||
| The lattice value is custom. Two entities are compabitible if both |
There was a problem hiding this comment.
perhaps semilattice. Since we support just the "join" operation, not "meet".
There was a problem hiding this comment.
Looking it up, it seems like join-semilattice is the formal term. What I'll do for now is explain that it is a join-semilattice but we'll use lattice for brevity.
There was a problem hiding this comment.
I ended up using partial order to remove the use of lattice. While build attributes are modelled on a lattice, the addenda32 only mentions it once.
| An executable or shared library. Also known as loadable-unit in | ||
| this document. | ||
|
|
||
| Loadable-unit |
There was a problem hiding this comment.
The existing docs don't use the term "loadable-unit". "link unit" has been used in several docs. Is there a rationale to introduce this alias?
There was a problem hiding this comment.
In some internal feedback some of my colleagues didn't like link-unit :-) . Loadable unit was felt to be more inituitively understandable than link-unit.
I'm confortable with link-unit, but that's many years of familiarity.
|
|
||
| The major differences between build attributes and GNU properties are: | ||
|
|
||
| - Build attributes are relocatable object only and have an encoding |
There was a problem hiding this comment.
This sentence appears to contradict with "Encoding of meta data in a loadable-unit" in buildattr64.rst. If the recommended practice is for loaders not to inspect the platform-specific build attributes, mention it in buildattr64.rst?
There was a problem hiding this comment.
In buildattr64.rst there is:
Encoding of meta data in a loadable-unit
----------------------------------------
Build attributes are only defined for relocatable objects. The
encoding of metadata in a loadable-unit (executable or shared-library)
is platform specific. For example a platform may choose to use GNU
program properties as defined in (LINUX_ABI_). This document specifies
the meaning of build attributes for relocatable objects only. The
presence of ``.ARM.attributes`` sections in a loadable-unit is
permitted, but the interpretation of the contents of the section is
outside the scope of this document.
I think that is consistent with Build Attributes are relocatable only.
Arm has traditionally taken the approach that the executable and shared-library are mostly "owned" by the platform holder, be that Android or the Linux community and the AArch64 ABI. I've written #229 which is a rationale for using GNU properties in sysvabi64.rst files which we equate to Linux/BSD.
Hope that makes sense. Any suggestions for improvement are welcome though.
| - All candidate libraries with build attributes ≤ selection build | ||
| attributes are compatible. | ||
|
|
||
| - For each compatible candidate library L with best candidate B then |
There was a problem hiding this comment.
I am puzzled by this sentence. Perhaps clarify it?
There was a problem hiding this comment.
OK, I'll try and rewrite it.
| a bit vector and use the binary ``or`` or ``and`` operator to do the | ||
| join. | ||
|
|
||
| Alternative one .aeabi_attributes section |
There was a problem hiding this comment.
Add a colon after "Alternative" to clarify that "alternative one" is not a phrase?
Introduce a new specification document for AArch64 build attributes. The 32-bit ABI makes extensive use of the build attributes defined in addenda32. These attributes defined for relocatable objects are used for a number of purposes including: * Checking ABI compatibility. * Checking required processor feature compatibility. * Automatic static library selection. With AArch64's focus on software platforms, there has not been a strong requirement to introduce extra metadata to denote the requirements and optional processor features used by a relocatable object. Programs are expected to do runtime testing to check if processor features are available. With the advent of security features like PAuthABI, BTI and GCS we need a way to record additional metadata that a static linker can use to set metadata like GNU properties in a loadable-unit (executable or shared-library). A brief summary: * Made a generic "aeabi" prefix for Arm subsections. Including a header that states optionality and encoding. All ULEB or all NTBS. * Describes a single subsection that maps directly to the existing .note.gnu.properties and uses language similar to AAELF64. This includes the existing BTI and PAC properties. * Is accompanied by a design rationale with a suggestion for tool syntax.
Commmit will be squashed prior to commit. - Fixed references to GNU properties which have moved to sysvabi64.rst - Mention in buildattr64.rst that SysVr4 platforms are recommended to use GNU properties in loadable units. - Change lattice to partial order. - Be more consistent with relocatable object file, rather than relocatable file, relocatable object or relocatable object file. - Rewrite example of library selection to be clearer.
smithp35
force-pushed
the
build-attributes
branch
from
5e6ee79
to
7c35e21
Compare
This was unfortunately missed out in the initial commit.
|
Thanks for starting https://discourse.llvm.org/t/rfc-aarch64-build-attributes-for-elf-relocatable-objects/75161 and I came here while reading that post. I have done a lot of object file format/assembler/linker work in llvm-project and I am in favor of AArch64 Build Attributes. I haven't studied much about PAuth, but if loaders don't need to know the relevant build attributes, using build attributes should be good.
In |
buildattr64/README.md
Outdated
|
|
||
| ## About this document | ||
|
|
||
| The [Build Attributes for the Arm 64-bit Architecture](buildattr64.rst) describes the |
There was a problem hiding this comment.
missing words after "the"?
buildattr64/buildattr64.rst
Outdated
| ------------------- | ||
|
|
||
| The tool interface for private subsections is implementation defined. | ||
|
|
There was a problem hiding this comment.
delete trailing blank line
| multiple feature bits with forcing functions. A concrete example is | ||
| ``FEAT_LSE2`` which can only exist if ``FEAT_LSE`` exists. | ||
|
|
||
| - require more then one attribute to describe. For example the |
|
|
||
| - Textual formats are slower to parse and take up more space. | ||
|
|
||
|
|
There was a problem hiding this comment.
delete trailing blank lines?
Make further corrections, these were all non-functional in nature. This commit will be squashed prior to merging.
|
Uploaded new version, thanks for the additional comments. |
Introduce a new specification document for AArch64 build attributes.
The 32-bit ABI makes extensive use of the build attributes defined in addenda32. These attributes defined for relocatable objects are used for a number of purposes including:
Checking ABI compatibility.
Checking required processor feature compatibility.
Automatic static library selection.
With AArch64's focus on software platforms, there has not been a strong requirement to introduce extra metadata to denote the requirements and optional processor features used by a relocatable object. Programs are expected to do runtime testing to check if processor features are available.
With the advent of security features like PAuthABI, BTI and GCS we need a way to record additional metadata that a static linker can use to set metadata like GNU properties in a loadable-unit (executable or shared-library).
A brief summary:
Made a generic "aeabi" prefix for Arm subsections. Including a header that states optionality and encoding. All ULEB or all NTBS.
Describes a single subsection that maps directly to the existing .note.gnu.properties and uses language similar to AAELF64. This includes the existing BTI and PAC properties.
Is accompanied by a design rationale with a suggestion for tool syntax.