On 01/15/19 07:16,
szabol...@arm.com wrote:
> I wonder if a bit of the st_other field in a symbol table entry may
> be reserved for marking the symbol not to be resolved lazily
> (a.k.a bind now).
>
> This would require changing the gABI. The rationale is to solve a
> problem in the generic ABI that may affect multiple targets so the
> solution is consistent.
>
> If that is not possible then i wonder what's the recommended way to
> mark symbols in a psABI.
>
> The problem:
>
> As processor architectures continue to evolve there is a need to
> introduce multiple call abis or call abi extensions (e.g. because of
> a new SIMD instruction set extension). >
> The compiler can generate code appropriately in the caller and callee
> based on the type of the function, however the dynamic linker does
> not know the call abi of a symbol and may clobber registers that it
> shouldn't at the first call during on demand symbol resolution with
> lazy binding. Fixing the dynamic linker to handle all call abis may
> be possible, but can be expensive or introduce backward compatibility
> problems (e.g. increase stack usage breaking existing binaries).
...
> Updating dynamic linker on a system is more difficult in practice
> than updating the compiler or linker so ideally a backward compatible
> solution would not require a dynamic linker change.
I guess I don't see how you make something like this
work without some runtime linker change. I'm also skeptical
that tweaks needed for one platform would always generalize
to another. There's not a lot of room in st_other, and this
sounds pretty platform dependent. I'd need to see a detailed
description of how it would really work before I was convinced
that it was simple and stable (not continually evolving) enough
to really belong in the gABI. I'll be interested to hear what
others think.
One way to add platform specific features like this is to
introduce a new platform specific section type, using the
sh_link field to point at the related symbol table, and
probably with a related platform specific dynamic section
tag that lets the runtime linker find that section. In Solaris,
we have an OS-specific (ELFOSABI_SOLARIS) section named
.SUNW_syminfo that works that way, which might serve as an
example:
https://docs.oracle.com/cd/E37838_01/html/E36783/chapter7-17.html#scrolltoc
The runtime linker finds this section via the DT_SYMINFO element
in the .dynamic section. (Yes, this would better have been named
DT_SUNW_SYMINFO, but it predates the gABI). This section has
one element per symbol, in the same positions as the symbol
table. The runtime linker combines the information from both
sections to form its view of each symbol. .SUNW_syminfo was
originally invented to support direct bindings, but as it has
a flags field with sufficient room for expansion, we've since
given it other uses as well.
Another, simpler, example of a section that parallels a
symbol table is SHT_SUNW_versym (known as SHT_GNU_versym
in the ELFOSABI_GNU world).
If the issue is really about the runtime linker saving
and restoring the right registers across PLTs, without
encountering excess overhead, then I wonder if you can't
solve it in some other manner, outside of ELF? For instance,
sparcv9 PLTS can require saving and restoring the floating
point registers, which has undeniable overhead, but the
hardware sets the FPRS register when floating point is
actually used, and the runtime linker uses that to skip
the floating point registers in code that's not using them.
On the other hand, for X86, we just bite the bullet and save
SIMD related registers that may or may not be in use, rather
than adding complexity.
- Ali