[AArch64 ELF ABI] Vector calls and lazy binding on AArch64
Florian Weimer
fweimer@redhat.com
Wed May 22 15:34:00 GMT 2019
* Szabolcs Nagy:
> On 22/05/2019 16:06, Florian Weimer wrote:
>> * 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?
>
> the intention is to only allow 'register usage convention' to be
> relaxed compared to the base PCS (which has rules for stack etc),
> and even the register usage convention has to be compatible with
> the 'Call and Jump relocations section' which essentially says that
> veneers inserted by the linker between calls can clobber IP0, IP1
> and the condition flags.
>
> i.e. a variant pcs function follows the same rules as base pcs, but
> it may use different caller-/callee-saved/argument regiseters.
>
> when SVE pcs is merged into the current AAPCS document, then i hope
> the 'variant pcs' term used here will be properly specified so the
> ELF ABI will just refer back to that.
My concern is that with the current language, it's not clear whether
it's possible to use the stack as a scratch area during the call
transition, or rely on a valid TCB. I think this is rather
underspecified.
Thanks,
Florian
More information about the Gcc
mailing list