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

[Albert ARIBAUD]

Hi Mike,

On Thu, 19 Jul 2012 10:27:07 -0400, Mike Frysinger <vapier at gentoo.org> wrote:
> 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

Your description confirms that robustness and reliability are not equivalent,
thereby goes against your statement about pedantry... :)
 
> > 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.

Correct; here I was considering the requirements / operating conditions for both
projects, I was not considering development issues -- bugs during development
happen (morethan they do in the field, hopefully).

Do you mean you'd like to catch misalignments as early as possible, and would
like to have both -munaligned-access and A=1 during dev?
 
> > > 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).

I wouldn't care about the ARMv7 implementing explicit unaligned accesses with
native instructions if it didn't mean it won't catch unwanted unaligned accesses
any more, and thus such unalignments will be found in another context and will
take some more time to trace back.  

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

My problem is that as long as people start configuring their HW and compiler to
not care about unaligned accesses, they *won't* find such accesses when accidental,
because nothing will tell them.

Here's my suggestion: when building U-Boot as usual, strict aligment policy is
enforced, i.e. -mno-unaligned-access and A=1, and for platforms that could benefit
from native unaligned accesses, a run-time warning is emitted on the console.
However, with a specific command 'PRODUCTION' line option added, the constraint
is relaxed, i.e. -munaligned-access and A=0, no run-time message, but a build
warning is emitted stating that this build is afoul of the U-Boot strict policy.

This way, you get the robustness you want as you can easily build an ARMv7-
efficient binary, and I get the one I want as the build used for development is
slightly less MCPS-efficient but will catch potential issues.

Comments welcome.

> -mike

Amicalement,
-- 
Albert.