> From: Michael Hope <michael.h...@linaro.org> > Date: Fri, 8 Jun 2012 04:42:30 +0200
> On 8 June 2012 12:15, Hans-Peter Nilsson <hans-peter.nils...@axis.com> wrote: > > 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. So the default for ALIGNMENT_TRAP changed in >3.1? > 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. Totally disagree. Code that e.g. casts unaligned char * to int * and dereferences that, is crappy and unportable and fails without OS-configury choice on some platforms, and is also avoidable. But hopefully that wasn't what you meant. > Where else have you seen this? I don't get the "else". I've seen the unaligned accesses from userland code as quoted above. There were other (userland) places in that build-tree that I'm not going to check, as this was (again) GCC-generated code. There were no other misaligned accesses on that system; not from the kernel, not from userspace. > > + <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" I'll let an ARM maintainer sort out the names and color for the toolshed; ARMv6K isn't an obvious improvement to me over the names used in the patch introducing -munaligned-access. > > 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. In arch/arm/Kconfig it looks for all purposes default "on" to me (config ALIGNMENT_TRAP, 2.6.35): "default y if !ARCH_EBSA110" where ARCH_EBSA110 seems to be for some "evaluation board from Digital". brgds, H-P
