[DesignDocuments] Rationale for GNU Properties in sysvabi#229
[DesignDocuments] Rationale for GNU Properties in sysvabi#229smithp35 wants to merge 2 commits intoARM-software:mainfrom
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
elfmarkrationale
branch
from
f17daa3 to
4320473
Compare
| @@ -0,0 +1,496 @@ | |||
| .. | |||
| Copyright (c) 2023, Arm Limited and its affiliates. All rights reserved. | |||
There was a problem hiding this comment.
Nit: update copyright year
| The design goals of an ELF marking scheme are: | ||
|
|
||
| - Utilize existing ELF marking standards where possible. Platforms | ||
| may already have an implementation existing standards that can be |
There was a problem hiding this comment.
Nit: did you mean "implementation of existing..."
|
|
||
| To permit an ELF loader to reason about feature compatibility and take | ||
| extra actions as a result of features some additional metadata must be | ||
| recorded in the ELF file. This document will use the team ELF |
There was a problem hiding this comment.
A typo for "term ELF"
There was a problem hiding this comment.
Now updated to "term ELF"
| ====================== | ||
|
|
||
| GNU program properties are a linux extension defined in | ||
| (``LINUX_ABI_``). They are encoded in ``SHT_NOTE`` sections with a |
There was a problem hiding this comment.
Nit: some references are written with double inverse quotes ` and as a result they are not rendered as links.
There was a problem hiding this comment.
Removed the double inverse quotes from the references.
| platforms running on different hardware. Platform specific software | ||
| can be customized for the hardware that it runs on. | ||
|
|
||
| Only require features that can't be tested at runtime |
There was a problem hiding this comment.
We have properties for PAC, BTI, and GCS all of which can be tested at run time via HWCAP. The next paragraph about hint space features explains this but this paragraph seems to contradict what exists in practice.
The properties for PAC, BTI, and GCS inform the loader that the binary is supposed to work with the respective features if they are present in the system (so it is safe to enable them when the run time check passes).
There was a problem hiding this comment.
I think what I need to do is restrict this paragraph to "use of non-hint space instructions from an architectural extension".
Main thing to get over is that if function multiversioning is used then we don't need to record all the architecture features used in the alternative implementations, just the baseline.
BTI and GCS are (or can be) orthogonal to this. For example BTI only uses hint-space instructions, but requires action from the loader to enable BTI. In this case we record "I am compatible with BTI", and not "I require armv8.5-a for BTI instructions".
I'll have a go at rewriting.
Add a design rationale for use of GNU properties as well as guidelines for how these should be used for properties in the AArch64 processor space. Pull request ARM-software#228 moves the GNU properties and other dynamic section properties specific to SystemV ABI to the SystemV ABI document. Arm has typically left metadata in exectuables and shared-libraries to the platform. Only defining metadata for relocatable objects. With platforms such as Linux the most frequently run software on AArch64, Arm needs to document the metadata that it is using for SystemV platforms. We have chosen to use GNU properties and to document these in the sysvabi64.rst document.
* Fix copyright dates. * Update changelog. * Fix double quotes around links. * Clarify that runtime testing applies to architectural features
smithp35
force-pushed
the
elfmarkrationale
branch
from
4320473 to
42c0723
Compare
3 participants
Add a design rationale for use of GNU properties as well as guidelines for how these should be used for properties in the AArch64 processor space.
Pull request #228 moves the GNU properties and other dynamic section properties specific to SystemV ABI to the SystemV ABI document.
Arm has typically left metadata in exectuables and shared-libraries to the platform. Only defining metadata for relocatable objects. With platforms such as Linux the most frequently run software on AArch64, Arm needs to document the metadata that it is using for SystemV platforms.
We have chosen to use GNU properties and to document these in the sysvabi64.rst document.