[llvm] [PAC][CodeGen][ELF][AArch64] Support signed GOT (PR #105798)

[Daniil Kovalev via llvm-commits]

kovdan01 wrote:

> > The latest PR update fixes the following issue. With signed ELF GOT enabled, the linker looks at the symbol type to choose between keys IA (for STT_FUNC) and DA (for other types). Symbols for functions not defined in the module have STT_NOTYPE type by default. This makes linker to emit signing schema with DA key (instead of IA) for corresponding R_AARCH64_AUTH_GLOB_DAT dynamic reloc. To avoid that, force all function symbols used in the module to have STT_FUNC type. See https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst#default-signing-schema
> > @MaskRay could you please clarify if this is OK from linker's perspective? Does lld rely on the fact that undefined functions are STT_NOTYPE or is this OK to have them STT_FUNC? I've ran test-suite built with pauth enabled (including signed GOT), and nothing seems to break, but maybe there are some non-obvious issues which might appear under some conditions.
> > Would be glad to see everyone's feedback on this @tmatheson-arm @smithp35
> 
> Closest I can find in terms of use of STT_NOTYPE is this thread in the GABI https://groups.google.com/g/generic-abi/c/_ZPPq_c8FSQ which to my reading suggests that emitting the type on the reference could be a good thing as it would permit static linker's to diagnose mismatches in symbol types such as STT_FUNC and STT_OBJECT. However I think the discussion stopped short of requiring it. It doesn't however forbid it.
> 
> There's a bug report in GCC advocating it, with a patch that doesn't seem to have been applied https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35514.
> 
> From what I can see, it looks like the main advantage and disadvantage of setting the type on the symbol reference is that the static linker has to do some extra work to make sure that a combination of two references to sym one with STT_NOTYPE and one with any other type preserves the type. It also has to decide what to do if there is a mismatch of types on the reference and definition. It could ignore the reference, or could warn.
> 
> The most likely alternative is to provide alternative relocation types for code and non-code references. This is essentially moving the symbol type into the relocation code though.

@smithp35 Thanks for your feedback! Yes, providing alternative relocation types is a viable solution for this. But, as far as I see, the current way it's resolved now (by unconditionally setting `STT_FUNC` type even for undefined functions) is also not prohibited.

@MaskRay Could you please give your feedback on the problem? Would be glad to hear which solution looks better from linker's perspective.

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