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? _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
