[RFC PATCH] powerpc/vdso: Should VDSO64 functions be flagged as functions like VDSO32 ?

[Michael Ellerman]

Christophe Leroy <christophe.leroy at csgroup.eu> writes:
> On powerpc64 as shown below by readelf, vDSO functions symbols have
> type NOTYPE.
>
> $ powerpc64-linux-gnu-readelf -a arch/powerpc/kernel/vdso/vdso64.so.dbg
> ELF Header:
>   Magic:   7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00
>   Class:                             ELF64
>   Data:                              2's complement, big endian
>   Version:                           1 (current)
>   OS/ABI:                            UNIX - System V
>   ABI Version:                       0
>   Type:                              DYN (Shared object file)
>   Machine:                           PowerPC64
>   Version:                           0x1
> ...
>
> Symbol table '.dynsym' contains 12 entries:
>    Num:    Value          Size Type    Bind   Vis      Ndx Name
> ...
>      1: 0000000000000524    84 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
> ...
>      4: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS LINUX_2.6.15
>      5: 00000000000006c0    48 NOTYPE  GLOBAL DEFAULT    8 __[...]@@LINUX_2.6.15
>
> Symbol table '.symtab' contains 56 entries:
>    Num:    Value          Size Type    Bind   Vis      Ndx Name
> ...
>     45: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  ABS LINUX_2.6.15
>     46: 00000000000006c0    48 NOTYPE  GLOBAL DEFAULT    8 __kernel_getcpu
>     47: 0000000000000524    84 NOTYPE  GLOBAL DEFAULT    8 __kernel_clock_getres
>
> To overcome that, commit ba83b3239e65 ("selftests: vDSO: fix vDSO
> symbols lookup for powerpc64") was proposed to make selftests also
> look for NOTYPE symbols, but is it the correct fix ?
>
> VDSO32 functions are flagged as functions, why not VDSO64 functions ?
> Is it because VDSO functions are not traditional C functions using
> the standard API ?

Yes. There's some explanation in the original commit:

    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.