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

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* 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?

Thanks,
Florian