On 8 June 2012 15:20, Hans-Peter Nilsson <[email protected]> wrote:
>> From: Michael Hope <[email protected]>
>> Date: Fri, 8 Jun 2012 04:42:30 +0200
>
>> On 8 June 2012 12:15, Hans-Peter Nilsson <[email protected]> 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?
ALIGNMENT_TRAP is on by default but the early boot time trap is now
conditional on the architecture level:
__enable_mmu:
#if defined(CONFIG_ALIGNMENT_TRAP) && __LINUX_ARM_ARCH__ < 6
orr r0, r0, #CR_A
#else
bic r0, r0, #CR_A
#endif
>> 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.
I mean direct access via helpers:
inline u16 get_u16(const char *p) {
#ifdef __ARM_FEATURE_UNALIGNED
return ntohs(*(const u16 *)p);
#else
...
}
...
u16 checksum = get_u16(buffer + CHECKSUM_OFFSET);
>> 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.
You're suggesting we disable an optimisation. The combination of
older Linux ARM kernels and GCC 4.7 gives a faulty kernel. In all
other cases it should be an improvement. Have you seen other
combinations where there's a fault when this feature is turned on?
-- Michael
