Date: Fri, 27 May 2016 12:51:53 -0600 From: Ian Lepore <ian@freebsd.org> To: Matthias Andree <matthias.andree@gmx.de>, Cedric Blancher <cedric.blancher@gmail.com>, Mark Millard <markmi@dsl-only.net> Cc: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, freebsd-sparc64@freebsd.org Subject: Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses] Message-ID: <1464375113.1204.120.camel@freebsd.org> In-Reply-To: <5747F78A.5020103@gmx.de> References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> <CALXu0Uer=nOKBvd8x%2Bf=7F36603LRpkarAY4QOqau-4n_sLqQw@mail.gmail.com> <F79AE83A-B973-4FA1-BC6C-18FC24F6C41F@dsl-only.net> <CALXu0Uc2Ssqs5OzCpTZs0Mcy4Y0ZQBzKAJPpT1LjnMoD-8updg@mail.gmail.com> <5747F78A.5020103@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2016-05-27 at 09:30 +0200, Matthias Andree wrote: > Am 27.05.2016 um 06:14 schrieb Cedric Blancher: > > [...] > > > 2 - find someone to review the ARM and AARCH related #if preprocessor > stuff in ./include/lzo/lzodefs.h in the port's WRKSRC after > unpacking. > I just had a look. I think the cause of bugzilla 207096 is probably found on line 2544 of lzodefs.h: # elif 1 && defined(__TARGET_ARCH_ARM) && ((__TARGET_ARCH_ARM)+0 >= 7) A similar check on line 2551 assumes armv6-a and -r profiles also support unaligned. Our freebsd clang would normally not define __ARM_FEATURE_UNALIGNED (checked on line 2528 of lzodefs.h) unless someone had specifically added the -munaligned-access option; in the PR we see it specifically has -mno-unaligned-access. But it also has -march=armv7 (our default is v6 due to the rpi and the ongoing stupidity that we pretend v6 and v7 are "the same enough" to not need separate names). So with __ARM_FEATURE_UNALIGNED not defined and arch = armv7, the check on line 2544 makes the assumption (incorrect until a few days ago) that if the arch is v7, we must have support for unaligned access. I think that assumption is right for every major OS, but there could be special embedded environments where it's incorrect. (In fact, a highly specialized embedded system is pretty much the ONLY place you'd expect someone to legitimately disable unaligned accesses, now that freebsd gets it right). I think the right thing to do is: if __ARM_ARCH is defined, that means the current compiler properly supports the ACLE feature symbols[1] and thus only __ARM_FEATURE_UNALIGNED should be consulted. If __ARM_ARCH is not defined, then __ARM_FEATURE_UNALIGNED can't be used, and a fallback to guessing based on arch might be valid. [1] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1464375113.1204.120.camel>