Comment 26 for bug 1512323

Investigation shows that the test case is triggering kernel fix-ups for unaligned access, as shown by the incrementing counters in /proc/cpu/alignment on cady. I'm investigating to see if the phone kernels have a different default behavior for alignments (SIGBUS vs. fixup).

So I have a valid test case, it just unfortunately won't block the build with a test failure on our buildds because the kernel is fixing up the unaligned access for us. On other architectures we could build-depend on and use prctl to force SIGBUS to be raised, but ARM doesn't support prctl --unaligned.

I have also verified that booting the emulator shows /proc/cpu/alignment configured for signal (4) instead of fixup (2). This despite the fact that CONFIG_ALIGNMENT_TRAP=y is part of the common configuration for Ubuntu ARM kernels (config/config.common.ubuntu), and is definitely configured that way at build and runtime in the linux-goldfish package in the archive.

That means that *something* in the phone stack is changing the value of /proc/cpu/alignment post-boot. But I don't know what this "something" is; there are no matches for /proc/cpu/alignment in /etc on the generic image, nor in /android. Google points at it possibly being an android-inflicted problem. (https://groups.google.com/forum/#!topic/android-kernel/5vl47DgDz7E)

Now, raising signals on unaligned access is a sensible default behavior. But we currently have this exactly backwards, because we are fixing up those unaligned accesses on our build and test infrastructure but have them causing software failures in production! Someone from the phone team should investigate where this wrong setting is coming from and fix it.