From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathan_Lynch@mentor.com (Nathan Lynch) Date: Sat, 28 Jun 2014 10:19:53 -0500 Subject: [PATCH v7 7/9] ARM: add vdso user-space code In-Reply-To: <20140628095314.GC32514@n2100.arm.linux.org.uk> References: <1403493118-7597-1-git-send-email-nathan_lynch@mentor.com> <1403493118-7597-8-git-send-email-nathan_lynch@mentor.com> <20140628095314.GC32514@n2100.arm.linux.org.uk> Message-ID: <53AEDD19.80808@mentor.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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: >> 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 >> --- >> 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.