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

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

On 05/06/2019 15:41, Szabolcs Nagy wrote:
> On 04/06/2019 18:17, Szabolcs Nagy wrote:
>> On 04/06/2019 12:39, Szabolcs Nagy wrote:
>>> On 23/05/2019 13:31, Szabolcs Nagy wrote:
>>>> On 23/05/2019 12:35, Florian Weimer wrote:
>>>>>
>>>>> Looking at this, I wonder if it would be more natural to handle this as
>>>>> a new relocation type.  This way, you will get an error from old dynamic
>>>>> linkers.
>>>>
>>>> yes, but that's a more intrusive change.
>>>
>>> to expand a bit: i want old dynamic linkers to
>>> continue to work if they do not use lazy binding.
>>
>> Rich Felker commented that it's possible to force bind now
>> semantics for marked symbols in the static linker.
>> PLT entries may still be needed (e.g. in the main exe for
>> pointer equality), but those can use R_*_GLOB_DAT relocs
>> and appear outside of the normal PLT entries that are
>> associated with R_*_JUMP_SLOT relocs.
>>
>> then no dynamic linker change is needed, but lazy binding
>> (and ld_audit) cannot be supported later for vector calls.
>>
>> no dynamic linker change sounds preferable to me, but
>> i have to think about the details.
> 
> i think this approach (forcing marked symbols to bind now
> without dynamic linker change) might work.

it does not work in general, but it can be made to
work for the existing glibc implementation.

in the main exe a PLT must use a JUMP_SLOT reloc
(other relocs would resolve to the pseudo
definition provided by the PLT itself instead of
the real symbol definition) and a JUMP_SLOT reloc
may be lazy resolved.

in glibc relocs are not lazy resolved if they are
outside of the DT_JMPREL entries, but i don't think
that's a generic ELF guarantee. (glibc handles
JUMP_SLOT relocs outside of DT_JMPREL, that may
not be valid ELF depending on interpretation of
DT_JMPREL.)

the new abi text allows an implementation where
JUMP_SLOT relocs for marked symbols are not in
DT_JMPREL and thus bw compatible with old glibc,
if the abi required a new reloc type then this
would not work.

i'll try to implement the bw compat solution in
binutils that follows the current abi specs.
(then the abi does not guarantee bw compat but
the implementation in practice does)
is that acceptable?

(may be the DT_ tag can be changed to indicate that
JUMP_SLOT relocs are in DT_JMPREL and glibc can
then just reject such binaries as unsupported?)


> 
> it's similar to what i described in
> https://groups.google.com/d/msg/generic-abi/Bfb2CwX-u4M/2qbM5fDbDQAJ
> 
> i dropped that idea because it required two dynamic relocs,
> one of which is unused (and the interaction with local ifuncs
> was a bit messy).
> 
> but the same can be done with one dyn reloc if marked plt
> entries are sorted to the end of the plt section (which
> requires another pass over the symbols in the static linker,
> but i think that's fine).
> 
> what i can do is revert the binutils patch, write a new
> abi draft which uses similar symbol marking, but require
> static linkers not to emit lazy JUMP_SLOT relocs (i.e. in
> DT_JMPREL) for marked symbols.
> 
> then a new binary would work with an old dynamic linker
> (and an old toolchain can build libmvec.so other than the
> symbol markings, but those are not critical for interop).
> 
> if this plan fails i will go back to the previous plan.
>