public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: nd <nd@arm.com>, GNU C Library <libc-alpha@sourceware.org>,
	Binutils	<binutils@sourceware.org>,
	GCC Development <gcc@gcc.gnu.org>,
	"gnu-gabi@sourceware.org" <gnu-gabi@sourceware.org>,
	Ramana Radhakrishnan	<Ramana.Radhakrishnan@arm.com>,
	Richard Earnshaw <Richard.Earnshaw@arm.com>,
	Tejas Belagod <Tejas.Belagod@arm.com>,
	Richard Sandiford	<Richard.Sandiford@arm.com>,
	Steve Ellcey <sellcey@marvell.com>,
	Richard Henderson <richard.henderson@linaro.org>
Subject: Re: [AArch64 ELF ABI] Vector calls and lazy binding on AArch64
Date: Tue, 01 Jan 2019 00:00:00 -0000	[thread overview]
Message-ID: <607f440a-494a-8872-6f37-eb0f5e5cf0ac@arm.com> (raw)
In-Reply-To: <87pnoa33lu.fsf@oldenburg2.str.redhat.com>

On 22/05/2019 16:34, Florian Weimer wrote:
> * 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.

i think that's underspecified in general for normal calls too,
currently the glibc dynamic linker assumes it can use some stack
space and do various async signal safe operations (some of which
may even fail), variant pcs does not change any of this.

it only provides a per symbol escape hatch for functions with a
bit special call convention, and i plan to use the symbol marking
in glibc as 'force bind now for these symbols', because other
behaviour may not be forward compatible if the architecture
changes again (if lazy binding turns out to be very important
for these symbols i'd prefer introducing a second entry point
for them instead of checking the elf flags from the entry asm).

i'll try to post patches implementing this abi soon.

      reply	other threads:[~2019-05-22 15:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-01  0:00 Szabolcs Nagy
2019-01-01  0:00 ` Szabolcs Nagy
2019-01-01  0:00 ` Florian Weimer
2019-01-01  0:00   ` Szabolcs Nagy
2019-01-01  0:00     ` Florian Weimer
2019-01-01  0:00       ` Szabolcs Nagy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=607f440a-494a-8872-6f37-eb0f5e5cf0ac@arm.com \
    --to=szabolcs.nagy@arm.com \
    --cc=Ramana.Radhakrishnan@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=Richard.Sandiford@arm.com \
    --cc=Tejas.Belagod@arm.com \
    --cc=binutils@sourceware.org \
    --cc=fweimer@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gnu-gabi@sourceware.org \
    --cc=libc-alpha@sourceware.org \
    --cc=nd@arm.com \
    --cc=richard.henderson@linaro.org \
    --cc=sellcey@marvell.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).