Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses]

[Matthias Andree]

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=207096>
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.