================ @@ -827,6 +827,54 @@ DEFINE_LIBUNWIND_FUNCTION(__unw_getcontext) ret #endif +// +// extern "C" bool __libunwind_Registers_arm64_za_disable() +// +// On return: +// success (true/false) is returned in x0 +// + .p2align 2 +DEFINE_LIBUNWIND_FUNCTION(__libunwind_Registers_arm64_za_disable) + // If TPIDR2_EL0 is null, the subroutine just disables ZA. ---------------- MacDue wrote:
> I believe the two have different purposes, where `bti` protects the entry > point into the function and `pac` authenticates the return address. I was referring to `pacibsp` acting as an implicit `bti` see: https://developer.arm.com/documentation/ddi0602/2025-09/Base-Instructions/PACIB--PACIB1716--PACIBSP--PACIBZ--PACIZB--Pointer-Authentication-Code-for-instruction-address--using-key-B- However, I've also just noticed: ``` #define DEFINE_LIBUNWIND_FUNCTION(name) \ .globl SYMBOL_NAME(name) SEPARATOR \ HIDDEN_SYMBOL(SYMBOL_NAME(name)) SEPARATOR \ SYMBOL_IS_FUNC(SYMBOL_NAME(name)) SEPARATOR \ PPC64_OPD1 \ SYMBOL_NAME(name): \ PPC64_OPD2 \ AARCH64_BTI #endif ``` So the `DEFINE_LIBUNWIND_FUNCTION` will also add a `bti`. --- > The function preserves more registers than the normal calling convention. If > lazy-binding is enabled then the resolver function that finds the address, > updates the GOT and calls this function should also preserve the same > registers as the function that is being called. Otherwise, the first call to > this function does not preserve the same registers. I've added `.variant_pcs` for completeness, though I don't believe lazy binding will be used here (I think this is a local symbol statically linked into libunwind). https://github.com/llvm/llvm-project/pull/165451 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
