vdso function descriptors (VDS64_HAS_DESCRIPTORS)?

[Segher Boessenkool]

On Mon, Feb 17, 2020 at 11:08:52AM -0500, Joe Lawrence wrote:
> I was wondering if there was history behind VDS64_HAS_DESCRIPTORS and in
> what cases would one want to turn them on?  (Note, I'm assuming they are
> an implementation of Function Descriptors. [1])

It's from the very first patch implementing VDSOs for powerpc, which
says:

commit 86b67fe764e9e54443226a3a0b298f650588d6c5
Author: Benjamin Herrenschmidt <benh at kernel.crashing.org>
Date:   Fri Mar 4 17:33:32 2005 -0800

    [PATCH] ppc64: Implement a vDSO and use it for signal trampoline

[...]

    Note that
    the symbols exposed by the vDSO aren't "normal" function symbols, apps
    can't be expected to link against them directly, the vDSO's are both seen
    as if they were linked at 0 and the symbols just contain offsets to the
    various functions.  This is done on purpose to avoid a relocation step
    (ppc64 functions normally have descriptors with abs addresses in them).
    When glibc uses those functions, it's expected to use it's own trampolines
    that know how to reach them.

so already then this was unused code, presumably it was just used during
development.

> arch/powerpc/include/asm/vdso.h unsets the macro:
> 
>   /* Define if 64 bits VDSO has procedure descriptors */
>   #undef VDS64_HAS_DESCRIPTORS
> 
> so I don't believe they are ever used by default -- in this case
> V_FUNCTION_BEGIN doesn't add to the .opd section with .name, .TOC base,
> etc.
> 
> Manually setting VDS64_HAS_DESCRIPTORS results in a vdso64.so in which
> binutils tools like readelf properly report functions with symbol type
> FUNC instead of NOTYPE.
> 
> Are there pieces of the build/etc toolchain unprepared for function
> descriptors?  I'm just trying to figure out why the code defaults to
> unsetting them.

Because direct calls are faster than indirect calls?  Ben might have a
fuller explanation, cc:ing him.


Segher