On 16/10/15 16:28, Sandra Loosemore wrote: > Recently I tracked down a target crash problem in an ARM EABI configuration > running on a Cortex-A9 board to an unaligned access fault. The startup code > provided by the customer for this board doesn't enable the MMU, and unaligned > access support requires the MMU to be enabled per > > http://infocenter.arm.com/help/topic/com.arm.doc.faqs/ka13671.html > > The GCC manual presently says "By default unaligned access is disabled for > all pre-ARMv6 and all ARMv6-M architectures, and enabled for all other > architectures." I think it would be safer for GCC to default to > -maligned-access only in configurations that are known also to enable the > MMU, e.g. GNU/Linux. Code being built for bare-metal ARM EABI targets > typically includes low-level startup code and boot loaders that run before > the MMU is enabled, and likewise I don't think RTEMS, uCLinux, etc imply MMU > support, either. > > We could tell all ARM EABI users to build with -mno-unaligned-access, but if > multilibs for (say) -march=armv7-a are being provided then those must also be > built with the "safe" setting to avoid crashes in e.g. the Newlib memcpy > implementation. I think it would be more user-friendly just to change the > default.
> > ARM maintainers, WDYT? I will work up and test a patch if there is agreement > that this is a reasonable thing to do. I am not in favour of changing the defaults for arm-none-eabi as I think this is a regression for users of the GNU toolchain. You may be aware of some startup code in libgloss that ARM contributed which can help with such initialization of the MMU and as you say a number of the newlib routines are written to assume unaligned access is available. If the toolchain is built to include libgloss you can get support for this by using an appropriate specs file. We use this for testing with semi-hosting support on simulators internally. https://sourceware.org/ml/newlib/2013/msg00712.html https://sourceware.org/ml/newlib/2013/msg00752.html regards Ramana > > -Sandra >
