This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [AArch64 ELF ABI] Vector calls and lazy binding on AArch64
- From: Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: nd <nd at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>, Binutils <binutils at sourceware dot org>, GCC Development <gcc at gcc dot gnu dot org>, "gnu-gabi at sourceware dot org" <gnu-gabi at sourceware dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Tejas Belagod <Tejas dot Belagod at arm dot com>, Richard Sandiford <Richard dot Sandiford at arm dot com>, Steve Ellcey <sellcey at marvell dot com>, Richard Henderson <richard dot henderson at linaro dot org>
- Date: Wed, 22 May 2019 15:23:44 +0000
- Subject: Re: [AArch64 ELF ABI] Vector calls and lazy binding on AArch64
- References: <7be6eecc-9e36-c782-1c87-e608bb1b5678@arm.com> <87y32y34wi.fsf@oldenburg2.str.redhat.com>
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.