================
@@ -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.
----------------
sdesmalen-arm wrote:

> IIRC, pacibsp also acts like a bti

I believe the two have different purposes, where `bti` protects the entry point 
into the function and `pac` authenticates the return address.

> I'm not sure what .variant_pcs would mean/do here

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.

https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#st-other-values
> If a subroutine is called via a symbol reference that is marked with 
> STO_AARCH64_VARIANT_PCS, then code that runs between the calling routine and 
> the called subroutine must preserve the contents of all registers except for 
> IP0, IP1, and the condition code flags 
> [[AAPCS64](https://github.com/ARM-software/abi-aa/releases)]. It must also 
> preserve the processor execution mode, such as PSTATE.SM and PSTATE.ZA. It is 
> not possible to provide a definitive list of which state must be preserved, 
> since the intention is to allow it to grow as the architecture evolves.
> 
> In particular, when a call is made via the PLT entry of a symbol marked with 
> STO_AARCH64_VARIANT_PCS, a dynamic linker cannot assume that the call follows 
> the register usage convention of the base procedure call standard.

https://github.com/llvm/llvm-project/pull/165451
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to