Open smithp35 opened 8 months ago
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.
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.
LLD processing of Build Attributes sections similar to the ARM target.
In lld/ELF/Driver.cpp
, I added mergeRISCVAttributesSections
. For AArch64 we will need something similar.
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.