[PATCH v7 7/9] ARM: add vdso user-space code

[luto@amacapital.net (Andy Lutomirski)]

On 06/28/2014 03:03 AM, Russell King - ARM Linux wrote:
> On Sat, Jun 28, 2014 at 10:53:14AM +0100, Russell King - ARM Linux wrote:
>> On Sun, Jun 22, 2014 at 10:11:56PM -0500, Nathan Lynch wrote:
>>> Place vdso-related user-space code in arch/arm/kernel/vdso/.
>>>
>>> It is almost completely written in C with some assembly helpers to
>>> load the data page address, sample the counter, and fall back to
>>> system calls when necessary.
>>>
>>> If CONFIG_ARM_ARCH_TIMER is not enabled, the vdso cannot service
>>> high-resolution clocks and falls back to syscalls.  Low-resolution
>>> clocks e.g. CLOCK_REALTIME_COARSE can be serviced regardless.
>>>
>>> Of particular note is that a post-processing step ("vdsomunge") is
>>> necessary to produce a shared object which is architecturally allowed
>>> to be used by both soft- and hard-float EABI programs.
>>>
>>> The 2012 edition of the ARM ABI defines Tag_ABI_VFP_args = 3 "Code is
>>> compatible with both the base and VFP variants; the user did not
>>> permit non-variadic functions to pass FP parameters/results."
>>> Unfortunately current toolchains do not support this tag, which is
>>> ideally what we would use.
>>>
>>> The best available option is to ensure that both EF_ARM_ABI_FLOAT_SOFT
>>> and EF_ARM_ABI_FLOAT_HARD are unset in the ELF header's e_flags,
>>> indicating that the shared object is "old" and should be accepted for
>>> backward compatibility's sake.  While binutils < 2.24 appear to
>>> produce a vdso.so with both flags clear, 2.24 always sets
>>> EF_ARM_ABI_FLOAT_SOFT, with no way to inhibit this behavior.  So we
>>> have to fix things up with a custom post-processing step.
>>>
>>> In fact, the VDSO code in glibc does much less validation (including
>>> checking these flags) than the code for handling conventional
>>> file-backed shared libraries, so this is a bit moot unless glibc's
>>> VDSO code becomes more strict.
>>>
>>> Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
>>> ---
>>>   arch/arm/kernel/asm-offsets.c        |   5 +
>>>   arch/arm/kernel/vdso/.gitignore      |   1 +
>>>   arch/arm/kernel/vdso/Makefile        |  59 +++++++
>>>   arch/arm/kernel/vdso/checkundef.sh   |   9 +
>>>   arch/arm/kernel/vdso/datapage.S      |  15 ++
>>>   arch/arm/kernel/vdso/vdso.S          |  35 ++++
>>>   arch/arm/kernel/vdso/vdso.lds.S      |  88 ++++++++++
>>>   arch/arm/kernel/vdso/vdsomunge.c     | 193 +++++++++++++++++++++
>>>   arch/arm/kernel/vdso/vgettimeofday.c | 320 +++++++++++++++++++++++++++++++++++
>>>   9 files changed, 725 insertions(+)
>>>   create mode 100644 arch/arm/kernel/vdso/.gitignore
>>>   create mode 100644 arch/arm/kernel/vdso/Makefile
>>>   create mode 100755 arch/arm/kernel/vdso/checkundef.sh
>>>   create mode 100644 arch/arm/kernel/vdso/datapage.S
>>>   create mode 100644 arch/arm/kernel/vdso/vdso.S
>>>   create mode 100644 arch/arm/kernel/vdso/vdso.lds.S
>>>   create mode 100644 arch/arm/kernel/vdso/vdsomunge.c
>>>   create mode 100644 arch/arm/kernel/vdso/vgettimeofday.c
>>
>> One change I would like to see (to stop the directory tree getting soo
>> deep) is to move this to arch/arm/vdso - just like x86 is arch/x86/vdso.
>> Was there a pressing reason to have it in arch/arm/kernel ?
>
> It also looks like there's something missing for vdso_install to work.
> arch/x86 has this:
>
> PHONY += vdso_install
> vdso_install:
>          $(Q)$(MAKE) $(build)=arch/x86/vdso $@
>
> but doesn't list it in the arch help.  I'm sure we can do better on ARM. :)

In 3.16-rc3 this is rather improved, albeit still undocumented.  It's 
probably worth matching x86's behavior for gdb's benefit.

--Andy