Re: [PATCH glibc 2/2] aarch64: handle STO_AARCH64_VARIANT_PCS

[Florian Weimer <fweimer at redhat dot com>]

* Szabolcs Nagy:

> Florian: please explain if you still prefer a new dynamic reloc.
>
> alternatives:
>
> (1) stick to proposed abi text and the posted patches.
>     (check st_other flag and force bind now if necessary)
>
> (2) use a new dynamic relocation type for variant pcs
>     symbols with PLT entries. (and always force that
>     to bind now)
>
> (3) keep the abi text but in static linkers for linux
>     reorder PLTs such that variant pcs PLTs come at the
>     end and associated relocations and GOT entries are
>     moved out of the .rela.plt and .got.plt area.
>     (this is backward compatible with existing libcs)
>
> i have a prototype implementation for (3): it is nasty
> because of ifunc PLT handling (many corner cases) and
> it adds an ABI requirement: PLT relocs outside of the
> DT_JMPREL area must not be lazy resolved. (some tools
> may assume all PLT relocs are in the DT_JMPREL area,
> e.g. objdump will not display @plt labels correctly,
> but i don't think anything would be broken by this)
>
> currently my preference is (1) and i'd like to hear some
> feedback if that is still considered problematic.

If I actually had to support this for end users, I would *strongly*
prefer (2).  But for various reasons, it does not appear to be likely
for the foreseeable future that I will be personally confronted with
fallout from picking (1) over (2), so I really don't care all that much.

I think we (at Red Hat) have sufficient time to backport the loader
changes for either (1) or (2), so that our own downstream users would
never notice the loader issue.  We should put the change on the upstream
stable branches, too, so that distributions which synchronize with those
pick it up, too.  (One caveat: we have very limited backporting
capability for CentOS because there is no EUS for CentOS.)

The link editor changes are more concerning.  I expect us to backport
them because old linkers will silently create broken binaries.  That's
true for all three approaches, I think.  But given the long-standing
recommendation that you should build on the oldest distribution you want
to support, I'm not sure how successful such backporting efforts will be
in preventing broken binaries which only work superficially.  (Again,
CentOS could be a problem here.)

Perhaps we should combine the loader backport of (1) or (2) with an SVE
trampoline that zaps the first vector argument register?  Just to make
the breakage obvious immediately, and not when we change vector register
usage in the dynamic linker five years from now, exposing a substantial
number of binaries as broken.  If that ever happens, we *will* have to
save the entire register file in the trampoline at that point, like we
do now on x86-64.

Thanks,
Florian