From owner-freebsd-sparc64@freebsd.org Fri May 27 18:52:03 2016 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 45D47B4C95B for ; Fri, 27 May 2016 18:52:03 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A213E1B55 for ; Fri, 27 May 2016 18:52:02 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 192b0ab7-243c-11e6-8d8d-01a8ff6afd94 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 27 May 2016 18:52:01 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u4RIprAf008169; Fri, 27 May 2016 12:51:53 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1464375113.1204.120.camel@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] From: Ian Lepore To: Matthias Andree , Cedric Blancher , Mark Millard Cc: freebsd-arm , FreeBSD Toolchain , freebsd-sparc64@freebsd.org Date: Fri, 27 May 2016 12:51:53 -0600 In-Reply-To: <5747F78A.5020103@gmx.de> References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> <5747F78A.5020103@gmx.de> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 18:52:03 -0000 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