#
331722 |
|
29-Mar-2018 |
eadler |
Revert r330897:
This was intended to be a non-functional change. It wasn't. The commit message was thus wrong. In addition it broke arm, and merged crypto related code.
Revert with prejudice.
This revert skips files touched in r316370 since that commit was since MFCed. This revert also skips files that require $FreeBSD$ property changes.
Thank you to those who helped me get out of this mess including but not limited to gonzo, kevans, rgrimes.
Requested by: gjb (re)
|
#
300701 |
|
25-May-2016 |
ian |
Disable alignment faults on armv6, adjust various alignment-related macros to match the new state of affairs. The hardware we support has always been able to do unaligned accesses, we've just never enabled it until now.
This brings FreeBSD into line with all the other major OSes, and should help with the growing volume of 3rd-party software that assumes unaligned access will just work on armv6 and armv7.
|
#
300375 |
|
21-May-2016 |
ian |
Adjust _ALIGNBYTES to the proper value for arm and armv6 arches. Modern compilers can emit arm instructions that require 8-byte alignment. The alignment-sensitive instructions were added in armv5, which has to be supported by our combined v4/v5 kernels, so the value is set uncoditionally for all arm architecture versions.
Also adjust the comment to explain in more detail why the macros have the form and values they do.
Per advice from bde@, maintain the unsignedness of the value of _ALIGNBYTES (but do so using his second choice of allowing sizeof() to supply the unsignedness, rather than just hardcoding '8U', which in my mind would require an even more verbose comment to explain why it's right). Also explain in the comment that the resulting type of _ALIGN() is equivelent to uinptr_t on arm (32-bit unsigned int), but it's purposely spelled as "unsigned" to avoid problems with including other header files. Even including machine/_types.h to allow use of __uintptr_t causes compilation failures because of this header being included (indirectly) in asm code.
The discussion that led to this change (albeit at a glacial pace) is at https://lists.freebsd.org/pipermail/svn-src-head/2014-November/064593.html
|