From owner-freebsd-sparc64@freebsd.org Thu May 26 22:03:35 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 1232FB4CAC6 for ; Thu, 26 May 2016 22:03:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-168.reflexion.net [208.70.211.168]) (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 A24131B02 for ; Thu, 26 May 2016 22:03:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12314 invoked from network); 26 May 2016 22:03:28 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 May 2016 22:03:28 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 26 May 2016 18:03:32 -0400 (EDT) Received: (qmail 8767 invoked from network); 26 May 2016 22:03:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 May 2016 22:03:32 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CFFF61C43D6; Thu, 26 May 2016 15:03:22 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses] Date: Thu, 26 May 2016 15:03:26 -0700 Message-Id: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> Cc: freebsd-arm , FreeBSD Toolchain , mandree@FreeBSD.org To: freebsd-sparc64@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) 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: Thu, 26 May 2016 22:03:35 -0000 Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access = failure [from before -r300694] would (likely?) also be a failure on some = forms of FreeBSD SPARC use? Why I ask: One of the ports that I had submitted a bug report for unaligned access = problems on a rpi2 (armv7-a/cortex-a7 style handling) was: archivers/lzo2 ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207096 ). I'd = recently commented that the report might go away after testing what is = now -r300694 (allowing more unaligned access on, for example, = armv7-a/cortex-a7). Matthias Andree has since asked in a comment: > ISTR SPARC architectures also barf on unaligned access, so is it worth = bothering the upstream author? I have generally stuck to architectures for which I have examples to = observe, if nothing else than to validate at least some of my = understanding that is from reading materials. I normally only submit = what I've observed in some form. I've no such SPARC context nor do I have knowledge/reference material = for SPARCs. Nor am I familiar with the choices FreeBSD may have made for = SPARC configuration coverage. As a matter of hear-say my impression is that some SPARCs can be = configured to require some variation of strict alignment. But I do not know how much I can infer from what I observed on a rpi2 = (armv7-a/cortex-a7) to FreeBSD SPARC use getting similar results for at = least come configurations. Nor do I have access to a test environment = for SPARC. So I wonder if my archivers/lzo2 submittal in question should survive = because of SPARC even if the problem is validated to go away for the = updated rpi2 like contexts (with armv7-a/cortex-a7 tailoring possibly = involved). I have some other submittals that might face the same type of = question. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-sparc64@freebsd.org Fri May 27 03:21:35 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 DBF7EB4C16F; Fri, 27 May 2016 03:21:35 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC1031679; Fri, 27 May 2016 03:21:35 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: by mail-pa0-x22b.google.com with SMTP id bz2so6068294pad.1; Thu, 26 May 2016 20:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=dkWu8SyHWKW0ZPWcskkPm00TWK2Cs6wAUUvMjRCtKkM=; b=RbElxn1pCnRaRLhOwMkUNklzSzViq2spBYg892WQP8F2bSBg2WmVhDlhYPKA07QPM8 c8CFvwYmtb6GGg56DBdPpAUoNIQir0QlNGA7rDw5NX8bjNFSIugJSlVBV3O33SSsP0tE hyniL55uh5EhoJkkAS38zl4a0uKZw1l+POQSneNxfNwTI9MM0zch3eX+3qny4suzH9iQ c45HUuhfzvoDuRwJWMjkIixKweVjSYhTprMAscUZGC6rYO9KvXaOWcSFjVpiiDCIt6AJ fsxliFYR8b401Eq0wqq2sn694gFUMRL+mV8snWzPvyB49i5OnpADs2F5F3XeaMgzSAQd fopw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=dkWu8SyHWKW0ZPWcskkPm00TWK2Cs6wAUUvMjRCtKkM=; b=QU2dLTOta2v6gUhvXMSV/+R05U0JPNM+VYPRgZv7qyydaFZ0tLntFRoiOrPdDi+mXF +cM9zu3DxpcD6z3H6muH1DOTA6cb7zgxcON3dDx7+rKqwzP8cD8v9j8KxWvgOOR6U2kO XlwZiq1KUrLdeyMigS4kT3TavykIbdMb0gRoiZp/FFFXHjBvIU2qOK3jK2iVE9Dk4EEL OiAtdegZQCEXOvHerTRVr64dFHn1Te2ePCeH0MyxkOh3HotpXxBa1hDP+Lbv29ZfNAyC YLlcNmnpISMJuTO2cNagN9dk00zSs0R1dw4LI+L7DbUCDbO5ZztOZFLI+WMGwatzWB6J enIw== X-Gm-Message-State: ALyK8tL55qa8VO2gV4dxoZHHCBMB4Ye/mlFZ076or4X6ukePdOjpIxNpLmEPBAqqFOxaACjroeodIVxGNVODpQ== MIME-Version: 1.0 X-Received: by 10.66.26.165 with SMTP id m5mr18269601pag.155.1464319295224; Thu, 26 May 2016 20:21:35 -0700 (PDT) Received: by 10.66.183.232 with HTTP; Thu, 26 May 2016 20:21:35 -0700 (PDT) In-Reply-To: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> Date: Fri, 27 May 2016 05:21:35 +0200 Message-ID: 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: Cedric Blancher To: Mark Millard Cc: freebsd-sparc64@freebsd.org, freebsd-arm , FreeBSD Toolchain , mandree@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 03:21:36 -0000 All pure RISC implementations enforce 'natural alignment' - a 32bit data type must be aligned 32bit, i.e. 4 bytes, a 64bit data type must be 8 byte aligned, a 128bit data type must be 16 byte aligned. Some RISC implementations are not pure, but still the misalignment comes with a (performance) penalty, either by issuing two loads or running through a whole trap handler (!!!!) function with hundreds of instructions. Ced On 27 May 2016 at 00:03, Mark Millard wrote: > Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access fai= lure [from before -r300694] would (likely?) also be a failure on some forms= of FreeBSD SPARC use? > > > Why I ask: > > One of the ports that I had submitted a bug report for unaligned access p= roblems on a rpi2 (armv7-a/cortex-a7 style handling) was: > > archivers/lzo2 > > ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207096 ). I'd recen= tly commented that the report might go away after testing what is now -r300= 694 (allowing more unaligned access on, for example, armv7-a/cortex-a7). > > Matthias Andree has since asked in a comment: > >> ISTR SPARC architectures also barf on unaligned access, so is it worth b= othering the upstream author? > > I have generally stuck to architectures for which I have examples to obse= rve, if nothing else than to validate at least some of my understanding tha= t is from reading materials. I normally only submit what I've observed in s= ome form. > > I've no such SPARC context nor do I have knowledge/reference material for= SPARCs. Nor am I familiar with the choices FreeBSD may have made for SPARC= configuration coverage. > > As a matter of hear-say my impression is that some SPARCs can be configur= ed to require some variation of strict alignment. > > But I do not know how much I can infer from what I observed on a rpi2 (ar= mv7-a/cortex-a7) to FreeBSD SPARC use getting similar results for at least = come configurations. Nor do I have access to a test environment for SPARC. > > So I wonder if my archivers/lzo2 submittal in question should survive bec= ause of SPARC even if the problem is validated to go away for the updated r= pi2 like contexts (with armv7-a/cortex-a7 tailoring possibly involved). I h= ave some other submittals that might face the same type of question. > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org= " --=20 Cedric Blancher Institute Pasteur From owner-freebsd-sparc64@freebsd.org Fri May 27 03:59:04 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 D9E09B4C894 for ; Fri, 27 May 2016 03:59:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-165.reflexion.net [208.70.211.165]) (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 9E8481A36 for ; Fri, 27 May 2016 03:59:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6424 invoked from network); 27 May 2016 03:59:03 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 27 May 2016 03:59:03 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 26 May 2016 23:59:40 -0400 (EDT) Received: (qmail 31337 invoked from network); 27 May 2016 03:59:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 27 May 2016 03:59:39 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3D9151C43E9; Thu, 26 May 2016 20:58:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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: Mark Millard In-Reply-To: Date: Thu, 26 May 2016 20:59:01 -0700 Cc: freebsd-sparc64@freebsd.org, freebsd-arm , FreeBSD Toolchain , mandree@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> To: Cedric Blancher X-Mailer: Apple Mail (2.3124) 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 03:59:05 -0000 On 2016-May-26, at 8:21 PM, Cedric Blancher = wrote: > All pure RISC implementations enforce 'natural alignment' - a 32bit > data type must be aligned 32bit, i.e. 4 bytes, a 64bit data type must > be 8 byte aligned, a 128bit data type must be 16 byte aligned. > Some RISC implementations are not pure, but still the misalignment > comes with a (performance) penalty, either by issuing two loads or > running through a whole trap handler (!!!!) function with hundreds of > instructions. >=20 > Ced Thanks for the notes. Having once worked in a "micros" group in a logic analyzer product line = for many years, working on the software tools that were used for that = subject area, I'm very familiar with that general structure of = alternatives --but not with SPARC specifics. In your terminology: I've = no clue how pure of a RISC implementation is involved for any SPARC = variation. I'm looking for SPARC-specific information that suggests if the defect = report originally for armv7-a/cortex-a7 as FreeBSD formerly configured = things instead also likely applies to some SPARC variation/configuration = that FreeBSD supports. (See later below.) If FreeBSD has some other fairly strict alignment context that is not a = SPARC that might also serve. Unless upstream can be told that some specific FreeBSD variant is = unsupported by their software because of presuming unaligned access is = okay, I doubt that a report to upstream should be made based on FreeBSD = as a context. (This presumes that the port passes a test under the new = armv7-a/cortex-a7 and related alignment requirements. I'm not to that = point yet.) > On 27 May 2016 at 00:03, Mark Millard wrote: >> Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access = failure [from before -r300694] would (likely?) also be a failure on some = forms of FreeBSD SPARC use? >>=20 >>=20 >> Why I ask: >>=20 >> One of the ports that I had submitted a bug report for unaligned = access problems on a rpi2 (armv7-a/cortex-a7 style handling) was: >>=20 >> archivers/lzo2 >>=20 >> ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207096 ). I'd = recently commented that the report might go away after testing what is = now -r300694 (allowing more unaligned access on, for example, = armv7-a/cortex-a7). >>=20 >> Matthias Andree has since asked in a comment: >>=20 >>> ISTR SPARC architectures also barf on unaligned access, so is it = worth bothering the upstream author? >>=20 >> I have generally stuck to architectures for which I have examples to = observe, if nothing else than to validate at least some of my = understanding that is from reading materials. I normally only submit = what I've observed in some form. >>=20 >> I've no such SPARC context nor do I have knowledge/reference material = for SPARCs. Nor am I familiar with the choices FreeBSD may have made for = SPARC configuration coverage. >>=20 >> As a matter of hear-say my impression is that some SPARCs can be = configured to require some variation of strict alignment. >>=20 >> But I do not know how much I can infer from what I observed on a rpi2 = (armv7-a/cortex-a7) to FreeBSD SPARC use getting similar results for at = least come configurations. Nor do I have access to a test environment = for SPARC. >>=20 >> So I wonder if my archivers/lzo2 submittal in question should survive = because of SPARC even if the problem is validated to go away for the = updated rpi2 like contexts (with armv7-a/cortex-a7 tailoring possibly = involved). I have some other submittals that might face the same type of = question. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-sparc64@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 >> To unsubscribe, send any mail to = "freebsd-sparc64-unsubscribe@freebsd.org" >=20 >=20 >=20 > --=20 > Cedric Blancher > Institute Pasteur =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-sparc64@freebsd.org Fri May 27 04:14:55 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 57498B4CC90; Fri, 27 May 2016 04:14:55 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26C331325; Fri, 27 May 2016 04:14:55 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: by mail-pf0-x22f.google.com with SMTP id g64so37760909pfb.2; Thu, 26 May 2016 21:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=sBSNRe3gf63kFJ5c21VlMqTvZ/omf2EELZiyqpV2UZs=; b=VmsPzDRCR5BOXLHf7BOEQZ+h9OZhzum42bxIAT6Na1Y0OWIUMSFekRNkFdpFJ5dV9P Re9RrzB8FlEuIM2hJP1mTsx52qo4lN3w8LSJc1f8wLY7wz8GmztJt9XDDNmApjYnEJSo vDFDbnYBDqudcJFz5BRiEDKSXazpce8AlNM3mkS9ynSJdJDB+sDiZGCxwXEd5NikyG84 EdQduIi3yUGUV3UC70Cle2hq9oAuKJWDPyOAeBAOA0e12ur7tGL8m+PVAXCmDQAfN8kF PeYhw4R4OJU/bJxlZIznOo4M/jHTjn+6jzrcAH2B/2D+q5OXfdgUPZXyPVql+8XT83/H U1Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=sBSNRe3gf63kFJ5c21VlMqTvZ/omf2EELZiyqpV2UZs=; b=iTZ8Daco9S/I4ifPGBve2jvfwmuJAS6lkfe6i0n4YXgChz940tZ0HHOasve8kZqXwE BWYwdNlywS+4/PXdLoKIyqoGAd4jbFJ5pI+r/C2T0cWLOzqRuZXfVtZvNlUe5vUK/46i wdK75QPTPiG+IJ4x55msRgXBM5S0aRMEHTICEnPSro0O1Yj3YIzMojamelDjZFxlP0Bb Rcw76M018CxxI/dYC0+AlB4zPeDHLinHT5r82jtTFYefgJevMuJjbxicbrQMzVo5VXxq +Wxj6AqKGN9dMdJ1AMYBy++qHxb/kW4Ybs8T26Fm1rBxHJPmqJC7uB2Tr8PCV9IKO7mN U2+w== X-Gm-Message-State: ALyK8tJ6hI4xxKHFlxi5Bbaw//IJNuVRqoGf0jEK6h31rij70S9IIuHmEA2gp9NtARGeyxsPNwpcNn2BiPWVpw== MIME-Version: 1.0 X-Received: by 10.98.19.5 with SMTP id b5mr19187982pfj.153.1464322494570; Thu, 26 May 2016 21:14:54 -0700 (PDT) Received: by 10.66.183.232 with HTTP; Thu, 26 May 2016 21:14:54 -0700 (PDT) In-Reply-To: References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> Date: Fri, 27 May 2016 06:14:54 +0200 Message-ID: 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: Cedric Blancher To: Mark Millard Cc: freebsd-sparc64@freebsd.org, freebsd-arm , FreeBSD Toolchain , mandree@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 04:14:55 -0000 SPARCv7, SPARCv8 and SPARCv9 mandate natural alignment like all 'normal' RISC implementations. SPARCv9 ABI adds some 'special' instructions (separate from the normal load/store instructions) for unaligned access, but as said they come with costs, as stated before PLUS the risk that they are unimplemented in the actual hardware and trigger emulation traps. Ced On 27 May 2016 at 05:59, Mark Millard wrote: > On 2016-May-26, at 8:21 PM, Cedric Blancher w= rote: > >> All pure RISC implementations enforce 'natural alignment' - a 32bit >> data type must be aligned 32bit, i.e. 4 bytes, a 64bit data type must >> be 8 byte aligned, a 128bit data type must be 16 byte aligned. >> Some RISC implementations are not pure, but still the misalignment >> comes with a (performance) penalty, either by issuing two loads or >> running through a whole trap handler (!!!!) function with hundreds of >> instructions. >> >> Ced > > Thanks for the notes. > > Having once worked in a "micros" group in a logic analyzer product line f= or many years, working on the software tools that were used for that subjec= t area, I'm very familiar with that general structure of alternatives --but= not with SPARC specifics. In your terminology: I've no clue how pure of a = RISC implementation is involved for any SPARC variation. > > I'm looking for SPARC-specific information that suggests if the defect re= port originally for armv7-a/cortex-a7 as FreeBSD formerly configured things= instead also likely applies to some SPARC variation/configuration that Fre= eBSD supports. (See later below.) > > If FreeBSD has some other fairly strict alignment context that is not a S= PARC that might also serve. > > Unless upstream can be told that some specific FreeBSD variant is unsuppo= rted by their software because of presuming unaligned access is okay, I dou= bt that a report to upstream should be made based on FreeBSD as a context. = (This presumes that the port passes a test under the new armv7-a/cortex-a7 = and related alignment requirements. I'm not to that point yet.) > >> On 27 May 2016 at 00:03, Mark Millard wrote: >>> Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access f= ailure [from before -r300694] would (likely?) also be a failure on some for= ms of FreeBSD SPARC use? >>> >>> >>> Why I ask: >>> >>> One of the ports that I had submitted a bug report for unaligned access= problems on a rpi2 (armv7-a/cortex-a7 style handling) was: >>> >>> archivers/lzo2 >>> >>> ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207096 ). I'd rec= ently commented that the report might go away after testing what is now -r3= 00694 (allowing more unaligned access on, for example, armv7-a/cortex-a7). >>> >>> Matthias Andree has since asked in a comment: >>> >>>> ISTR SPARC architectures also barf on unaligned access, so is it worth= bothering the upstream author? >>> >>> I have generally stuck to architectures for which I have examples to ob= serve, if nothing else than to validate at least some of my understanding t= hat is from reading materials. I normally only submit what I've observed in= some form. >>> >>> I've no such SPARC context nor do I have knowledge/reference material f= or SPARCs. Nor am I familiar with the choices FreeBSD may have made for SPA= RC configuration coverage. >>> >>> As a matter of hear-say my impression is that some SPARCs can be config= ured to require some variation of strict alignment. >>> >>> But I do not know how much I can infer from what I observed on a rpi2 (= armv7-a/cortex-a7) to FreeBSD SPARC use getting similar results for at leas= t come configurations. Nor do I have access to a test environment for SPARC= . >>> >>> So I wonder if my archivers/lzo2 submittal in question should survive b= ecause of SPARC even if the problem is validated to go away for the updated= rpi2 like contexts (with armv7-a/cortex-a7 tailoring possibly involved). I= have some other submittals that might face the same type of question. >>> >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>> >>> _______________________________________________ >>> freebsd-sparc64@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 >>> To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.o= rg" >> >> >> >> -- >> Cedric Blancher >> Institute Pasteur > > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > --=20 Cedric Blancher Institute Pasteur From owner-freebsd-sparc64@freebsd.org Fri May 27 07:30:34 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 37F29B4BDAD; Fri, 27 May 2016 07:30:34 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D694112B; Fri, 27 May 2016 07:30:33 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mandree.no-ip.org ([78.48.16.123]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lg6op-1btmfG333D-00pZAw; Fri, 27 May 2016 09:30:21 +0200 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 7EDAA23CF40; Fri, 27 May 2016 09:30:19 +0200 (CEST) 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] To: Cedric Blancher , Mark Millard References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> Cc: freebsd-sparc64@freebsd.org, freebsd-arm , FreeBSD Toolchain From: Matthias Andree Message-ID: <5747F78A.5020103@gmx.de> Date: Fri, 27 May 2016 09:30:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:x4Dzr8rnhGNCAllALYKVEMmLxtNzsdMnMdvKIg7iiIFtSxJIc3F DJkwkTurVDChYM0tLhSEzrJMpr7QtAYtVyl9o1d4X+PfD0qJKNOikWMRArwl3tqOCOOwCcA zO66467O5WlSgKq0uPiBSCg/WBE5k9bO2VfddEdNsuZHgYSguw9XM/HPOoR5UjSFJlXv6qI Lqb5UpRxnUoZz++R933hw== X-UI-Out-Filterresults: notjunk:1;V01:K0:E75w9CCR9Zo=:b2T1Qls706obKcMBPZD1J6 bOFjVIeUeXM5F9WUZqfyYljblg6nh0thPkoEMeY5uDx3wVp+yyGUiyWIDQW55ST17y149fwq5 OLMm0gKzfjfLTYc37HTqROr9yDlaXSWBes5WW1xofgf9z9IXYrc2prlMfdzQcVKdsjT2ZMqK3 n2xtbjrFPJuHJAm4CUNF/WrzwZHRHKXVpzR8pCEKrBoOdUQ23/nzJRAJc3xmbIh/MDWGqM7hK AlCxtiOQ86SFPzsjGfuIshq3WK1Bw9vabeDNOL/Gv3NRqwnAo6KtI5TZIIFeKba7hICxBCW29 Sebbi/NzOmPGUU9N052CYQR/ZiECc/vMvPy7gfNea5qt68PG97YSspwKEJ/LOjf2N2AIFePwb AkHngImjDvpj/akYGbnwWVKpdFR1ImSCQQIHeQ0ZAsXT9vmqn3CCUKZRDGDgTjI21cDTGOT1I U8sTBI9GwuHDBarip4KsWqT5NaaQdK4hVWAAQo795MV+sepa7xzYi9R6GibJUlbRtoyFDccI9 KHpYiNci8AharOkPpwDXBKNzUem/QfiJIwue6DqimH/Sf4z+Axg7aZReilTpd29DHaebZsrJM lGZoVokipGCbAlTq8+mzQiasHy9XM7U5BKhedtY1nau2kUgRjBVqRqwLA4344SubShxgSQma3 bU9zfg4LR5Zg5rMHfbdj+PPePp1v3waZ4pKn5vRqQZyYNmosuxcCalfNdd8AfSmXKwOmn3tpS p5NiLnagNEP4trgeaYPAm1rwF4FyR6B2woKssOTSesYsPk9HVDCKKF5Ahky0bzUXpZWaYo1Ma zBmeoGa 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 07:30:34 -0000 Am 27.05.2016 um 06:14 schrieb Cedric Blancher: > SPARCv7, SPARCv8 and SPARCv9 mandate natural alignment like all > 'normal' RISC implementations. SPARCv9 ABI adds some 'special' > instructions (separate from the normal load/store instructions) for > unaligned access, but as said they come with costs, as stated before > PLUS the risk that they are unimplemented in the actual hardware and > trigger emulation traps. LZO libraries (archivers/lzo2) are mainly about speed end efficiency for mobile or otherwise energy-challenged devices, so we probably want to avoid unaligned access whatsoever in the port even if the crash happens outside inner loops. Now looking at the PR, there's a resolved core dump that leaves me with the impression it's trying to get 16 bit from an odd address, without digging too deep. Someone stop me here if I'm misinterpreting this. Where the take-home message for me was in Comment 4: > While options like -mno-unaligned-access will make the compiled code > avoid adding new misalignments as "optimizations" when the original > code does not misalign it will not repair code that directly generates > misalignments. (The alignment fixes to clang++ were all source code > fixes, not compiler option changes.) Meaning that this, for now, appears to be a port bug. Now, below is my current plan in the role of the port's maintainer, and any assistance will be appreciated (<- that's soliciting input) 1 - figure if this affects other RISC architectures. Cedric got the SPARC on the hook, but I'm open for input on other arch's. If someone can report back if the lzo2 port runs into unaligned-access-emulation traps on FreeBSD/sparc*, that would be helpful. I do not have access to SPARC computers any more. 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. 3 - if it's nothing we can do about, get Markus F. X. J. Oberhumer into the loop and ask him to make his code work on strict-alignment computers and possibly provide initial patches. Finally a question of my personal interest for the ARM7 folks: How much of an effort is it to get a RPi configured to the point that I can reproduce the problem? Is it more something to do over a coffee, or will it take a week of frequent hand-holding and compiles over night? The RPi seems pretty affordable and I meant to get one (for Linux) anyways, I might just get another SD card for FreeBSD 11. From owner-freebsd-sparc64@freebsd.org Fri May 27 11:35:57 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 CEA01B4C0A6 for ; Fri, 27 May 2016 11:35:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-178.reflexion.net [208.70.211.178]) (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 92D2E1104 for ; Fri, 27 May 2016 11:35:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7689 invoked from network); 27 May 2016 11:36:25 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 May 2016 11:36:25 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Fri, 27 May 2016 07:35:53 -0400 (EDT) Received: (qmail 9321 invoked from network); 27 May 2016 11:35:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 27 May 2016 11:35:53 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id EF0601C43F4; Fri, 27 May 2016 04:35:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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: Mark Millard In-Reply-To: <5747F78A.5020103@gmx.de> Date: Fri, 27 May 2016 04:35:54 -0700 Cc: Cedric Blancher , freebsd-sparc64@freebsd.org, freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> <5747F78A.5020103@gmx.de> To: Matthias Andree X-Mailer: Apple Mail (2.3124) 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 11:35:57 -0000 On 2016-May-27, at 12:30 AM, Matthias Andree = wrote: > Am 27.05.2016 um 06:14 schrieb Cedric Blancher: >> SPARCv7, SPARCv8 and SPARCv9 mandate natural alignment like all >> 'normal' RISC implementations. SPARCv9 ABI adds some 'special' >> instructions (separate from the normal load/store instructions) for >> unaligned access, but as said they come with costs, as stated before >> PLUS the risk that they are unimplemented in the actual hardware and >> trigger emulation traps. >=20 > LZO libraries (archivers/lzo2) are mainly about speed end efficiency = for > mobile or otherwise energy-challenged devices, so we probably want to > avoid unaligned access whatsoever in the port even if the crash = happens > outside inner loops. >=20 > >=20 > Now looking at the PR, there's a resolved core dump that leaves me = with > the impression it's trying to get 16 bit from an odd address, without > digging too deep. Someone stop me here if I'm misinterpreting this. That is what the ldrh instruction would be doing given the value listed = for r0. Before the recent kernel change that attempt caused an = exception. Now it would to the misaligned access without complaint. (But = I've not got as far as testing such yet: other things are taking my = time.) > > Where the take-home message for me was in Comment 4: >=20 >> While options like -mno-unaligned-access will make the compiled code >> avoid adding new misalignments as "optimizations" when the original >> code does not misalign it will not repair code that directly = generates >> misalignments. (The alignment fixes to clang++ were all source code >> fixes, not compiler option changes.) >=20 > Meaning that this, for now, appears to be a port bug. >=20 > Now, below is my current plan in the role of the port's maintainer, = and > any assistance will be appreciated (<- that's soliciting input) >=20 > 1 - figure if this affects other RISC architectures. Cedric got the > SPARC on the hook, but I'm open for input on other arch's. >=20 > If someone can report back if the lzo2 port runs into > unaligned-access-emulation traps on FreeBSD/sparc*, that would be > helpful. I do not have access to SPARC computers any more. I also have no access to any SPARC variants. > 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. >=20 >=20 > 3 - if it's nothing we can do about, get Markus F. X. J. Oberhumer = into > the loop and ask him to make his code work on strict-alignment = computers > and possibly provide initial patches. >=20 >=20 > Finally a question of my personal interest for the ARM7 folks: >=20 > How much of an effort is it to get a RPi configured to the point that = I > can reproduce the problem? Is it more something to do over a coffee, = or > will it take a week of frequent hand-holding and compiles over night? > The RPi seems pretty affordable and I meant to get one (for Linux) > anyways, I might just get another SD card for FreeBSD 11. The rpi vintage matters: Original rpi's (before rpi2): ARM1176JZF-S, 32-bit (not armv6 nor = armv7-a/cortex-a7) rpi2: armv7-a/cortex-a7, 32-bit (this is where the problem was = originally shown) rpi3: cortex-A53, 64-bit (not supported by FreeBSD 11.0 yet) (I've done no testing of an original rpi and do not know its behavior. = Original rpi's would be slower.) As far as I know you would need an rpi2 specifically and likely a = now-older 11.0-CURRENT vintage that is pickier about alignment (or a = more modern kernel adjusted back to being picker). I've not been using the 11.0 snapshots to install but building from = source on an amd64 context and copying over the installation materials = separately. Also I have / on a usb drive instead of a slower SD card. An = SD card is still required for part of the boot sequence for such = contexts but is otherwise is normally unused as I do things. I did buildworld/buildkernel once on the rpi2 itself and it took about = 14 hours at the time as I remember. By contrast, all my port builds from source were on the rpi2 itself, not = cross builds. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-sparc64@freebsd.org Fri May 27 12:03:23 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 75A3AB4A53D; Fri, 27 May 2016 12:03:23 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (chuckie.co.uk [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3707C1A5D; Fri, 27 May 2016 12:03:22 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from host31-50-169-25.range31-50.btcentralplus.com ([31.50.169.25] helo=[192.168.1.65]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1b6GD6-00077b-K1; Fri, 27 May 2016 12:45:49 +0100 To: Mark Millard , Matthias Andree References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> <5747F78A.5020103@gmx.de> Cc: freebsd-arm , FreeBSD Toolchain , freebsd-sparc64@freebsd.org From: Mark Cave-Ayland Message-ID: <5748334B.6070504@ilande.co.uk> Date: Fri, 27 May 2016 12:45:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 31.50.169.25 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on s16892447.onlinehome-server.info X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 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] X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: Yes (on s16892447.onlinehome-server.info) 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 12:03:23 -0000 On 27/05/16 12:35, Mark Millard wrote: >> 1 - figure if this affects other RISC architectures. Cedric got the >> SPARC on the hook, but I'm open for input on other arch's. >> >> If someone can report back if the lzo2 port runs into >> unaligned-access-emulation traps on FreeBSD/sparc*, that would be >> helpful. I do not have access to SPARC computers any more. > > I also have no access to any SPARC variants. If you grab yourself a copy of the latest QEMU 2.6, you should be able to happily install FreeBSD-current under qemu-system-sparc64 in -nographic mode. The emulation is still a work-in-progress but one of its primary use cases is allow people to generate builds even if they don't have access to the real hardware. ATB, Mark. From owner-freebsd-sparc64@freebsd.org Fri May 27 18:15:46 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 EED33B4C05A for ; Fri, 27 May 2016 18:15:46 +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 5CC841046 for ; Fri, 27 May 2016 18:15:45 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 08d546ab-2437-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:15:46 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u4RIFc0U008102; Fri, 27 May 2016 12:15:38 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1464372938.1204.98.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: Mark Millard , Matthias Andree Cc: freebsd-arm , FreeBSD Toolchain , Cedric Blancher , freebsd-sparc64@freebsd.org Date: Fri, 27 May 2016 12:15:38 -0600 In-Reply-To: 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:15:47 -0000 On Fri, 2016-05-27 at 04:35 -0700, Mark Millard wrote: > On 2016-May-27, at 12:30 AM, Matthias Andree > wrote: > > > Am 27.05.2016 um 06:14 schrieb Cedric Blancher: > > > [...] > The rpi vintage matters: > > Original rpi's (before rpi2): ARM1176JZF-S, 32-bit (not armv6 nor > armv7-a/cortex-a7) > Original rpi is indeed 1176JZF-S, which IS armv6. The differences between it and armv7 are almost entirely in the cache maintenence routines, and notably not in handling unaligned access the way we now configure the hardware. Bottom line: this is an old slow chip and you'll be nothing but frustrated using it. If you're going to get an rpi, get the much faster rpi2, which is a quad-core system. These days you may be even better off with something even newer based on the Allwinner chips (banana pi, cubieboard, a bunch of others), thanks to the excellent support work done recent (and still happening) by Jarred and Emmanuel. But I'm not sure of the price comparisons. -- Ian 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