Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses

[Michael Hope <michael dot hope at linaro dot org>]

On 8 June 2012 12:15, Hans-Peter Nilsson <hans-peter.nilsson@axis.com> wrote:
> (CC to ARM maintainer approving the original patch.)
>
> I'm listing this under "caveats" rather than "improvements" and
> before the current top ARM-related caveat (as this one is more
> important :) because I don't see performance figures in the
> context of the original patch (r178852) backing up this as an
> improvement, and it caused sort-of a wild goose hunt for
> applications causing unaligned accesses, until it was found to be
> deliberately emitted by gcc-4.7 when configured for
> arm-unknown-linux-gnueabi and passing "-marmv6". ?Hence caveat.
> Nomenclature taken from that patch; if prefer a different
> spelling of the ARM variants, please tell how. ?The "some source
> codes" was in the analyzed case a strcpy of a five-byte string
> (busybox/libbb/procps.c:365 'strcpy(filename_tail, "stat");' of
> some unknown busybox-version).
>
> An OS configured with unaligned accesses turned off (IIUC the
> default for Linux/ARM), has the nice property that you easily
> spot a certain class of bad codes.
>
> Ok to commit?

The wording is scarier than I'd like.  Userspace and the Linux kernel
post 3.1 are fine.  Earlier kernels fail to start due to the kernel
turning off the hardware support and an interaction of
-fconserve-stack and -munaligned-access cause a char array to be
unaligned on the stack.

I don't agree that unaligned access is a sign of wrong code.  It's
very common when poking about in protocol buffers.  Using the hardware
support is better than the multi-byte read plus OR that GCC used to
do.

Where else have you seen this?

> Alternatively and IMHO preferably, there's reason enough to
> revert the (new) default, including the gcc-4.7 branch.
>
> Index: changes.html
> ===================================================================
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
> retrieving revision 1.113
> diff -p -u -r1.113 changes.html
> --- changes.html ? ? ? ?5 Jun 2012 11:03:53 -0000 ? ? ? 1.113
> +++ changes.html ? ? ? ?8 Jun 2012 00:01:09 -0000
> @@ -43,6 +43,16 @@
>
> ? ? </li>
>
> + ? ?<li>On ARM, when compiling for ARMv6 (but not ARMv6-M), ARMv7-A,
> + ? ?ARMv7-R, or ARMv7-M

How about "ARMv6K and above"? or "ARMv6 and above, except for ARMv6-M"

> the default of the new option
> + ? ?<code>-munaligned-accesses</code> is on, which for some source
> + ? ?codes generates code that accesses memory on unaligned adresses.
> + ? ?This will require the OS of those systems to enable such accesses
> + ? ?(controlled by CP15 register c1, refer to ARM documentation).

The CPU has an unaligned access trap which is off by default.  The
kernel has to turn the trap on to cause the fault.

> + ? ?Alternatively or for compatibility with OS versions that do not
> + ? ?enable unaligned accesses, all codes has to be compiled with
> + ? ?<code>-mno-unaligned-accesses</code>.</li>
> +
> ? ? <li>Support on ARM for the legacy floating-point accelerator (FPA) and
> ? ? the mixed-endian floating-point format that it used has been obsoleted.
> ? ? The ports that still use this format have been obsoleted as well.
>
> brgds, H-P