[RFC/PATCH] ARM: VDSO support
Joseph Myers
joseph@codesourcery.com
Tue Apr 7 22:22:00 GMT 2015
On Tue, 7 Apr 2015, Nathan Lynch wrote:
> I referred specifically to the recent x86 VDSO work when writing this.
> Although unlike the support which was added for the 32-bit x86 VDSO,
> this code introduces a test and branch into the system call path rather
> than an unconditional dispatch through a function pointer. This seems
> to impose the least overhead. For example on i.MX6 (Cortex-A9), where I
That suggests making that specific point configurable by architectures
(VSYSCALL_TEST_IN_SYSCALL_PATH or similar), with comments on the ARM
definition explaining the reason for the choice there.
> I avoided implementing INLINE_VSYSCALL for ARM partly out of the perhaps
> mistaken belief that it would require assembly (both arm and thumb
> versions of INLINE_VSYSCALL_NCS), and partly in order to avoid using
> preprocessor-pasting which defeats grep (__vdso_##name). But if
> INLINE_VSYSCALL is the preferred method, I can use that; I have an older
> version of the patch which has it.
I don't think you should need assembly; the x86_64 version does a normal
function call. Indeed, maybe something like the x86_64 definition should
go in a new sysdeps/unix/sysv/linux/sysdep.h, with all Linux architectures
being made to use that file (architectures with existing definitions could
still override them if they have good reasons to do so).
In general, the preferred method is to keep architecture-specific code to
a minimum (cf the recent removal of lots of architecture-specific assembly
in NPTL, for example); if something can be done generically, there should
be a good reason (such as your benchmark results showing one approach is
more efficient than another) for adding anything architecture-specific
beyond what's needed to cause the generic code to be used.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list