Date: Fri, 27 May 2016 04:35:54 -0700 From: Mark Millard <markmi@dsl-only.net> To: Matthias Andree <matthias.andree@gmx.de> Cc: Cedric Blancher <cedric.blancher@gmail.com>, 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: <C15677FD-F3D2-4EC1-AD10-606780880B87@dsl-only.net> In-Reply-To: <5747F78A.5020103@gmx.de> 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> <5747F78A.5020103@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-May-27, at 12:30 AM, Matthias Andree <matthias.andree@gmx.de> = 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 > <http://www.oberhumer.com/opensource/lzo/>; >=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.) > <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207096>; > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C15677FD-F3D2-4EC1-AD10-606780880B87>