From owner-freebsd-arm@freebsd.org Fri May 27 11:35:57 2016 Return-Path: Delivered-To: freebsd-arm@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 CF1ABB4C0A7 for ; Fri, 27 May 2016 11:35:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-192.reflexion.net [208.70.211.192]) (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 92CF91103 for ; Fri, 27 May 2016 11:35:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7407 invoked from network); 27 May 2016 11:35:56 -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:35:56 -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-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." 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