[lld] [lld][AArch64][ELF][PAC] Support AUTH relocations and AUTH ELF marking (PR #72714)

Peter Smith via llvm-commits llvm-commits at lists.llvm.org
Mon Mar 18 12:01:20 PDT 2024


smithp35 wrote:

> > Do we really need to support .note.AARCH64-PAUTH-ABI-tag `NT_ARM_TYPE_PAUTH_ABI_TAG`?
> 
> @MaskRay The spec has it defined, and I suppose there is a reason for this. We do not control the input object files we get, and a we might have to process ones with .note.AARCH64-PAUTH-ABI-tag - someone can possibly generate such files since its explicitly allowed by the spec. If we do not process this section properly, we'll just silently concatenate corresponding input sections and emit this in the output - this is definitely not what we want. As for me, support is not that complicated and does not add too much complexity to lld - so, is there a strong reason not to have it? We benefit a lot from supporting the spec fully w/o any gaps and pay for this with a bit of extra code.
> 
> P.S. I'm going to push a couple of small changes to this PR and leave comments regarding the latest feedback before re-requesting the review.

I can give some background on the specification. 

At the time the specification was first written (probably 2020) GNU properties were unpopular in Arm for relocatable objects after experiences with BTI. I used a PT_NOTE as a first pass to avoid GNU properties. In the intervening years Arm's thinking of ELF marking has coalesced towards GNU properties in ELF Executables/Shared-libraries (ELF loaders already have to deal with BTI) and Build Attributes for relocatable objects.

I think the only value in the alternative PT_NOTE is if there are legacy objects/executables that can't be recompiled using it. To the best of my knowledge I'm not aware of any of these as this is the only serious implementation of the ELF spec. All other implementations that I know of have been incomplete prototypes.

I would be very happy to take out the PT_NOTE from the specification if no-one is using it.



https://github.com/llvm/llvm-project/pull/72714


More information about the llvm-commits mailing list