[U-Boot] [PATCH] arm: armv7: add compile option -mno-unaligned-access if available

[Albert ARIBAUD]

Hi Mike,

On Thu, 19 Jul 2012 00:29:23 -0400, Mike Frysinger <vapier at gentoo.org> wrote:
> On Monday 02 July 2012 12:14:40 Måns Rullgård wrote:
> > It's slightly more complicated than that.  Data can be misaligned for a
> > variety of reasons:
> > 
> > 1. Errors in software.
> > 2. Specified by a file format or communication protocol.
> > 3. Deliberately misaligned by the compiler.
> > 
> > Misaligned data of type 1 should of course be fixed properly, not worked
> > around in any way.
> 
> it's also a reliability aspect.  people don't write bug free software, not bug 
> free protocols, nor bug free compilers.  when misalignment does happen in the 
> field, it's a hell of a lot better if the software continued to execute 
> correctly rather than randomly triggered an exception.
> -mike

Nitpick: this is robustness, not reliability.

That being said, yes, this robustness is desirable when you do not control all
of the SW running on the product; Linux, for instance, will have to execute
processes which were built with any old (or new) compiler settings, thus the
Linux folks have to make sure the kernel won't fail running those.

But the only uncontrolled SW U-Boot runs is its payload -- typically the
kernel image -- which are usually very cautious in what they assume they can
do, thus are unlikely to perform unaligned accesses.

(pasting your other comment)

> simply search the kernel for get_unaligned then.  there are plenty of examples 
> in there.  granted, many apply to stacks that don't show up in u-boot (yet?) 
> such as bluetooth, wireless, and irda, but i'm pretty sure TCP/IPv4 has a few 
> edge cases too.

I'll have a look, if only to lament that protocol are not what they used to be
in the old days. :)

Anyway: as I said: performing *controlled* unaligned accesses for external reasons
other than bugs is fine with me. Having our own get_unaligned() in such places
would be fine with me.
 
Amicalement,
-- 
Albert.