Date: Thu, 26 May 2016 15:03:26 -0700 From: Mark Millard <markmi@dsl-only.net> To: freebsd-sparc64@freebsd.org Cc: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, mandree@FreeBSD.org 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] Message-ID: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7AFD3661-9764-434B-A387-FD31B62DD77E>