Thread (76 messages) 76 messages, 8 authors, 2014-07-22
STALE4451d

Revision v7 of 16 in this series.

Revisions (16)
  1. v7 [diff vs current]
  2. v7 [diff vs current]
  3. v7 [diff vs current]
  4. v7 current
  5. v7 [diff vs current]
  6. v7 [diff vs current]
  7. v7 [diff vs current]
  8. v7 [diff vs current]
  9. v7 [diff vs current]
  10. v7 [diff vs current]
  11. v7 [diff vs current]
  12. v7 [diff vs current]
  13. v7 [diff vs current]
  14. v7 [diff vs current]
  15. v7 [diff vs current]
  16. v8 [diff vs current]

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

From: Nathan Lynch <hidden>
Date: 2014-06-28 15:19:53

On 06/28/2014 04:53 AM, Russell King - ARM Linux wrote:
On Sun, Jun 22, 2014 at 10:11:56PM -0500, Nathan Lynch wrote:
quoted
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 <redacted>
---
 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 ?
No pressing reason.  I think I was just following the example of non-x86
architectures.  I can move it to arch/arm/vdso.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help