Comment 4 for bug 1516331

A quick test on the arm64 porter box suggests that they're trapped and
fixed up:

  (wily-arm64)cjwatson@rugby:~$ cat t.c
  #include <inttypes.h>
  #include <stdint.h>
  #include <stdio.h>

  void unaligned(uint64_t *x) { printf("x: %" PRIx64 "\n", *x); }

  int main(int argc, char **argv) {
          uint64_t a, b;
          a = 0x0123456789abcdef;
          b = 0xfedcba9876543210;
          unaligned((uint64_t *)((char *)&a + 1));
          return 0;
  }
  (wily-arm64)cjwatson@rugby:~$ gcc -O0 -g t.c -o t
  (wily-arm64)cjwatson@rugby:~$ ./t
  x: 100123456789abcd

So, I suppose we can do this, but it's going to cease being effective as
soon as we switch armhf to scalingstack, since this will be running on
top of arm64 kernels. My question is therefore: is it worth it given
that there would probably be some kind of cost and that the benefit
would be fairly short-term? If so, maybe somebody should look into how
an alignment trap that forces a signal on arm64 might work in more
detail.