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

[Mike Frysinger]

On Thursday 19 July 2012 02:28:05 Albert ARIBAUD wrote:
> On Thu, 19 Jul 2012 00:29:23 -0400, Mike Frysinger 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.
> 
> Nitpick: this is robustness, not reliability.

useless pedantry: by increasing robustness, the system is more reliable

> 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.

it isn't just that.  there is no way you can guarantee both the linux kernel 
and u-boot code bases themselves are perfect.  in fact, it's even worse when 
these are the ones that get tripped up because it means your system 
resets/hardlocks/kills a kitten.  when doing driver development under the 
linux kernel, we would come across parts of core stacks that lacked alignment 
checking and would panic the system.  sometimes it would always panic, other 
times it depended on factors that made life worse: the compiler version (newer 
ones always like to pack/optimize better), the actual data stream, or the 
execution paths.

> > 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.

i have no problem adding put/get_unaligned() to all the right places.  that 
makes perfect sense.  but, as an orthogonal issue wrt ARMv7, i don't see any 
problem enabling hardware functionality: it increases robustness (:P), shrinks 
the code base (all the get/put unaligned macros expand into a single memory 
access as they no longer have to do alignment fixups in software), and speeds 
up the runtime (a single unaligned memory access is always faster than address 
masking/multiple loads/bit shifting/etc... -- obviously this ignores 
multimedia type code that does alignment adjustment at the start, then lets of 
memory accesses, then another adjustment at the end, but that's not what we're 
talking about here).

if you want to tell people that if they found an unaligned access in code they 
must fix that, then great.  make them fix it.  then once that bug has been fixed, 
let's merge the purely optimization patch that allows the hardware to do 
unaligned accesses.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120719/2ddfe667/attachment.pgp>