On Fri, 17 Oct 2014, Andrew Deason wrote: > On Fri, 17 Oct 2014 14:07:31 -0700 > Micheal Waltz <mwa...@qualcomm.com> wrote: > > > Reading the ARM docs it appears we should use the > > aarch64-arm-none-eabi target, as using the armv8a-arm-none-eabi target > > is the 32-bit state of armv8 [3]. I also am assuming we would want to > > not disable fpu registers in order to avoid performance hits. > > That's common in kernel code, I thought; maintaining fpu state is added > overhead and it's not commonly used. Unless the crypto stuff has some
Some registers are shared between the FPU and sse and/or mmx instructions on some x86 systems, IIRC, so kernels wishing to use those instructions must save/restore the FPU context around such uses. > special handling to allow it to be used for performance reasons. > > > Unfortuantely I'm not sure where I can disable the use of the > > -mgeneral-regs-only flag, as I don't see it in the Makefile or > > configure as an option. > > You're compiling for the kernel, so it's likely coming from Linux; when > building a kernel module, the Linux build system tells us what compiler > flags to use (a lot of them, anyway). There might be a way to disable it > from there if you look around, or maybe we just shouldn't be using a > floating-point type (note that we're not actually using the data, from a > brief glance). We shouldn't really be using a floating-point type in the kernel, but that's part of the RAND_add() API that hcrypto uses, and we don't apply local patches to the bits in src/external, so we're stuck with fun things like '#define double int64_t' in src/crypto/hcrypto/kernel/config.h. crypto-rand.c, compiled into libafsrfc3961, has a call to RAND_add, but it is not compiled in the kernel build, so the above #define should give a self-consistent KBI for our kernel non-use, and the difference from the userspace ABI should not cause problems. That doesn't make it any more pretty, of course... -Ben _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
