This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Aarch64: Add simd exp/expf functions
On 23/05/2019 12:08, Florian Weimer wrote:
> * Szabolcs Nagy:
>
>> however not following the new ELF abi in libmvec.so itself should
>> be fine: the new ELF symbol marking is needed in the module that
>> has R_*_JUMP_SLOT relocations for vector symbols, i.e. on the
>> caller side. testing libmvec in glibc still works by luck since
>> lazy binding does not clobber problematic fp regs, and there are
>> no ifunc resolvers for vector math functions that use fp regs
>> either (the test binaries won't be abi conform though because
>> of the missing symbol marking).
>
> But the dynamic section of libmvec won't have the ABI-mandated markup,
> right?
yes (st_other marking will be missing from the dynamic symbol table)
> Based on the draft, I assume that it's sufficient if the markup
> is present on either side to trigger the special processing.
markup on either side (definition or reference) triggers adding
the markup to a shared lib or executable at link time.
markup must be present on the caller side (reference) to trigger
special processing at runtime.
the VABI requires markup on *both* sides (i.e. in all conforming
binaries the vector function symbol references will be marked)
> It's
> unclear if it's the compiler's job to set the flag for the libmvec
> routines, or if it can rely on the link editor divining it (from the
> DSO, which it needs anyway for the symbol version) and trigger the
> required processing for the symbols concerned.
both:
the reference should be marked by the compiler(+assembler) according
to VABI rules.
if any reference or definition is marked in linker inputs then on
the output the symbol should be marked according to ELF ABI rules.
in practice the case where the definition is marked but the ref
is unmarked should not happen if everything conforms to the VABI.
(future pcs extension using the same marking may behave differently).
so unmarked libmvec.so would work in practice but not abi conform,
i don't immediately see a huge problem with non-abi conform libmvec
(other than it's ugly and may confuse tools that try to rely on the
marking for some reason), but i think it's also possible to add a
tiny elf processing tool to glibc that adds the marking manually to
the dynamic symbol table if the linker does not know how to do it.