Date: Fri, 27 May 2016 09:30:18 +0200 From: Matthias Andree <matthias.andree@gmx.de> To: Cedric Blancher <cedric.blancher@gmail.com>, Mark Millard <markmi@dsl-only.net> Cc: freebsd-sparc64@freebsd.org, freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@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: <5747F78A.5020103@gmx.de> In-Reply-To: <CALXu0Uc2Ssqs5OzCpTZs0Mcy4Y0ZQBzKAJPpT1LjnMoD-8updg@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. <http://www.oberhumer.com/opensource/lzo/>; 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. <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207096>; 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5747F78A.5020103>