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

Mark Millard markmi at dsl-only.net
Fri May 27 11:35:57 UTC 2016


On 2016-May-27, at 12:30 AM, Matthias Andree <matthias.andree at 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.
> 
> 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.

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

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

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.

===
Mark Millard
markmi at dsl-only.net







More information about the freebsd-sparc64 mailing list