[AArch64 ELF ABI] Vector calls and lazy binding on AArch64
Florian Weimer
fweimer@redhat.com
Tue Jan 1 00:00:00 GMT 2019
* Szabolcs Nagy:
> AAELF64: in the Symbol Table section add
>
> st_other Values
> The st_other member of a symbol table entry specifies the symbol's
> visibility in the lowest 2 bits. The top 6 bits are unused in the
> generic ELF ABI [SCO-ELF], and while there are no values reserved for
> processor-specific semantics, many other architectures have used these
> bits.
>
> The defined processor-specific st_other flag values are listed in
> Table 4-5-1.
>
> Table 4-5-1, Processor specific st_other flags
> +------------------------+------+---------------------+
> |Name | Mask | Comment |
> +------------------------+------+---------------------+
> |STO_AARCH64_VARIANT_PCS | 0x80 | The function |
> | | | associated with the |
> | | | symbol may follow a |
> | | | variant procedure |
> | | | call standard with |
> | | | different register |
> | | | usage convention. |
> +------------------------+------+---------------------+
>
> A symbol table entry that is marked with the STO_AARCH64_VARIANT_PCS
> flag set in its st_other field may be associated with a function that
> follows a variant procedure call standard with different register
> usage convention from the one defined in the base procedure call
> standard for the list of argument, caller-saved and callee-saved
> registers [AAPCS64]. The rules in the Call and Jump relocations
> section still apply to such functions, and 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 called subroutine
> must preserve the contents of all registers except IP0, IP1 and the
> condition code flags [AAPCS64].
Can you clarify if there has to be a valid stack at this point which can
be used during the call transfer? What about the stack alignment
requirement?
Thanks,
Florian
More information about the Gnu-gabi
mailing list