[U-Boot] [RFC] ARM: prevent misaligned array inits
Stephen Warren
swarren at wwwdotorg.org
Tue Oct 2 22:06:53 CEST 2012
On 10/02/2012 12:46 PM, Albert ARIBAUD wrote:
> Under option -munaligned-access, gcc can perform local char
> or 16-bit array initializations using misaligned native
> accesses which will throw a data abort exception. Fix files
> where these array initializations were unneeded, and for
> files known to contain such initializations, enforce gcc
> option -mno-unaligned-access.
> +++ b/doc/README.arm-unaligned-accesses
...
> +However this will only apply to the version of gcc which will have such
> +an option. For other versions, there are four workarounds:
> +
> +a) Enforce as a rule that array initializations as described above
> + are forbidden. This is generally not acceptable as they are valid,
> + and usual, C constructs. The only case where they could be rejected
> + is when they actually equate to a const char* declaration, i.e. the
> + array is initialized and never modified in the function's scope.
> +
> +b) Drop the requirement on unaligned accesses at least for ARMv7,
> + i.e. do not throw a data abort exception upon unaligned accesses.
> + But that will allow adding badly aligned code to U-Boot, only for
> + it to fail when re-used with another, more strict, target, possibly
> + once the bad code is already in mainline.
> +
> +c) Relax the -munified-access rule globally. This will prevent native
I assume that's meant to say -munaligned-access?
> + unaligned accesses of course, but that will also hide any bug caused
> + by a bad unaligned access, making it much harder to diagnose it. It
> + is actually what already happens when building ARM targets with a
> + pre-4.7 gcc, and it may actually already hide some bugs yet unseen
> + until the target gets compiled with m-unaligned-access.
s/m-/-m/
> +d) Relax the -munified-access rule only for for files susceptible to
I assume that's meant to say -munaligned-access?
> + the local initialized array issue. This minimizes the quantity of
> + code which can hide unwanted misaligned accesses.
> +
> +Considering the rarity of actual occurrences (as of this writing, 5
> +files out of 7840 in U-Boot, or .3%, contain an initialized local char
> +array which cannot actually be replaced with a const char*), detection
> +if the issue in patches should not be asked from contributors.
I assume therefore that option (d) was chosen. Perhaps state this
explicitly?
More information about the U-Boot
mailing list