[U-Boot] [PATCH v2] arm: Switch to -mno-unaligned-access when supported by the compiler

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Tom,

On Mon, 10 Feb 2014 08:21:39 -0500, Tom Rini <trini@ti.com> wrote:

> On Mon, Feb 10, 2014 at 10:24:47AM +0100, Albert ARIBAUD wrote:
> > Hi Tom,
> > 
> > On Tue,  4 Feb 2014 12:05:33 -0500, Tom Rini <trini@ti.com> wrote:
> > 
> > > When we tell the compiler to optimize for ARMv7 it assumes a default of
> > > unaligned accesses being supported at the hardware level and can make
> > > use of this to perform what it deems as an optimization in any case,
> > > including allowing for data to become unaligned.  We explicitly disallow
> > > this hardware feature so we must tell the compiler.
> > > 
> > > Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
> > > Cc: Mans Rullgard <mans@mansr.com>
> > > Signed-off-by: Tom Rini <trini@ti.com>
> > 
> > NAK -- the discrepancy between the compiler being told to allow native
> > unaligned accesses while at the same time telling the hardware to trap
> > them is conscious and voluntary. It was chosen to help detect unaligned
> > accesses which are rarely necessary and can be explicitly performed by
> > software on a case by case basis.
> > 
> > If and when a specific file requires unaligned access which cannot be
> > made by some other mean than enabling -mno-unaligned-access, then this
> > file should have it added, not the whole of U-Boot.
> 
> Right, I recall the discussion, and we chose wrong.

I am quite prepared to discuss whether we chose wrong or right, and
to change my mind when the conditions are right, but I'll need more than
such a short and simple statement. :)

> We aren't being clever and making problems that would appear on armv5
> and lower (or non-ARM never allows unaligned access platforms) problems
> to appear on more common armv7 platforms.

Agreed that we are making problems appear on ARMv7 which are not that
much of an issue on ARMv7, but are a true issue on non-ARMv7 arches;
that *is* the intent. We want to know as early as possible when some
code which runs ok on unaligned-access-friendly platforms such as
ARMv7 might cause trouble on unaligned-access-adverse platforms later,
once it gets used there too.

>  We're telling the compiler it's OK to do
> one thing when it's not and then getting annoying problems such as the
> EFI partition one where the compiler looks at everything, says we can do
> $this and then fails at runtime because we lied to it. The whole
> splashguard set of options is another place where I believe we've shot
> ourselves in the foot, quite likely.

Ok, so the cause of this patch is not the apparent contradiction between
the compiler and hardware setting per se; it is that the EFI code has
issues which make it susceptible to crash on unaligned-access-adverse
platforms.

This means the trap has worked as expected and has caught some code
which does unaligned accesses. Let's analyze it: either we'll conclude
it can and should be fixed through e.g. ad hoc unaligned access macros
or we'll conclude it can't and we'll add -mno-unaligned-access to the
files which can't work otherwise.

Amicalement,
-- 
Albert.