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: Florian Weimer <fweimer at redhat dot com>
- To: Szabolcs Nagy <Szabolcs dot Nagy at arm 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\@sourceware.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 17:34:21 +0200
- 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> <0167c338-09b6-288f-6314-ccc470894ac3@arm.com>
* 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