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

[Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>]

On 11/06/2019 22:15, Florian Weimer wrote:
> * 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.)

old linker can silently create broken binaries
(with unmarked SVE symbols), but the assembler
would fail when it sees the .variant_pcs directive
(which is emitted by the compiler to mark SVE
functions)

since in binutils the linker and assembler are
in one package, i think it's less likely to get
silent breakage: if you use a new compiler
with old binutils you see an assembler error
immediately.

if your toolchain has its own new assembler but
uses an old linker, then using -z now linking is
a way to avoid breakage (assuming such situation
can be detected, i didnt try any detection in gcc
because of the asm issue).

(i think new dynamic relocation would not fix
the silent breakage with old linker unless new
static relocs are introduced too for relocatable
objects, which means many new relocs, potentially
with non-trivial new asm syntax etc)

> 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.

note: for SVE the breakage is quite obvious: dynamic
linkers save/restore q0-q7 registers which overlap
with z0-z7 SVE argument registers and this zeros
out the top bits before the call is entered (if the
SVE registers >128bit).

> Thanks,
> Florian

thanks for your comments, based on this i will still
go with (1) because in the long term i bet on -z now
linkage to be common/acceptable which makes the
problem go away, and (2) would affect more systems
and i don't immediately have a solution for that.