* 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
