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.