Граф коммитов

4 Коммитов

Автор SHA1 Сообщение Дата
H. Nikolaus Schaller 38850d786a ARM: 8449/1: fix bug in vdsomunge swab32 macro
Commit 8a603f91cc ("ARM: 8445/1: fix vdsomunge not to depend on
glibc specific byteswap.h") unfortunately introduced a bug created but
not found during discussion and patch simplification.

Reported-by: Efraim Yawitz <efraim.yawitz@gmail.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Fixes: 8a603f91cc ("ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.h")
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-10-29 15:20:15 +00:00
H. Nikolaus Schaller 8a603f91cc ARM: 8445/1: fix vdsomunge not to depend on glibc specific byteswap.h
If the host toolchain is not glibc based then the arm kernel build
fails with

  HOSTCC  arch/arm/vdso/vdsomunge
  arch/arm/vdso/vdsomunge.c:48:22: fatal error: byteswap.h: No such file or directory

Observed: with omap2plus_defconfig and compile on Mac OS X with arm ELF
cross-compiler.

Reason: byteswap.h is a glibc only header.

Solution: replace by private byte-swapping macros (taken from
arch/mips/boot/elf2ecoff.c and kindly improved by Russell King)

Tested to compile on Mac OS X 10.9.5 host.

Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-10-19 17:07:32 +01:00
Szabolcs Nagy 13ee9fdba9 ARM: 8397/1: fix vdsomunge not to depend on glibc specific error.h
If the host toolchain is not glibc based then the arm kernel build
fails with

 arch/arm/vdso/vdsomunge.c:53:19: fatal error: error.h: No such file or directory

error.h is a glibc only header (ie not available in musl, newlib and
bsd libcs).  Changed the error reporting to standard conforming code
to avoid depending on specific C implementations.

Signed-off-by: Szabolcs Nagy <szabolcs.nagy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Fixes: 8512287a81 ("ARM: 8330/1: add VDSO user-space code")
Cc: stable@vger.kernel.org
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-07-03 09:57:21 +01:00
Nathan Lynch 8512287a81 ARM: 8330/1: add VDSO user-space code
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.

The VDSO can service gettimeofday and clock_gettime when
CONFIG_ARM_ARCH_TIMER is enabled and the architected timer is present
(and correctly configured).  It reads the CP15-based virtual counter
to compute high-resolution timestamps.

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>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2015-03-27 22:20:45 +00:00