Re: [PATCH] riscv: Resolve symbols directly for symbols with STO_RISCV_VARIANT_CC.

[Jessica Clarke <jrtc27@jrtc27.com>]

On 2 Dec 2021, at 21:44, Florian Weimer <fweimer@redhat.com> wrote:
> 
> * Jessica Clarke:
> 
>> The intent of the spec is not to make repurposing just ra/sp/gp/tp as
>> anything other than their ABI-defined meanings (per table 1 of riscv-cc
>> and, in the case of the stack pointer, the alignment required by the
>> integer calling convention) legal unless you use STO_RISCV_VARIANT_CC,
>> so the glibc requirement, which is also true of FreeBSD for exactly the
>> same reasons, is intended to be what is specified. Upon re-reading what
>> was written I can see that requirement was lost or forgotten, so I’ll
>> look at tightening it up, probably changing
>> 
>>  Any functions that use additional argument registers ...
>> 
>> to
>> 
>>  Any functions that use registers in a way that is incompatible with
>>  the register convention of the ABI in use ...
>> 
>> I also note we currently only talk about the run-time linker preserving
>> argument registers, and say nothing about preserved registers, nor the
>> return address. I’m not sure quite why we do the former (maybe I’ve
>> just forgotten a past conversation), I feel like that’s implied by lazy
>> binding being an implementation optimisation that must not break the
>> calling convention, but if we want to keep that language then it should
>> probably be changed to:
>> 
>>  Run-time linkers that use lazy binding must only clobber registers
>>  defined as temporary registers for the ABI in use.
>> 
>> Does that all sound sensible, and sufficient, to you?
> 
> One further aspect is that glibc has dynamic linker plugins called
> auditors, and arbitrary code can run *after* a function has returned.
> For that to work, we need save registers used for return values as well.
> (The default dynamic linker trampoline sidesteps this because it makes a
> tail call to the actual implementation, based on what the core symbol
> binding routine in the dynamic linker has returned.)  This is a fairly
> obscure feature, and I don't think anyone has a really good solution for
> their architecture today.  There might also be better alternatives
> (e.g., if you know the signature of the function you are intercepting,
> you don't need a general solution for arbitrary calling conventions
> anymore).
> 
> Do temporary registers overlap with return registers?

The audit support in glibc is a good point, and something that hadn’t
even crossed my mind (though probably should have; I have used it).

Short answer is it’s the like AArch64 (but no IP0/1 and veneer
weirdness equivalents). Long answer is that the register convention
currently defines registers as preserved across calls, not preserved
across calls, and unallocatable (special case for gp and tp, as “don’t
clobber unless you’re the runtime or otherwise really know what you’re
doing”). Those registers not preserved across calls are further
subdivided into argument registers, used for both arguments and return
values, and temporary registers, which have no other defined role in
the calling convention.

Dealing with glibc’s auditing in the implementation-agnostic ABI starts
to become a bit awkward; in particular, interposing on the return
requires clobbering the return address on the call path, which is not a
temporary register, and so would not be legal per my suggested text,
but you don’t want to give free reign for people to clobber it because
clearly that’s totally broken in almost other cases.

Perhaps that’s an argument for dropping the first sentence entirely,
and just having the “Any functions ...” sentence, possibly with a bit
of extra non-normative text if it then looks lacking in rationale. Do
you know if any other psABIs specify the requirements on run-time
linkers like we’re currently trying (and failing) to do?

Jess